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: border2.nntp.dca1.giganews.com!nntp.giganews.com!usenet.blueworldhosting.com!feeder01.blueworldhosting.com!peer02.iad.highwinds-media.com!news.highwinds-media.com!feed-me.highwinds-media.com!post02.iad.highwinds-media.com!fx18.iad.POSTED!not-for-mail From: Brad Moore User-Agent: Mozilla/5.0 (X11; Linux x86_64; rv:24.0) Gecko/20100101 Thunderbird/24.5.0 MIME-Version: 1.0 Newsgroups: comp.lang.ada Subject: Re: On intended use cases of the distributed annex References: <20a06909-d123-4c51-8185-057d50e50186@googlegroups.com> <2fe842c3-1e5c-4fd7-89be-515e86c8aeb4@googlegroups.com> <839d7364-8e5d-4273-bd96-d4452e2dc817@googlegroups.com> In-Reply-To: <839d7364-8e5d-4273-bd96-d4452e2dc817@googlegroups.com> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 8bit Message-ID: NNTP-Posting-Host: 68.145.219.148 X-Complaints-To: internet.abuse@sjrb.ca X-Trace: 1412055889 68.145.219.148 (Tue, 30 Sep 2014 05:44:49 UTC) NNTP-Posting-Date: Tue, 30 Sep 2014 05:44:49 UTC Date: Mon, 29 Sep 2014 23:44:49 -0600 X-Received-Bytes: 8563 X-Received-Body-CRC: 2005891297 X-Original-Bytes: 8481 Xref: number.nntp.dca.giganews.com comp.lang.ada:189248 Date: 2014-09-29T23:44:49-06:00 List-Id: On 14-09-26 01:36 AM, Maciej Sobczak wrote: > W dniu czwartek, 25 września 2014 17:02:07 UTC+2 użytkownik Brad Moore napisał: > >> Not quite true that all the nodes need to be written in Ada. I have >> used DSA to send C++ objects to C++ applications (or at least objects of >> C++ classes that are derived from Ada types), and as well had C++ >> applications remotely interacting with each other C++ and other Ada >> applications using the DSA. > > This sounds interesting. Can you give a bit more details on this? Sure, I wrote a paper back in 2008 describing this, which you can download here. http://sourceforge.net/projects/dequesterity/files/RemoteBuffers.pdf/download The paper grew out of the buffer work that eventually became the dequesterity project, which is the underlying buffer abstraction I was working on. I still have the source code for the distributed demo system, but that is not currently available on any public site, since it is too limited and specific of an application to be generally useful, other than perhaps providing a base for new design. The distributed monitoring application demo evolved out of my interest in distributed systems. I built a working demo of the concept, where one could monitor and control any number of remote nodes. I did have some nodes compiled under Linux, and others compiled under Windows, and the nodes could communicate with each other. Was it related to the DSA implementation that actually used CORBA under the hood? The original version used the DSA implementation called Glade I think which did not involve CORBA. Later, I integrated the PolyORB version, which was pretty new at the time, and utilized CORBA. Was it necessary to extract some interface definition files from Ada specs? I basically defined C++ classes, and mirroring Ada specs as Tagged types. The C++ code used the C++ classes, but made calls to Ada servers with exported C/C++ function calls, which knew how to marshal the C++ classes. The code involved a message factory which could create objects of different types in the class hierarchy, which could be passed into a C/C++ application code. Although I did not try this, Java supposedly also could be used since the GCC compiler uses the same binary API for the different languages. > Or did you just reverse-engineered the DSA wire protocol that was in use? I didn't look at the DSA wire protocol. One thing I wanted to do however was distribute the nodes to each other without there having to be a central server. My initial implementation had a central server, which was an RCI Ada package, but I moved to a peer to peer type system. I distributed the Remote Access to Class Wide Type objects to other peers using my own multicast messaging approach. Once the nodes had discovered each other, they could make calls to the RACW remote pointers directly, which was pretty cool. That was the one major limitation I found with the DSA, was that it didn't directly support multicast communications, however I was able to work around this. It think that could be an area of improvement for DSA, to provide some sort of group broadcast/discovery. > Was your solution immune to compiler upgrades? I'd say not completely immune, but I did switch from Glade to PolyORB relatively painlessly, which was a completely different implementation. I don't think I needed to make any changes to my code. I only needed to configure the underlying DSA differently. The idea of the DSA is that the Ada code should be decoupled from the underlying DSA implementation. > And so on - lot's of questions. :-) > >> I also appreciate that the DSA is more closely integrated with the >> compiler, allowing the compiler to check and catch problems that a >> library only approach does not provide. > > Was it also closely integrated with the C++ nodes? ;-) I'm not sure I understand your question. I think the C++ code was not as closely integrated, to be expected, since C++ generally does not provide as much checking as an Ada compiler, and the C++ compiler does not have the same semantic knowledge of the Ada compiler and vice versa. But the C++ classes worked pretty much as expected for the C++ code. > > The "close integration with the compiler" makes most sense when there is a single build process for all the nodes. True. All the applications that talk to each other are compiled at the same time in my case. Although, as I mentioned, I had nodes communicating between OS'es, (Windows and Linux), so for that scenario, the compilations would have been separate. I think separate compilation could work in other cases, but if any of the distributed object classes are modified, I think all the applications that pass there objects around would need to be recompiled. Otherwise there is no guarantee that individual nodes are compiled with the same specs and the whole notion of static type safety goes down the drain. With the DSA there are mechanism's to at least check the consistency of the system. Eg. P'Version, and P'Body_Version in RM E.3, although I never experimented with these. I think it would be difficult to change the object structures of distributed classes, and have out of date nodes be expected to still work. Probably someone might be able to devise some sort of introspection mechanism, but that's far beyond what I was trying to do. Some sort of dynamic typing system such as the one described in your link below could be helpful here. This is particularly relevant in bigger systems where distinct nodes are developed by different teams and/or are deployed at different time schedules. More on this here: I can see how large systems and teams can make changes difficult or messy. I've seen large deployments that have tried different approaches. 1) Replace everything at the same time. Can be very difficult, because the upgrade can take a significant amount of time, which might be too long to go without a working system. This is likely not an option for many large systems. 2) Replace parts of the system. In this case, backwards compatibility is very important. Often its better to create a new API for new stuff and keep the old one in place until it can be fully deprecated, if ever. The example of HTML is a good one here, which basically follows case 2. New features can be added to HTML and newer versions of HTML, but they had better not break the support for earlier versions of HTML. Another example is SNMP. Once an SNMP interface is defined, and distributed for use in a large deployment. It usually means the existing API's cannot be changed, and any new changes are typically brought in, in the form of new API's. > > http://www.inspirel.com/articles/What_Is_Wrong_With_IDL.html > > Still, I'm very much interested in your Ada/C++ integration over DSA. > I'd be happy to answer any other questions you might have. For future work, I was always interested in RM E.5 (24.1-24.2) and other paragraphs in the same section that suggest that the user could supply their own PCS system to replace the compilers version. I don't know how easy this would be to do, and I am not aware of anyone who has tried to do this, but I recognize that different applications may have needs for specific protocols for specific networks that may be outside the ones provided by the implementation. Brad