I am using WebLogic 10.3.5 within an Oracle Fusion Middleware 11g installation on linux.
I want to set up multiple independent instances of an application that utilizes JMS. Each application should have its own queues and topics, i.e. they do not talk to each other. I am setting up separate servers for each application instance for ease of management. So I will have a Test server, a Training server, etc. within this installation of WebLogic.
I am wondering what the best way to set up the JMS resources within WebLogic is. As I understand it, WebLogic has JMS servers, JMS modules and subdeployments. Do I need separate instances of each for each instance of the application, or could they share?
It looks like according to the documentation, the best thing to do is a separate JMS server - JMS module - subdeployment for each instance.
Subdeployments are highly recommended for destination configuration as a best practice:
The following might help:
* A WL domain can host multiple individual WL servers and/or clusters of WL servers.
* A WL cluster, or even a single WL server, can host one or more sets of JMS servers.
* Each WL JMS server instance in a set is configured and targeted individually. A logical JMS server consisting of a set of JMS servers is comprised of multiple configured JMS server instances.
* Each set of JMS servers can in turn host independent clustered destinations from one or more modules. For example, you can configure a "uniform distributed queue" in a module, and target the distributed queue by having it reference a subdeployment for the module that in turn references each JMS server in a particular set a of JMS servers.
* (BTW, for 12.1.2 we're planning on delivering a feature that eliminates the need to configure each JMS server in a set individually.)
* You can configure security (ACLs) at the per-module level, or the fine grained per-destination level.
* The configured "mbean" names of two different destinations can be the same in different modules, but their JNDI names must be different. This is because the JNDI name-space is shared across the entire cluster.