WebLogic Support for JMS

WebLogic Server complies with the JMS 1.0.2b version of the J2EE 1.3 specifications.

WebLogic JMS Architecture

The WebLogic JMS architecture has the structure illustrated in Figure 15.5, and described here:

• Message producers and message consumers A message sender is called a message producer. A message receiver, on the other hand, is called a message consumer. These two entities are represented by the classes MessageProducer and MessageConsumer, respectively. These objects are associated with a destination, that is, a queue or a topic.

• Session A Session object creates the MessageProducer and MessageConsumer objects. This Session object defines an order in which the messages are to be produced and consumed. A single session can have multiple message producers and consumers. Messages can be produced and consumed on the same thread. If the application requires the messages to be produced and consumed on different threads, different session objects have to be used to create the message producers and consumers.

• Connection A Session object is created using the Connection object, which in turn is created from a ConnectionFactory object through a JNDI lookup. You will look at how to start, stop, and close a connection a little later. Connections enable multiple threads to access the same objects simultaneously.

Figure 15.5. WebLogic JMS architecture.

WebLogic fully implements the JMS API. Hence, the two basic models of messaging, point-to-point and publisher-subscriber, are provided by WebLogic. The following points about each of these models are worth noting:

• Point-to-point In this kind of messaging, as mentioned earlier, multiple senders can deliver messages to the destination (queue), but the message can be delivered to one and only one receiver. If more receivers are polling the queue for messages, then WebLogic delivers the message to a receiver on a first-come-first-served basis. This means that the message is delivered to the receiver that first requests the message from the destination. If there are no receiving applications already waiting on the destination for a message, WebLogic keeps the message until a receiver associates itself with the destination to pick up the message or until the message times out, whichever comes first.

• Publisher-subscriber In this kind of messaging, the message is held in the destination (topic) until all the subscribing applications receive the message. In this model, WebLogic supports durable subscribers, to which you can assign a name and with which you can associate a user or application. In this case, the message persists in a file or a database until the message is delivered to the subscriber or the message has expired, whichever comes first. By default, subscribers are nondurable; that is, the messages are delivered to the subscriber only if the subscriber is active.

WebLogic has two classes or APIs that extend the JMS API: weblogic.jms.ServerSessionPoolFactory and weblogic.jms.extensions.

In addition to these classes, WebLogic provides a number of useful features.

Message Persistence

A message can either be persistent or nonpersistent. This has to be defined while you configure your destination. A persistent message is one that is not considered delivered unless and until it has been written to a database or a file. The message is delivered at least once. If the message is defined as persistent, then a flat file, a paging store, or a JDBC database has to be specified.

Concurrent Message Processing

The ServerSessionPoolFactory class enables concurrent message processing. This is used to create a factory of a server-side ServerSessionPool. The default value, weblogic.jms.ServerSessionPoolFactory, is associated with the name of the server on which this ServerSessionPoolFactory object is created. This can be associated with the name of the server by adding :<name_of_server> in front of the default weblogic.jms.ServerSessionPoolFactor. This default ServerSessionPoolFactory object is created and bound to a WebLogic JNDI namespace during WebLogic Server startup.

The ServerSessionPool objects that are created in the ServerSessionPoolFactory are WebLogic application server objects, which enable the consumers to establish a connection to the destination to concurrently process messages. These objects are created when the ServerSessionPoolFactory object is created at WebLogic startup.

A ServerSessionPool object, as the name suggests, is a pool of ServerSession objects, which are also application server objects and help associate a thread of your application with the JMS session by providing the context to create, read, and send messages.

A ConnectionConsumer object is used to process incoming messages using a ServerSessionPool object. The ConnectionConsumer object performs the task of load balancing in case there is heavy message traffic by assigning multiple messages to a single destination to avoid context thread switching.

Distributed Destinations

In the case of clustering, WebLogic allows you to create multiple physical destinations (queues or topics). This ensures service continuity in case of a server failure in a clustered environment. A failure of any server results in redirection of the messages to a destination on another server in the cluster.

WebLogic Message Bridging

In the case of distributed destinations, message bridging is responsible for the transfer of messages between two JMS providers. This feature helps in configuring a store (as described earlier regarding message persistence) and in forwarding the messages from one JMS provider to another. This feature is brought about by using JTA transactions. Also, these messages can be delivered to a group of hosts using multicast IP addresses.

Temporary Destinations

Temporary queues and topics can be created using the WebLogic JMS API. Temporary destinations last through a connection; that is, a temporary destination lives as long as the current connection is alive or until the temporary destination is deleted. Hence, messages used in temporary destinations are by default nonpersistent. To create temporary destinations, the corresponding methods of the Session class are used to return a QueueSender or TopicPublisher object. Also, a JMS template has to be created through the Administration Console. After a temporary destination has been created, it has to be deleted. Code snippets to create and then destroy a temporary destination follow:

 //in case of a queue destination  try{   QueueSender = Session.createTemporaryQueue(); } catch(JMSException jmsEx){        JmsEx.printStackTrace(); } //in case of a topic destination try{   TopicPublisher = Session.createTemporaryTopic(); } catch(JMSException jmsEx){        JmsEx.printStackTrace(); } //to delete a temporary queue destination try{    QueueSender.delete(); } catch(JMSException jmsEx){   jmsEx.printStackTrace(); } //to delete a temporary topic destination try{    TopicPublisher.delete(); } catch(JMSException jmsEx){   jmsEx.printStackTrace(); } 

Message Paging

This is a new feature of WebLogic Server 7.0. This feature enables swapping messages from the virtual memory into persistent storage in order to free virtual memory when the load of the destination reaches a specified limit. Because messages can be really large, this feature can help improve performance greatly.

Flow Control

This feature helps in managing the performance of the destinations. When the load of messages on the JMS server or destination reaches the threshold, then the WebLogic Server sends a message to the producers to limit the message flow.

High-Availability Enhancement

WebLogic Server has implemented a migration framework for clustered environments. This feature is used by the WebLogic Server to respond appropriately to migration requests. This feature brings the JMS server online and offline in a methodical fashion in case of scheduled tasks or in case of WebLogic Server failure.

Additional Features

Using the WebLogic JMS extension API, you can

• Create XML messages

• Define session exception listeners

• Define scheduled delivery times and redelivery time delays for messages

• Define producers' delivery time

• Support pre-6.0 JMS MessageID formats and their conversion into WebLogic JMS 7.0 format

• Create permanent queues and topics dynamically

• Define and display the preconfigured value of permitted asynchronous messages in a session