This page provides information on the on-going standards work related to DDS. The specifications listed in this page are in the submission stage. This means that the Request for Proposals (RFP) has been approved (a.k.a. issued), and the submitters (typically vendors or providers of the technology) are working on the "responses" to the RFP. The OMG Middleware Task Force will review the responses, provide feedback, and eventually select among the RFP responses the one that will become the corresponding standard.

DDS for Lightweight CCM

The RFP solicits proposals that extend the LwCCM specification to support component ports which map to DDS and which enable and expose DDS functionality to the component developer.

This technology is still in the initial submission stage.

DDS for Lightweight CCM work in progress page (requires OMG member access). Working documents and status of the submissions.

Native C++ Language DDS API (PSM)

This RFP solicits proposals for a Native C++ Language (ISO Standard C++) API to DDS, which would use and conform with the standard data-types and programming idioms of the language. The objective is to provide a more "natural" API for C++ programmers as well as to improve portability between DDS implementations by having standard header files defined by OMG.

In the text below the term "Platform Specific Model" (or PSM) refers to each concrete language API (C++ in this case). This terminology derives from the fact that DDS is defined in a platform independent manner using UML. This Platform Independent Model (or PIM) is them mapped to each language API. This approach ensures semantic equivalence between all languages.

Specific requirements:

• The new PSMs should be functionally equivalent to the existing (IDL defined) PSM. While the syntax may change, the application should be able to accomplish exactly the same tasks as using the existing PSM.
• Applications programmed using different PSMs should interoperate transparently, i.e., an application that communicates with another one should have no awareness, other than informational, of what PSM the peer application is using.
• The new PSMs should be derivable from the PIM by following a fairly small set of rules which should be described for each PSM.
• It is anticipated that a single developer or team may use different PSMs in different parts of their system to better fit the platform or deployment requirements. As such it is desirable that the relationship and functional equivalence between the PSMs is easy to understand.
• The new programming-language PSMs should be described using the ‘common’ or ‘accepted’ idioms for that programming language, e.g., header files in C++.
• The new PSMs should be designed such that they can co-exist with other technologies, specifically they should not interfere with the namespaces used by other OMG specifications, or commonly used packages.

Native C++ Language DDS PSM (requires OMG member access). Working documents and status of the submissions.

Extensible and Dynamic Topic Types for DDS

This RFP looks for responses to extend the DDS standard with the following features:

1. Extensible Topic Type System. Response to this RFP are expected to define an abstract type system for DDS Topics Type, that shall provide built-in support for extensibility, as well as support for complex types such as object maps, and sparse data.

2. Dynamic DDS API.Responses to this RFP are expected to define a Dynamic DDS API, to be used as an alternative to existing API, that shall allow to define, read, take, access, and write, Topics whose types are not know at compile time.

3. Data Encapsulation Format. Responses to this RFP shall define new data encapsulation format, or extend existing, so to efficiently support extensible and dynamic types.

This technology is still in the initial submission stage.

Extensible and Dynamic Topic Types for DDS (requires OMG member access). RFP document.