OpenDDS is based on the 1.0 DDS Specification (formal/04-12-02).

It offers the following default transport protocols:

• TCP
• Reliable multicast
• Unreliable multicast
• UDP

OpenDDS has been found to perform better than other TAO services (notification and real-time event channel) by a factor of two or three. The features offered by the RTEC and NS are similar to DDS, but not identical, so carefully examine your use-cases before choosing one service over another. Speed is not the only criterion.

Isn’t DDS just another CORBA service?

The answer is no. DDS is defined by the OMG and has some similarities to CORBA, but the specification for DDS does not require any CORBA. The CORBA A/V streaming service for example was designated a "specialized" CORBA service because it did not comply with all the architectural norms that have become associated with CORBA. Some aspects of the CORBA model were not suitable for the high volume data transfer that the service was intended to address. However DDS with its demands goes beyond even being considered as a specialized service.

Two instances of such non-CORBA behavior in DDS are the relaxation of the requirement to support CDR (Common Data Representation) and its associated IIOP (Internet Inter-ORB Protocol). These waivers make sense for the circumstances under which most publish and subscribe system operate.

These distinctions also separate DDS publish and subscribe from other publish and subscribe models found in the Notification Service, COS events, or the real time event channel. DDS is therefore able to address a wider variety of "pub/sub" situations than previous OMG CORBA services. DDS expands the reach of OMG CORBA related technologies.

Note: Normally OMG CORBA services are shareable. This means that one ORB implementation with one set of bindings can utilize other ORB implementations' services (i.e. naming, notification, trading etc.) regardless of its language bindings. There are some exceptions. For instance the FT CORBA service requires other ORB implementations have cores that are "FT enabled". DDS was not originally a shareable service however there now exists an OMG DDS interoperability specification, called RTPS, which when implemented by various DDS implementations will allow for interoperation.

Why is DDS different?

DDS is motivated by a desire to distribute data predictably with a minimum of overhead. A certain class of real-time systems requires the transfer of large amounts of data reliably and at the highest possible performance. The speed requirement drives implementations to transfer data with as little penalty as possible, which is why traditional CORBA objects are usually reserved for lower bandwidth command and control functions in such systems. DDS is intended to achieve the goals of CORBA functionality (location transparency, reliable operation, portable definitions) while incurring less overhead cost in data transfer.

The Object Management Group added the Data Distribution Service to its suite of distributed systems specifications to increase the range of publish/subscribe options available to developers of distributed real-time systems. OpenDDS is a hybrid of CORBA/GIOP communication for administrative tasks (such as connecting publishers to subscribers) and type-safe custom transports for data transfer. Open Data Distribution Service enables a developer to benefit from CORBA's distributed object computing paradigm, interoperability, and location transparency in connecting publishers and subscribers while meeting the transport performance requirements of extreme real-time applications. The use of custom transports enables system developers to gain the advantages of efficient, low-latency data transmission protocols while retaining the benefits of high-level standard interfaces.

Are all DDS Implementations CORBA based?

No. DDS is written in such a way that vertically integrated DDS products need not have CORBA features, or be CORBA ORBs. However, OpenDDS was developed to ensure its existing CORBA functionality was shared with DDS and the duplication of functionality be avoided. Therefore a more natural integration was achieved. For instance, OpenDDS uses the TAO IDL compiler. TAO is used to register for a topic and quality of services required. The ORB is required and runs with DDS.

OpenDDS enables designers to easily co-mingle DDS and CORBA styles in a "one-stop shopping" manner.

OpenDDS, as body of code, is loosely coupled with TAO. This permits DDS to evolve rapidly and yet allows TAO to evolve at its own pace. Any dependencies between versions of TAO and its DDS will be managed carefully with view to minimizing their impact. With care, it will be possible in many cases to upgrade either, without effect to the other.

In those areas of DDS that there is no ORB core utilization OpenDDS uses ACE as its abstraction (or portability) layer. This enables DDS to support the same wide variety of platforms as TAO. It also allows DDS to get socket (ACE like) level performance for its data transfer. (See the architecture diagrams below.)

The default CORBA communication model is a request/reply model. A client connects directly to a server and sends a request directly to that server. The server processes the request and sends a reply to the client. The advantage to the client is reliability - the client knows whether or not the request has made it to the server, and the reply tells the client when the request has succeeded. Most applications have some portions that are best served by this communication model. However, the request/reply communication model is not appropriate for all parts of all applications.

Publish and Subscribe (sometimes called message queuing) is a communication paradigm for distributed computing applications in which flexibility through anonymity is a prominent factor. Publishers provide data to the application without being aware of how it is consumed; subscribers receive data without knowledge of its source. This loose coupling of publishers and subscribers enables a publish/subscribe-based architecture to be scalable as new publishers and subscribers can be seamlessly integrated into the existing application without affecting existing code.

Performance testing of ORB implementations often focuses on the round trip time (latency) for an empty message to be sent and returned. This metric is a fairly well established way of assessing the ability of distributed systems models to support consistency amongst their applications. High latency for instance, would result in sluggish systems response. Low latency ensures a shared responsive behavior. Performance tests for publish and subscribe systems focus on message throughput, messages sent, or messages received. They also vary the styles comparing point to point, one way, one to many, data types and message sizes. All these factors may vary, causing the analysis of performance metrics between traditional ORB behavior and DDS systems to be problematic.

OpenDDS when compared with TAO RT event channel, which has a pub/sub service, seems to indicate a better than threefold improvement in performance, on point to point messaging.