So, when it comes to understanding JMS deployment in a Weblogic environment, it helps to be aware of the major components of the WebLogic JMS Server architecture. JMS Servers act as management containers for JMS Queue and Topic destinations in JMS Modules, which contains configuration resources such as Queues, Topics, distributed Destinations and Connections Factories. These JMS module resources are grouped and targeted to Weblogic server resources such as JMS servers, server instances, or cluster by a mechanism called SubDeployment. Information on JMS modules' administered objects are placed in a JNDI namespace and are written to the file <product-module-name>--jms.xml in the config\jms subdirectory of the domain directory. The JMS module will be referenced in the domain's config.xml file as a <jms-system-resource> element.
Here is a representation of the JMS resources deployment from a standalone i.e. non-cluster SOA Suite 11g-PS6 deployment, that could be helpful in enhancing your understanding. The persistent store depicted can either be 'File' or a table in database.
Some points to remember for a successful JMS resources deployment and transparent access:
- All JMS server names must be unique within a domain and across all inter-operating domains
- All JMS store (File or JDBC) names must be unique and have unique MBean names
- All user-defined JMS connection factories targeted to servers/clusters in a domain must have unique JNDI and MBean names
- Queue destinations can use the same name as other Queues on different JMS servers
- Topic destinations can also use the same name as other Topics on different JMS servers
Refer the official documentation for latest and greater details on Weblogic JMS architecture.