Rahul Sharma (Editor)

Data Distribution Service

Updated on
Edit
Like
Comment
Share on FacebookTweet on TwitterShare on LinkedInShare on Reddit
Data Distribution Service

The Data Distribution Service for real-time systems (DDS) is an Object Management Group (OMG) machine-to-machine (sometimes called middleware) standard that aims to enable scalable, real-time, dependable, high-performance and interoperable data exchanges using a publish–subscribe pattern. DDS addresses the needs of applications like financial trading, air-traffic control, smart grid management, and other big data applications. The standard is used in applications such as smartphone operating systems, transportation systems and vehicles, software-defined radio, and by healthcare providers. DDS was promoted for use in the Internet of things.

Contents

History

A few proprietary DDS systems had been available for several years. Starting in 2001, two vendors, the US government contractor Real-Time Innovations and the French Thales Group teamed up to create the DDS specification, which was subsequently approved by the Object Management Group (OMG) resulting in version 1.0 in published in December 2004. Version 1.1 was published in December 2005, 1.2 in January 2007, and 1.4 in April 2015. DDS is covered by several US patents, among others.

The DDS specification describes two levels of interfaces:

  • A lower data-centric publish-subscribe (DCPS) level that is targeted towards the efficient delivery of the proper information to the proper recipients.
  • An optional higher data local reconstruction layer (DLRL), which allows for a simple integration of DDS into the application layer.
  • Other related standards followed the initial core document. The Real-time Publish-Subscribe Wire Protocol DDS Interoperability Wire Protocol Specification ensured that information published on a topic using one vendor's DDS implementation is consumable by one or more subscribers using the same or different vendor's DDS implementations. Although the specification is targeted at the DDS community, its use is not limited. Versions 2.0 was published in April 2008, version 2.1 in November 2010, and 2.2 in September 2014.

    DDS for Lightweight CCM (dds4ccm) offers an architectural pattern that separates the business logic from the non-functional properties. A 2012 extension added support for streams. A Java 5 Language PSM for DDS defined a Java 5 language binding, referred to as a Platform Specific Model (PSM) for DDS. It specified only the Data-Centric Publish-Subscribe (DCPS) portion of the DDS specification; Additionally, it encompasses the DDS APIs introduced by DDS-XTypes and DDS-CCM. DDS-PSM-Cxx defines the ISO/IEC C++ PSM language binding, referred to as a Platform Specific Model (PSM) for DDS. It provides a new C++ API for programming DDS that is more natural to a C++ programmer. The specification provides mappings for the application programming interface (API) specified in DDS-XTypes, and accessing quality of service (QoS) profiles specified in DDS-CCM.

    Extensible and Dynamic Topic Types for DDS (DDS-XTypes) provided support for data-centric publish-subscribe communication where topics are defined with specific data structures. To be extensible, DDS topics use data types defined before compile time and used throughout the DDS global data space. This model is desirable when static type checking is useful. A Unified Modeling Language (UML) profile specified DDS domains and topics to be part of analysis and design modeling. This specification also defined how to publish and subscribe objects without first describing the types in another language, such as XML or OMG IDL. An interface definition language (IDL) was specified in 2014 independently from the Common Object Request Broker Architecture (CORBA) specification chapter 3. This IDL 3.5 was compatible with the CORBA 3 specification, but extracted as its own specification so that it can evolve independently from CORBA.

    Starting with DDS version 1.4 in 2015, the optional DLRL layer was moved to a separate specification.

    Model

    DDS is networking middleware that simplifies complex network programming. It implements a publish–subscribe pattern for sending and receiving data, events, and commands among the nodes. Nodes that produce information (publishers) create "topics" (e.g., temperature, location, pressure) and publish "samples". DDS delivers the samples to subscribers that declare an interest in that topic.

    DDS handles transfer chores: message addressing, data marshalling and demarshalling (so subscribers can be on different platforms from 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 decoupled. Little design time need be spent on handling their mutual interactions. In particular, the applications never need information about the other participating applications, including their existence or locations. DDS transparently handles message delivery without requiring intervention from the user applications, including:

  • determining who should receive the messages
  • where recipients are located
  • what happens if messages cannot be delivered
  • DDS allows the user to specify quality of service (QoS) parameters to configure discovery and behavior mechanisms up-front. By exchanging messages anonymously, DDS simplifies distributed applications and encourages modular, well-structured programs. DDS also 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 automatically switches back to the primary when it recovers, too.

    Interoperability

    Both commercial and open-source software implementations of DDS are available. These include application programming interfaces (APIs) and libraries of implementations in Ada, C, C++, C#, Java, Scala, Lua, Pharo and Ruby. Some implementations are shown in the table at the end of this article.

    DDS vendors participated in interoperability demonstrations at the OMG Spring technical meetings from 2009 to 2013.

    During demos, each vendor published and subscribed to each other's topics using a test suite called the shapes demo. For example, one vendor publishes information about a shape and the other vendors can subscribe to the topic and display the results on their own shapes display. Each vendor takes turns publishing the information and the other subscribe. Two things made the demos possible: the DDS-I or Real-Time Publish-Subscribe (RTPS) protocol, and the agreement to use a common model.

    In March 2009, three vendors (Real-Time Innovations, Inc., PrismTech and Twin Oaks) demonstrated interoperability between the individual, independent products that implemented the OMG Real-time Publish-Subscribe protocol version 2.1 from January 2009. The demonstration included the discovery of each other's publishers and subscribers on different OS Platforms (Microsoft Windows and Linux) and supported multicast and unicast network communications.

    By March 2013, six more companies joined the interoperability demonstration: Object Computing Inc. (OCI, OpenDDS), Electronics and Telecommunications Research Institute (ETRI), IBM, Kongsberg, Milsoft, and RemedyIT.

    The DDS interoperability demonstration used scenarios such as:

  • Basic connectivity to network using Internet Protocol (IP)
  • Discovery of publishers and subscribers
  • Quality of service (QoS) Compatibility between requester and offerer
  • Delay-tolerant networking
  • Multiple topics and instances of topics
  • Exclusive ownerships of topics
  • Content filtering of topic data including time and geographic
  • References

    Data Distribution Service Wikipedia