This chapter includes the following sections:
The following sections outline a basic procedure on how to configure JMS applications:
Before you start configuring JMS servers and persistent stores, consider the following:
Destinations, connection factories, and other JMS resources are configured separately from their host JMS servers and persistent stores. The best practice steps for configuring JMS resources will be described later.
If you plan to leverage WebLogic distributed destinations, then you must configure a WebLogic cluster with a JMS server and a custom persistent store on each WebLogic server in the cluster. WebLogic JMS distributed destination features require a working WebLogic cluster.
Although it does not support all WebLogic JMS features (such as Unit-of-Order, singleton destinations, and Store-and-Forward Agents), Clustered JMS Servers provides a simplified configuration and the ability to dynamically scale resources. See Simplified JMS Cluster and High Availability Configuration.
Migratable targets are only supported with clusters. If you are not using a cluster, then you may want to reconsider and use a cluster of size one. This enables the use of migratable targets, and migratable targets enable a useful restart-in-place capability as mentioned below. This also helps "future-proof" your application, as it simplifies the process of expanding from a single server to multiple servers.
Note:
For high availability, Oracle recommends targeting the JMS artifacts to a cluster along with appropriate high availability configuration settings instead of using Migratable Targets.Use the following steps to configure JMS servers and persistent stores in Configured clusters:
A homogenous set of JMS servers is a single cluster-targeted JMS server with its distribution-policy set to Distributed or a single JMS server with its distribution-policy set to Singleton, or a set of similarly configured JMS servers that each host the same distributed destination. Configure a JMS module and a single associated subdeployment for each homogenous set of JMS servers:
SAF agents, their stores, and their imported destinations should follow the same best practices as JMS servers, their stores, and JMS destinations. Avoid targeting a SAF agent at a cluster, as such a SAF agent is not be able to use migratable targets.
Oracle recommends the following targeting guidelines for JMS resources:
Avoid default targeting, WebLogic server targeting, and cluster targeting with destinations. Instead use advanced targeting (subdeployment targeting) for destinations and ensure that the subdeployment references only JMS servers or SAF agents.This applies to all destination types, including non-distributed, distributed, and imported.
Even if the current JMS Servers or SAF Agents in your domain are only used for your specific application, this is a best practice because:
New JMS Servers or SAF Agents that are unrelated to your current application can be introduced by other applications, web services, or 3rd-party products.
In the future, your application may require different destinations and different JMS Servers or SAF Agents for scalability or management purposes.
Always use advanced targeting when configuring Web Services deployments and error queues, this includes both development and production environments.
To use an error destination within a distributed queue, it must be targeted to the same subdeployment as its parent destination.
In most cases, you can use default targeting with connection factories as default targeting causes the resource to inherit the module's target. For connection factories that are only used by remote clients, use the module's subdeployment target.
Although it does not support all WebLogic JMS features (such as Unit-of-Order, singleton destinations, and Store-and-Forward Agents), consider using Clustered JMS Servers to simply configuration and allow applications to more easily scale WebLogic Messaging resources. See Simplified JMS Cluster Configuration.
The following section provides best practice information for integration and multi-domain environments using WebLogic Server:
For server side applications that communicate with destinations in a remote WebLogic cluster or server, see Integrating Remote JMS Providers in Developing JMS Applications for Oracle WebLogic Server.
Interoperating WebLogic Server domains have the following restrictions:
Domain names must be unique.
WebLogic server names must be unique, even if they are in two different domains.
JMS server names must be unique, even if they are in two different domains.
Interoperating domains may have special Security considerations.
For applications that interoperate with AQ JMS, see Interoperating with Oracle AQ JMS.
To configure your domain to enable inter-domain transactions, see Configuring Communication for Inter-Domain Transactions in Developing JTA Applications for Oracle WebLogic Server.
For client applications (applications that have a runtime environment independent of WebLogic Server) there are multiple JMS client options, including: Java, .NET, and C clients. See JMS Clients in Developing Stand-alone Clients for Oracle WebLogic Server.
Note:
WebLogic JMS clients do not directly support foreign transaction managers. Use the WebLogic TM if possible. For advanced users, the transaction subsystem Interposed Transaction Manager feature may be used as an XA resource.
Applications that are communicating with a remote WebLogic Server instance or cluster must specify a URL when creating their JNDI InitialContext objects and/or setting application attributes in order to connect to a server or a cluster.
Do not specify URLs for applications that run on the same server or cluster as their JMS resources. When an initial context is created without specifying URLs, it automatically references the local server or cluster JNDI.
If a URL resolves to multiple addresses, WebLogic Server clients will randomly select an address in the list to start with and then automatically try each address in turn until one succeeds.
In production systems, consider using DNS round robin or a hardware load balancer for initial hostname resolution rather than using the multiple host/port URL notation shown in URL syntax.
The WebLogic URL syntax is:
[t3|t3s|http|https|iiop|iiops]://address[,address]...
where
address = hostlist : portlist
hostlist = hostname [,hostname]...
portlist = portrange [+portrange]...
portrange = port [-port]
Use port-port
to indicate a port range, and + to separate multiple port ranges. For example, a simple address is typically something like t3://hostA:7001
; the address t3://hostA,hostB:7001-7002
is equivalent to the following addresses.
t3://hostA,hostB:7001+7002
t3://hostA:7001-7002,hostB:7001-7002
t3://hostA:7001+7002,hostB:7001+7002
t3://hostA:7001,hostA:7002,hostB:7001,hostB:7002
If strictly ordered message processing is required, then application design and configuration needs to carefully take this requirement into account.
The simplest and most capable option is to leverage the WebLogic JMS Unit-of-Order feature. This option normally requires minimal or even no changes to applications, plus it works with distributed destinations, scheduled messages, delayed messages, transactions, and store-and-forward. See Using Message Unit-of-Order in Developing JMS Applications for Oracle WebLogic Server.
If High Availability (HA) or scalability is a concern, develop applications so that they leverage clustered WebLogic features. This approach is best taken in the early configuration and application design stage as it is usually difficult process to change a non-clustered application into a clustered application.
In WebLogic JMS, a message is only available if its host JMS server for the destination is running. If a message is in a central persistent store, the only JMS server that can access the message is the server that originally stored the message. WebLogic includes features for automatically restarting and/or migrating a JMS server after a failure. It also includes features for clustering (distributing) a destination across multiple JMS servers within the same cluster.
HA is normally accomplished using both:
Distributed destinations
HA Servers/Services. JMS Servers can be automatically restarted and/or migrated using either Whole Server Migration or Automatic Service Migration.
Distributed queues are generally fairly easy to apply to an arbitrary clustered queueing use case. Distributed topics are best applied when:
Subscribers are non-durable, or
You use MDBs to subscribe (direct durable subscribers have limitations and may require use of sophisticated extensions).
See Configuring and Deploying MDBs Using JMS Topics in Developing Message-Driven Beans for Oracle WebLogic Server and Using Distributed Destinations in Developing JMS Applications for Oracle WebLogic Server.
In your JMS foreign server configuration:
Specify oracle.jms.AQjmsInitialContextFactory
as the JNDI initial context factory.
Configure the JDBC data sources needed for your application environment.
For more information, see:
Configuring Foreign Server Resources to Access Third-Party JMS Providers
Configure foreign servers in Oracle WebLogic Server Administration Console Online Help
The following link is for a checklist of items to consider when tuning WebLogic JMS:
JMS Performance & Tuning Check List in Tuning Performance of Oracle WebLogic Server.