WebLogic Server 9.0: JMS Enhancements

by Michael Hart
10/26/2005

Abstract

BEA WebLogic Server 9.0 offers a plethora of new Java Message Service (JMS) features and enhancements. These can be divided into two categories: changes for administrators such as the modular configuration of JMS resources, new store and forward facilities, and a new persistence store subsystem; and changes for developers such as JMS 1.1 support, unit-of-order enhancements, and message-driven bean improvements. This article explains at a high level some of the key changes that will affect any development team as it prepares to migrate to WebLogic Server 9.0. 

JMS Changes for Administrators

There are four major changes for administrators. The first involves how JMS resources are configured and deployed. The second is management of destinations, including the long-awaited ability to view the contents of a queue or topic. The third is the new store-and-forward capability. The last is the foundation of the entire JMS subsystem—the WebLogic Persistent Store.

Modular configuration of JMS resources

Prior to WebLogic Server 9.0, JMS resources such as queues and topics were tied to a specific JMS server. This was obvious even in the console, where queues and topics were viewed as branches of the individual JMS servers. JMS resources were created by the WebLogic administrators, prior to any application deployments. This has radically changed in WebLogic Server 9.0. 

JMS resources are now created as deployable resources. They exist in separate XML files, as defined by the weblogic-jmsmd.xsd schema. These resources can be deployed with the applications or separately.

JMS resources can be created as system modules (also known as environment-related) or as application modules. Application modules are managed like standard J2EE modules and can be deployed as standalone modules just like any other J2EE application, or they can be included as part of a J2EE application. The main difference between system modules and application modules comes down to ownership. System resource modules are owned and modified by the WebLogic administrator and are available to all applications. Application resource modules are owned and modified by the WebLogic developers, who package the JMS resource modules with the application's EAR file.

System modules can be managed using the WebLogic console or the WebLogic Scripting Tool (WLST). A resource consists of two parts:

1. The first file is the config/config.xml configuration file, which is where the resource is defined.
2. A second XML file is placed in the config/jms directory of the domain home and contains the details of the JMS resource.

This is best understood by an example. I created a system module called MikesTestModule. It contains two entities, a queue called MIKES_TEST_QUEUE and a topic called MIKES_TEST_TOPIC. Here is the snippet describing the system module from the domain's config/config.xml file:

<jms-system-resource>
    <name>MikesTestModule</name>
    <target>AdminServer</target>
    <sub-deployment>
        <name>MIKES_TEST_QUEUE</name>
        <target>MyJMSServer</target>
    </sub-deployment>
    <sub-deployment>
        <name>MIKES_TEST_TOPIC</name>
        <target>MyJMSServer</target>
    </sub-deployment>
    <descriptor-file-name>jms/MikesTestModule-jms.xml
    </descriptor-file-name>
</jms-system-resource>

Notice the element named <descriptor-file-name/>. It references the file containing the details about each JMS entity. The referenced config/jms/MikesTestModule-jms.xml is as follows:

<weblogic-jms xmlns="http://www.bea.com/ns/weblogic/90">
    <queue name="MIKES_TEST_QUEUE">
       <message-logging-params>
         <message-logging-enabled>true</message-logging-enabled>
         <message-logging-format>%headers%,%properties%
         </message-logging-format>
       </message-logging-params>
       <jndi-name>mike.test.queue</jndi-name>
    </queue>
    <topic name="MIKES_TEST_TOPIC">
        <jndi-name>mike.test.topic</jndi-name>
    </topic>
</weblogic-jms>

Application modules are configured by creating an XML file that conforms to the same weblogic-jmsmd.xsd schema as the config/jms/MikesTestModule-jms.xml file shown in the example above. It must be included in the application EAR file and referenced in the weblogic-application.xml file, as outlined in the documentation. Once the EAR file with the JMS application modules is deployed, it is left to the administrator to define a persistent store for the resources.

Choosing between system modules and application modules depends on the practices of your IT shop. Any environment that requires interaction with other messaging products will likely require deployment of system modules, whereas any application that uses only WebLogic JMS queues or topics internally may need application modules. 

Both system modules and application modules are made up of one or more of the following entities:

• JMS queue and JMS distributed queue
• JMS topic and distributed topic
• Quota
• Template
• Connection factory
• Foreign server
• Destination key
• Store-and-forward imported destination
• Remote store-and-forward context
• Store-and-forward error handling

Each entity in the module is then targeted to an existing JMS server. Some entities, such as connection factories, can also be targeted to a WebLogic server or cluster. 

Figure 1 shows the administrator console viewing the example module called MikesTestModule with the two entities. They have both been targeted to the JMS server called MyJMSServer.

Figure 1. Displaying module entities

Several advantages come to mind when comparing deployable JMS resources to WebLogic 8 configuration:

• It is much easier for an administrator or deployer to migrate an application and all its resources from one environment to another. Much less manual configuration is required, especially if the resources are application modules.
• Separating the resource from the configuration of the resource provides a much clearer demarcation between what an application needs, such as  a queue, and how that queue is configured.
• Application modules are especially handy if an application uses some queues internally (where messages are not destined for other applications); these modules can save the administrators and deployers a lot of time. For example, a BEA WebLogic Workshop-based Web application requires at least two JMS queues to function properly, as defined in the wlw-manifest.xml file generated during the build. Using deployable resources, these queues will be deployed with the application, and the deployer will never again forget to create them.
• The files can be checked against their respective schema before deployment, not during. Anyone who has ever hacked a config.xml file only to have the server fail miserably on startup because of a badly placed bracket will appreciate this.

Overall, the new way of defining JMS resources will make life easier in the long run for administrators and deployers.