JMS

The Java Messaging Service (JMS) has become the de facto standard for accessing message-oriented middleware products. It equips the Java developer with a powerful programming model that facilitates asynchronous, decoupled communication. WebLogic provides both the point-to-point and publish-and-subscribe models, as well as message persistence, flow control, guaranteed delivery, message redelivery, expiry, paging, concurrent message handling, and more. By supporting all of these features and enhancements, WebLogic offers a rich and robust framework for creating portable JMS applications that can operate and scale in a clustered environment.

All of the messaging facilities are implemented by a JMS server, which is pinned to a particular WebLogic instance. The JMS server in turn hosts a number of destinations (either topics or queues) with which clients can interact. In order to connect to the JMS server, you need to set up one or more connection factories. A connection factory encapsulates a number of properties that typically apply to all connections (and sessions) manufactured by it. Both the connection factories and JMS destinations are available in the server's JNDI tree.

WebLogic provides a number of ways to tune the performance of the JMS server. You can set up quotas that limit the number of messages that can be held in the server's memory, and enable paging so that the messages held in memory can be swapped out to a persistent store under threshold conditions. A JMS server can also throttle the rate at which JMS clients produce messages when it reaches threshold conditions. In extreme situations, it can temporarily block producers from sending messages. WebLogic 8.1 lets you customize the manner in which expired messages are handled.

JMS stores are needed for facilities such as persistent messaging, paging, and durable subscriptions. WebLogic JMS supports two kinds of JMS stores: a file store and a JDBC store. In some ways, JDBC stores are more flexible and easier to manage when a JMS server fails. Nevertheless, file stores offer a large performance advantage, especially when combined with the various asynchronous write policies.

WebLogic provides several ways of adjusting how messages are delivered and handled. For instance, you can set a delay between when messages are sent and when they arrive at a destination. You can also set up a schedule that determines the exact time periods when messages are delivered. Of course, you can set a maximum age for the message, which determines how long the message will be retained by the system. And you can decide how JMS messages are redelivered, when a JMS session needs to recover, or when a transacted session needs to roll back. Messages intended for topics can be delivered to subscribers using the more optimal network multicasts, but at the expense of reliability. Producers can send (or broadcast) preacknowledged messages so that consumers need not acknowledge their receipt.

WebLogic JMS also introduces an additional message type for handling XML data. The message selector syntax has been augmented to allow XPath filters that can inspect the contents of the message body. Its support for a server-side pool of JMS sessions provides an alternative way to concurrently handle incoming messages, much like message-driven beans. Of course, WebLogic JMS is XA-enabled, which means that all activity within a JMS session can occur within the scope of a JTA transaction, alongside other XA-aware resources. In fact, WebLogic JMS neatly integrates with standard J2EE components so that your servlets and EJBs can automatically benefit from connection pooling, distributed transactions, and container-managed security.

WebLogic's JMS is designed to operate in a clustered environment. Connection factories deployed to a cluster can automatically route JMS requests to the pinned JMS server. Client requests for a JMS connection are automatically load-balanced among the available servers that host the connection factory. WebLogic JMS also introduces the notion of a distributed destination, which represents a number of physical destinations hosted on different JMS servers in the same cluster. Both consumers and producers are load-balanced among the members of this distributed destination. Unfortunately, WebLogic cannot automatically failover consumers when a member of the distributed destination becomes unavailable. Message producers can however, silently failover in certain situations, depending on how they are configured. Still, subsequent consumers and producers can be load-balanced among the remaining members of the distributed destination set. To better support availability, you can migrate a JMS server to another WebLogic instance, when required.

Finally, WebLogic provides two ways to integrate with other messaging systems. First, you can use a messaging bridge to connect WebLogic JMS with another JMS provider and thereby interoperate with a third-party enterprise messaging system. Alternatively, you can directly set up a foreign JMS server and make its connection factories and destinations available to JMS clients of WebLogic.