This document is a resource for system administrators who configure, manage, and monitor WebLogic JMS resources, including JMS servers, stand-alone destinations (queues and topics), distributed destinations, and connection factories.
The document is relevant to production phase administration, monitoring, and performance tuning. It does not address the pre-production development or testing phases of a software project. For links to WebLogic Server documentation and resources for these topics, see Related Documentation.
It is assumed that the reader is familiar with WebLogic Server system administration. This document emphasizes the value-added features provided by WebLogic Server JMS and key information about how to use WebLogic Server features and facilities to maintain WebLogic JMS in a production environment.
Configuring Basic JMS System Resources, describes how to configure basic WebLogic JMS resources, such as a JMS server, destinations (queues and topics), and connection factories.
Configuring JMS Application Modules for Deployment, describes how to prepare JMS resources for an application module that can be deployed as a stand-alone resource that is globally available, or as part of an Enterprise Application that is available only to the enclosing application.
Deploying Applications to WebLogic Server is the primary source of information about deploying WebLogic Server applications, which includes standalone or application-scoped JMS resource modules.
Using the WebLogic Persistent Store in Configuring WebLogic Server Environments describes the benefits and use of the system-wide WebLogic Persistent Store.
Configuring and Managing the WebLogic Messaging Bridge explains how to configure a messaging bridge between any two messaging products—thereby providing interoperability between separate implementations of WebLogic JMS, including different releases, or between WebLogic JMS and another messaging product.
WebLogic Server Performance and Tuning contains information on monitoring and improving the performance of WebLogic Server applications, including information on how to get the most out of your JMS applications by using the administrative performance tuning features available with WebLogic JMS.
JMS Samples and Tutorials for the JMS Administrator
In addition to this document, BEA Systems provides JMS code samples and tutorials that document JMS configuration, API use, and key JMS development tasks. BEA recommends that you run some or all of the JMS examples before configuring your own system.
Avitek Medical Records Application (MedRec) and Tutorials
MedRec is an end-to-end sample J2EE application shipped with WebLogic Server that simulates an independent, centralized medical record management system. The MedRec application enables patients, doctors, and administrators to manage patient data using a variety of different clients.
MedRec demonstrates WebLogic Server and J2EE features, and highlights BEA-recommended best practices. MedRec is included in the WebLogic Server distribution, and can be accessed from the Start menu on Windows machines. For Linux and other platforms, you can start MedRec from the WL_HOME\samples\domains\medrec directory, where WL_HOME is the top-level installation directory for WebLogic Platform.
JMS Examples in the WebLogic Server Distribution
This release of WebLogic Server optionally installs API code examples in WL_HOME\samples\server\examples\src\examples, where WL_HOME is the top-level directory of your WebLogic Server installation. You can start the examples server, and obtain information about the samples and how to run them from the WebLogic Server Start menu.
Additional JMS Examples Available for Download
Additional API examples for download at http://codesamples.projects.dev2dev.bea.com. These examples are distributed as ZIP files that you can unzip into an existing WebLogic Server samples directory structure.
You build and run the downloadable examples in the same manner as you would an installed WebLogic Server example. See the download pages of individual examples for more information at https://codesample.projects.dev2dev.bea.com.
New and Changed JMS Features In This Release
WebLogic Server 9.2 includes the following improvements in the administration, availability, and performance of WebLogic JMS.
Client-Side Store-and-Forward for Reliable JMS Messaging
The WebLogic Store-and-Forward (SAF) service introduced in release 9.0 enables WebLogic Server to reliably deliver JMS messages between server-side JMS applications distributed across WebLogic Server clusters, domains, and server instances. For example, a JMS message producer connected to a local server instance can reliably forward messages to a JMS destination on a remote server instance, even though the remote destination may be temporarily unavailable when the message was sent.
In release 9.2, the JMS SAF Client provides a store-and-forward mechanism whereby standalone JMS clients can reliably send messages to server-side JMS destinations, even when a JMS client cannot temporarily reach a destination (for example, due to a network connection failure). While disconnected from the server, messages sent by a JMS SAF client are stored locally on the client and are forwarded to server-side JMS destinations when the client reconnects.
With the automatic JMS client reconnect feature, if a server or network failure occurs, some JMS client objects will attempt to transparently failover to another server instance, if one is available. In release 9.1 or later, WebLogic JMS message producers automatically attempt to reconnect to an available server instance without any manual configuration or changes to existing client code. For release 9.2, you can use the Administration Console or WebLogic JMS APIs to configure WebLogic JMS message consumers to automatically reconnect to an available server instance.
Release 9.0 introduced the Message Unit-of-Order feature, which groups messages by delivering messages within the unit one at a time. However, some applications need an even more restricted notion of a group. Therefore, release 9.2 introduces the Unit-of-Work feature, which allows applications to send JMS messages, identifying some of them as a group and allowing the consumer to process them as such. For example, an application can designate a set of messages that need to be delivered to a single client without interruption, so that the messages can, indeed, be processed as a unit.
The WebLogic Store administration utility allows you to troubleshoot a WebLogic Store or to extract its data. The most common uses-cases for store administration are for compacting a file store to reduce its size and for dumping the contents of a file store or JDBC store to an XML file for troubleshooting purposes. This utility can be run from a Java command line or from WLST.
Improved Non-Persistent Messaging Performance with One-Way Message Sends
You may greatly improve the performance of typical non-persistent messaging by using one-way message sends. By enabling the "One-Way Send Mode" option on your connection factory, its associated producers can send messages without internally waiting for a response from the target destination's host JMS server. You can choose to allow queue senders and topic publishers to do one-way sends, or limit this capability to topic publishers only. You can also configure a one-way window size to determine when a two-way message is required to regulate producer before they can continue making additional one-way sends.
JMSXDeliveryCount is a system generated property that specifies the number of message delivery attempts, where the first attempt is 1, the second is 2, and so on. WebLogic Server makes a best effort to persist the delivery count, so that the delivery count does not reset back to one after a server reboot. See Message Property Fields in Programming WebLogic JMS.
Deprecation of Messaging Bridge Adapter for WLS 5.1
BEA WebLogic Server 5.1 is retired and is no longer supported. In this release, the Messaging Bridge adapter used to interoperate with WebLogic Server 5.1 is deprecated and will be removed in the next major release. See WebLogic Server 5.1 End-of-Life Announcement in Supported Configurations.
WebLogic Server Value-Added JMS Features
WebLogic JMS provides numerous WebLogic JMS Extension APIs that go above and beyond the standard JMS APIs specified by the JMS 1.1 Specification. Moreover, it is tightly integrated into the WebLogic Server platform, allowing you to build secure J2EE applications that can be easily monitored and administered through the WebLogic Server console. In addition to fully supporting XA transactions, WebLogic JMS also features high availability through its clustering and service migration features, while also providing interoperability with other versions of WebLogic Server and third-party messaging providers.
The following sections provide an overview of the unique features and powerful capabilities of WebLogic JMS.
Enterprise-grade Reliability
Out-of-the-box transaction support:
Fully supports transactions, including distributed transactions, between JMS applications and other transaction-capable resources using the Java Transaction API (JTA), as described in Using Transactions with WebLogic JMS in Programming WebLogic JMS.
Fully-integrated Transaction Manager, as described in Introducing Transactions in Using WebLogic JTA.
File or database persistent message storage (both fully XA transaction capable). See Using the WebLogic Persistent Store in Configuring WebLogic Server Environments.
Message Store-and-Forward (SAF) is clusterable and improves reliability by locally storing messages sent to unavailable remote destinations. See Understanding the Store-and-Forward Service in Configuring and Managing WebLogic Store-and-Forward.
If a server or network failure occurs, JMS producer and consumer objects will attempt to transparently failover to another server instance, if one is available. See Automatic Failover for JMS Clients in Programming WebLogic JMS.
Supports connection clustering using connection factories targeted on multiple WebLogic Servers, as described in Configuring WebLogic JMS Clustering.
System-assisted configuration of Uniform Distributed Destinations that provide high availability, load balancing, and failover support in a cluster, as described in Using Distributed Destinations in Programming WebLogic JMS.
Automatic whole server migrationprovides improved cluster reliability and server migration WebLogic Server now supports automatic and manual migration of a clustered server instance and all the services it hosts from one machine to another, as described in Configuring WebLogic JMS Clustering.
Supports the JMS Delivery Count message property (JMSXDeliveryCount), which specifies the number of message delivery attempts, where the first attempt is 1, the second is 2, and so on. WebLogic Server makes a best effort to persist the delivery count, so that the delivery count does not reset back to one after a server reboot. See Message Property Fields in Programming WebLogic JMS.
Provides three levels of load balancing: network-level, JMS connections, and distributed destinations.
Enterprise-level Features
WebLogic Server fully supports the JMS 1.1 Specification, is fully compliant with the J2EE 1.4 specification, and provides numerous WebLogic JMS Extensions that go beyond the standard JMS APIs.
Provides robust message and destination management capabilities:
Administrators can manipulate most messages in a running JMS Server, using either the Administration Console or runtime APIs. See Managing JMS Messages.
Administrators can pause and resume message production, message insertion (in-flight messages), and message consumption operations on a given JMS destination, or on all the destinations hosted by a single JMS Server, using either the Administration Console or runtime APIs. See Controlling Message Operations on Destinations.
Message-Driven EJBs (MDBs) also supply message pause and resume functionality, and can even automatically temporarily pause during error conditions. See Message-Driven EJBs in Programming WebLogic Enterprise JavaBeans.
Modular deployment of JMS resources, which are defined by an XML so that you can migrate your application and the required JMS configuration from environment to environment without opening an enterprise application file, and without extensive manual JMS reconfiguration. See Overview of JMS Modules.
JMS message producers can group ordered messages into a single unit-of-order, which guarantees that all such messages are processed serially in the order in which they were created. See Using Message Unit-of-Order in Programming WebLogic JMS.
To provide an even more restricted notion of a group than the Message Unit-of-Order feature, the Message Unit-of-Work (UOW) feature allows JMS producers to identify certain messages as components of a UOW message group, and allows a JMS consumer to process them as such. For example, a JMS producer can designate a set of messages that need to be delivered to a single client without interruption, so that the messages can be processed as a unit. See Using Message Unit-of-Work in Programming WebLogic JMS.
Message Life Cycle Logging provides an administrator with better transparency about the existence of JMS messages from the JMS server viewpoint, in particular basic life cycle events, such as message production, consumption, and removal. See Message Life Cycle Logging.
Timer services available for scheduled message delivery, as described in Setting Message Delivery Times in Programming WebLogic JMS.
Flexible expired message policies to handle expired messages, as described in Handling Expired Messages in WebLogic Server Performance and Tuning.
Thin application client .JAR that provides full WebLogic Server J2EE functionality, including JMS, yet greatly reduces the client-side WebLogic footprint. See WebLogic JMS Thin Client in Programming Stand Alone Clients.
The JMS SAF Client enables standalone JMS clients to reliably send messages to server-side JMS destinations, even when the JMS client cannot temporarily reach a destination (for example, due to a network connection failure). While disconnected from the server, messages sent by the JMS SAF client are stored locally on the client and are forwarded to server-side JMS destinations when the client reconnects. See Reliably Sending Messages Using the JMS SAF Client in Programming Stand Alone Clients.
Automatic pooling of JMS client resources in server-side applications via JMS resource-reference pooling. Server-side applications use standard JMS APIs, but get automatic resource pooling. See Enhanced J2EE Support for Using WebLogic JMS With EJBs and Servlets in Programming WebLogic JMS.
Performance
WebLogic JMS features enterprise-class performance features, such as automatic message paging, message compression, and DOM support for XML messages:
WebLogic Server uses highly optimized disk access algorithms and other internal enhancements to provide a unified messaging kernel that improves both JMS-based and Web Services messaging performance. See Using the WebLogic Persistent Store in Configuring WebLogic Server Environments.
You may greatly improve the performance of typical non-persistent messaging with One-Way Message Sends. When configured on a connection factory, associated producers can send messages without internally waiting for a response from the target destination's host JMS server. You can choose to allow queue senders and topic publishers to do one-way sends, or to limit this capability to topic publishers only. You can also specify a "One-Way Window Size" to determine when a two-way message is required to regulate the producer before it can continue making additional one-way sends. See Configure connection factory flow control in the Administration Console Online Help.
Message paging automatically kicks in during peak load periods to free up virtual memory. See Paging Out Messages To Free Up Memory in WebLogic Server Performance and Tuning.
Administrators can enable the compression of messages that exceed a specified threshold size to improve the performance of sending messages travelling across JVM boundaries using either the Administration Console or runtime APIs. See Compressing Messages in WebLogic Server Performance and Tuning.
Synchronous consumers can also use the same efficient behavior as asynchronous consumers by enabling the Prefetch Mode for Synchronous Consumers option on the consumer's JMS connection factory, using either the Administration Console or runtime APIs. See Receiving Messages Synchronously in Programming WebLogic JMS
Supplies a wide variety of performance tuning options for JMS messages. See Tuning WebLogic JMS in WebLogic Server Performance and Tuning.
Supports MDB transaction batching by processing multiple messages in a single transaction. See Message-Driven EJBs in Programming WebLogic Enterprise JavaBeans.
JMS SAF provides better performance than the WebLogic Messaging Bridge across clusters. See Tuning WebLogic JMS Store-and-Forward in WebLogic Server Performance and Tuning.
DOM (Document Object Model) support for sending XML messages greatly improves performance for implementations that already use a DOM, since those applications do not have to flatten the DOM before sending XML messages. See Sending XML Messages in Programming WebLogic JMS.
Multicasting of messages for simultaneous delivery to many clients using IP multicast, as described in Using Multicasting with WebLogic Server in Programming WebLogic JMS.
Tight Integration with WebLogic Server
JMS can be accessed locally by server-side applications without a network call because the destinations can exist on the same server as the application.
Uses same ports, protocols, and user identities as WebLogic Server (T3, IIOP, and HTTP tunnelling protocols, optionally with SSL).
Web Services, Enterprise Java Beans (including MDBs), and servlets supplied by WebLogic Server can work in close concert with JMS.
Can be configured and monitored by using the same Administration Console, or by using the JMS API.
Fully supports direct interoperability from WebLogic Server 7.0 through WebLogic Server 9.2. For example, a release 7.0 client can interoperate with a release 9.2 server and vice-versa.
Messages forwarded transactionally by the WebLogic Messaging Bridge to other JMS providers — as well as to other instances and versions of WebLogic JMS, as described see Configuring and Managing WebLogic Messaging Bridge.
Supports mapping of other JMS providers so their objects appear in the WebLogic JNDI tree as local JMS objects. Also references remote instances of WebLogic Server in another cluster or domain in the local JNDI tree. See Foreign Server Configuration.
Uses MDBs to transactionally receive messages from multiple JMS providers. See Message-Driven EJBs in Programming WebLogic Enterprise JavaBeans.
Reliable Web Services integration with JMS as a transport, as described in Using Reliable Web Services Messaging in Programming WebLogic Web Services.
Integration with BEA Tuxedo messaging provided by WebLogic Tuxedo Connector. SeeHow to Configure the Tuxedo Queuing Bridge in the WebLogic Tuxedo Connector Administration Guide.
The Weblogic JMS C APIenables programs written in `C' to participate in JMS applications. This implementation of the JMS C API uses JNI in order to access a Java Virtual Machine (JVM). See WebLogic C API in Programming WebLogic JMS.
