by Michael Hart
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.
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.
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:
config/config.xmlconfiguration file, which is where the resource is defined.
config/jmsdirectory 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
<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 documentatio. 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:
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
Figure 1. Displaying module entities
Several advantages come to mind when comparing deployable JMS resources to WebLogic 8 configuration:
wlw-manifest.xmlfile 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.
config.xmlfile 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.