Skip navigation.

eDocs Home > BEA WebLogic Server 9.0 Documentation > Configuring and Managing WebLogic JMS > Introduction and Roadmap

Configuring and Managing WebLogic JMS

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index View as PDF   Get Adobe Reader

Introduction and Roadmap

This section describes the contents and organization of this guide—Configuring and Managing WebLogic JMS.

 

Document Scope and Audience

This document is a resource for system administrators responsible for configuring, managing, and monitoring WebLogic JMS resources, such as JMS servers, standalone destinations (queues and topics), distributed destinations, and connection factories.

The topics in this document are relevant to production phase administration, monitoring, or performance tuning topics. This document 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.

 

Guide to This Document

 

Related Documentation

This document contains JMS-specific configuration and maintenance information.

For comprehensive guidelines for developing, deploying, and monitoring WebLogic Server applications, see the following documents:

 

JMS Samples and Tutorials for the JMS Administrator

In addition to this document, BEA Systems provides a variety of JMS code samples and tutorials that show JMS configuration and API use, and provide practical instructions on how to perform 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 provides a framework for 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.

MedRec includes a service tier comprised primarily of Enterprise Java Beans (EJBs) that work together to process requests from web applications, web services, and workflow applications, and future client applications. The application includes message-driven, stateless session, stateful session, and entity EJBs.

JMS Examples in the WebLogic Server Distribution

WebLogic Server 9.0 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 9.0 Start menu.

Additional JMS Examples Available for Download

Additional API examples for download at http://dev2dev.bea.com/code/index.jsp. 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 http://dev2dev.bea.com/code/index.jsp.

 

New and Changed JMS Features In This Release

WebLogic Server 9.0 introduces major changes in the configuration, deployment, and dynamic administration of WebLogic JMS.

JMS 1.1 Specification Support

WebLogic Server 9.0 is compliant with the JMS 1.1 Specification for use in production, and so supports unified APIs that work for both queues and topics. For more information, see the Java JMS technology page on the Sun Web site at http://java.sun.com/products/jms/.

Modular Configuration and Deployment of JMS Resources

JMS configurations in WebLogic Server 9.0 are stored as modules, defined by an XML file that conforms to the weblogic-jmsmd.xsd schema, similar to standard J2EE modules. An administrator can create and manage JMS modules as global system resources, as modules packaged with a J2EE application (as a packaged resource), or as standalone modules that can be made globally available. With modular deployment of JMS resources, you can migrate your application and the required JMS configuration from environment to environment, such as from a testing environment to a production environment, without opening an enterprise application file (such as an EAR file) or a JMS standalone module, and without extensive manual JMS reconfiguration.

For more information, see Configuring JMS System Resources.

Store-and-Forward for Highly Available Message Production

The JMS Store-and-Forward feature is built on the WebLogic Store-and-Forward (SAF) service to provide highly available JMS message production. For example, a JMS message producer connected to a local server instance can reliably forward messages to a remote JMS destination, even though that remote destination may be temporarily unavailable when the message was sent. Persistent JMS messages are always forwarded with Exactly-once quality of service provided by the SAF. For non-persistent JMS messages, applications can also use the At-least-once and At-most-once qualities of service. JMS store-and-forward works with all WebLogic JMS features, including new features introduced in release 9.0.

For more information, see Understanding the Store-and-Forward Service in Configuring and Managing WebLogic Store-and-Forward.

Enhanced Run-time Message Management

New message administration enhancements greatly enhance a JMS administrator's ability to view and browse all messages, and to manipulate most messages in a running JMS Server, using either the Administration Console or through new public runtime APIs. These message management enhancements include message browsing (for sorting), message manipulation (such as move and delete), message import and export, as well as transaction management, durable subscriber management and JMS client connection management.

For more information on managing messages, see Monitoring JMS Statistics and Managing Messages.

Pause and Resume Message Operations on Destinations

New WebLogic JMS configuration and runtime APIs enable an administrator to 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, either programmatically or administratively. A potential use of this feature is asserting administrative control of the JMS subsystem behavior in the event of an external resource failure. Otherwise, such a failure could cause the JMS subsystem to ignore the external failures and overload the system (both server and clients) by continuously accepting and delivering (redelivering) messages.

For more information, see Controlling Message Operations on Destinations.

More Transparency with Message Life Cycle Logging

The message life cycle is an external view of the basic events that a JMS message will traverse through once it has been accepted by the JMS server, either through the JMS APIs or the JMS Message Management APIs. Therefore, 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.

