JMS System Module and Resource -- Subdeployment Targeting

JMS system modules must be targeted to one or more WebLogic Server instances or to a cluster. Targetable JMS resources defined in a system module must also be targeted to JMS server or WebLogic Server instances within the scope of a parent module's targets. Additionally, targetable JMS resources inside a system module can be further grouped into subdeployments during the configuration or targeting process to provide further loose coupling of JMS resources in a WebLogic domain.

Basic System Assisted Targeting

When using the Administration Console to configure resources in a JMS system module, you can choose whether to simply accept valid, pre-selected targets for a resource type or to proceed to an advanced targeting page where you can select an existing subdeployment or create a new one.

When you select a pre-selected target, a system owned subdeployment is automatically generated for the resource and selected target. The name space for system created/owned subdeployments is defined as:

BEA_JMS_SUBDEPLOYMENT_XXXX

where XXXX represents:

• For queue and topic resource types, the name of the JMS server. For example, BEA_JMS_SUBDEPLOYMENT_MyJMSServer-0

or for all other JMS resource types targeted to JMS servers, server instances, or an entire cluster:

• The name of the parent module hosting the targeted resource. For example, BEA_JMS_SUBDEPLOYMENT_MyModule-0

JMS administrators cannot create any subdeployment beginning with BEA_JMS_SUBDEPLOYMENT. This naming restriction is validated during the subdeployment creation process.

For more information on configuring JMS system resources, see "Configure resources for JMS system modules" in the Administration Console Online Help.

Advanced Subdeployment Targeting

A subdeployment is a mechanism by which targetable JMS system module resources (such as queues, topics, and connection factories) are grouped and targeted to specific server resources within a system module's targeting scope. Although a JMS system module can be targeted to a wide array of WebLogic Server instances in a domain, a module's standalone queues or topics can only be targeted to a single JMS server. Whereas, connection factories, uniform distributed destinations (UDDs), and foreign servers can be targeted to one or more JMS servers, one or more WebLogic Server instances, or to a cluster.

Therefore, standalone queues or topics cannot be associated with a subdeployment if other members of the subdeployment are targeted to multiple JMS servers, which would be the case, for example, if a connection factory is targeted to a cluster that is hosting JMS servers in a domain. UDDs, however, can be associated with such subdeployments since the purpose of UDDs is to distribute its members to multiple JMS servers in a domain.

Table 3-1 shows the valid targeting options for JMS system resource subdeployments:

Table 3-1 JMS System Resource Subdeployment Targeting JMS Resource	Valid Targets
Queue	JMS server
Topic	JMS server
Connection factory	JMS server(s) | server instance(s) | cluster
Uniform distributed queue	JMS server(s) | server instance(s) | cluster
Uniform distributed topic	JMS server(s) | server instance(s) | cluster
Foreign server	JMS server(s) | server instance(s) | cluster
SAF imported destinations	SAF Agent(s) | server instance(s) | cluster

 

An example of a simple subdeployment for standalone queues or topics would be to group them with a connection factory so that these resources are co-located on a specific JMS server, which can help reduce network traffic. Also, if the targeted JMS server should be migrated to another WebLogic Server instance, the connection factory and all its connections will also migrate along with the JMS server's destinations.

For example, if a system module named jmssysmod-jms.xml, is targeted to a WebLogic Server instance that has two configured JMS servers: jmsserver1 and jmsserver2, and you want to co-locate two queues and a connection factory on only jmsserver1, you can group the queues and connection factory in the same subdeployment, named jmsserver1group, to ensure that these resources are always linked to jmsserver1, provided the connection factory is not already targeted to multiple JMS servers.

<weblogic-jms xmlns="http://www.bea.com/ns/weblogic/91">
  <connection-factory name="connfactory1">
    <sub-deployment-name>jmsserver1group</sub-deployment-name>
    <jndi-name>cf1</jndi-name>
  </connection-factory>
 <queue name="queue1">
    <sub-deployment-name>jmsserver1group</sub-deployment-name>
    <jndi-name>q1</jndi-name>
  </queue>
 <queue name="queue2">
    <sub-deployment-name>jmsserver1group</sub-deployment-name>
    <jndi-name>q2</jndi-name>
  </queue>
</weblogic-jms>

And here's how the jmsserver1group subdeployment targeting would look in the domain's configuration file:

  <jms-system-resource>
   <name>jmssysmod-jms</name>
   <target>wlsserver1</target>
   <sub-deployment>
     <name>jmsserver1group</name>
     <target>jmsserver1</target>
   </sub-deployment>
   <descriptor-file-name>jms/jmssysmod-jms.xml</descriptor-file-name>
  </jms-system-resource>

To help manage your subdeployments for a JMS system module, the Administration Console provides subdeployment management pages. For more information, see "Configure subdeployments in JMS system modules" in the Administration Console Online Help.

For information about deploying stand-alone JMS modules, see "Deploying JDBC and JMS Application Modules."