JMS and CORBA Notification Interworking
Pages: 1, 2

Message

Related Reading Java Message Service By Richard Monson-Haefel & David Chappell Table of Contents Index Sample Chapter Full Description Read Online -- Safari

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:

1. DeliveryMode: If delivery mode is PERSISTENT the EventReliability QoS in the variable header of a structured event is set to Persistent. If delivery mode is NON_PERSISTENT, the Notification EventReliability QoS is set to BestEffort.
2. Expiration: The JMS expiration in milliseconds is set in the Timeout QoS in the variable header of structured events. Expired messages are not visible to clients.
3. Priority: The message priority is mapped to the Notification Priority QoS 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 boolean, byte, short, int, long, float, double, or String; these types are converted to IDL using the standard language mapping.

Map Message

A 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

A bytes message supports a body with uninterpreted data. The message supports the methods of the DataInputStream and 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

An object message provides a body that can contain any Java object that supports the 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 OctetSeq 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

A 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 AnySeq data type. The elements in this sequence are mapped using the standard Java-to-IDL mapping.

Text Message

A 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 any.

Figure 4. Mapping between JMS message and structured event.

Message Filtering

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
StructuredEvent	Message
EventChannel	Queue
EventType	Topic
StructuredPushConsumer	MessageConsumer
StructuredPushSupplier	MessageProducer

Conclusion

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.