Yes! To date there are two Open Source implementation of DDS, OpenSplice DDS and OpenDDS.

The short answer is that JMS is message-centric, was developed with enterprise messaging in mind, and works only in Java whereas DDS is data-centric, was developed with real-time applications in mind, and works on multiple platforms.

The Data-Centric model used by DDS can be seen as an extension of the message-centric model of JMS where, in addition to a Topic the application provides a user-defined Key that uniquely identifies a data-object for that Topic. The use of keys allows DDS to offer additional QoS such as the ability to maintain the 'most-recent value' of every data-object, or the ability to control the liveness of individual objects.

A detailed answer to this question requires understanding the publish-subscribe models of JMS and DDS in more detail. The papers in the WhitepapersPage provide a detailed analysis and comparison of DDS with other middleware standards including JMS.

Yes. This capability is provided in DDS by means of special "built-in" Topics which the application can read.

The DDS specification defines four "builtin-topics" named:  "DDSParticipant", "DCPSTopic", "DCPSPublication", and "DCPSSubscription"

The DDS middleware contains a builtin subscriber and pre-created DataReaders for these Topics. The builtin subscriber can be retrieved using the get_builtion_subscriber() operation on a DomainParticipant and the pre-created data readers can be retrieved using the lookup_datareader() operation on the builtin subscriber.

Data read on these builtin DataReaders represent the presence and discovery of other DomainParticipants, Topics, DataWriters and DataReaders on the network.

In our experience most Topics should have a key. 

You should have a key whenever the act of writing data on a Topic logically represents updating the value of some data-object or a change in the state of the the system.  Specifically if you think that writing to a Topic "replaces" or "updates" a previously-written value.

If a Topic has a key, DDS can use that information to determine which data-object is being affected by your write operation. This allows DDS to implement QoS policies that properly manage the information maintaned by the system:

For example:

• The HISTORY QoS allows the DDS middleware to remember only the last N (history depth) updates to each data-object
• The DEADLINE QoS allows the DDS middleware to monitor that each data-objects is being updated at the specified rate
• The (Exclusive) OWNERSHIP QoS allows the DDS middleware to arbitrate between DataWriters so that  there is only one "active" DataWriter allowed to update the data-object
• The TIME_BASED_FILTER QoS allows the DDS middleware to filter rapid updates made to a data-object so that the DataReader receives at most one update per data-object per specified maximum period.

Generally speaking the definition of a key allows an application to fully leverage the capabilities of the DDS History Cache. This simplifies the application logic and can also result in significant overall performance benefits as it avoids duplicating that logic in application code.

You should not define key fields in a Topic if that Topic represents raw messages which have message-to-message identity. Meaning that there is no concept of a "write" operation updating the state of a data-object or replacing the old value with a new one. rather new messages are always "appended" to the existing set of messages. An example for this are messages representing transactions or logging events.

The short answer is yes. DDS can be used to send any kind of Data, including event data.

The long answer... When people talk about events, they typically refer to two things:

• A particular schema of data (e.g. data that carries a header with specific fields that identify things like the source of the event, the timestamp, the priority, one or more classification categories, keywords, etc.).
• An infrastructure that supports a variety of filtering and dispatch mechanisms based on the header fields, the priority, the content, etc.

In DDS the application developer is responsible for defining the schema for the data. DDS does not define a built-in event type, but the application can define any desired event type and include the fields it wants. In addition the use of time-based filters and ContentFilteredTopic in DDS allows the application to perform flexible filtering of events.

DDS contains a QoS that is richer that most event-dispatching systems as it can be used to propagate not only events but also state information and sampled-data values. When used to propagate events the QoS should be configured to match the typical semantics of events. The typical settings are:

• RELIABILITY QoS kind set to RELIABLE
• HISTORY QoS kind set to KEEP_ALL
• DESTINATION_ORDER QoS kind set to BY_SOURCE_TIMESTAMP
• DEADLINE QoS period set to DURATION_INFINITE
• TIME_BASED_FILTER QoS period set to DURATION_INFINITE

In addition Domains and the PARTITION QoS can be exploited to create flexible and scalable event-distribution overlays.

The contributed HelloWorldApplication contains an example of how to do a minimal application that uses DDS to communicate between multiple computers.