There are some fundamental conceptual differences between DDS and JMS which can deeply impact data-centric design especially as regards tothe monitoring and coordination of activities amongst diversedistributed controllers and sensors.
Particular attention in any embedded design involving real timedelivery of information must be paid to differences in the areas ofdata modeling, dataflow routing, device discovery, and data typing.
Data modeling: Autonomous messagesvs. Data-objects
P-S middlewarean be distinguished in their use of data models, which ranges from (1) messaging or eventing, where the data payload is opaque to themiddleware; to (2) data-objectcentric, where the data payload isinterpreted and managed by the middleware.
Messaging or eventing P-S middleware treat a message on a topic asan event with an optional data payload that is opaque to themiddleware. Data-object centric (or simply data-centric) P-S middlewareallow an application to identify 'data-objects' to the middleware. The'data-objects' are unique in the 'global data space' of the distributedsystem across all participants. Each participant is regarded as havinga local cache of the underlying global data-object.
A message on a topic is regarded as an update to the underlyingdata-object that can be identified and managed by the middleware. Localchanges to a data-object are propagated by the middleware; themiddleware can distinguish between messages or update samples fromdifferent data-objects and manage their delivery to the interestedparticipants on a per data-object basis.
JMSdoes not support an underlying data model; it is a pure “messaging” or”eventing” middleware, and treats a message as an event with anoptional data payload that is opaque to the middleware.
A JMS message is a self-contained autonomous entity, representing anevent with optional data payload. In its lifetime, a message may be(re)sent multiple times across multiple processes. A JMS client on theway may examine it, consume it, forward it, or generate new messages toaccomplish its task. A message is uniquely identified with messageId,and carries with it its deliveryMode, priority, expiration,correlationID, redelivery flag, reply destination, and so on in theheader fields.
Message payload contents are not interpreted or managed by the JMSprovider; each message is a unique and distinct entity. Data modelingcapabilities, if needed, will have to be provided at the applicationlayer, in the JMS client software.
|Figure6. DDS provides a relational data model. The middleware keeps track ofthe data-objects instances, which can be thought of as rows in a table.|
DDSis data-object centric middleware, and supports a relational data modelcommonly used in database applications, as shown in Figure 6, above . In database terms,a topic corresponds to a Table; the table schema corresponds to thetopic type. Certain type fields (columns) can be marked as keys(primary keys) in the type description (table schema).
A data-object instance is identified by its keys, and corresponds toa row in the table. Underlying this data model is an implicitassumption of a shared global data space in which the data-objectslive. The global data space is defined by the communicatingapplications in the DDS domain. Each participant is viewed as havingaccess to a local cache of the topics (tables) in the global dataspace.
A DataWriter can write (or update) one or more data-object instances(or rows) in its local cache. The updates are propagated by themiddleware to the associated DataReaders for the topic, and aredelivered as samples to be applied to the local cache on the receivingend.
The DDS middleware can distinguish between different data-objectinstances based on the keys, and can manage the delivery of samples ona per data-object instance basis. Since the keys are embedded in thedata type, relations between data-object instances are also implicitlymanaged by the DDS middleware.
DDS also supports unkeyed topic types, which are effectivelyequivalent to messaging (or eventing), as supported by JMS.
Unlike JMS, where messages are first class objects, DDS messages areuser defined types and do not carry any 'per message' user settableheaders or fields. However, the user is free to define the message datatype, and therefore can specify needed fields.
As a consequence of this difference, DDS data delivery has thepotential to be higher performance than JMS messages delivery, becausethe extra overhead of mandatory headers per message is not requiredwith DDS.
Dataflow routing: Specificdestinations vs. Matching endpoints
JMS destinations (Queue or Topic) are logical “message stores orchannels”, uniquely defined and managed by the middleware, as shown in Figure 7, below . A destination maybe configured statically in the middleware using JMS vendor providedconfiguration tools; or it may be created dynamically using temporarydestinations.
|Figure7. JMS destinations are logical message stores or channels configuredusing administrative tools supplied by the JMS vendor.|
In either case, they represent unique well-defined “channels” in themiddleware. A destination and can hold any type of message (since JMSis opaque to the payload). A consumer is attached to a specificdestination from which it will receive messages. A producer can specifythe destination at the time of sending a message. A destination acts asa “mini-broker” managing the delivery of the messages sent to it. Adataflow is established between a producer and a consumer via thedestination as the intermediary.
A DDS topic represents an association between compatible DataWritersor DataReaders bound to the topic, in the global data space. A topichas a name, type, and associated QoS. An endpoint (DataReader orDataWriter) is tightly bound to a specific topic and may additionallyspecify different desired QoS. A dataflow between a DataReader andDataWriter is only established when the type and QoS offered by theDataWriter is compatible with that requested by the DataReader (Figure 8, below ).
|Figure8. DDS topics represent a name, type, and QoS. DDS provides aspontaneous connection mechanism, which automatically connects matchingDataReaders and DataWriters.|
The DDS requested/offered mechanism establishes dataflows onlybetween matching endpoints associated with a topic in the global dataspace. DDS notifies the application of incompatible endpoints, when adataflow cannot be automatically established. Thus, DDS middlewaretruly acts like an “information bus”, where dataflows are dynamicallyestablished and removed.
Unlike JMS, where a producer sends to a specific destination, a DDSDataWriter (producer) never specifies a destination; in DDS thedataflows are automatically managed by the DDS middleware based onmatching subscriptions. A DDS middleware implementation can takeadvantage of this behavior by supporting direct data transfer from aDataWriter to a DataReader, without involving an intermediary; thus ithas the potential for better performance and scalability than JMS.
Discovery: Administered vs.Spontaneous
JMS discovery is administered and centralized. JMS discovery requiresthat the producers and consumers be able to find and bind to thedestinations (and not each other). There are two mechanisms for JMSdestination discovery.
* Static destinations are discovered via JNDI APIs, which bind logicaldestination names to destination objects. The static destinationsaccessible this way must have been previously configured in the JMSmiddleware (server) using vendor supplied administrative tool (Figure7, above).
* Destinations (including temporary destinations) may also be discoveredvia the replyTo attribute of received messages. In order to discover adestination using this mechanism, a static destination must havealready be previously established.
Since JMS discovery is administered, the static destinations must bedetermined and configured before a client can use them. Determiningwhat static destinations to use is a critical aspect of a distributedsystem design, and must be considered carefully prior to deploying asystem based on JMS.
Evolving the system configuration for new requirements also requirescareful planning and administration. Destinations take up physicalresources, so destinations no longer needed in distributed system mustbe purged, and new ones added as needed over the lifetime of adistributed system based on JMS.
DDS discovery is spontaneous and decentralized. DDS requires thatendpoints be able to find each other to determine if they arecompatible and whether a dataflow should be established (Figure 8, above ). Thus, discovery isimplicit in the dataflow routing mechanism.
DDS provides APIs for an application to access the internalmiddleware discovery meta-data by means of built-in topics. Theinternal meta-data that can be accessed by a user application includesinformation such as participants joining/leaving a domain,creation/deletion of topics, data readers, and data writers in adomain.
The DDS DomainParticipant.get_builtin_subscriber() method can be used to monitor the following builtin-topics: DCPSParticipant ,DCPSTopic,DCPSPublication, DCPSSubscription.
Since DDS discovery is spontaneous, the topics can dynamicallychange over the lifetime of a deployed distributed system based on DDS,without any administrative impact. Endpoints on new topics arediscovered automatically, and dynamic dataflows established in aplug-n-play fashion. The spontaneous discovery mechanism of DDS canalso potentially scale better as the span of a distributed systemgrows.
Predefined message types vs.Arbitrary user data types
JMS provides five predefined message types, to conveniently specifydifferent types of message payloads. Since JMS destinations are nottyped, any type of payload can be produced and consumed on adestination.
If a consumer has a different idea of the message payload than theproducer, it will manifest as runtime typecasting exception when theconsumer tries to access the payload using a different message type.
Also, the user data payload must be converted into one of theavailable message types, thereby involving conversion overhead betweenuser data type and JMS message types at both the producer and consumerends.
DDS does not provide any predefined message or data types. Insteadit uses the data types defined in the programming language. Typicallythese are specified using interface definition language (IDL) in aprogramming language neutral way. Middleware vendor provided tools areused to generate a programming language type, and corresponding typesupport classes.
For example, given a user type Foo, type specificFooTypeSupport, FooDataWriter , and FooDataReader are generated with APIs as per the DDS standard. This approach hasseveral advantages: it allows for higher performance by eliminating apotential extra conversion between a user type and a middleware type;it potentially enables the user to plugin their own data serializationad deserialization scheme.
Also, since DDS topics are strongly typed, the middleware can detecta type mismatch between the endpoints and notify the application.
User Experience Similarities
Despite the fundamental paradigm differences, the DDS and JMS userexperience is somewhat similar, making it relatively easy to understandand switch back-and-forth between the two programming models. Figure 9 below illustrates the keysteps in writing a JMS client (application). Figure 10 below illustrates thekey steps in writing a DDS application.
|Figure9 JMS programming model.|
As shown in Figure 9 above of the JMS programming model, the key steps are typically as follows.First, decide the JMS messaging domain to use: Point-to-Point (PtP) orpublish-subscribe (Pub/Sub). Next, get a reference to theConnectionFactory for that JMS domain; typically this is done via JNDIor some other non-JMS API. Then, from a ConnectionFactory ,a Connectionobject is created; it represents the link between the clientapplication and the JMS provider.
From the Connection, Session objects can be created. When creating aSession object, decide if the session is transacted or not, and theacknowledgment mode to use. Next, obtain a reference to a Destinationon which messages will be produced, or from which messages will beconsumed.
A Destination reference is obtained using some non-JMS API, usuallyJNDI. In order to producemessages on the destination, create aMessageProducer from the Session. Next, create the desired type ofMessage object, and specify the data payload to send. Then call thesend() method on the MessageProducer to send the message to theDestination. In order to consume message from aDestination , from theSession create a MessageConsumer associated with the Destination.Register a MessageListener with theMessageConsumer , and implement itsonMessage() method to receive incoming messages sent to thedestination.
|Figure10. DDS programming model.|
Figure 10 above summarizesthe DDS programming model. The key steps are typically as follows.First, get a reference to the DomainParticipantFactory singleton, andcreate a DomainParticipant object associated with a domain id. A DDSdomain comprises of communicating peer participants associated with thesame domain id. (Note that “domain” has an entirely different meaningin the context of DDS than when used in the context of JMS). Then, foreach type to be used by the application, use the middleware vendorprovided scheme to generate type support classes from a high level typedescription (for example in IDL).
For a type “Foo “,the classes “FooTypeSupport “,”FooDataWrite r”and “FooDataReader “classes are automatically generated for use with the DDS middlewareimplementation. Register the data types to be used by the applicationwith the DomainParticipant. This is done using the “FooTypeSupport.register_type() “method generated for each user type. After registering the types,create the Topics on which data will be exchanged by the application. ATopic is created from the DomainParticipant, and is bound to one of theregistered types.
In order to produce data on a Topic, create a Publisher from theDomainParticipant, and from the Publisher, create a DataWriter bound toa previously created Topic. Then, to produce a data sample, call theDataWriter's write() method with the new sample value. In order to consume data, create aSubscriber from the DomainParticipant, and from the Subscriber create aDataReader bound to a previously created Topic.
Register a DataReaderListener with the DataReader to be notifiedwhen data is available. When data is available, call the read() or the take() methodson the DataReader to access the received samples. In DDS, one can alsospecify desired quality of service (QoS) and a status listener on eachof the entities, including DomainParticipant, Topic, Publisher,DataWriter, Subscriber, DataReader to tune the behavior and operationof the middleware.
While the user experience in using these two APIs is somewhat similar,there are some key differences.
For example, JMS offers five predefinedmessage types, whereas DDS allows the use of arbitrary user data types.In DDS the type specific DataWriter and DataReader facades are stronglytyped and generated using a vendor specific scheme. In JMS,Destinations are not typed; whereas DDS Topics are stronglytyped.
In JMS, the destination to which a message is to be sent can bespecified at the time of sending; in DDS the topic is implicitlyassociated with a DataWriter. In DDS one can find out the availabilityof a new update first, and then access the data; in JMS thenotification and the message arrive together.
Some of these differences arise from the fundamental paradigmdifferences between the two APIs. A programmer must be aware of thesedifferences when switching between the two APIs or when mapping adistributed application architecture to the underlying middlewaretechnology.
To come in Part 3: Practical considerations when using DDSand/or JMS
To read Part 1 go to: The basics ofDDS and JMS
Rajive Joshi, Ph.D., is principalengineer at Real-TimeInnovations, Inc.
1) DataDistribution Service for Real-time Systems, v1.1,