Responding to Status Changes
Each DDS entity is associated with a set of Status objects, whose value can be updated by the the get_*_status() methods on the entity. An application can poll for status changes, install listeners to be automatically notified by the middleware upon status changes, or wait on condition variable that gets triggered upon specific status changes.
The application can respond to specific status changes of interest. For example, the application can be notified when a DataWriter is no longer active or its liveliness is changed; or when another topic exists with the same name but different characteristics; or when a QosPolicy value was incompatible with what is offered; or when a deadline was missed; or when a new DataReader (or DataWriter) matching a Topic is discovered; or when data is available; or when samples are lost or rejected.
The application response to status changes can be tuned on a per entity instance basis.
Probing Further
We have looked at the key features of the OMG DDS specification, and highlighted some of the key QosPolicies and Status available for DDS entities.
Other QoS parameters control when the middleware detects nodes that have failed, suggest latency budgets, set delivery order, attach user data, prioritize messages, set resource utilization limits, partition the system into namespaces, and more.
DDS can also support content-based subscriptions. An application can use a ContentFilteredTopic to declare a filter expression by which only selected data samples of the specified Topic would be received and presented to the application. For example, an "alarm" application could setup DataReaders to only receive samples when a temperature exceeded a certain threshold.
DDS also supports a MultiTopic construct, which specifies a logical grouping of several Topics. It allows an application to select fields from multiple types and recombine them into a new type. As a large application evolves, MultiTopics can be a powerful tool: the data types used within a subsystem may change, but the contents of those new types can be recombined to look like the old types, preserving the interface between subsystems.
Conclusion
The Data Distribution Service is a OMG specification that creates a very simple architecture for data communication, while enabling very complex data patterns. Topics allow endpoint nodes to be abstracted from each other, so nodes can enter and leave the distributed application dynamically. The QoS parameters can be changed on a per entity basis. This per entity configurability is the key to supporting complex data communication patterns. The DDS API for sending and receiving data frees developers from having to worry about any low-level network programming.
References
Data Distribution Service (OMG document ptc/200403-07).
Catalog of OMG IDL / Language Mappings Specifications
Rajive Joshi and Gerardo Pardo-Castellote: "A Comparison and Mapping of Data Distribution Service and High-Level Architecture", Paper Id 03F-SIW-68, 2003 Fall Simulation Interoperability Workshop, Fall 2003.
Gerardo Pardo-Castellote: "OMG Data Distribution Service: Architectural overview", IEEE International Conference on Distributed Computing Systems, 2003.
Stan Schneider and Bert Farabaugh: "Is DDS for You?"
Data Distribution Service Resources
RAJIVE JOSHI, Ph.D. is a Principal Engineer at Real-Time Innovations (RTI) Inc. Dr. Joshi specializes in object-oriented and component-based software architecture and design. He is responsible for the DDS C++ API and the pluggable transports framework in RTI's NDDS product which implements the DDS specification. He can be reached at [email protected].
GERARDO PARDO-CASTELLOTE, Ph.D. is the Chief Technology Officer at RTI. Dr. Pardo-Castellote specializes in Real-Time software architectures and networking. His professional experience includes time-critical software for data acquisition and processing, real-time planning and scheduling software, control system software, and software-system design. He can be reached at [email protected].
