JMS and CORBA Notification Interworking

Asynchronous messaging is a proven communication model for developing large-scale, distributed enterprise integration solutions. As opposed to regular request/reply-based communications in traditional client-server systems, messaging provides more flexibility and scalability because senders and receivers of messages are decoupled and are no longer required to execute in lockstep.

In addition to the traditional requirements for a messaging system, most application integration solutions also have a basic need for interoperability of messaging, since components often execute in a heterogeneous environment. Although Java Message Service (JMS) is a powerful API for pure Java environments, many integration solutions being developed today require the JMS server to be capable of communicating with:

1. Components written in languages other than Java.
2. CORBA components.
3. Other proprietary MOM (Message Oriented Middleware) products for which a CORBA gateway exists.

These requirements are adequately met by the CORBA Notification products available from several messaging vendors. In response to the demonstrated need to integrate CORBA Notification and JMS, the OMG (Object Management Group) is currently working on standardizing interworking. Vendors such as PrismTech are also working ahead of the standards efforts to produce commercial solutions.

This article introduces JMS and CORBA Notification and describes the challenges being addressed by the OMG in providing an interworking solution.

CORBA Notification

The Notification Service is an OMG standard that allows multiple event suppliers to send events to multiple event consumers. It is a mature standard that has been one of the OMG's success stories. It has been widely used in a range of scenarios, such as the integrating mechanism for disparate telecom equipment, within large- scale routers on the Internet backbone, part of e-commerce frameworks for major banks, and as the messaging infrastructure to link satellites and their ground stations.

Notification differs from JMS in that its specification covers both the client interface and the messaging engine. Suppliers are de-coupled from consumers by means of an event channel, which takes care of client registration and de-registration and dissemination of events to multiple consumers. The channel also accommodates slow or unavailable consumers.

The Notification Service supports both push and pull models, and the architecture allows event channels to be federated without the use of intermediators. It extends the event service to include event filtering and a comprehensive "quality of service" (QoS) framework. Some of the more important QoS properties include:

• Persistent events and connections to support guaranteed delivery.
• Queue management to support ordering and discard policies.
• Event start and stop times to delay and time out events.

The Notification Service also supports the concept of a structured event, which qualifies as a "proper" message in terms of message middleware systems. The main interfaces in the Notification Service are depicted in Figure 1, which also shows that the Notification Service supports un-typed, structured, and sequence client types for sending and receiving events.

A developer will typically perform the following steps in Notification Service client applications:

1. Obtain a reference to an event channel, e.g., create one using the event channel factory.
2. Get or create an administration object; a supplier must use a "supplier administration object," while a consumer must use a "consumer administration object."
3. Create a proxy object, which is a connection end point. Suppliers use proxies to send events, while consumers use proxies to receive events.
4. Attach filters to administration or proxy objects if necessary.

One of the more important architectural features of the Notification Service is that it supports channel federation without the use of intermediators that forward events from one channel to another; a proxy supplier can be connected directly to a proxy consumer. This feature implies that routing with the Notification Service can be achieved very easily for improved reliability, scalability, and performance. Since the Notification Service is based on the CORBA architecture, it also supports integration with applications not written in Java.

Several commercial implementations of the Notification Service are available from Hitachi, NEC, Fujitsu, and PrismTech. Typically, these products also include a suite of management tools to support the service.

JMS

The Java Message Service (JMS) defines a standard API that allows Java developers to easily build enterprise integration solutions. JMS is important in its own right because it provides a simplified and common way for Java clients to access message-oriented middleware. For example, JMS interfaces have been produced to both IBM and Tibco's messaging products. More importantly, with the introduction of message-driven beans (MDB), JMS has become even more tightly integrated into J2EE. This provides an asynchronous manner for Enterprise Java Beans (EJBs) to communicate with other elements in a distributed architecture. In a relatively short space of time, JMS has become an enormously popular messaging paradigm and enjoys support from all of the major messaging vendors.

It should also be recognized that JMS was designed as an abstraction over existing (and new) messaging products. This has a number of benefits, including the ability to replace message systems with no or few client modifications. This abstraction has also resulted in the following characteristics:

