Here is a valuable educational resource structured to build a strong understanding of DDS concepts. This DDS tour is unique because, rather than just reiterating the DDS Standards, it presents a clear and structured approach to grasping core DDS concepts.
The CoreDX DDS Tour starts with a look at middleware technologies in general. From this discussion, we can see how CoreDX DDS fits, and how it is different from other middleware architectures.
CoreDX DDS is an implementation of the Data Distribution Service (DDS). DDS is a data communications standard that describes low-latency data communications for distributed applications. The DDS standard defines a system, application programming interface (API), and wire protocol for type-safe network communications.
CoreDX DDS provides a Open Standards based communications architecture. Using DDS eliminates custom, proprietary software and provides standard interfaces. There are a number of benefits to this architecture, including:
Distributed applications are challenging to develop. This is due largely to the differences in:
The need for interoperability across all distributed platforms makes this software complex to develop and maintain.
Creating distributed applications without a communications middleware like DDS requires using proprietary communications built directly using Operating Systems services - eg the Socket API.
In this scenario, the application defines the protocol and data types used for communications. The application is also responsible for providing Operating System and platform independence and the distributed architecture.
This is expensive software to create, maintain, and extend.
Communication Middleware provides a layer of abstraction between the Application and Operating System. There are different types of middleware, but they have common goals, including:
There are a number of advantages to using a Communications Middleware. Middleware technologies provide standardization, an abstraction from the Operating System, and in most cases, sophisticated features.
Some benefits to using a Communications Middleware include:
Today's common middleware architectures can be classified as either Functional (sometimes known as Service Oriented) Middleware or Message Oriented Middleware (MOM).
Examples of Functional / Service Oriented Middleware:
Examples of Message Oriented Middleware (MOM):
Functional Middleware includes a client and a service (or server). The client located the server or service and makes a call to the service. The service performs some action or actions and returns the result.
Examples of Functional Middleware include RPC, CORBA, and SQL.
Functional Middleware is fundamentally a point-to-point architecture, and the client and service are tightly coupled.
Message Oriented Middleware includes a publisher or producer that generates data or messages and a subscriber or consumer that accesses the data. With MOM, the middleware manages the data.
Examples of Message Oriented Middleware include MQSeries, Rendezvous, JMS, and CoreDX DDS.
Message Oriented Middleware publishers and subscribers are loosely coupled.
CoreDX DDS is a Message Oriented Middleware and extends MOM concepts.
CoreDX DDS provides strong data typing to mazimize performance and safety of data communications.
CoreDX DDS adds a number of Quality of Service (QoS policies) to tailor the communication behavior between publishers and subscribers. Some QoS policies include Reliable communications, saved historical data, and data filtering.
And, CoreDX DDS is based on a formalized standard providing a portable API and interoperable wire protocol between DDS vendors.
To further the discussion of communication middleware, we now compare CoreDX DDS with some other common middleware technologies.
The standard Socket API requires specialized code on each side of the connection. On the 'server' side, this code performs the necessary tasks to create and configure the socket, wait for and accept a connection, and write data. On the 'client' side, this code performs the necessary tasks to create and configure the socket, attempt a connection, and read data. Further, this code is potentially different for each Operating System and coding language.
CoreDX DDS publishers and subscribers are easy to create and use. Simply create the publisher (or subscriber) and write (or read) data. Further, the application uses the same API for all Operating Systems and coding languages.
Not only is CoreDX DDS much easier to use than the Sockets API, but it is also packed with features. These features can only be accomplished using the Sockets API if they are hand written, tested, and maintained by the application developer.
The CORBA API requires an Object Request Broker (ORB). All clients and servers must connect to and register with the ORB before starting communications, which is usually a stand-alone server. CORBA clients call a remote method on the server and get a response. This is a Remote Procedure Call (RPC) architecture.
Each CoreDX DDS application contains all the necessary code for discovery and data communications - there is no server required.
CoreDX DDS does not contain the single point of failure like the CORBA architecture, and furthermore, it is packed with features:
These features are not available with CORBA.
The JMS architecture requires a server that must be configured and available before data communications can occur. JMS producers and consumers of data must locate and connect to this server. The JMS server often requires significant resources and creates a single point of failure.
Each CoreDX DDS application contains all necessary code for discovery and communications. There is no server required. In addition, CoreDX DDS applications automatically discover each other, so they do not require configuration of end-points.
CoreDX DDS does not contain the single point of failure like JMS, and furthermore, it is packed with features:
These features are not available with JMS.
Web Services require a web server that is configured that has the appropriate web services modules installed. Each client must be configured with the address of the web server before the service can be called. This architecture, once again, depends on a server (in this case, the web server).
Each CoreDX DDS application contains all necessary code for discovery and communications. There is no server to install or configure, and no single point of failure in the architecture.
CoreDX DDS does not contain the single point of failure like the Web Services architecture, and furthermore, it is packed with features:
These features are not available with SOA Web Services.
We have looked at the basic features of a few types of communication middleware and compared some common middleware architectures. This next section highlights some of the fundamental features of the CoreDX DDS technology.
This section touches on only a few of the features of CoreDX DDS, in order to highlight the difference between CoreDX DDS and other middleware technologies. For a more in depth view of CoreDX DDS features, take a look at Why Choose CoreDX DDS?.
CoreDX DDS provides Dynamic Discovery of publishers and subscribers.
The application does not know or configure CoreDX DDS endpoints - they can be on the same machine or across a network. The application simply indicates an intent to publish or subscribe to data and CoreDX DDS does the rest.
This is a unique and powerful feature of CoreDX DDS that is not found in other common middleware technologies. Dynamic Discovery provides for a flexible deployment architecture, where applications can be added, removed, or moved to different platforms with no impact to the rest of the network.
CoreDX DDS provides strong type safety. The application specifies the Types of data that will be used for communications, and these types are passed into write() calls and returned from read() calls. CoreDX DDS includes a compiler to generate type-specific code that is called by the application.
Strong Type Safety reduces programming errors, since type mismatches are discovered at compile time.
Many other middleware technologies provide an API to read and write a stream of bytes, or an XML format, which does not provide this type safety.
CoreDX DDS provides a rich set of Quality of Service (QoS) policies to tailor data communications. QoS Policy settings affect the behavior of data communications and control diverse aspects of DDS.
Dynamic Discovery uses QoS settings to appropriately match Producers and Consumers of data. These QoS Policies of Producers and Consumers do not necessarily have to match, but the must be compatible.
What is Interoperability? Interoperability is the ability of DDS Implementations from different vendors/sources to communicate.
Why do we want it? Interoperability provides increased flexibility in implementation decisions and vendor independence.
Open Standards from the OMG allow for Interoperability: DDS API, RTPS Wire Protocol, CDR Data Encoding.
Some vendors commit to and test Interoperability, including the makers of CoreDX DDS, Twin Oaks Computing.
CoreDX DDS has a low-latency communication architecture. It includes fundamental design principles aimed to meet the requirements of real-time and near-real time systems, including:
This section provides a number of basic examples where CoreDX DDS can be used to solve common architecture challenges. These examples are high-level and are intended to be a helpful learning resource. They are not designed provide full architectural solutions.
The Continuous Data Use Case addresses a scenario with a sensor producing data and consumers of this data.
The sensor produces data updates at a high frequency. The consumers should receive the data in near-real-time, without any significant network delays.
Some consumers need all the data produced by the sensor, other consumers need only recent data.
The Continuous Data Use Case is a very common application for CoreDX DDS. In this solution the following CoreDX DDS features are used:
The Reliability Use Case addresses a scenario where poor communications must use a network infrastructure that lossy, or are just old or slow. This presents a common problem - ensuring reliable data transfers in these environments.
In this example, we look at a Package Deliver Service with a central office that tracks delivery status, and drivers with hand-held devices to scan packages as they are received or delivered.
The wireless network used to communicate between the hand-held devices and central office is inherently unreliable. Yet it is important that the data from the hand-held devices is received by the central office.
This solution for the Reliability Use Case uses the following CoreDX DDS Features:
The Simulation and Test Use Case addresses a testing scenario where the system under test will interface with specialized equipment. For initial testing phases, simulators need to be used in place of the specialized equipment, which will not be available until later testing in the testing process.
In many cases, different code is executed to communicate with simulators versus the actual equipment, which is not necessarily an accurate test of the system.
This solution for the Simulation and Test Use Case uses the following CoreDX DDS Features:
The Failover Use Case addresses a scenario where there are redundant servers. CoreDX DDS provides features that can be used in conjunction with other failover mechanisms to provide a robust solution.
In this scenario there are two copies of a Data Producer. The Data Producers may be on the same machine, or on multiple machines across the network. Each Data Producer can produce the necessary data, and the Data Consumer should not see more than one copy of the data, and there cannot be an interruption in the delivery of data if one Data Producer fails.
This solution for the Failover Use Case uses the following CoreDX DDS Features:
The State Information Use Case addresses a scenario where sensor devices are publishing state information. One consumer of this state information is a user display application.
The display needs only the current state of the sensors.
The display cannot miss updates, even if the display application starts late (after the Sensors have published their current state).
This solution for the State Information Use Case uses the following CoreDX DDS Features:
The State Information Use Case addresses a scenario where published sensor data needs to be stored to disk. The sensors are writing data faster than the disk I/O can handle, so it is necessary to distribute the disk I/O over several machines.
This solution for the Distributing Network Load Use Case uses the following CoreDX DDS Features:
Many of the powerful concepts provided by CoreDX DDS are connected and inter-related. This section provides a look into some of these features in a well organized and ordered manner, where each new concept will build on previously presented concepts.
Additional resources and further information on these topics and other CoreDX DDS Features can be found at (Why Use CoreDX DDS?) and (Developing with CoreDX DDS).
With CoreDX DDS, application data types can be defined at compile time or run-time. CoreDX DDS uses data type information to:
CoreDX DDS provides a number of basic and complex data types, and these can be combined as needed to build application data types.
Each CoreDX DDS Topic, DataWriter and DataReader are associated with a single application data type.
Application data types that define a key (keyed data types) imply relationships between data updates.
A data Sample is one data update or messages.
An Instance is any number of data Samples with the same key value. Instances enable advanced CoreDX DDS concepts:
The figure to the right depicts an example application data type: Temperature.
The History QoS policy allows both DataReaders and DataWriters to specify the amount of historical data to keep in the CoreDX DDS middleware. Each DataReader and DataWriter maintains a DataCache that holds historical data samples.
For DataWriters, this historical data can be used for retransmission in Reliable communications, or for late joining DataReaders in Durable communications.
For DataReaders, this historical information can be provided to the application on read() calls.
The History QoS Policy allows the application to specify:
The Durability QoS specifies how long published samples are kept for late joining subscribers. These already published samples can then be delivered to subscribers that do not exist when the original sample was published.
There are several levels (Kinds) of Durability:
CoreDX DDS provides filtering options for DataReaders to limit the data that is received by the application. This filtering can be performed at the sending end or receiving end, but either way, filtering reduces both network traffic and CPU load.
Different filters can be specified by each DataReader, even those DataReaders subscribing to the same Topic. Some DataReaders may receive unfiltered data, while other set different filter criteria.
There are two kinds of filters:
Content filters can be implemented at the source or destination.
The more typical use is to filter at the destination. This allows the DataWriter to publish data as usual, multicasting samples to all matched DataReaders. The DataReader applies the filter very early in the data receiving process, eliminating unnecessary processing by both CoreDX DDS and the application.
Filtering at the source can also be beneficial. For data that will pass filters on a small number of matched DataReaders, filtering at the source not only reduces network traffic, but also does not 'wake up' threads to receive data that will just be dropped by the filter.
CoreDX DDS DataReaders also have the option to filter data received by time. This allows the DataReader to receive samples no more frequency than a minimum separation.
For example, a sensor publishes 500 updates every second. A display application subscribing to the sensor data will only refresh once per second. This display application can configure a time based filter to receive no more than one update every second. The remaining 499 updates that arrive in that second will be dropped by CoreDX DDS.
Time based filters are applied per Instance. For example, consider 5 sensors, each publishing on a different Instance on the Temperature Topic. In this case, the display application with a time based filter minimum_separation = 1 second may receive 5 samples each second. That is, the subscribing application will receive one sample per second for each Instance.
The CoreDX DDS wire protocol uses UDP, which is a low overhead, but unreliable network protocol. CoreDX DDS allows applications to choose the reliability of data communications: either RELIABLE or BEST_EFFORT.
The RELIABLE setting adds hand shaking and transmission functions to guarantee data delivery.
The BEST_EFFORT setting uses the default UDP protocol, and there is no guarantee of data delivery.
With the RELIABLE setting, retransmission of data is dependent on additional QoS Policy settings:
The diagram to the right shows an example of BEST_EFFORT and RELIABLE communications when a published data sample is lost by the network.
We hope this tour of CoreDX DDS has provided you with a strong foundation for the many features and benefits of this extraordinary technology. Of course, there is a wealth of additional information about CoreDX DDS. The following is a list of additional resources available:
CoreDX DDS Features...
Try a CoreDX DDS Demonstration...
Developer Resources...
Documentation...
User Forums...
