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 Programming Model
Figure 3 illustrates the key objects in typical DDS distributed application. A "domain" is an abstract concept referring to a collection of DomainParticipant objects that can communicate with each other. A "DomainParticipant" object represents the membership of an application in a domain. Thus, a domain represents a communication plane: participants may communicate only with other participants on the same domain. The DomainParticipant is a container of all other DDS objects.
Figure 3: Object diagram of a typical DDS application. The domain comprises of three DomainParticipants communicating over three different Topics. The first DomainParticipant contains a Subsriber constaining a single DataReader and a Publisher containing two DataWriters. The second DomainParticipant contains a single subscriber containing two DataWriter bound to two different topics. The third DomainParticipant contains a single Publisher containing a single DataWriter.
A "Publisher" object is responsible for data issuance, and may publish data of different data types. A "DataWriter" object is a typed facade to a publisher; participants use DataWriter(s) to communicate the value of and changes to data of a given type. Once new data values have been communicated to the publisher, it is the Publisher's responsibility to determine when it is appropriate to issue the corresponding message and to actually perform the issuance (the Publisher will do this according to its QoS, or the QoS attached to the corresponding DataWriter, and/or its internal state).
A "Subscriber" object receives published data and makes it available to the participant. A Subscriber may receive and dispatch data of different specified types. To access the received data, the participant must use a typed "DataReader" attached to the Subscriber.
The association of a DataWriter object (representing a publication) with DataReader objects (representing the subscriptions) is done by means of the "Topic". A Topic associates a name (unique in the system), a data type, and QoS related to the data itself. The type definition provides enough information for the service to manipulate the data (for example serialize it into a network-format for transmission). The definition can be done by means of a textual language (e.g. something like "float x; float y;") or by means of an operational "plugin" that provides the necessary methods.
Figure 4 shows the DDS class diagram. A DomainParticipantFactory is a singleton used to create and delete DomainParticipants. A DomainParticipants is bound to the domain given by DomainParticipant::get_domain_id(). The DomainParticipant acts as factory for creating and deleting the DomainEntities Topic, Publisher, and Subscriber. The Publisher acts as a factory for creating and deleting strongly types DataWriters for a previously created topic. The Subscriber acts as a factory for creating and deleting strongly types DataReaders for a previously created topic. The DataWriter::write() operation allows the user application to update the data with anew value. The DataReader::take() operation is used to take the received data sample from the DDS middleware.
[Click image to view at full size]
Figure 4: UML class diagram showing the DDS entity inheritance and containment relationships. Key methods are shown.
The abstract Entity interface defines the common operations supported by all the DomainParticipant, and the DomainEntities (i.e. Topic, Publisher, DataWriter, Subscriber, DataReader). The get_qos() and set_qos() operation can be used to retrieve and modify of the QoS; the get_listener() and operations can be used to retrieve and install user listeners for specific status conditions that can be detected by the DDS middleware. The exact list of QoS policies and listeners is specific to each concrete entity type.