For more information, see Message Life Cycle Logging.

Debug and Diagnostic Information More Readily Available

In Weblogic Server 9.0, the JMS subsystem uses the new system-wide diagnostics service for centralized debug access and logging. With this new service, enabling debugging is easy, and debug and diagnostic information is more readily available so you can easily diagnose and fix problems.

For more information, see Understanding the WebLogic Diagnostic Framework.

Strict Message Ordering with Unit-of-Order

The Unit-of-Order feature goes beyond the message delivery ordering requirements in the JMS 1.1 Specification by providing JMS message producers with the ability to group ordered messages into a single unit. This single unit is called a Unit-of-Order and it guarantees that all messages created from that unit are processed sequentially in order by the same consumer until that consumer acknowledges them or it is closed. For example, if a queue has messages with many consumers, and each message has an account number as a Unit-of-Order, then two consumers will not process messages with the same account number at the same time. A Unit-of-Order can be created programmatically with new JMS API extensions to the JMSMessageProducer interface, or administratively by specifying a Unit-of-Order on a connection factory.

For more information, see Using Message Unit-of-Order in Programming WebLogic JMS.

Uniform Configuration of Distributed Destinations

This release of WebLogic Server introduces a new type of distributed destination, termed Uniform Distributed Destination, that greatly simplifies the management and development of distributed destination applications. By using the Uniform Distributed Destination feature, the administrator no longer needs to create or designate destination members, but relies on the system to uniformly create the necessary members on the JMS servers to which a JMS module is targeted. This feature ensures the consistent configuration of all distributed destination parameters, particularly in regards to weighting, security, persistence, paging, and quotas. The Weighted Distributed Destination feature is still available for those who want to manually fine-tune distributed destination members.

For more information, see Configuring Distributed Destinations.

Access to JMS Applications from "C" Clients

The Weblogic JMS C API enables 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). The JMS C API does not support WebLogic JMS extensions, JMS Object messages, and Java MBean management.

For more information, see WebLogic C API in Programming WebLogic JMS.

Message-Driven Bean (MDB) Enhancements for JMS

MDB enhancements enable support for transaction batching (via processing multiple messages in a single transaction), and for load balancing MDB instances across member destinations in different clusters or domains, regardless of whether the MDB and destination reside in the same cluster or in different clusters or domains.

For more information, see Message-Driven Bean Enhancements in the Release Notes.

Document Object Model (DOM) Support for XML Messages

This feature enhances the WebLogic JMS API to provide native support for the Document Object Model (DOM) when sending XML messages. This will greatly improve performance for implementations that already use a DOM, since those applications will not have to flatten the DOM before sending XML messages.

For more information, see Sending XML Messages in Programming WebLogic JMS.

Flexible and Simplified Destination Quotas

The new destination quota objects for JMS modules allows administrators to configure named quota objects and then have destinations refer to them. To increase flexibility, destinations can be assigned their own quotas; multiple destinations can share a quota; or destinations can share the JMS server's quota. In addition, a destination that defines its own quota now no longer also shares space in the JMS server's quota. JMS servers still allow the direct configuration of message and byte quotas. However, these attributes are only used to provide quota for destinations that do not refer to a quota object.

For more information, see Defining Quota.

Improved Message Paging

The message paging feature for freeing up virtual memory during peak message load situations is always enabled on JMS servers. Additionally, administrators no longer need to create a dedicated message paging store since paged out messages can be stored in a directory on your file system. However, for the best performance you should specify that messages be paged to a directory other than the one used by the JMS server's persistent store.

For more information, see Paging Out Messages To Free Up Memory.

Message ID Propagation Security Enhancement

This enhancement introduces the JMSXUserID property, which provides the ability to identify the user who produced a message when the message is received. With this property, the recipient has the option of querying the message property to find out who sent the message, and then could possibly run different logic in the application, depending on who the initiator was. The message sender requests the user identity by using a connection factory with the AttachJMSXUserID attribute enabled. The delivery of the user identity is controlled by the Attach Sender value on destinations, which can also be managed for multiple destinations by using a JMS template.

Message Bridge Enhancements

The message bridge functionality has been improved with the following enhancements:

For more information, see "Configuring and Managing a Messaging Bridge" in Configuring and Managing WebLogic Messaging Bridge.

Automatic Compression of Messages

