PolyORB is a deprecated product. It will be baselined with the GNAT Pro release 28. After this release, there will be no new versions of this product. Contact your sales representative or send a message to sales@adacore.com to get recommendations for replacements.”
Sad to say but Polyorb is now officially dead. This leaves Ada without any DSA support, which hits home for me at least, since several of my projects rely heavily on DSA. I’ve been using Polyorb since it’s inception, when it used customised Makefiles instead of po_gnatdist. So many, many years of wasted development.
I had thought, if this happened, it might be possible to fork Polyorb, strip it down to only the DSA personality and continue to maintain it. However, I doubt this is feasible and am pretty certain I lack the skill. It would take a 1/2 dozen or so dedicated developers with enough time on their hands, at least.
Seems a shame DSA is only an annex and not a part of the core Ada spec but I expect that would impose too heavy a burden on compiler developers who have to cope with what is already a very complex, yet magnificent, language.
It seems ARG is aware more work is needed in the distributed area.
Perhaps the following can give you some peace of mind.
Better support for heterogeneous and distributed environments
Modern computing often involves systems of various architectures, connected either with shared memory or over a high-speed bus. Ada’s Distributed System Annex is one approach, but has not been widely implemented nor used. A “building block” approach might be one alternative way to support heterogeneous and distributed systems. This is clearly related to the above item related to representing arbitrary types in some sort of stream representation.
It would be helpful to create an ARG GitHub Issue about distributed systems support in Ada going forward, and try to capture the pros and cons of the DSA approach. Please feel free to create the issue here: GitHub · Where software is built
Well, CORBA etc was a wrong design from the start. IDL and tight coupling have very limited use in practice when a distributed system is rather flexible with nodes and objects come and go. Synchronous data transfer (RPC) is too heavy burden and too slow.
In our commercial product (100% Ada) we used a dynamically linked data distribution layer, no RPC, configurable push/poll etc.
As for distributed annex one could bring up an implementation of it in a few hours backed by some transport if the annex were specified in a usable way. Unfortunately, at least in GNAT, it is buried in a predefined package which is not replaceable (System.RPC), last time I tried. Furthermore, it seems that you cannot have several implementations of the annex, e.g. backed by different transport layers and there is no way to specify quality of service.
Could you describe your system from an API point of view? If some sort of new “distributed” annex API were to be standardized, what would you recommend?
It is a middleware. In the API it is viewed as a set of variables accessed with Get, Set, Request, Send. The latter two are to be performed by the hardware. There are further services for creating, waiting, monitoring, enumeration etc. Network is just a “hardware” like CAN, EtherCAT, ModBus etc. When a network variable it is sent the operation is performed remotely and the effect is propagated back asynchronously depending on the QoS settings.
I do not think a middleware should be in the standard.
Distributed annex is more general because it works with all object and all calls. What it lacks: discovery/browsing, dynamic binding, QoS, notification services and an ability to have multiple transports.
Dynamic bindings and asynchronous I/O are interesting challenge. In the middleware each variable has a status. So when a remote host is out the status indicates that. For Ada objects we have no such thing (X’Valid?). Furthermore middleware has a built-in set of types. Distributed annex must work with any type, thus a kind of introspection is required. E.g. if an object is mapped the remote host must check the type/arguments.
It looks like too much work. So maybe leaving it static but allowing transport specification and QoS would be more realistic.
Interesting. One could generalize it with some enumeration type rather than Boolean.
In the middleware among health (status) there is also the timestamp associated with the value and historic values. Both are used for consistency, e.g. to avoid race condition when variable are updated asynchronously.