This guide gives a quick and simple overview of the concepts you will meet when you use a Distributed Data Service (DDS) System.

What is DDS?

In today’s connected world data is everywhere.  Information is stored on computers and needs to quickly travel around the globe.  Consider a train system.  The trains travel on tracks and need to stop at different stations to pick people up and drop people off.  The controller of the train system needs to know where the train is at any one time, how fast it is going and if there are any problems on the line. The network needs to keep running smoothly. The challenge is making data available across operating systems, hardware platforms and coding languages.  Data needs to be sent quickly around distributed systems spread across different nodes and networks.

This is where DDS or the Data Distribution Service is used. DDS is a communications middleware that allows data to be sent to the components that need it.  DDS is a publish subscribe service based on the transmission of data. DDS consists of publishers that publish data into a global data space. This data can be read by subscribers to the global data space. Publishers and subscribers can join or leave the global data space at any time. Components are decoupled in space and time and the data is dynamically forwarded.

The Data Distribution Service (DDS) is defined by an Object Management Group (OMG) standard which means that different DDS versions will interoperate. There are two parts to the standard. The DDS API covers the source code portability whilst the DDSI standard ensures on the wire interoperability between different implementations.

The OMG standard and other documents can be found here:  http://portals.omg.org/dds/

The DDS Architecture

The DDS standard provides an application programming interface (API) . The API consists of DCPS – Data Centric Publish Subscribe which allows communication between DDS enabled applications.

A data-centric environment allows you to have a communication mechanism that is custom-tailored to your distributed application’s specific requirements.  Distributed application developers can concentrate on the operation of their specific application—without worrying about how they are going to communicate with the other applications in the environment. The data will flow though the system seamlessly.

DDS is a publish subscribe service. Applications communicate by writing data into the data domain and reading data from the data domain. The only information publishers and subscribers need in order to communicate with each other is a definition of the data.  Data will then flow though out the system regardless of what node or network the readers and writers are on.

Basic DDS Components

A DDS system is made up of a number of components. These are:

• Domain
• Domain Participant
• Topic
• Data Writer
• Publisher
• Data Reader
• Subscriber

The picture below shows how these relate to each other in a DDS system.

DDS also provides a way to query data and filter it using SQL language. Conceptually the global data space is like a distributed database. DDS is real-time , it provides deterministic behaviour and determinist propagation time, so it is obliged to handle data in memory.

Domains and Domain Participants

A domain is a virtual network that links all the applications that share the same domain id and allows them to communicate. DDS applications send and receive data within a domain.  All Data Writers and Data Readers with like data types will communicate within this domain.

You can have multiple domains which enables data isolation within your system. For example you could have one domain to deal with command data for trains, telling them where to go and how fast and another domain to deal with the status information that tells you how well a train is running. Only readers and writers associated with the same domain can communicate. This allows communication to be isolated within a community that shares a common interest. Topic names/definitions needs only need to be unique within the same Domain. A network can contain one or more domains and a domain can span one or more networks.

An application uses an element known as a domain participant to represent its activity in the domain. The domain participant indicates that the component contains elements related to DDS. It serves as a factory, container and manager for DDS entities in the system. The Domain Participant object enables a developer to specify default Quality of Service (QoS) properties for all data writers, data readers, publishers and subscribers in the corresponding domain. The Qos properties control data availability, data delivery, data timeliness and resource usage.

Topic

A topic is the unit of information that can be written to or read within the DDS system.  Communication will only take place if the topic being written into the system matches the topic being read from the system.

A topic is made up of:

• A topic type
• A topic name
• A set of Quality of Service (QoS) properties

The topic name is a string that uniquely identifies the topic within the domain. The topic type contains the definition of the data stored within the topic. The QoS properties are used to control the behaviour of the data in the system. Topics need to be uniquely defined within a domain, topics with the same name and different data types are considered to be different.

The topic types are defined using the OMG interface definition language (IDL). This is the standard language for defining object/data instances. IDL is  a language-independent means of describing data which can be used in different programming languages and on different operating systems.

One or more of the data types in the topic type definition can be chosen to be a topic key. The topic keys are used by the DDS system to sort incoming data. This allows applications to retrieve data matching a specific key.

Read more: Creating Topics in DDS

Data Writers and Publishers

Data is published into a DDS domain by a DataWriter. Once a data writer has been set up and configured with the appropriate QoS properties then an application just needs to call write for the data to be published.

A publisher is an entity which groups together individual data writers. Setting qos properties for a publisher will apply them to all the data writers that use the publisher.

The application controls how fast data is published. When write is called the data will move from the data writer into the publisher where it is sent to the DDS domain.

Data Readers and Subscribers

Subscribers receive data from a DDS domain and send it onto their DataReaders. A Subscribers is an entity that groups together DataReaders. Setting QoS properties for a subscriber will apply them to all the DataReaders that use that subscriber.

Applications get notification that data is available in a number of ways. These are:

• Using a listener – callback routine that runs when data is available for the reader. You need to add application code inside the callback routine to access the data.
• Polling the DataReader – the application will query the DataReader to see if data is available.
• Using a waitset – the application will wait until a certain condition is met and will then access the data.

The data is then obtained by calling take() or read(). If you use the take() call will remove the data from the middleware after the application has read it. The read() call leaves the data in the middleware so it can be retrieved multiple times.