DDS and JMS
Posted in TechBlog on January 31, 2011 by Angelo Corsaro
I recently gave a Webcast in which I compared the similarities and the differences between DDS and JMS. The slides presented during the webcast are now available on slideshare however I'd like to review and summarize some of the key points made in the webcast in this blog post.
The first thing that I'd like to share is the figure below which tries to make a parallel between JMS and DDS core entities. As you can see from the figure, a DDS DomainParticipant is conceptually equivalent to a JMS Connection. The DDS DomainParticipant gives access to a DDS domain, while the JMS Connection essentially connects to a JMS provider.
Next we have the JMS Session object which in DDS is somewhat split into two different DDS entities, the Publisher and the Subscriber. In essence DDS has two different entities for dealing with publications and subscriptions sessions.
At the bottom of this diagram we find (1) the JMS Destination which parallels the DDS Topic (at least for the Pub/Sub JMS Domain) and (2) the JMS MessageProducer/MessageConsumer which parallel the DDS DataWriter/DataReader.
Beyond the differences and similarities between the key DDS and JMS entities, one of the important differences concerns the definition of what a Topic is. In JMS a Topic is a kind of Destination and is characterized by a name N. A JMS application can send/receive against/from a Topic one of the five different flavors of a JMS Messages (e.g. Byte, Text, Stream, Object, Map). In DDS a Topic is characterized by three aspects, a name N, a type T and a set Q of QoS. A DDS applications reads/writes values of the type T with the QoS Q (the QoS can be refined by the DataReader/DataWriter too) against the topic named N.
As a result DDS topics are strongly typed and ensure end-to-end type-safety between application producing topic updates and those consuming them. The same cannot be said of JMS since the application data produced has to be represented under one of the 5 available message types and eventually extracted from the receiving application -- thus introducing the potential for mismatch both in the expected message type as well as in the expected payload type (especially for the ObjectMessage type).
The pictures below shows the boilerplate code required for creating a JMS application.
Now suppose that we wanted to publish the position of cars moving around a city, for instance to allow better traffic management and control. To this end let's assume that the application type we were using to express the car position was the VehiclePosition class listed below.
class VehiclePosition implements java.io.Serializable {
private String plate;
private long x;
private long y;
// Ctors / Setters-Getters
} To publish this our car position in JMS we would have to write the following code:
VehiclePosition vp =
new VehiclePosition(“Hello”, 10, 20);
// Create an Object Message
ObjectMessage om = s.createObjectMessage(vp);
// Send the Object Message
mp.send(om);
The subscribing application receiving the car position publications would have to write something like this (notice that I am not checking types with instanceof to maintain the code more compact, e.g., for illustration purposes):
ObjectMessage om = (ObjectMessage)ms.receive();
VehiclePosition vp = (VehiclePosition)om.getObject();
Notice that the code above requires to check the type of the received message as well as the type of the received object. This is error-prone, tedious, can lead to runtime-errors, and makes it harder to develop large scale systems that are easy to maintain and evolve.
If we focus now on DDS, the pictures below shows the boilerplate code required for creating a basic DDS application.
Writing a publication for the car position in DDS is a simple as shown below:
VehiclePosition vp(“Hello”, 10, 20);
dw << vp;
// Alternative Syntax
dw.write(vp);
While one way of reading a publication for the car position is shown below:
std::vector data(size);
std::vector info(size);
dr.read(data.begin(), info.begin(), size);
Notice that the DDS code does not require any downcast nor explicit type checking. The DDS DataReaders and DataWriters are parametrized on the Topic type and as a result the application type is maintained end-to-end.
In summary, in this blog post I showed a parallel between DDS and JMS that should help people familiar with JMS migrate to DDS. I also showed that writing a DDS application is not any harder than writing a JMS application (especially with the new C++/Java PSM).
A+