• JMS is purely an interface. In order to transport and route messages, some form of messaging engine is required. The JMS specification has nothing to say about the engine, its architecture, or the transport. This has led to a wide range of different solutions from different vendors.
• The JMS specification does not facilitate interoperability between different implementations. This is a natural consequence of the previous point. If the specification does not mandate a transport protocol and wire format, then there will never be interoperability.
• Compared to the proprietary MOM products, JMS has a relatively simple set of six message formats.

JMS supports a point-to-point (or queue) model and a publish/subscribe model, and it defines a number of message types that publishers and subscribers can exchange. Messages support properties that define how they should be treated by the message system. Subscribers can filter messages using an SQL grammar. Clients can be transient or durable, and messages can be sent or received in the context of a transaction.

Figure 2 shows the main concepts in JMS. Although the publish/subscribe and point-to-point communication models are very different from a conceptual point of view, the authors of JMS realized that the models have a lot in common. JMS is therefore centered on a generic messaging model, and publish/subscribe and point-to-point are derived (in the sense of interface inheritance) from the generic model.

The boxes in Figure 2 represent interfaces with the point-to-point interfaces on the left and the publish/subscribe interfaces on the right. The arrows leading from top to bottom in the figure represents the typical steps that a JMS developer performs developing client applications:

1. Resolve a connection factory and a destination from JNDI. A destination is either a queue or a topic.
2. Create a connection using the connection factory.
3. Create a session with the desired properties from the connection.
4. If the application is a supplier, create a MessageProducer; if the application is a consumer, create a MessageConsumer from the session.
5. Start to send or receive messages using the producer or consumer object. A producer will use the session to create different kinds of messages.

JMS supports six different kinds of messages, which are used to carry different types of payload. The header of a message is the same regardless of the payload, which means that filtering is the same for all six message types. A message supports a number of properties to set priority, reliability, and other QoS properties, which will be interpreted and handled by the JMS server.

In order to properly support durable messages, JMS uses the notion of a durable subscriber. This is only necessary in the publish/subscribe model, as messages on a queue will be consumed by any queue receiver that connects to the queue in question. A durable subscriber is identified by a name, and the same operation is conveniently used to both create and re-create the subscriber.

In addition to the interfaces depicted in Figure 2, JMS supports a number of interfaces for transactional message delivery and consumption. The connection factory, connection, and session interfaces each have an interface with the XA prefix, which supports the Java Transaction API (JTA) for distributed transactions. This is typically supported when JMS is integrated into an application server.

Finally, JMS supports an expert facility called a "connection consumer." Although regular JMS clients will seldom use this API, it supports a portable way for integrating a JMS system into an application service. The connection consumer is used by application services to link a Message-Driven Bean to the functionality provided by a JMS vendor.

Integration Points

Although there is a comfortable overlap between the JMS and Notification Service communication models and capabilities, there are three areas where the integration must necessarily be defined:

• The Notification Service supports a message, which is a structured event and defined in IDL. JMS supports six different message formats with different message bodies.
• The Notification Service supports a different filter grammar than JMS.
• The Notification Service only supports a publish/subscribe model. JMS supports both a publish/subscribe model and a point-to-point model.

We will describe how these issues are being addressed by the OMG standards work and by commercial implementations such as PrismTech's OpenFusion.

Message Conversions

The JMS specification defines five different messages that all derive common functionality from the base Message interface. JMS messages are conceptually transmitted using the Notification Service, as depicted in Figure 3. Since JMS does not define a wire protocol, some type of message mapping is required.

JMS supports two ways of receiving events: a pull model or a push model. In the pull model, a JMS client invokes a method on the message consumer in order to receive an event. In the push model, the consumer registers a callback object with the consumer or session and messages are received asynchronously by invocations of the onMessage method in the callback interface.

Both models for receiving events map well to the Notification Service push and pull models. It is not possible, however, for a Notification Service consumer to be both a push and a pull consumer. It is expected, therefore, that the Notification Service will be extended to support a new delivery queue object that is similar to the JMS message consumer interface.