Configuring Basic JMS System Resources

3 Configuring Basic JMS System Resources

Learn how to configure and manage basic JMS system resources for Oracle WebLogic Server, such as JMS servers and JMS system modules.

This chapter includes the following sections:

Methods for Configuring JMS System Resources

WebLogic Administrators can use multiple methods to configure and deploy (target) JMS resources. Methods include the WebLogic Server Administration Console, the WebLogic Scripting Tool (WLST), and so on.

You can use the following tools to configure JMS system resources:

The WebLogic Server Administration Console lets you to configure, modify, and target JMS-related resources:
- JMS servers, as described in JMS Server Configuration.
- JMS system modules, as described in JMS System Module Configuration.
- Store-and-Forward services for JMS, as described in Configuring SAF for JMS Messages in Administering the Store-and-Forward Service for Oracle WebLogic Server.
- Persistent stores, as described in Using the WebLogic Persistent Store in Administering Server Environments for Oracle WebLogic Server.
WebLogic Scripting Tool (WLST) is a command-line scripting interface that allows system administrators and operators to initiate, manage, and make persistent WebLogic Server configuration changes interactively or by using an executable script. See Using WLST to Manage JMS Servers and JMS System Module Resources.
Java Management Extensions (JMX) is the Java EE solution for monitoring and managing resources on a network. See Overview of WebLogic Server Subsystem MBeans in Developing Custom Management Utilities Using JMX for Oracle WebLogic Server.
The JMSModuleHelper extension class contains methods to create and manage JMS module configuration resources in a given module. See Using JMS Module Helper to Manage Applications in Developing JMS Applications for Oracle WebLogic Server or the JMSModuleHelper Class Javadoc.

Note:

For information about configuring and deploying JMS application modules in an enterprise application, see Configuring JMS Application Modules for Deployment.
WebLogic Server REST APIs let you to create and deploy new JMS system resource and link it up to the cluster. See Configuring System Resources in Administering Oracle WebLogic Server with RESTful Management Services.

Main Steps for Configuring Basic JMS System Resources

Use the WebLogic Server Administration Console to configure a persistent store, a JMS server, and a basic JMS system module.

For instructions about using the WebLogic Server Administration Console to manage a WebLogic Server domain, see the Oracle WebLogic Server Administration Console Online Help.

WebLogic JMS provides default values for some configuration options; you must provide values for all others. After WebLogic JMS is configured, applications can send and receive messages using the JMS API. For information on tuning the default configuration parameters, see Tuning WebLogic JMS in Tuning Performance of Oracle WebLogic Server or JMSBean in the MBean Reference for Oracle WebLogic Server.

If you require persistent messaging, then use one of the following storage options:
- To store persistent messages in a file-based store, you can simply use the server's default persistent store, which requires no configuration on your part. However, you can also create a dedicated file store for JMS. See Creating a Custom (User-Defined) File Store in the Administering the WebLogic Persistent Store.
- To store persistent messages in a JDBC-accessible database, you must create a JDBC store. See Using a JDBC Store in Administering the WebLogic Persistent Store.
Configure a JMS server to manage the messages that arrive in the queue and topic destinations in a JMS system module. See Overview of JMS Servers.
Configure a JMS system module to contain your destinations, as well as other resources, such as quotas, templates, destination keys, distributed destinations, and connection factories. See JMS System Modules.
Before creating any queues or topics in your system module, you can optionally create other JMS resources in the module that can be referenced from within a queue or topic, such as JMS templates, quota settings, and destination sort keys:
- Define quota resources for your destinations. Destinations can be assigned their own quotas; multiple destinations can share a quota; or destinations can share the JMS server's quota. See Quota Configuration.
- Create JMS templates, which let you define multiple destinations with similar option settings. See JMS Template Configuration.
- Configure destination keys to create custom sort orders of messages as they arrive in a destination. See Destination Key Configuration.
After these resources are configured, you can select them when you configure your queue or topic resources.
Configure a queue or topic destination or both in your system module:
- Configure a standalone topic for the delivery of messages to multiple recipients (publish/subscribe). See Queue and Topic Destination Configuration.
- Configure a standalone queue for the delivery of messages to exactly one recipient (point-to-point). See Queue and Topic Destination Configuration.
If the default connection factories provided by WebLogic Server are not suitable for your application, then create a connection factory to enable your JMS clients to create JMS connections.

