Browse Prior Art Database

A method for dynamic creation of JMS Destinations based on DDS topic discovery events Disclosure Number: IPCOM000180176D
Original Publication Date: 2009-Mar-05
Included in the Prior Art Database: 2009-Mar-05
Document File: 2 page(s) / 44K

Publishing Venue



This publication discusses how a JMS provider interoperating in a DDS (Data Distribution Service) environment can utilise DDS discovery data and make the topics available to the JMS application environment.

This text was extracted from a PDF file.
This is the abbreviated version, containing approximately 52% of the total text.

Page 1 of 2

A method for dynamic creation of JMS Destinations based on DDS topic discovery events

If a Java* Message Service provider decides to create a product that can interoperate with the real-time technology called DDS (Data Distribution Service) then it would be advantageous for the JMS provider to allow the JMS application to interact with the DDS topic spaces.

    Part of the DDS specification discusses broadcasting meta-data, on a regular basis, about topics currently active (or newly active) this is called "discovery" (DDS only has topics - there are no queues). Part of this discovery information is a set of attributes describing the Quality Of Service (QoS) the publisher and subscriber are expected to have when sending updates on Objects in the topic. The concept being that a DDS reader or writer looks at the topic and sets their QoS according to the hints set on the topic. by the administrator of the system.

    This article discusses the ability to create JMS destinations dynamically from this topic meta-data so that DDS - enabled JMS applications, can interoperate within DDS environments.

    DDS broadcasts information about new and previously created topics into the network. This information includes the name of the topic and various attributes of that topic (in DDS terms these attributes are called Quality of Service - QoS). This information is broadcast so that all DDS processes within the domain can see the information.

    A DDS - enabled JMS provider will have the standard concept of JMS destinations - typically as administered objects. These standard JMS destinations can have the DDS QoS added to them so that the JMS applications can utilise the same QoS as a DDS application.

    The key element here is that the JMS provider listens for and transforms the DDS discovery data into JMS destination objects. The JMS objects are then republished, as provider specific JMS ObjectMessages, onto a well-known JMS destination (probably a topic but could be a queue).

    There are two potential ways that this destination object can now be handled from within the JMS environment.
1) Either the JMS application itself listens on the well-known JMS destination, from within the JMS environment and dynamically reacts to the new destinations.

2) the JMS destinations are placed into JNDI so that the JMS applications can use them as per normal without ev...