From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED.3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: polyorb Date: Tue, 13 Aug 2019 12:09:21 +0200 Organization: Aioe.org NNTP Server Message-ID: References: <66682a4f-33ef-4ee8-a611-8899dcc23703@googlegroups.com> <87aa92f3-eceb-4021-b36c-cf9f1837242a@googlegroups.com> <34cf9e20-756f-4cb5-8f5e-de7821704745@googlegroups.com> <7682ca22-c220-44be-ad66-9b814556e06f@googlegroups.com> NNTP-Posting-Host: 3d73Ybk3C5U4I2t8lv+lAQ.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.8.0 X-Notice: Filtered by postfilter v. 0.9.2 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:57047 Date: 2019-08-13T12:09:21+02:00 List-Id: On 2019-08-13 10:13, tonyg wrote: > The flexibility from the DSA comes from the rigidity of the types used across the partitions. This being a natural amplification from the ada language. Annex E is intended and good for tightly coupled static systems, e.g. a network of engine control units of a car. In a loosely coupled system with nodes going on and off, changing or only modifying their roles and services, RPCs and types known prior to start is not a good choice. Another problem with RPC is that synchronous calls are utterly inefficient and slow. For a real-time system with a time-triggered transport calculated for the worst-case scenario this is no problem. But for most practical applications the load is unpredictable and millisecond accumulating latencies is not an option. Regarding types, there were many attempts to bring some sort of abstract types and even OO to distributed systems, they all failed (CORBA, ASN.1 included). This is why data distribution layers stick to some fixed set of primitive types leaving to the application to build upon them. Many have no types at all, only messages (e.g. MQTT). It is not nice but it works. IMO, annex E's remote types was a good start. But there is a lot of work required to make it full OO, to defining QoS things making it usable in loosely coupled applications. I also think that current work on new concurrent programming primitives is wasting time. It must be invested into annex E which should serve both concurrent and distributed programming. The difference between a distributed and a multiple core system is not that dramatic (and shared memory architectures will likely die in some future anyway). > I have found it in action, very resiliant, one time when the connection was interrupted between two nodes by a server room fire, both nodes merrily carried on and updated nicely swapping all the stored information once the server inbetween was replaced. **true story :) ** Well that is certainly some application layer stuff that did the replication, not the annex E. It has no idea about the deeper states (no pun intended (:-)) of partitions. -- Regards, Dmitry A. Kazakov http://www.dmitry-kazakov.de