For more information about using the default connection factories, see Using the Default Connection Factories Defined by WebLogic Server. For more information about configuring a Connection Factory, see Connection Factory Configuration Parameters.

Advanced Resources in JMS System Modules

Beyond basic JMS resource configuration, you can add these advanced resources to a JMS system module:

Create a Uniform Distributed Destination resource to configure a set of queues or topics that distributed across the cluster, with each member belonging to a separate JMS server in the cluster. See Configuring Distributed Destination Resources.
Create a JMS Store-and-Forward resource to reliably forward messages to remote destinations, even when a destination is unavailable at the time that message is sent, as described in Configuring SAF for JMS Messages in Administering the Store-and-Forward Service for Oracle WebLogic Server.
Create a Foreign Server resource to reference third-party JMS providers within a local WebLogic Server JNDI tree. See Configuring Foreign Server Resources to Access Third-Party JMS Providers.

JMS Configuration Naming Requirements

Within a domain, each server, machine, cluster, virtual host, and any other resource type must have a unique name and cannot use the same name as the domain. This unique naming rule also applies to all configuration objects, including configurable JMS objects that can be configured as JMS servers, JMS system modules, and JMS application modules.

The resource names inside JMS modules must be unique per resource type (for example, queues, topics, and connection factories). However, two different JMS modules can have a resource of the same type that can share the same name.

The JNDI name of any bindable JMS resource (excluding quotas, destination keys, and JMS templates) across JMS modules must use the following naming requirements:

Global names must be unique across the cluster.
Local names must be unique across the server.
If there is a naming conflict, then the JMS resource is not bound into the JNDI tree. If there is any doubt, then make the JNDI name globally unique.

Note:

WebLogic Domain, WebLogic Server, and WebLogic JMS Server names have additional unique naming requirements when two different WebLogic domains interoperate with each other, or when a client communicates with more than one WebLogic domain. Minimally, the two associated domains must have different domain names, and, if global transactions span the domains, then stores should not share the same name even if they are in different domains.

JMS Server Configuration

JMS destinations are configured in JMS modules and are targeted to JMS servers which are configured separately.

A JMS server's primary responsibility for its targeted destinations is to maintain information about what persistent store is used for any persistent messages that arrive on the destinations, and to maintain the states of durable subscribers created on the destinations. As a container for targeted destinations, any configuration or run-time changes to a JMS server can affect all of its destinations.

Note:

A sample examplesJMSServer configuration is provided with the product in the Examples Server. For more information about developing basic WebLogic JMS applications, refer to Developing a Basic JMS Application in Developing JMS Applications for Oracle WebLogic Server.

JMS server configuration covers the following information:

JMS Server Configuration Parameters

The WebLogic Server Administration Console lets you configure, modify, target, and delete JMS server resources in a system module. For a road map of the JMS server tasks, see Configure JMS servers in the Oracle WebLogic Server Administration Console Online Help.

You can configure the following parameters for JMS servers:

General configuration parameters, including persistent storage, message paging defaults, a template to use when your applications create temporary destinations, and expired message scanning.
Threshold and quota parameters for destinations in JMS system modules targeted to a particular JMS server.

For more information about configuring messages and bytes quota for JMS servers and destinations, see Defining Quota in Tuning Performance of Oracle WebLogic Server.
Message logging parameters for a JMS server's log file, which contains the basic events that a JMS message traverses, such as message production, consumption, and removal.

For more information about configuring message life cycle logging on JMS servers, see Message Life Cycle Logging.
Destination pause and resume controls that lets you pause message production, message insertion (in-flight messages), and message consumption operations on all the destinations hosted by a single JMS Server.

For more information about pausing message operations on destinations, see Controlling Message Operations on Destinations.

