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.

Figure 1

The DDS Middleware is a software layer that abstracts the Application from the details of the operating system, network transport, and low-level data formats. The same concepts and APIs are provided in different programming languages allowing applications to exchange information across of operating systems, languages, and processor architectures. Low-level details like data wire format, discovery, connections, reliability, protocols, Qos management, etc. are managed by the middleware.

 

 

Data Centricity

Figure 2

DDS provides Qos-controlled data-sharing. Applications communicate by publishing and subscribing to Topics identified by their Topic name. Subscriptions can specify time and content filters and get only a subset of the data being published on the Topic. Different DDS Domains are completely independent from each other. There is no data-sharing across DDS domains.

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.

Figure 3

Inside a DDS domain the unit of information sharing is data-objects within Topics. The topic is identified by its name and the data-object by some ‘Key” attributes. This is similar to how key attributes are used to identify records in a Database. This is figure is conceptual. DDS communicates peer-to-peer and does not require the data to be brokered by a server or cloud.

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.

 

Dynamic Discovery

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.

 

Scalable Architecture

Figure 4

DDS systems can span from Edge to Fog to Cloud. At the edge they can be used for high-speed real-time machine to machine communications. Within the intermediary system they can provide robust, reliable QoS and content-aware information flows. Integrating these systems DDS provides scalable access and distribution of information all the way to and within the cloud.

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.

Skip to toolbar