This feature enables the compression of messages that exceed a specified threshold size to improve the performance of sending messages travelling across JVM boundaries. A threshold can be set programmatically using a new JMS API extension to the JMSMessageProducer interface, or administratively by either specifying a value on a connection factory or on a SAF remote context. Once configured, message compression is triggered on producers for message sends, on connection factories for message receives and message browsing, or through SAF forwarding.

For more information, see Compressing Messages.

 

Deprecated JMS Features, Methods, Interfaces, and Methods

In WebLogic Server 9.0, many changes were made to the JMS subsystem, including the removal of some classes and the deprecation of many configuration MBeans.

Legacy JMS Resource Configuration Interfaces

The new module-based method of configuring WebLogic JMS resources uses Java Descriptor Bean interfaces to create JMS system modules and deployable packaged modules. This fundamental change necessitated the deprecation of the following MBean interfaces:

The new Descriptor Bean interfaces are documented in "WebLogic Server System Module Beans" in the WebLogic Server MBean Reference. The root bean that represents an entire JMS module is named JMSBean.

For more information about JMS module resources, see What Are JMS Configuration Resources?.

JMS Helper APIs

The module-based method of configuring JMS module resources necessitated the deprecation of the JMSHelper class for locating JMS runtime and configuration JMX MBeans.

This class has been replaced by a new JMSModuleHelper class with methods for managing (locate/create/delete) JMS Module configuration resources (descriptor beans) in a given JMS module (including the JMS Interop Module), and for locating JMS runtime MBeans.

For more information on using the JMS module helper methods, see the JMSModuleHelper Javadoc.

Messages Paging Enabled, Bytes Paging Enabled, and Paging Store Methods

The new simplified JMS Paging configuration necessitated the deprecation of the BytesPagingEnabled and MessagesPagingEnabled attributes of the JMSTemplateMBean, JMSDestinationMBean, and JMSServerMBean interfaces.

The new paging configuration has also caused the replacement of the PagingStore attribute on the JMSServerMBean with new PagingDirectory and MessageBufferSize attributes.

For more information, see Paging Out Messages To Free Up Memory.

Expiration Logging Policy Method

The new Message Life Cycle Logging feature necessitated the deprecation of the ExpirationLoggingPolicy attribute of the JMSTemplateMBean, JMSDestinationMBean, and JMSServerMBean interfaces.

For more information about expired message handling, see Handling Expired Messages. For more infomation about message life cycle logging, see Message Life Cycle Logging.

JMS Session Pool and JMS Connection Consumer Interfaces

The JMSSessionPoolMBean (and its associated methods on the JMSServerMBean) and JMSConnectionConsumerMBean interfaces have been deprecated. These interfaces were used to automatically create a JMS session pool and start the JMS consumers on the server side.

The ConnectionConsumer and ServerSessionPool APIs are still supported, but BEA strongly recommends using message-driven beans (MDBs), which are simpler, easier to manage, and more capable.

For more information on designing MDBs, see Message-Driven EJBs in Programming WebLogic Enterprise JavaBeans.

JMS Store Interfaces

The new WebLogic Persistent Store necessitated the deprecation of the following MBean interfaces:

This deprecation also includes any associated JMS Store methods on the JMSServerMBean interface.

For more information, see Using The WebLogic Persistent Store in Configuring WebLogic Server Environments.

Pause and Resume Methods On the JMS Destination Runtime Interface

The new "Pause and Resume JMS Destinations" feature necessitated the deprecation of the pause(), resume(), and isPaused() APIs on the JMSDestinationRuntimeMBean interface. A new set of Pause/Resume APIs have been introduced to the JMSDestinationRuntimeMBean and JMSServerRuntimeMBean interfaces.

Message Purge Method on the JMS Durable Subscriber Runtime Interface

The new "JMS Message Management" feature necessitated the deprecation of the purge(), API on the JMSDurbableSubscriberRuntimeMBean interface.

For more information, see "JMSMessageManagementRuntimeMBean" in the WebLogic Server MBean Reference.

JMS Extensions: WLMessage Interface

The following methods in the WLMessage class have been deprecated:

These methods have been replaced by the following properties:

These new properties includes the corresponding setter methods.

For more information on using these WLMessage extensions, see the JMS WLMessage Extension Javadoc.

Messaging Bridge Properties

The Thread Pool Size property for a server instance has been deprecated. Use the common thread pool or a work manager. See Change the Thread Pool Size in Configuring and Managing the WebLogic Messaging Bridge

 

Skip navigation bar  Back to Top Previous Next