Some JMS server options can be dynamically configured. When options are modified at runtime, only incoming messages are affected; stored messages are not affected. For more information about the default values for all JMS server options, see JMSServerBean and JMSServerRuntimeMBean in MBean Reference for Oracle WebLogic Server.

JMS Server Targeting

You can target a JMS server to either an independent WebLogic Server instance or to a cluster (dynamic or mixed), or to a migratable target server where it will be deployed.

Weblogic Server instance — The server target where you want to deploy the JMS server. When a target WebLogic Server starts, the JMS server starts as well. If no target WebLogic Server is specified, then the JMS server does not start.
Cluster-Targeted JMS — You can target JMS service artifacts such as JMS Server, SAF Agents, Persistent Stores, and Path Service to a cluster.

Note:
Oracle recommends using Cluster targeting with new Store configuration that supports Automatic Service Migration, instead of using Migratable Targets. See Simplified JMS Cluster and High Availability Enhancements.
Migratable Target — Migratable targets define a set of WebLogic Server instances in a cluster that can potentially host an exactly-once service, such as a JMS server. When a migratable target server starts, the JMS server boots as well on the specified user-preferred server in the cluster. However, a JMS server and all of its destinations can be migrated to another server within the cluster in response to a server failure or due to a scheduled migration for system maintenance. For more information about configuring a migratable target for JMS services, see Migration of JMS-related Services.

For instructions about specifying JMS server targets using the WebLogic Server Administration Console, see Change JMS server targets in the Oracle WebLogic Server Administration Console Online Help. For JMS Server targeting best practices, see Targeting Best Practices.

JMS Server Monitoring Parameters

You can monitor runtime statistics for active JMS servers, destinations, and server session pools.

Monitor all active JMS servers — A table shows all instances of the JMS server deployed across the WebLogic Server domain.
Monitor all active JMS destinations — A table displays showing all active JMS destinations for the current domain.
Monitor all active JMS session pool runtimes — A table displays showing all active JMS session pools for the current domain.

For more information about monitoring JMS objects, see Monitoring JMS Statistics and Managing Messages.

Session Pools and Connection Consumers

Note:

Session pool and connection consumer configuration objects were deprecated in WebLogic Server 9.x. They are not a required part of the Java EE specification, do not support JTA user transactions, and are largely superseded by Message-Driven Beans (MDBs), which are a required part of Java EE. For more information on designing MDBs, see Developing Message-Driven Beans for Oracle WebLogic Server.

Server session pools enable an application to process messages concurrently. After you define a JMS server, you can configure one or more session pools for each JMS server. Some session pool options can be dynamically configured, but the new values do not take effect until the JMS server is restarted. See Defining Server Session Pools in Developing JMS Applications for Oracle WebLogic Server.

Connection consumers are queues (point-to-point) or topics (publish/subscribe) that retrieve server sessions and process messages. After you define a session pool, configure one or more connection consumers for each session pool. See Defining Server Session Pools in Developing JMS Applications for Oracle WebLogic Server.

JMS System Module Configuration

JMS system modules are owned by the administrator, who can delete, modify, or add JMS system resources at any time. The configuration resources described as part of a JMS system module are queue and topic destinations, connection factories, templates, destination keys, and quotas.

With the exception of standalone queue and topic resources that must be targeted to a single JMS server, the connection factory, distributed destination, foreign server, and JMS SAF destination resources in system modules can be made globally available by targeting them to server instances and clusters configured in the WebLogic domain. These resources are therefore available to all applications deployed on the same targets and to client applications. The naming convention for JMS system modules is MyJMSModule-jms.xml.

The WebLogic Server Administration Console lets you configure, modify, target, monitor, and delete JMS system modules in your environment. For a road map of the JMS system module configuration tasks, see Configure JMS system modules and add JMS resources in the Oracle WebLogic Server Administration Console Online Help.

You define the following "basic" configuration resources as part of a JMS system module:

