The Proven Data Connectivity Standard for the Internet of Things
The Data Distribution Service (DDS™) is a middleware protocol and API standard for data-centric connectivity from the Object Management Group® (OMG®). It integrates the components of a system together, providing low-latency data connectivity, extreme reliability, and a scalable architecture that business and mission-critical Internet of Things (IoT) applications need.
In a distributed system, middleware is the software layer that lies between the operating system and applications. It enables the various components of a system to more easily communicate and share data. It simplifies the development of distributed systems by letting software developers focus on the specific purpose of their applications rather than the mechanics of passing information between applications and systems.
There are many communications middleware standards and products. DDS is uniquely data centric, which is ideal for the Internet of Things. Most middleware works by sending information between applications and systems. Data centricity ensures that all messages include the contextual information an application needs to understand the data it receives.
The essence of data centricity is that DDS knows what data it stores and controls how to share that data. Programmers using traditional message-centric middleware must write code that sends messages. Programmers using data-centric middleware write code that specifies how and when to share data and then directly share data values. Rather than managing all this complexity in the application (your) code, DDS directly implements controlled, managed, secure data sharing for you.
Global Data Space
DDS conceptually sees a local store of data called the “global data space.” To the application, the global data space looks like native memory accessed via an API. You write to what looks like your local storage. In reality, DDS sends messages to update the appropriate stores on remote nodes. You read from what looks like a local store.
All together, the local stores give applications the illusion of having access to the entire global data space. This is only an illusion; there is no global place where all the data lives. Each application locally stores only what it needs and only for as long as it needs it. DDS deals with data in motion; the global data space is a virtual concept that is really only a collection of local stores. Every application, in almost any language, running on any system, sees local memory in its optimal native format. The global data space shares data between embedded, mobile, and cloud applications across any transport, regardless of language or system, and with extremely low-latency.
Quality of Service
The data can also be shared with flexible Quality of Service (QoS) specifications including reliability, system health (liveliness), and even security. In a real system, not every other end-point needs every item in your local store. DDS is smart about sending just what it needs. If messages don’t always reach their intended destinations, the middleware implements reliability where needed. When systems change, the middleware dynamically figures out where to send which data, and intelligently informs participants of the changes. If the total data size is huge, DDS intelligently filters and sends only the data each end-point really needs. When updates need to be fast, DDS sends multicast messages to update many remote applications at once. As data formats evolve, DDS keeps track of the versions used by various parts of the system and automatically translates. For security-critical applications, DDS controls access, enforces data flow paths, and encrypts data on-the-fly.
The true power of DDS emerges when you specify all of these things simultaneously, at extremely high speeds, and in a very dynamic, demanding, and unpredictable environment.
DDS provides Dynamic Discovery of publishers and subscribers. Dynamic Discovery makes your DDS applications extensible. This means the application does not have to know or configure the endpoints for communications because they are automatically discovered by DDS. This can be completed at runtime and not necessarily at design or compile time, enabling real “plug-and-play” for DDS applications.
This dynamic discovery goes even further than discovering endpoints. DDS will discover if the endpoint is publishing data, subscribing to data, or both. It will discover the type of data being published or subscribed to. It will also discover the publisher’s offered communication characteristics and the subscriber’s requested communications characteristics. All of these attributes are taken into consideration during the dynamic discovery and matching of DDS participants.
DDS participants can be on the same machine or across a network: the application uses the same DDS API for communications. Because there is no need to know or configure IP addresses, or take into account the differences in machine architectures, adding an additional communication participant on any operating system or hardware platform becomes an easy, almost trivial, task.
The OMG DDS architecture is designed to be scalable from small devices to the cloud and for very large systems.DDS enables the Internet of Things by scaling across thousands or millions of participants, delivering data at ultra-high speed, managing many thousands of data objects, and providing extreme availability and security. DDS simplifies distributed systems development by absorbing much of the complexity in a single, standard communications layer.
For further information on the DDS standard then please visit the specifications page.
Note: A DDS DomainParticipant represents the local membership of the application in a domain. A domain is a distributed concept that links all the applications able to communicate with each other. It represents a communication plane: only the publishers and the subscribers attached to the same domain may interact. Furthermore, it acts as a factory for DDS Publishers, Subscribers, Topics, MultiTopics and ContentFilteredTopics.