Evolving a distributed application wi... PreviousNext
Data Distribution Service (DDS) Forum > DDS Technical Forum >
Message/Author
Next message Joachim Achtzehnter  posted on Tuesday, April 27, 2010 - 09:49 pm
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.

Thanks,

Joachim
Next message Erik Hendriks  posted on Thursday, April 29, 2010 - 10:11 am
Hi Joachim,

There is a new initiative within the OMG that is called 'Extensible Topics' which addresses your concerns exactly. (See for example http://www.omgwiki.org/dds/content/news/omg-architecture-board-endorses-extensib le-topics-dds-specification).

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.

Regards,
Erik.
Next message Joachim Achtzehnter  posted on Friday, April 30, 2010 - 12:37 am
Thanks Erik!

Good to see that this issue is being addressed. The actual documents are currently only accessible to OMG members. Are public draft versions available somewhere?

Thanks,

Joachim
Next message Angelo Corsaro  posted on Friday, April 30, 2010 - 10:20 pm
Hello Joachim,

The spec has actually been voted during the last OMG meeting. It should be soon publicly available at:

http://www.omg.org/techprocess/meetings/schedule/DDS-XTypes.html#Beta_1_Specific ation_Publication

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.

Cheers,
Angelo
Back to top
Add Your Message Here
Post:
Username: Posting Information:
This is a private posting area. Only registered users and moderators may post messages here.
Password:
Options: Post as "Anonymous"
Enable HTML code in message
Automatically activate URLs in message
Action: