Re: On intended use cases of the distributed annex

[Brad Moore <brad.moore@shaw.ca>]

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