Skip navigation.

eDocs Home > BEA WebLogic Server 9.0 Documentation > Configuring and Managing WebLogic JMS > Configuring JMS System Resources

Configuring and Managing WebLogic JMS

  Previous Next vertical dots separating previous/next from contents/index/pdf Contents Index View as PDF   Get Adobe Reader

Configuring JMS System Resources

These sections explain how to configure global JMS system resources for your WebLogic Server implementation:

 

Ways to Configure Messaging Resources

Messaging resources can be configured in a number of ways:

Administrators

WebLogic Administrators typically use the Administration Console, WebLogic Java Management Extensions (JMX) API, or the WebLogic Scripting Tool (WLST) to create and deploy (target) messaging resources.

Application Developers

Developers create application modules in an enterprise-level IDE or another development tool that supports editing of XML files, then package the JMS modules with an application and pass the application to a WebLogic Administrator to deploy.

 

Using the Administration Console to Configure JMS Resources

The WebLogic Server Administration Console provides an interface for easily configuring and managing the features of the WebLogic Server, including JMS. To invoke the Administration Console, refer to the procedures described in "Starting and Stopping Servers" in Managing Server Startup and Shutdown.

Using the Administration Console, you define configuration options to:

Modifying Default Values for Configuration Options

WebLogic JMS provides default values for some configuration options; you must provide values for all others. Follow the procedures outlined in this section to configure and manage JMS resources. Once WebLogic JMS is configured, applications can send and receive messages using the JMS API. For more information about developing basis WebLogic JMS applications, refer to "Developing a Basic JMS Application" in Programming WebLogic JMS.

A sample examplesJMSServer configuration 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.

Starting WebLogic Server and Configuring JMS

The following sections review how to start WebLogic Server and the Administration Console, as well as provide a procedure for configuring a basic WebLogic JMS implementation.

Starting the Default WebLogic Server

The default role for a WebLogic Server is the Administration Server. If a domain consists of only one WebLogic Server, that server is the Administration Server. If a domain consists of multiple WebLogic Server instances, you must start the Administration Server first, and then you start the Managed Servers.

For complete information about starting the Administration Server, see "Starting and Stopping Servers" in Managing Server Startup and Shutdown.

Starting the Administration Console

The Administration Console is the Web-based administrator front-end (administrator client interface) to WebLogic Server. You must start the server before you can access the Administration Console for a server. 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.

Configuring Basic JMS System Resources

This section describes how to configure a persistent store, a JMS server, and a basic JMS system module using the Administration Console.

This section does not cover the configuration parameters available to fine-tune JMS resources once they are created. For information about these parameters, refer to the corresponding system module beans in the "System Module MBeans" folder of the WebLogic Server MBean Reference. The root bean in the JMS module that represents an entire JMS module is named JMSBean.

  1. For storing 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.

    2. For more information on configuring a custom file store, see "Creating a Custom (User-Defined) File Store" in the Configuring WebLogic Server Environments.

  2. For storing persistent messages in a JDBC-accessible database, you must create a JDBC store.

    3. For more information on JDBC stores, see "Creating a JDBC Store" in Configuring WebLogic Server Environments.

  3. Create a JMS server to manage the queue and topic destinations in a JMS system module.

    4. For more information, see JMS Servers.

  4. Create a JMS system module to contain your JMS system resources, such as quota, templates, destination keys, standalone queue and topic destinations, and connection factories.

    5. For more information, see JMS System Resource Modules.

  5. Before creating any queue or topic resources 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:

    6. Once these resources are configured, they can be selected when configuring your queue or topic resources.

  6. Create a topic to include in your JMS module.

    7. For more information on configuring JMS topics, see Creating Topics.

  7. Create a queue to include in your JMS module.

    8. For more information on configuring JMS queues, see Creating Queues.

  8. If the default connection factories provided by WebLogic Server are not suitable for your application, create a connection factory to enable your JMS clients to create JMS connections.

    9. For more information about using the default connection factories, see Using a Default Connection Factory. For more information on configuring a Connection Factory, see Creating Connection Factories.

Guidelines for Configuring Advanced JMS System Module Resources

This section describes the advanced resources that can be added to a JMS system module using the Administration Console.

JMS Configuration Naming Requirements

