Channels ▼
RSS

Design

OMG's Data Distribution Service Standard


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 rajive@rti.com.

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 pardo@rti.com.


Related Reading


More Insights






Currently we allow the following HTML tags in comments:

Single tags

These tags can be used alone and don't need an ending tag.

<br> Defines a single line break

<hr> Defines a horizontal line

Matching tags

These require an ending tag - e.g. <i>italic text</i>

<a> Defines an anchor

<b> Defines bold text

<big> Defines big text

<blockquote> Defines a long quotation

<caption> Defines a table caption

<cite> Defines a citation

<code> Defines computer code text

<em> Defines emphasized text

<fieldset> Defines a border around elements in a form

<h1> This is heading 1

<h2> This is heading 2

<h3> This is heading 3

<h4> This is heading 4

<h5> This is heading 5

<h6> This is heading 6

<i> Defines italic text

<p> Defines a paragraph

<pre> Defines preformatted text

<q> Defines a short quotation

<samp> Defines sample computer code text

<small> Defines small text

<span> Defines a section in a document

<s> Defines strikethrough text

<strike> Defines strikethrough text

<strong> Defines strong text

<sub> Defines subscripted text

<sup> Defines superscripted text

<u> Defines underlined text

Dr. Dobb's encourages readers to engage in spirited, healthy debate, including taking us to task. However, Dr. Dobb's moderates all comments posted to our site, and reserves the right to modify or remove any content that it determines to be derogatory, offensive, inflammatory, vulgar, irrelevant/off-topic, racist or obvious marketing or spam. Dr. Dobb's further reserves the right to disable the profile of any commenter participating in said activities.

 
Disqus Tips To upload an avatar photo, first complete your Disqus profile. | View the list of supported HTML tags you can use to style comments. | Please read our commenting policy.
 

Video