![]() ![]() ![]() ![]() ![]() ![]() |
The procedures in the following sections describe how to configure and manage basic JMS system resources, such as JMS servers and JMS system modules.
WebLogic Administrators can use these tools to create and deploy (target) system resources, such as JMS servers and JMS system modules.
Note: | For information on configuring and deploying JMS application modules in an enterprise application, see Configuring JMS Application Modules for Deployment. |
This section describes how to use the Administration Console to configure a persistent store, a JMS server, and a basic JMS system module. For instructions about using the Administration Console to manage a WebLogic Server domain, see The WebLogic Server Administration Console in the Administration Console Online Help.
WebLogic JMS provides default values for some configuration options; you must provide values for all others. Once WebLogic JMS is configured, applications can send and receive messages using the JMS API. For information on tuning the default configuration parameters, see Performance and Tuning or
JMSBean
in the WebLogic Server MBean Reference.
Once these resources are configured, you can select them when you configure your queue or topic resources.
For more information about using the default connection factories, see Using a Default Connection Factory. For more information on configuring a Connection Factory, see Connection Factory Configuration Parameters.
WebLogic JMS provides default values for some configuration options; you must provide values for all others. Once WebLogic JMS is configured, applications can send and receive messages using the JMS API.
Beyond basic JMS resource configuration, you can add these advanced resources to a JMS system module:
Within a domain, each server, machine, cluster, virtual host, and any other resource type must be named uniquely and must not use the same name as the domain. This unique naming rule also applies to all configuration objects, including configurable JMS objects such 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.
Also, the JNDI name of any bindable JMS resource (excluding quotas, destination keys, and JMS templates) across JMS modules has to be unique.
JMS servers are environment-related configuration entities that act as management containers for JMS queue and topic resources within JMS modules that are specifically targeted to JMS servers. 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. 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 Programming WebLogic JMS. |
The WebLogic Server Administration Console enables you to 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 Administration Console Online Help.
You can configure the following parameters for JMS servers:
For more information about configuring messages and bytes quota for JMS servers and destinations, see Performance and Tuning.
For more information about configuring message life cycle logging on JMS servers, see Message Life Cycle Logging.
For more information about pausing message operations on destinations, see Controlling Message Operations on Destinations.
Some JMS server options are dynamically configurable. 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 the WebLogic Server MBean Reference.
You can target a JMS server to either an independent WebLogic Server instance or to a migratable target server where it will be deployed.
For instructions on specifying JMS server targets using the Administration Console, see Change JMS server targets in the Administration Console Online Help.
You can monitor run-time statistics for active JMS servers, destinations, and server session pools.
For more information about monitoring JMS objects, see Monitoring JMS Statistics and Managing Messages.
Note: | Session pool and connection consumer configuration objects were deprecated in WebLogic Server 9.0. They are not a required part of the J2EE specification, do not support JTA user transactions, and are largely superseded by Message-Driven Beans (MDBs), which are a required part of J2EE. For more information on designing MDBs, see Message-Driven EJBs in Programming WebLogic Enterprise JavaBeans. |
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 are dynamically configurable, but the new values do not take effect until the JMS server is restarted. See Defining Server Session Pools in Programming WebLogic JMS.
Connection consumers are queues (Point-to-Point) or topics (Pub/Sub) that will 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 Programming WebLogic JMS.
JMS system modules are owned by the Administrator, who can delete, modify, or add JMS system resources at any time. 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 enables you to 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 Administration Console Online Help.
You define the following “basic” configuration resources as part of a JMS system module:
You can also define the following “advanced” clustering configuration resources as part of a JMS system module:
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 Managing Server Startup and Shutdown.
For information on alternative methods for configuring JMS system modules, such as using the WebLogic Scripting Tool (WLRT), see Methods for Configuring JMS System Resources.
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.
When using the 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.
When you select the default targeting mechanism, it’s target status will be reflected by the Default Targeting Enabled check box on the resource type’s Configuration: General page on the Administration Console.
For more information on configuring JMS system resources, see Configure resources for JMS system modules in the Administration Console Online Help.
When targeting standalone queue and topic resources, or when bypassing the default targeting mechanism for other resource types, you must use subdeployment targets. A subdeployment is a mechanism by which targetable system module resources (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 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:
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. |
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, JMS, and WLDF Application Modules in Deploying Applications to WebLogic Server.
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 a Default Connection Factory.
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.
WebLogic Server defines two default connection factories, which can be looked up using the following JNDI names:
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 Programming WebLogic JMS
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 WebLogic Server MBean Reference.
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 Administration Console Online Help.
The WebLogic Server Administration Console enables 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 Administration Console Online Help.
You can modify the following parameters for connection factories:
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. |
Some connection factory options are dynamically configurable. 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 the WebLogic Server MBean Reference.
You can target connection factories to one or more JMS server, to one or more WebLogic Server instances, or to a cluster.
For more information on JMS system module subdeployment targeting, see JMS System Module and Resource Subdeployment Targeting.
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:
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 enables you to 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 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 and/or a topic:
Note: | Although queue and topic JNDI names can be dynamically changed, there may be long-lived producers or consumers, such as MDBs, that will continue trying to produce or consume messages to and from the original queue or topic JNDI name. |
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.
Some options are dynamically configurable. 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 the WebLogic Server MBean Reference.
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 same JMS server as the destination(s) it is associated with. For more information, see Configuring an Error Destination for Undelivered Messages in Programming WebLogic JMS.
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.
Stand-alone queues and topics can only be deployed 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 and/or topics with a connection factory on a specific JMS server, 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 only be targeted to the same JMS server.
For more information on JMS system module subdeployment targeting, see JMS System Module and Resource Subdeployment Targeting.
You can monitor run-time statistics for queues and topics in system modules, as well as manage the messages on queues and durable subscribers on topics.
A JMS template is an efficient means of defining multiple destinations with similar option settings:
The WebLogic Server Administration Console enables you to 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 Administration Console Online Help.
The configurable options 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:
Any options that are not explicitly defined for a destination are assigned default values. If no default value exists, be sure to specify a value within the JMS template or as a destination option override.
Some template options are dynamically configurable. 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 topic options, see
TemplateBean
in the WebLogic Server MBean Reference.
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 enables you to 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 Administration Console Online Help.
For more information about the default values for all destination key options, see
DestinationKeyBean
in the WebLogic Server MBean Reference.
A quota resource defines a maximum number of messages and bytes, and is then associated with one or more destinations and is responsible for enforcing the defined maximums.
A foreign server resource enables 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.
A distributed destination resource is a single set of destinations (queues or topics) that are 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 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 Configuring and Managing WebLogic Store-and-Forward.
![]() ![]() ![]() |