In the context of a complex distributed application with pieces contributed by several vendors or development groups, how would one evolve a DDS application in a backwards-compatible way, that does not require all pieces to be upgraded at once?
With an object-oriented middleware like CORBA one can introduce an enhanced version by creating a derived interface. Other programs that know only the old version (base interface) can interoperate with the new application.
It seems to enhance a DDS publisher in a backwards-compatible fashion it would need to publish two separate topics, the unchanged old topic and an extension topic with new attributes. Successive enhancements would result in more and more slices, which is not great in terms of application design, and probably impacts performance too.
Or would one publish the old topic and a complete new topic, which includes the old attributes, in parallel?
Are there better ways to do this? At first glance the MultiTopic idea looked like a way to simulate the old topic for old subscribers, but this would require changing the subscribers.
I guess you will need to wait a while for the implementation of this spec to become available in the various DDS products lines. Until then you could split up the various evolutions stages of your data model into separate topics (modeling each extension into a separate extension topic using similar key fields as its parent), and merge them back to one coherent type on the receiver side. (DDS products that support DLRL or MultiTopic could help you automate your merging effort).
An alternative approach when you do not want to do merging on the receiver side is to make a complete topic representation of each evolution (a topic for evolution phase 1, a separate topic containing phase 1 + its extension in phase 2, etc.). The publisher will then need to publish all these different topics in parallel, with consumes much more bandwith because of the overlap in the different topic payloads.
Both approaches are valid: your system constraints could determine which one is better suitable for you.
To wet your appetite, in the "Extensible and Dynamic Topic Types" we've introduced a new type-system in DDS. The new type system is structural (a la Modula-3) and allows you to cope with types extensibility and evolvability.
This specification was designed to ensure that the information model of long lively systems can be evolved without the need of "all-at-once" upgrades.
Furthermore, this flexibility comes without compromising temporal or spatial efficiency and while maintaing a sound type-system.
Finally, something else the spec introduced is a dynamic API that allows you create data-readers/data-writers for types for which the application does not have compile time knowledge.