JMS and CORBA Notification Interworking
Pages: 1, 2
The Message interface is a base interface for all JMS messages. Since all JMS messages are interfaces, it is the responsibility of vendors of JMS client libraries to provide message implementations. A JMS message consists of a header, a set of properties and a body. The body part is different for each of the five different JMS message types. The header and properties are the same for all message types.
JMS only allows clients to filter on the message properties. To ensure that only message headers may be filtered, this information must be packaged into the filterable body of a structured event. This is the only information from JMS messages that becomes part of the filterable body. The Message interface supports three attributes that have well-defined meanings in the Notification Service:
- DeliveryMode: If delivery mode is
EventReliabilityQoS in the variable header of a structured event is set to
Persistent. If delivery mode is
NON_PERSISTENT, the Notification
EventReliabilityQoS is set to
- Expiration: The JMS expiration in milliseconds is set in the
TimeoutQoS in the variable header of structured events. Expired messages are not visible to clients.
- Priority: The message priority is mapped to the Notification
PriorityQoS in the variable header of structured events. Priority delivery mode is used to ensure that messages with higher priority are delivered before messages with lower priority.
The user-defined name/value pairs of a message can be any of the Java types
String; these types are converted
to IDL using the standard language mapping.
map message supports the
Message interface and provides a body of name/value
pairs. The body can conveniently be inserted into the remainder of the body field
of a structured event using the
PropertySeq data type, which is a sequence of
name/value pairs defined in the Notification Service IDL.
bytes message supports a body with uninterpreted data. The message supports
the methods of the
DataOutputStream interfaces from the
Java I/O package. As the body is an array of bytes, it is written to the remainder
of the body field of a structured event using an IDL octet sequence.
object message provides a body that can contain any Java object that supports
Serializable interface. This type of message is serialized onto a byte sequence
and written onto the array in the remainder of the body using the same
data type described above. On the receiver side, the byte sequence is converted
to an object input stream from which the object is read.
stream message adds a body that is a stream of objects. The objects on the
stream stack are written onto the remainder of the body using the
type. The elements in this sequence are mapped using the standard Java-to-IDL
text message provides a body, which is a Java String. The body is inserted
into a structured event by simply inserting the string into the
The Notification Service filtering uses a very rich grammar known as the Extended
Trader Constraint Language, while JMS uses the
where clause from SQL92. In order
to produce an interworking solution, it is necessary to extend the Notification
Service to support the SQL92 grammar defined in the JMS specification. In the
Notification Service, this grammar allows application developers to filter on
properties in the filterable body of structured events. The advantages of this
design are that filtering occurs on the server side to reduce network traffic
and that non-JMS applications can filter using SQL92.
Notification Service Extensions
The Notification Service is conceptually centered around a master queue, which contains all events that have been delivered to an event channel but not yet delivered to all connected consumers. Events in the master queue can be marked as persistent using different databases, in which case they will be recovered and re-delivered after a server crash.
The master queue disseminates events into a set of connected delivery queues. Each delivery queue represents an event consumer. The delivery queue supports various QoS properties such as ordering and discard policies, maximum queue size, etc. Also, the delivery queue supports fine-grained filtering using a variety of different constraint languages.
The delivery queue interface is similar to the JMS message consumer, which makes it easy for a JMS consumer to connect to and receive messages from a delivery queue. Since topics are implemented using the coarse-grained filtering, it is feasible to have one channel that receives and disseminates the publish/subscribe messages.
The master queues which are used as message stores by event channels support additional QoS properties that allow them to support JMS point-to-point functionality:
- Acknowledge level: This determines the level at which events are acknowledged. It can be set to either local or global, depending on whether the channel requires a publish/subscribe or a point-to-point queue. A publish/subscribe queue would set this to local, because when one topic subscriber acknowledges an event it will not affect any other subscribers. A point-to-point queue has global acknowledgement, because when one queue receiver acknowledges an event it will not be visible to any other receivers -- it will be entirely removed from the master queue.
- Initial queue: This determines the initial contents of the queue visible to a connected consumer. It can be set to all or none, again depending on whether the channel requires a publish/subscribe or a point-to-point queue. A publish/subscribe queue would set this to none, because a topic subscriber will only see events received by the channel after the subscriber was connected. A point-to-point queue initially has all events available in the master queue, because it will also receive unacknowledged events received prior to connecting.
In addition to the general queue QoS properties described above, the OpenFusion Notification Service supports a QoS property to set the message acknowledge mode. This QoS property applies to the delivery queue and can be set to automatic, client, or lazy, in a similar manner to the JMS acknowledge modes. Again, this allows non-JMS applications to take advantage of these additional QoS properties.
Table 1 shows how interfaces in the Notification Service correspond to interfaces in JMS. As described above, topics are represented as event types that all get communicated on an event channel with the channel name "pubsub" while queues corresponds to individual channels with a name corresponding to the queue name. Structured events are mapped to messages as described earlier.
A JMS message consumer is a structured push consumer, which is connected to a delivery queue. This means the message consumer can be either a pull or a push consumer depending on the preferred style of the developer. Finally, a message producer is a structured push supplier, which simply sends messages using a push model.
Table 1: Relation between Notification Service and JMS interfaces.
|Notification Service||Java Message Service|
The Java Message Service is an important API because it provides simplified access to enterprise messaging systems from Java applications. Also, JMS is the API for messaging in an EJB environment, which is now becoming the platform of choice for service-side Java development. Although the JMS API is quite straightforward, it provides all the features that are expected from messaging middleware systems.
Many new applications are being built on the Java platform, but there will always be a need to integrate applications across operating systems and programming languages. Although fast, reliable, and transactional message delivery is provided by JMS, many applications will also require that JMS integrate easily with both non-Java components and other messaging systems.
This article has described how the CORBA Notification Service is being expanded
to support JMS. The mapping between the Notification Service and JMS is open
and easy to use, which means that it is straightforward to support integration
between pure JMS applications and other non-Java applications.
Steve Trythall is a senior manager for Prismtech Ltd, and an expert Java developer with experience in CORBA technologies and Java-CORBA interoperability.
Return to ONJava.com.