Queue and topic destinations, as described in Queue and Topic Destination Configuration.
Connection factories, as described in Connection Factory Configuration.
Templates, as described in JMS Template Configuration.
Destination keys, as described in Destination Key Configuration.
Quota, as described in Quota Configuration.

You can also define the following "advanced" clustering configuration resources as part of a JMS system module:

Foreign servers, as described in Configuring Foreign Server Resources to Access Third-Party JMS Providers.
Distributed destinations, as described in Configuring Distributed Destination Resources.
JMS Store-and-Forward configurations, as described in Configuring SAF for JMS Messages in Administering the Store-and-Forward Service for Oracle WebLogic Server.

A sample examples-jms module is provided with the product in the Examples Server. For more information about starting the Examples Server, see Starting and Stopping Servers in Administering Server Startup and Shutdown for Oracle WebLogic Server.

For information about alternative methods for configuring JMS system modules, such as using the WebLogic Scripting Tool (WLST), see Methods for Configuring JMS System Resources.

JMS System Module and Resource Subdeployment Targeting

JMS system modules must be targeted to one or more WebLogic Server instances or to a cluster. JMS resources that can be targeted and are 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, JMS resources that can be targeted and are 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.

Default Targeting

When using the WebLogic Server Administration Console to configure resources in a JMS system module, you can choose whether to simply accept the parent module's default targets or to proceed to an advanced targeting page where you can use the subdeployment mechanism for targeting the resource. However, standalone queue and topic resource types cannot use default targets and must be targeted to a subdeployment that is targeted to a single JMS server and it is a best practice to use subdeployment targeting instead of default targeting for all destination types regardless.

When you select the default targeting mechanism, its target status is reflected by the Default Targeting Enabled check box on the resource type's Configuration: General page on the WebLogic Server Administration Console.

For more information about configuring JMS system resources, see Configure resources for JMS system modules in the Oracle WebLogic Server Administration Console Online Help.

Note:

Default targeting is not recommended for any type of destination. Instead, use subdeployment targeting. See Targeting Best Practices.

Advanced (Subdeployment) Targeting