Each server instance within a domain must have a name that is unique for all configuration objects in the domain. 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 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 (e.g., queues, topics, or 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 Server Configuration

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.

There are a number of ways to create JMS servers.

Creating JMS Servers

As management containers for destinations, JMS servers feature the following configuration parameters:

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 in the WebLogic Server MBean Reference.

Targeting JMS Servers

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 more information on configuring a migratable target for JMS, see Configuring Migratable Targets for JMS Servers.

Monitoring JMS Servers

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.

Configuring Session Pools and Connection Consumers

Note: Session pool and connection consumer configuration objects are deprecated in this release of WebLogic Server. 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. For more information about creating session pools, 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. For more information about creating connection consumers, see "Defining Server Session Pools in Programming WebLogic JMS.

 

JMS System Module Configuration

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 following basic configuration resources are defined as part of a JMS system module:

The following "advanced" clustering configuration resources are also defined as part of a JMS system module:

Creating JMS System Modules

There are a number of ways to create a JMS system module and its resources.

Targeting JMS Modules and Subdeployment Resources

JMS system modules must be targeted to one or more WebLogic Server instances or to a cluster. Targetable 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.

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. However, UDDs 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

Distributed queue

JMS server(s) | server instance(s) | cluster

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/90">
  <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>

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

 

Connection Factory Resources

Connection factories are objects 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. However, 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 Servers. For more information on configuring JMS clustering, see Configuring WebLogic JMS Clustering.

Using a Default Connection Factory

WebLogic JMS 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.

Another distinction when using the default connection factories is 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: Services: Configuration" in the Administration Console Online Help.

Creating Connection Factories

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.

Connection factories feature the following configuration parameters:

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.

Targeting Connection Factories

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 Targeting JMS Modules and Subdeployment Resources.

 

Queue and Topic Destination Resources

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:

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 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.

Note: Because error destinations must be targeted to the same JMS server as the destination(s) it is associated with, error destinations cannot be used with distributed destinations since distributed destination members are targeted to multiple JMS servers.

Distributed Destinations

A distributed destination resource is a single unit of destination (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 unit are usually distributed across multiple servers within a cluster, with each member belonging to a separate JMS server. Applications that use distributed destinations are more highly available than applications that use simple destinations because WebLogic JMS provides load balancing and failover for member destinations of a distributed destination within a cluster.

Weblogic Server supports two types of distributed destinations:

Uniform Distributed Destinations — In a uniform distributed destination (UDD), each of the member destinations has a consistent configuration of all distributed destination parameters, particularly in regards to weighting, security, persistence, paging, and quotas.

Weighted Distributed Destinations — In a weighted distributed destination, the member destinations do not have a consistent configuration of all distributed destination parameters, particularly in regards to weighting, security, persistence, paging, and quotas.

For more information on configuring distributed destination resources, see Configuring Distributed Destinations.

Creating Queues

A JMS queue defines a point-to-point destination type for a JMS server. Queues are used for asynchronous peer communications.A message delivered to a queue will be distributed to one consumer.

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

Queues feature the following configuration parameters:

Some queue 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 queue options, see QueueBean in the WebLogic Server MBean Reference.

Creating Topics

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 will be distributed to all topic consumers.

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

Topics feature the following configuration parameters:

Some topic 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 TopicBean in the WebLogic Server MBean Reference.

Targeting Queues and Topics

Standalone 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 Targeting JMS Modules and Subdeployment Resources.

 

JMS Template Resources

A JMS template provides an efficient means of defining multiple destinations with similar option settings. JMS templates offer the following benefits:

The configurable options for a JMS template are the same as those configured for a destination. 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.

Creating JMS Templates

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.

JMS templates feature the following configuration parameters for destinations that use the template:

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.

 

Destination Key Resources

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).

Creating JMS Destination Keys

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.

 

Quota Resources

In prior releases, there were multiple levels of quotas: destinations had their own quotas and would also have to compete for quota within a JMS server. In this release, there is only one level of quota: destinations can have their own private quota resource or they can compete with other destinations using a shared quota resource.

For more information on configuring quota resources, see Defining Quota.

 

Foreign Server Resources

Foreign server resources enable you to reference foreign (that is, 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.

For more information on configuring foreign servers resources, see Accessing Foreign Server Providers.

 

Distributed Destination Resources

A distributed destination resource is a single unit of destination (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 unit are usually distributed across multiple servers within a cluster, with each member belonging to a separate JMS server. Applications that use distributed destinations are more highly available than applications that use simple destinations because WebLogic JMS provides load balancing and failover for member destinations of a distributed destination within a cluster.

Weblogic Server supports two types of distributed destinations:

Uniform Distributed Destinations — In a uniform distributed destination (UDD), each of the member destinations has a consistent configuration of all distributed destination parameters, particularly in regards to weighting, security, persistence, paging, and quotas.

Weighted Distributed Destinations — In a weighted distributed destination, the member destinations do not have a consistent configuration of all distributed destination parameters, particularly in regards to weighting, security, persistence, paging, and quotas.

For more information on configuring distributed destination resources, see Configuring Distributed Destinations.

 

JMS Store-and-Forward (SAF) 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

For more information on configuring JMS SAF resources, see "Configuring SAF for JMS Messages" in Configuring and Managing WebLogic Store-and-Forward.

 

Skip navigation bar  Back to Top Previous Next