Configuring and Managing WebLogic JMS
The WebLogic Server implementation of JMS is an enterprise-class messaging system that is tightly integrated into the WebLogic Server platform. It fully supports the JMS 1.1 Specification and also provides numerous WebLogic JMS Extensions that go beyond the standard JMS APIs.
An enterprise messaging system enables applications to asynchronously communicate with one another through the exchange of messages. A message is a request, report, and/or event that contains information needed to coordinate communication between different applications. A message provides a level of abstraction, allowing you to separate the details about the destination system from the application code.
WebLogic JMS accepts messages from producer applications and delivers them to consumer applications. For more information on JMS API programming with WebLogic Server, see Programming WebLogic JMS.
In general, the WebLogic Server domain configuration file (
config.xml) contains the configuration information required for a domain. This configuration information can be further classified into environment-related (or system resource definitions) and application-related information. Some examples of environment-related definitions are the identification and definition of JMS servers, JDBC data sources, WebLogic persistent stores, and server network addresses. These system resources are usually unique from domain to domain.
The configuration and management of these system resources are the responsibility of a WebLogic administrator, who usually receives this information from an organization's system administrator or MIS department. To accomplish these administrative tasks, an administrator can use the WebLogic Administration Console, various command-line tools, such as WebLogic Scripting Tool (WLST), or JMX APIs for programmatic administration.
Some examples of application-related definitions that are highly independent of the domain environment are the various J2EE application components configurations, such as EAR, WAR, JAR, RAR files, and which in this release includes JMS and JDBC modules. The application components are originally developed and packaged by an application development team, and may contain optional programs (compiled Java code) and respective configuration information (also called descriptors, which are mostly stored as XML files). In the case of JMS and JDBC modules, however, there are no compiled Java programs involved. These pre-packaged applications are given to WebLogic Server administrators for deployment in a WebLogic domain.
WebLogic Server provides tools for deploying applications, such as the Administration Console and the
weblogic.Deployer command-line utility. The process of deploying an application links the application components to the environment-specific resource definitions, such as which server instances should host a given application component (targeting), and the WebLogic persistent store to use for persisting JMS messages.
Once the initial deployment is completed, an administrator has only limited control over deployed applications. For example, administrators are only allowed to ensure the proper life-cycle of these applications (deploy, undeploy, redeploy, remove, etc.) and to tune the parameters, such as increasing or decreasing the number of instances of any given application to satisfy the client needs. Other than lifecycle and tuning, any modification to these applications must be completed by the application development team.
In prior releases, all JMS configuration information was stored in a WebLogic domain's configuration file. In this release, JMS configurations (destinations, connections factories, templates, etc.) are stored outside of the WebLogic domain as module descriptor files, which are defined by XML documents that conform to the
weblogic-jmsmd.xsd schema. JMS modules do not include JMS server definitions, which are still stored in the WebLogic domain configuration file.
You create and manage JMS resources either as system resource modules, similar to the way they were managed prior to this release, or as application modules. JMS application modules are a WebLogic-specific extension of J2EE modules and can be deployed either 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 standalone JMS module, and without extensive manual JMS reconfiguration.
JMS servers are environment-related configuration entities that act as management containers for JMS queue and topic resources within JMS modules that are targeted to specific JMS servers. A JMS server's primary responsibility for its targeted destinations is to maintain information on what persistent store is used for any persistent messages that arrive on the destinations, and to maintain the states of durable subscribers created on the destinations. As a container for targeted destinations, any configuration or run-time changes to a JMS server can affect all of its destinations.
As in prior releases, JMS servers are persisted in the domain's
config.xml file and multiple JMS servers can be configured on the various WebLogic Server instances in a cluster, as long as they are uniquely named. Client applications use either the JNDI tree or the
java:/comp/env naming context to look up a connection factory and create a connection to establish communication with a JMS server. Each JMS server handles requests for all targeted modules' destinations. Requests for destinations not handled by a JMS server are forwarded to the appropriate server instance.
For more information on configuring JMS servers, see JMS Server Configuration.
When you create a JMS module using the Administration Console, the WebLogic Scripting Tool (WLST), or WebLogic Management Extension (JMX) utilities, the WebLogic Server creates a JMS module file in the
config\jms subdirectory of the domain directory, and adds a reference to the module in the domain's
config.xml file as a
JMSSystemResource element. This reference includes the path to the JMS module file and a list of target servers and clusters on which the module is deployed. The JMS module conforms to the
weblogic-jmsmd.xsd schema, as described in JMS Schema.
JMS resources that you configure this way are considered system modules. JMS system modules are owned by the Administrator, who can delete, modify, or add similar resources at any time. System modules are globally available for targeting to servers and clusters configured in the domain, and therefore are available to all applications deployed on the same targets and to client applications. System modules are also accessible through JMX as a
JMSSystemResourceMBean. The naming convention for JMS system modules is MyJMSModule
Figure 2-2 shows an example of a JMS system module listing in the domain's
config.xml file and the module that it maps to in the
For more information about configuring JMS system modules, see Configuring JMS System Resources.
JMS configuration resources can also be managed as deployable application modules, similar to standard J2EE descriptor-based modules. JMS Application modules can be deployed either with a J2EE application as a packaged module, where the resources in the module are optionally made available to only the enclosing application (i.e., application-scoped), or as a standalone module that provides global access to the resources defined in that module.
Application modules are generally created and packaged by an application developer and are then deployed, managed, and tuned by a WebLogic administrator. As discussed in Domain Configuration: System Resources vs. Application Resources, JMS application modules do not contain compiled Java programs as part of the package, enabling administrators or application developers to create and manage JMS resources on demand.
For more information about JMS application modules, see Configuring JMS Application Modules for Deployment.
A JMS application module can be deployed by itself as a standalone module, in which case the module is available to the server or cluster targeted during the deployment process. JMS resources deployed in this manner can be reconfigured using the
weblogic.Deployer utility or the Administration Console, but are not available through JMX or WLST. However, standalone JMS modules are available using the basic JSR-88 deployment tool provided with WebLogic Server plug-ins (without using WebLogic Server extensions to the API) to configure, deploy, and redeploy J2EE applications and modules to WebLogic Server.
For information about WebLogic Server deployment, see "Understanding WebLogic Server Deployment." For more information about preparing standalone JMS modules for deployment, see Deploying Standalone JMS Modules.
JMS application modules can also be included as part of an J2EE Enterprise Application Archive (EAR), as a packaged module. Packaged modules are bundled with an EAR file or in an exploded EAR directory, and are referenced in the
weblogic-application.xml deployment descriptor. The packaged module is deployed along with the Enterprise Application, and its resources can be be made available only to the enclosing application. Using packaged modules ensures that an application always has access to required resources and simplifies the process of moving the application into new environments. For more information about preparing packaged JMS modules for deployment, see Deploying JMS Modules That Are Packaged In an Enterprise Application.
In support of the modular configuration model for JMS resources in this release, BEA provides a schema for WebLogic JMS objects:
jmsmd stands for JMS module descriptor. When you create JMS resource modules (descriptors), the modules must conform to the schema. IDEs and other tools can validate JMS resource modules based on this schema.
weblogic-jmsmd.xsd schema is available online at http://www.bea.com/ns/weblogic/90/weblogic-jmsmd.xsd.
A key to understanding WebLogic JMS configuration and management is that who creates a JMS resource and how a JMS resource is created determines how a resource is deployed and modified. Both WebLogic administrators and programmers can configure JMS modules:
In contrast to system modules, deployed application modules are owned by the developer who created and packaged the module, rather than the administrator who deploys the module, which means the administrator has more limited control over deployed resources. When deploying an application module, an administrator can change resource properties that were specified in the module, but the administrator cannot add or delete resources. As with other J2EE modules, deployment configuration changes for a application module are stored in a deployment plan for the module, leaving the original module untouched.
Table 2-1 lists the JMS module types and how they can be configured and modified.
For more information about preparing JMS application modules for deployment, see Configuring JMS Application Modules for Deploymentand Deploying Applications and Modules in Deploying Applications to WebLogic Server
A JMS interop module is a special type of JMS system resource module. It is created and managed as a result of a JMS configuration upgrade for this release, and/or through the use of WebLogic JMX MBean APIs from prior releases.
interop-jms.xmland the file exists in the domain's
JMSInteropModuleMBean, which is a child MBean of
DomainMBean, and can be looked up from
DomainMBeanlike any other child MBean in a domain.
The WebLogic Persistent Store provides a built-in, high-performance storage solution for all subsystems and services that require persistence. For example, it can store persistent JMS messages or temporarily store messages sent using the Store-and-Forward feature. Each WebLogic Server instance in a domain has a default persistent store that requires no configuration and which can be simultaneously used by subsystems that prefer to use the system's default storage. However, you can also configure a dedicated file-based store or JDBC database-accessible store to suit your JMS implementation. For more information on configuring a persistent store for JMS, see "Using the WebLogic Persistent Store" in Configuring WebLogic Server Environments.
The SAF service enables WebLogic Server to deliver messages reliably between applications that are distributed across WebLogic Server instances. For example, with the SAF service, an application that runs on or connects to a local WebLogic Server instance can reliably send messages to a destination that resides on a remote server. If the destination is not available at the moment the messages are sent, either because of network problems or system failures, then the messages are saved on a local server instance, and are forwarded to the remote destination once it becomes available.
JMS modules utilize the SAF service to enable local JMS message producers to reliably send messages to remote JMS queues or topics. For more information, see "Understanding the Store-and-Forward Service" in Configuring and Managing WebLogic Store-and-Forward.
The WebLogic Server Path Service is a persistent map that can be used to store the mapping of a group of messages to a messaging resource by pinning messages to a distributed queue member or store-and-forward path. For more information on configuring a path service, see Using the WebLogic Path Service.
The Messaging Bridge allows you to configure a forwarding mechanism between any two messaging products, providing interoperability between separate implementations of WebLogic JMS, or between WebLogic JMS and another messaging product. The messaging bridge instances and bridge source and target destination instances are persisted in the domain's
config.xml file. For more information, see "Understanding the Messaging Bridge" in Configuring and Managing WebLogic Messaging Bridge.
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 highly-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 seamless interoperability with other versions of WebLogic Server and third-party messaging providers.
Note: This section lists only the value-added features for prior releases. For a comprehensive listing of the new WebLogic JMS feature introduced in this release, see New and Changed JMS Features In This Release.
The WebLogic JMS architecture implements clustering of multiple JMS servers by supporting cluster-wide, transparent access to JMS destinations from any server in the cluster. Although WebLogic Server supports distributing JMS destinations and connection factories throughout a cluster, JMS topics and queues are still managed by WebLogic Server instances in the cluster.
For more information about configuring clustering for WebLogic JMS, see Configuring WebLogic JMS Clustering. For detailed information about WebLogic Server clustering, see Using WebLogic Server Clusters.