When targeting standalone queue and topic resources, or when bypassing the default targeting mechanism for other resource types, you must use advanced targeting (also known as subdeployment targeting). A subdeployment is a mechanism by which system module resources that can be targeted (such as standalone destinations, distributed destinations, 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 be targeted only to a single JMS server. 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 because 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

Note:

Connection factory, uniform distributed destination, foreign server, and SAF imported destination resources can also be configured to default to their parent module's targets, as explained in Default Targeting.

Default targeting, server instance targeting, and cluster targeting is not recommended for any type of destination (including non-distributed destinations, distributed destinations, or SAF imported destinations). Instead, use a subdeployment target that contains JMS servers, or, for SAF imported destinations, that contains contains SAF agent(s). See Targeting Best Practices.

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 collocated 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 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 collocate two queues and a connection factory on only jmsserver1, then 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://xmlns.oracle.com/weblogic/weblogic-jms">
  <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 the following is 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 WebLogic Server Administration Console provides subdeployment management pages. See Configure subdeployments in JMS system modules in the Oracle WebLogic Server Administration Console Online Help.

For information about deploying standalone JMS modules, see Deploying JDBC, JMS, and WLDF Application Modules in Deploying Applications to Oracle WebLogic Server.

Specifying the Unmapped Resource Reference Mode for Connection Factories

When you declare a JMS connection factory in the EJB or Servlet using the @Resource annotation or the resource-ref element in the deployment descriptors, and if this resource reference is not mapped to a JNDI name directly by a lookup attribute, a mappedName attribute, or a jndi-name, then WebLogic Server allows you to specify the behavior of such unmapped resource references to JMS connection factories.

If a JNDI name is mapped to the resource reference, then the unmapped resource reference mode does not take effect and the resource reference either resolves to the specified object in the JNDI or generates an exception, javax.naming.NameNotFoundException.

For more information about resource references, see Enhanced Support for Using WebLogic JMS with EJBs and Servlets in Developing JMS Applications for Oracle WebLogic Server

On the WebLogic Server Administration Console, a value that you specify for the Connection Factory Unmapped Resource Reference Mode parameter for a server determines the behavior of resource references to JMS connection factories. Possible values are:

ReturnDefault: If the resource reference does not match the local JNDI name of a configured foreign JMS provider or if it does not match with an object bound to the JNDI tree, then it returns java:comp/DefaultJMSConnectionFactory, which is the default JMS connection factory defined by the Java EE 7 specification. See Using the Default JMS Connection Factory Defined by Java EE 7.
FailSafe: The resource reference resolves to an object bound to the JNDI tree with the same name as the resource reference name, if one can be found in JNDI. Otherwise, it throws an exception, javax.naming.NameNotFoundException.

Note:

Oracle recommends configuring the reference mode to FailSafe. See Configure JMS Resources.

For more information about the values for the unmapped resource reference mode, see the definition of the JMSConnectionFactoryUnmappedResRefMode attribute in MBean Reference for Oracle WebLogic Server.

Connection Factory Configuration

Connection factories are resources that enable JMS clients to create JMS connections.

A connection factory supports concurrent use, enabling multiple threads to access the object simultaneously. WebLogic JMS provides pre-configured default connection factories that can be enabled or disabled on a per-server basis, as described in Using the Default Connection Factories Defined by WebLogic Server.

Otherwise, you can configure one or more connection factories to create connections with predefined options that better suit your application. Within each JMS module, connection factory resource names must be unique. And, all connection factory JNDI names in any JMS module must be unique across an entire WebLogic domain, as defined in JMS Configuration Naming Requirements. WebLogic Server adds them to the JNDI space during startup, and the application then retrieves a connection factory using the WebLogic JNDI APIs.

You can establish cluster-wide, transparent access to JMS destinations from any server in the cluster, either by using the default connection factories for each server instance, or by configuring one or more connection factories and targeting them to one or more server instances in the cluster. This way, each connection factory can be deployed on multiple WebLogic Server instances. For more information on configuring JMS clustering, see Configuring WebLogic JMS Clustering.

Using the Default JMS Connection Factory Defined by Java EE 7

WebLogic Server supports the default JMS connection factory defined by the Java EE 7 platform specification. This default connection factory can be looked up using the java:comp/DefaultJMSConnectionFactory JNDI name or it can be accessed using the @Resource annotation. The java:comp/DefaultJMSConnectionFactory JNDI name resolves to the equivalent of the default weblogic.jms.XAConnectionFactory.

Note:

The lookup of DefaultJMSConnectionFactory using @Resource and Context.lookup() always returns pooled and wrapped connection factory, to ensure that the resource provides adequate performance and also to ensure that the Java EE restriction on a server-side JMS API usage is properly enforced.

The Java EE 7 default connection factory can be accessed only from within a Java EE application unlike the default connection factories defined by WebLogic Server. The Java EE 7 connection factory cannot be accessed from standalone clients except by using the application client container facility.

Note:

Oracle recommends using custom connection factories instead of using default connection factories because the default connection factories cannot be tuned. Custom connection factories that can be tuned often prove useful for tuning applications even after the application is in production
A WebLogic Server administrator cannot disable the Default JMS Connection Factory per WebLogic Server.

See Look Up a Connection Factory in JNDI in Developing JMS Applications for Oracle WebLogic Server.

Using Default Connection Factories Defined by WebLogic Server

WebLogic Server defines two default connection factories, which can be looked up using the following JNDI names:

weblogic.jms.ConnectionFactory
weblogic.jms.XAConnectionFactory

You only need to configure a new connection factory if the pre-configured settings of the default factories are not suitable for your application. For more information on using the default connection factories, see Understanding WebLogic JMS in Developing JMS Applications for Oracle WebLogic Server.

The main difference between the pre-configured settings for the default connection factories and a user-defined connection factory is the default value for the "XA Connection Factory Enabled" option to enable JTA transactions. For more information about the XA Connection Factory Enabled option, and to see the default values for the other connection factory options, see JMSConnectionFactoryBean in the MBean Reference for Oracle WebLogic Server.

Also, using default connection factories means that you have no control over targeting the WebLogic Server instances where the connection factory may be deployed. However, you can enable and or disable the default connection factories on a per-WebLogic Server basis, as defined in Server: Configuration: Services in the Oracle WebLogic Server Administration Console Online Help.

Note:

Oracle recommends using custom connection factories instead of default connection factories because default connection factories are not tunable. Custom connection factory tunables often prove useful for tuning applications even after the application is in production.

Connection Factory Configuration Parameters

The WebLogic Server Administration Console lets you to configure, modify, target, and delete connection factory resources in a system module. For a road map of the JMS connection configuration tasks, see Configure connection factories in the Oracle WebLogic Server Administration Console Online Help.

You can modify the following parameters for connection factories:

General configuration parameters, including modifying the default client parameters, default message delivery parameters, load balancing parameters, unit-of-order parameters, and security parameters.
Transaction parameters, which enable you to define a value for the transaction time-out option and to indicate whether an XA queue or XA topic connection factory is returned, and whether the connection factory creates sessions that are JTA aware.

Note:

When selecting the XA Connection Factory Enabled option to enable JTA transactions with JDBC stores, you must verify that the configured JDBC data source uses a non-XA JDBC driver. This limitation does not remove the XA capabilities of layered subsystems that use JDBC stores. For example, WebLogic JMS is fully XA-capable regardless of whether it uses a file store or any JDBC store.
Flow control parameters, which enable you to tell a JMS server or destination to slow down message producers when it determines that it is becoming overloaded.

Some connection factory options can be dynamically configured. When options are modified at runtime, only incoming messages are affected; stored messages are not affected. For more information about the default values for all connection factory options, see JMSConnectionFactoryBean in MBean Reference for Oracle WebLogic Server.

Connection Factory Targeting

You can target connection factories to one or more JMS server, to one or more WebLogic Server instances, or to a cluster.

JMS server(s) — You can target connection factories to one or more JMS servers along with destinations. You can also group a connection factory with standalone queues or topics in a subdeployment targeted to a specific JMS server, which guarantees that all these resources are collocated to avoid extra network traffic. Another advantage of such a configuration would be if the targeted JMS server needs to be migrated to another WebLogic Server instance, then the connection factory and all its connections also migrate along with the JMS server destinations. However, when standalone queues or topics are members of a subdeployment, a connection factory can be targeted only to the same JMS server.
Weblogic server instance(s) — To establish transparent access to JMS destinations from any server in a domain, you can target a connection factory to multiple WebLogic Server instances simultaneously.
Cluster — To establish cluster wide, transparent access to JMS destinations from any server in a cluster, you can target a connection factory to all server instances in the cluster, or even to specific servers within the cluster.

For more information about JMS system module subdeployment targeting, see JMS System Module and Resource Subdeployment Targeting. For information on connection factory targeting best practices, see Targeting Best Practices.

Queue and Topic Destination Configuration

A JMS destination identifies a queue (point-to-point) or topic (publish/subscribe) resource within a JMS module. Each queue and topic resource is targeted to a specific JMS server.

A JMS server's primary responsibility for its targeted destinations is to maintain information on what persistent store is used for any persistent messages that arrive on the destinations, and to maintain the states of durable subscribers created on the destinations.

You can optionally create other JMS resources in a module that can be referenced from within a queue or topic, such as JMS templates, quota settings, and destination sort keys:

Quota : Assign quotas to destinations; multiple destinations can share a quota; or destinations can share the JMS server's quota. See Defining Quota in Tuning Performance of Oracle WebLogic Server.
JMS Template : Define multiple destinations with similar option settings. You also need a JMS template to create temporary queues. See JMS Template Configuration.
Destination Key : Create custom sort orders of messages as they arrive on a destination. See Destination Key Configuration.

Queue and Topic Configuration Parameters

A JMS queue defines a point-to-point destination type for a JMS server. A message delivered to a queue is distributed to a single consumer. A JMS topic identifies a publish/subscribe destination type for a JMS server. Topics are used for asynchronous peer communications. A message delivered to a topic is distributed to all consumers that are subscribed to that topic.

The WebLogic Server Administration Console lets you configure, modify, target, and delete queue and topic resources in a system module. For a road map of queue and topic tasks, see Configure queues and Configure topics in the Oracle WebLogic Server Administration Console Online Help. Within each JMS module, queue and topic resource names must be unique. And, all queue and topic JNDI names in any JMS module must be unique across an entire WebLogic domain, as defined in JMS Configuration Naming Requirements.

You can configure the following parameters for a queue or a topic:

General configuration parameters, including a JNDI name, a destination key for sorting messages as they arrive at the destination, or selecting a JMS template if you are using one to configure properties for multiple destinations.

Note:

Although queue and topic JNDI names can be dynamically changed, there may be long-lived producers or consumers, such as MDBs, that continue trying to produce or consume messages to and from the original queue or topic JNDI name.
Threshold and quota parameters, which define the upper and lower message and byte threshold and maximum quota options for the destination. See Quota Configuration.
Message logging parameters, such as message type and user properties, and logging message life cycle information into a JMS log file.

See Message Life Cycle Logging. Pause and resume controls for message production, message insertion (in-flight messages), and message consumption operations on a destination. See Controlling Message Operations on Destinations.
Message Delivery override parameters, such as message priority and time-to-deliver values, which can override those values specified by a message producer or connection factory.
Message Delivery failure parameters, such as defining a message redelivery limit, selecting a message Expiration Policy, and specifying an error destination for expired messages.
For topics only, multicast parameters, including a multicast address, time-to-live (TTL), and port.

Some options can be dynamically configured. When options are modified at run time, only incoming messages are affected; stored messages are not affected. For more information about the default values for all options, see QueueBean and TopicBean in MBean Reference for Oracle WebLogic Server.

Creating Error Destinations

To help manage recovered or rolled back messages, you can also configure a target error destination for messages that have reached their redelivery limit. The error destination can be either a topic or a queue, but it must be a destination that is targeted to the same JMS server as the destinations it is associated with. See Configuring an Error Destination for Undelivered Messages in Developing JMS Applications for Oracle WebLogic Server.

Creating Distributed Destinations

A distributed destination resource is a group of destinations (queues or topics) that are accessible as a single, logical unit to a client (for example, a distributed topic has its own JNDI name). The members of the set are typically distributed across multiple servers within a cluster, with each member belonging to a separate JMS server. See Distributed Destination Configuration.

Queue and Topic Targeting

Stand alone queues and topics can be deployed only to a specific JMS server in a domain because they depend on the JMS servers they are targeted to for the management of persistent messages, durable subscribers, and message paging.

If you want to associate a group of queues or topics with a connection factory on a specific JMS server, then you can target the destinations and connection factory to the same subdeployment, which links these resources to the JMS server targeted by the subdeployment. However, when standalone destinations are members of a subdeployment, a connection factory can be targeted only to the same JMS server.

For more information on JMS system module subdeployment targeting, see JMS System Module and Resource Subdeployment Targeting. For Queue and Topic targeting best practices, see Targeting Best Practices.

Destination Monitoring and Management Parameters

You can monitor runtime statistics for queues and topics in system modules, as well as manage the messages on queues and durable subscribers on topics.

For information about using the WebLogic Server Administration Console to monitor queues, see Monitoring queues in JMS system modules in the Oracle WebLogic Server Administration Console Online Help.
For information about managing messages on queues, as described in Managing JMS Messages.
For more information about using the WebLogic Server Administration Console to monitor topics, see Monitor topics in JMS system modules in the Oracle WebLogic Server Administration Console Online Help
For information about managing durable subscriber on topics, as described in Managing JMS Messages.

JMS Template Configuration

A JMS template provides a way to centrally specify settings that are shared across multiple destinations.

You do not need to reenter every option setting each time you define a new destination; you can use the JMS template and override any setting to which you want to assign a new value.
You can modify shared option settings dynamically simply by modifying the template.
You can specify subdeployments for error destinations so that any number of destination subdeployments (groups of queue or topics) use only the error destinations specified in the corresponding template subdeployments.

JMS Template Configuration Parameters

The WebLogic Server Administration Console lets you configure, modify, target, and delete JMS template resources in a system module. For a road map of the JMS template tasks, see Configure JMS templates in the Oracle WebLogic Server Administration Console Online Help.

The options that can be configured for a JMS template are the same as those configured for a destination. See Queue and Topic Configuration Parameters.

These configuration options are inherited by the destinations that use them, with the following exceptions:

If the destination that is using a JMS template specifies an override value for an option, then the override value is used.
If the destination that is using a JMS template specifies a message redelivery value for an option, then that redelivery value is used.
The Name option is not inherited by the destination. This name is valid for the JMS template only. You must explicitly define a unique name for all destinations. See JMS Configuration Naming Requirements.
The JNDI Name, Enable Store, and Template options are not defined for JMS templates.
You can configure subdeployments for error destinations, so that any number of destination subdeployments (groups of queue or topics) use only the error destinations specified in the corresponding template subdeployments.

Any options that are not explicitly defined for a destination are assigned default values. If no default value exists, then specify a value within the JMS template or as a destination option override.

Some template options can be dynamically configured. When options are modified at runtime, only incoming messages are affected; stored messages are not affected. For more information about the default values for all topic options, see TemplateBean in MBean Reference for Oracle WebLogic Server.

Destination Key Configuration

As messages arrive on a specific destination, by default they are sorted in FIFO (first-in, first-out) order, which sorts ascending based on each message's unique JMSMessageID. However, you can use a destination key to configure a different sorting scheme for a destination, such as LIFO (last-in, first-out).

The WebLogic Server Administration Console lets you configure, modify, target, and delete destination key resources in a system module. For a road map of the destination key tasks, see Configure destination keys in the Oracle WebLogic Server Administration Console Online Help.

For more information about the default values for all destination key options, see DestinationKeyBean in the MBean Reference for Oracle WebLogic Server.

Quota Configuration

A quota resource defines a maximum number of messages and bytes, and is responsible for enforcing the defined maximums. It is then associated with one or more destinations.

See Defining Quota in Tuning Performance of Oracle WebLogic Server.

Message Limit in a Subscription

WebLogic JMS provides an option to set a limit on the messages in a topic subscription. If a subscription reaches its configured limit, then by default, the oldest messages in the subscription are ejected to make room for newer messages.

See Subscription Message Limits in Tuning Performance of Oracle WebLogic Server.

Foreign Server Configuration

A foreign server resource lets you to reference third-party JMS providers within a local WebLogic Server JNDI tree.

With a foreign server resource, you can quickly map a foreign JMS provider so that its associated connection factories and destinations appear in the WebLogic JNDI tree as local JMS objects. A foreign server resource can also be used to reference remote instances of WebLogic Server in another cluster or domain in the local WebLogic JNDI tree.

See Configuring Foreign Server Resources to Access Third-Party JMS Providers.

Distributed Destination Configuration

A distributed destination resource is a single set of destinations (queues or topics) that is accessible as a single, logical destination to a client. For example, a distributed topic has its own JNDI name.

The members of the set are typically distributed across multiple servers within a cluster, with each member belonging to a separate JMS server. Applications that use a distributed destination are more highly available than applications that use standalone destinations because WebLogic JMS provides load balancing and failover for the members of a distributed destination in a cluster.

See Configuring Distributed Destination Resources.

JMS Store-and-Forward (SAF) Configuration

JMS SAF resources build on the WebLogic Store-and-Forward (SAF) service to provide highly available JMS message production.

For example, a JMS message producer connected to a local server instance can reliably forward messages to a remote JMS destination, even though that remote destination may be temporarily unavailable when the message was sent. JMS Store-and-forward is transparent to JMS applications; therefore, JMS client code still uses the existing JMS APIs to access remote destinations.

See Configuring SAF for JMS Messages in Administering the Store-and-Forward Service for Oracle WebLogic Server.