Design
OMG's Data Distribution Service Standard
By Rajive Joshi and Gerardo Pardo,Castellote, November 20, 2006
The OMG Data Distribution Service (DDS) Standard specifies a mandatory API for data-centric publish-subscribe
The DDS Communication Model
Data Centric Publish-Subscribe
The DDS publish-subscribe model connects anonymous information producers (publishers) with information consumers (subscribers). A distributed application is composed of processes called "participants", each running in a separate address space, possibly on different computers. A participant may simultaneously publish and subscribe to typed data-flows identified by names called "Topics". The interface allows publishers and subscribers to present type-safe API interfaces to the application.
The typical DDS application architecture can be represented as a "data-flow bus" as in Figure 1. The data model means you can essentially ignore the complexity of the data flow; each node gets the data it needs from the bus. The communications are decoupled in space (nodes can be anywhere), time (delivery may be immediately after publication or later), and flow (delivery may be reliably made at controlled bandwidth).
Strongly Typed Global Data Space
Participants using DDS can read/write data efficiently and naturally with a typed interface. Underneath, the DDS middleware will distribute the data so that each reading participant can access the "most-current" values. In effect, the service creates a global "data space" that any participant can read and write. It also creates a namespace to let participants find and share objects.
Figure 1: DDS may be regarded as a data-bus for distributed applications.
To increase scalability, topics may contain multiple independent data channels identified by "keys". This allows nodes to subscribe to many, possibly thousands, of similar data streams with a single subscription. When the data arrives, the middleware can sort it by the key and deliver it for efficient processing.
DDS also provides a "state propagation" model. This model allows nodes to treat DDS-provided data structures like distributed shared-memory structures, with values efficiently updated only when they change. There are facilities to ensure coherent and ordered state updates. An optional part of the specification called the Data Local Reconstruction Layer (DLRL) abstracts most of the underlying publish-subscribe semantics and presents a very-near analog to distributed shared memory.
Quality of Service Per Data Flow
DDS allows for fine control over Quality of Service (QoS) on a "per data flow basis". Each publisher-subscriber pair can establish independent quality of service (QoS) agreements. This aspect, unique to DDS, enables application designs that easily support extremely complex, flexible data flow requirements.
QoS parameters control virtually every aspect of the DDS model and the underlying communications mechanisms. Many QoS parameters are implemented as "contracts" between publishers and subscribers; publishers offer and subscribers request levels of service. The middleware is responsible for determining if the offer can satisfy the request, thereby establishing the communication or indicating an incompatibility error. Ensuring that participants meet the level-of-service contracts guarantees predictable operation necessary for real-time systems.
Automatic Discovery and Management of Data Flows
DDS is designed to automatically discover publishers and subscribers for each topic, and autonomously establish data flows between them as permitted by the settings of the quality of service parameters.
The DDS model provides fast location transparency. That makes it well suited for systems with dynamic configuration changes. It quickly discovers new nodes, new participants on those nodes, and new data topics between participants. The system cleanly flushes old or failed nodes and data flows as well.
Unreliable Connectionless Transports
DDS is fundamentally designed to work over unreliable transports, such as UDP or wireless networks. No facilities require central servers or special nodes. Efficient, direct, peer-to-peer communications, or even multicasting, can implement every part of the model.
Figure 2 summarizes the above five key aspects of the DDS communication model.
Figure 2: Fundamental aspects of the DDS communication model.
