How difficult would it be to write a JMS adapter for the RTI Routing service which can subscribe to arbitrarily complex types (beyond simple shapes with integer and string fields)?
Context
Our application needs to interface with an ActiveMQ broker (JMS provider). However, our primary messaging middleware is RTI Connext DDS. Our application is one of many interfacing with this broker, so we cannot simply swap out ActiveMQ without forcing those other applications to modify their applications.
Ideally, we can use the RTI suite of tools for all of our incoming messages. One idea was using the Routing Service to bridge JMS-DDS. We're specifically concerned with being able to consume messages. These messages are complex types (nested structures). My biggest concern is having to write code to transform complex, nested types (objects containing arrays of objects).
Hi,
Do you mean consume messages from Connext DDS and send them via ActiveMQ/DDS or the other way around?
Gerardo
Hi Gerardo,
You're correct, we want to consume from Connext DDS. The way I see it, our routing service adapter would transform any incoming JMS messages into DDS messages.
For context, our real-time and user-interface applications both use DDS. However, our real-time application interfaces with several other sub-systems which chose to use JMS (ActiveMQ). Currently, our user-interface application subscribes to messages published by our real-time application over DDS. However, our user-application will also need to subscribe to messages published to the JMS bus by those other sub-systems. Ideally, we can use the routing service to transform all incoming data traffic into DDS, so we can write subscribers and use RTI tools for all incoming messages to our subsystem.
Hi,
If the data is coming from JMS, then it all depends on how the data is formatted/serialized.
My understanding is that JMS can send/receive messages of 5 types: BytesMessage, StringMessage, MapMessage, StreamMessage, and ObjectMessage. When you said "arbitrarily complex types" do you mean the ObjectMessage where you are receiving an arbitrary (Serializable) Java Object? Or do you mean some of the other messages?
The comments below assume you meant the ObjectMessage.
One potential problem is that DDS expects all the data on a given Topic to have the same data-type. On the other hand it is possible for a JMS application to send ObjectMessages of different Java classes on a single Topic.
If the JSM application is sending MessageObjects for different object Classes on the same JMS Topic, then you cannot send this data into a single strongly-typed DDS Topic. What you could do in that case is either send the Java Object in a serialized form (i.e. make the DDS Type an Octet Sequence) and handle the de-serialization at the Application layer on the receiver side. This may be possible if it is also a Java application, otherwise it would seem hard. Alternatively you could convert the JMS ObjectMessage into some other generic format that can hold various types. For example a XML or JSON string and send that on DDS.
Both these approaches would hide the true data-type from DDS so some of the tools, for example data-visualization or content filtering would not be able to introspect the type.
If you know the complete set of Classes that may be received as ObjectMessages via JMS, then it may be possible to write a Java application that uses the reflection API to automatically create the equivalent IDL types. Then these could be put into a Union IDL type so that they can be published over single strongly-typed DDS Topic. The Java program would also need to generate the JMSToDynamicDataMessageTranslation class that the Routing Service JMS Adaptor uses to convert the received JMS Message into a DDS DynamicData object. I think writing this Java program could take a bit of work depending on how complex/generic you think those ObjectMessages classes can be.
I will check internally. I think at some point we had something written that was able to do some of this Java reflection.
Gerardo