Misplaced Pages

Revision as of 09:55, 6 November 2012

The Data Distribution Service for Real-Time Systems (DDS) is an Object Management Group (OMG) Publish/Subscribe (P/S) standard that aims to enable scalable, real-time, dependable, high performance and interoperable data exchanges between publishers and subscribers. DDS is designed to address the needs of mission- and business-critical applications like financial trading, air traffic control, smart grid management, and other big data applications. A goal of DDS is to set itself apart from messaging technologies and standards by defining distinct sets of functional and non-functional requirements.

History

A few proprietary DDS solutions had been available for several years. Starting in 2001, two major DDS vendors, the American group Real-Time Innovations and the French Thales Group teamed up to create the DDS specification which was subsequently approved by the Object Management Group resulting in Version 1.0 in 2003.

Version History

• DDS 1.3 — Working version, OMG members only.
• DDS 1.2 (January 1, 2007)
• DDS 1.1 (December 4, 2005)
• DDS 1.0 (June 1, 2003)

The DDS specification describes two levels of interfaces:

• A lower DCPS (Data-centric publish-subscribe) level that is targeted towards the efficient delivery of the proper information to the proper recipients.

• An optional higher DLRL (data local reconstruction layer) level, which allows for a simple integration of DDS into the application layer.

DDS architecture

DDS entities

• DomainParticipantFactory: A singleton factory that is the main entry point to DDS.
• DomainParticipant: Entry point for the communication in a specific domain; it represents the participation of an application in one DDS Domain. Furthermore, it acts as a factory for the creation of DDS Publishers, Subscribers, Topics, MultiTopics and ContentFilteredTopics.
• TopicDescription: Abstract base class for Topic, ContentFilteredTopic and MultiTopic.
• Topic: A specialization of TopicDescription that is the most basic description of the data to be published and subscribed.
• ContentFilteredTopic: A specialized TopicDescription like the Topic that additionally allows content-based subscriptions.
• MultiTopic: A specialization of TopicDescription like the Topic that additionally allows subscriptions to combine/filter/rearrange data coming from several topics.
• Publisher: A Publisher is the object responsible for the actual dissemination of publications.
• DataWriter: Allows the application to set the value of the data to be published under a given Topic.
• Subscriber: A Subscriber is the object responsible for the actual reception of the data resulting from its subscriptions.
• DataReader: A DataReader allows the application to declare the data it wishes to receive (by making a subscription using a Topic, ContentFilteredTopic or MultiTopic) and to access the data received by the attached Subscriber.

DDS model

DDS is networking middleware that simplifies complex network programming. It implements a publish/subscribe model for sending and receiving data, events, and commands among the nodes. Nodes that are producing information (publishers) create "topics" (e.g., temperature, location, pressure) and publish "samples." DDS takes care of delivering the sample to all subscribers that declare an interest in that topic.

DDS handles all the transfer chores: message addressing, data marshalling and demarshalling (so subscribers can be on different platforms than the publisher), delivery, flow control, retries, etc. Any node can be a publisher, subscriber, or both simultaneously.

The DDS publish-subscribe model virtually eliminates complex network programming for distributed applications.

DDS supports mechanisms that go beyond the basic publish-subscribe model. The key benefit is that applications that use DDS for their communications are entirely decoupled. Very little design time has to be spent on how to handle their mutual interactions. In particular, the applications never need information about the other participating applications, including their existence or locations. DDS automatically handles all aspects of message delivery, without requiring any intervention from the user applications, including:

• determining who should receive the messages,
• where recipients are located,
• what happens if messages cannot be delivered.

This is made possible by the fact that DDS allows the user to specify Quality of Service (QoS) parameters as a way to configure automatic-discovery mechanisms and specify the behavior used when sending and receiving messages. The mechanisms are configured up-front and require no further effort on the user's part. By exchanging messages in a completely anonymous manner, DDS greatly simplifies distributed application design and encourages modular, well-structured programs.

DDS automatically handles hot-swapping redundant publishers if the primary fails. Subscribers always get the sample with the highest priority whose data is still valid (that is, whose publisher-specified validity period has not expired). It also automatically switches back to a just-recovered primary.

Implementations

See also

• Middleware
• Open architecture computing environment

References

• Object Management Group (OMG) (the standards body that developed the DDS specification)
• Catalog of DDS Specifications
• Vendors list by OMG

External links

• The OMG DDS portal
• RTI Connext DDS commercial implementation
• RTI DDS open community source implementation
• PrismTech OpenSplice DDS commercial implementation
• PrismTech OpenSplice DDS open source implementation
• Kongsberg Gallium's InterCOM DDS commercial implementation
• Twin Oaks Computing's CoreDX commercial DDS implementation
• OCI's OpenDDS open source DDS implementation
• MilSOFT commercial implementation
• PocoCapsule for DDS A framework for component-based CORBA and DDS applications.
• Sparx DDS UML implementation
• Sistemi Software Integrati's BEE DDS commercial implementation
• Presentations and Papers on DDS

• Message-oriented middleware