JMS, WebLogic, and WebLogic Feature Pack

The JMS implementation in WebLogic—which requires manual intervention when a server goes down—can cause issues when used within WebLogic Feature Pack's dynamic environment. I'll detail three options for you after I describe the issues: pick the option that best meets your needs for each of your WebLogic applications.

What kind of issues?

The JMS implementation in WebLogic requires that each JMS server that uses persistent storage have its own backing store. Consequently, no other JMS server can access messages in a particular JMS server's store. Should a JMS server go off line, any messages in its store are trapped there until the server is restarted or you manually migrate the JMS server to another application node.

Meanwhile, WebLogic Feature Pack's dynamic deployment engine removes services automatically when capacity exceeds the SLA threshold. WebLogic Feature Pack selects a service randomly for removal, and may remove a service that's running a JMS server. Any messages in the JMS server's store at that moment are then unreachable.

The same trapped message issue can occur if an application node that is running a JMS server fails and Cassatt Active Response replaces the node: Cassatt Active Response might start the replacement node with a different image instance—again, leaving any messages inaccessible.

To put the messages back in circulation, you can manually migrate the JMS server to another application node—but this approach is tedious and counter to WebLogic Feature Pack automation. If your setup can use singleton or pinned JMS servers, WebLogic Feature Pack can automatically migrate the JMS server for you. Or you can wait for WebLogic Feature Pack to restart the service on a node running the original image instance—which is hit-or-miss: when capacity falls below the SLA threshold, WebLogic Feature Pack starts a service using any available image instance, and may or may not start a service using the image instance that contains the trapped messages.

JMS options with WebLogic Feature Pack

WebLogic provides three options for using JMS, each of which has pros and cons:

JMS servers in a foreign domain
Singleton or pinned JMS servers within the application's WebLogic domain
JMS servers within the application's WebLogic domain using distributed destinations

	Pros	Cons
Foreign	Dedicated servers for messages Generally no trapped messages Distributed message load Can host all of your JMS servers Can use hardware that is optimized for JMS processing	Could require additional licenses Requires additional hardware Messages could be trapped if a node fails Additional domain to manage Service capacity is a fixed size
Singleton or pinned	No additional licenses required Managed by Cassatt Active Response Fault tolerant No trapped messages because WebLogic Feature Pack migrates the servers when a node fails or WebLogic Feature Pack undeploys a service that hosts a JMS server	Single-server, limited scalability
Distributed	Distributed message load Capacity for growth within the tier that runs your application	Messages could be trapped if a node fails or capacity exceeds the SLA threshold and WebLogic Feature Pack undeploys a service

JMS servers in a foreign domain

Follow these steps to set up a foreign domain for JMS:

In WebLogic, create your JMS server domain. The domain can target the individual application nodes in your application tier or, if your application domain is clustered, the domain can target the cluster.

Be sure to conform to the naming restrictions suggested in BEA documentation for WebLogic 8.1 and WebLogic 9.2.
In Cassatt Active Response, create a new tier using the same WebLogic image as you created for your application domains. Set the minimum, maximum, and target nodes to the number of JMS servers you need.
Capture the JMS server domain and configure a service to run it. Set the minimum and maximum number of services to the same number as you set for nodes in the last step.
Set up distributed destinations on every managed server and a JMS server targeted to every managed server. For more information, see:

WebLogic 8.1: JMS: Configuring and Using Distributed Destinations
WebLogic 9.2: Configuring and Managing WebLogic JMS and Creating Distributed Destinations

For every domain that will use the JMS servers in your foreign domain, set up foreign JMS server values pointing to your new foreign domain.

Singleton or pinned JMS servers within the application's WebLogic domain

When you use pinned JMS servers, WebLogic Feature Pack runs the same number of JMS servers as were in your original domain.
WebLogic 8.1 only - You need to set JNDINameReplicated to "true" so that all managed servers can use the JMS servers, and all managed servers in your tier are migration targets. Your domain must be clustered to support JMS server migration and JNDI name replication.

Also, make sure that each JMS persistent store is available from every managed server.

WebLogic Feature Pack also migrates JTA within clustered WebLogic domains. For a JTA migration to succeed, the transaction log files must be written to a shared location that all managed servers can access. To configure this shared location on each server, go to Configuration > Services and set the Default Store parameter.

JMS servers within the application's WebLogic domain using distributed destinations

Set up distributed destinations on every managed server and a JMS server targeted to every managed server. For more information, see:

WebLogic 8.1: JMS: Configuring and Using Distributed Destinations
WebLogic 9.2: Configuring and Managing WebLogic JMS and Creating Distributed Destination