3 Configuring Basic JMS System Resources

The procedures in the following sections describe how to configure and manage basic JMS system resources, such as JMS servers and JMS system modules.

Methods for Configuring JMS System Resources

WebLogic Administrators can use these tools to create and deploy (target) system resources, such as JMS servers and JMS system modules.

Main Steps for Configuring Basic JMS System Resources

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 Oracle WebLogic Server Administration Console 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 for Oracle WebLogic Server or "JMSBean" in the Oracle WebLogic Server MBean Reference.

  1. If you require persistent messaging, 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 Configuring Server Environments for Oracle WebLogic Server.

    • To store persistent messages in a JDBC-accessible database, you must create a JDBC store. See "Creating a JDBC Store" in Configuring Server Environments for Oracle WebLogic Server.

  2. Configure a JMS server to manage the messages that arrive on the queue and topic destinations in a JMS system module. See Overview of JMS Servers.

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

  4. 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 allow you to define multiple destinations with similar option settings. See JMS Template Configuration.

    • Configure destination keys to create custom sort orders of messages as they arrive on a destination. See Destination Key Configuration.

    Once these resources are configured, you can select them when you configure your queue or topic resources.

  5. Configure a queue and/or topic destination in your system module:

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

    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.

Advanced Resources in JMS System Modules

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

JMS Configuration Naming Requirements

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.

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. See Integration and Multi-Domain Best Practices.

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.

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 JMS for Oracle WebLogic Server.

JMS Server Configuration Parameters

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 Oracle WebLogic Server Administration Console 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 Performance and Tuning for 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 enable you to 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 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 Oracle WebLogic Server MBean Reference.

JMS Server Targeting

You can target a JMS server to either an independent WebLogic Server instance or to a migratable target server where it will be deployed.

  • Weblogic Server instance — Server target where you want to deploy the JMS server. When a target WebLogic Server boots, the JMS server boots as well. If no target WebLogic Server is specified, the JMS server will not boot.

  • 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 boots, 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 on configuring a migratable target for JMS services, see Migration of JMS-related Services.

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

JMS Server Monitoring Parameters

You can monitor run-time statistics for active JMS servers, destinations, and server session pools.

  • Monitor all Active JMS Servers — A table displays showing 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 Chapter 8, "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 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 Programming 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 are dynamically configurable, but the new values do not take effect until the JMS server is restarted. See "Defining Server Session Pools" in Programming JMS for Oracle WebLogic Server.

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 JMS 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. 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 Oracle WebLogic Server Administration Console 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 Oracle WebLogic Server.

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 Module and Resource Subdeployment Targeting

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.

Default Targeting

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 Oracle WebLogic Server Administration Console Help.

Note:

Default targeting is not recommended for any type of destination. Instead, use subdeployment targeting. For more information 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 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:

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


Notes:

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 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://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 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 Oracle WebLogic Server Administration Console Help.

For information about deploying stand-alone JMS modules, see "Deploying JDBC, JMS, and WLDF Application Modules" in Deploying Applications to 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 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.

Using a Default Connection Factory

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 Programming JMS 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 Oracle 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 Oracle WebLogic Server Administration Console 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 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 Oracle WebLogic Server Administration Console 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 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 Oracle WebLogic Server MBean Reference.

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 co-located 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 will also migrate along with the JMS server's destinations. However, when standalone queues or topics are members of a subdeployment, a connection factory can only be targeted 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 on 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:

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 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 Oracle WebLogic Server Administration Console 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:

  • 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 will 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 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 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 Oracle WebLogic Server MBean Reference.

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 same JMS server as the destination(s) it is associated with. For more information, see "Configuring an Error Destination for Undelivered Messages" in Programming JMS 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 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. For Queue and Topic targeting best practices, see Targeting Best Practices.

Destination Monitoring and Management Parameters

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.

JMS Template Configuration

A JMS template is an efficient means of defining multiple destinations with similar option settings:

  • You do not need to re-enter 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) will use only the error destinations specified in the corresponding template subdeployments.

JMS Template Configuration Parameters

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 Oracle WebLogic Server Administration Console 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:

  • If the destination that is using a JMS template specifies an override value for an option, the override value is used.

  • If the destination that is using a JMS template specifies a message redelivery value for an option, 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) will 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, 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 Oracle WebLogic Server MBean Reference.

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 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 Oracle WebLogic Server Administration Console Help.

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

Quota Configuration

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.

See Performance and Tuning for Oracle WebLogic Server.

Foreign Server Configuration

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.

Distributed Destination Configuration

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 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 Configuring and Managing Store-and-Forward for Oracle WebLogic Server.