Re: JMS Server targeted to Server cluster

Thanks Tom.

<Tom Barnes> wrote in message news:570003340@newsgroups.bea.com...
There's no underlying machinery (code) that supports targeting a JMS server 
to a cluster.

The targeting problem can actually get fairly involved - for a variety of 
reasons, I tend to recommend the following cookie cutter approach.

This is a cut-and-paste from my notes:

(1) Create a custom WL store on each server, and target it to a migratable 
target (most of the time you can use the default migratable target that each 
server provides).

(2) Target the JMS servers to a migratable target each, the same MT as the 
store  (don't worry, the JMS server won't wander to a different server 
unless you configure the MT to allow this!)

(3) Target jms configuration system modules to the cluster (that's it! - not 
to anything else)

(4) Create one subdeployment per module (and only one), populate the 
subdeployment only with JMS servers from step (2) above.

(5) When targeting destinations always use advanced targeting  to target 
destinations to the subdeployment from above - not the 'default target'. 
If you have both non-distributed and distributed destinations, use two 
different JMS modules.  (The idea is to keep things simple to understand - 
each module should yield the same targeting solution for all of its 
component resources.   Default targetting can be problematic - it is far too 
easy for destination members to end up on JMS servers that you don't want 
them on.).

(6) When targeting a CF you have two options (A) use advanced targeting to 
target it to the subdeployment (for access by applications that are remote 
to the cluster) or (B) don't target it all (this will cause it to use the 
module target, which if you recall, we just set to the cluster, (for access 
by applications that run on a server within the cluster).  The choice 
actually depends on how you plan to use the CF - use (B) for apps running on 
servers within the cluster, and (A) for apps running remote to the cluster. 
See the otherwise-largely-outdated JMS Performance Guide for the reasoning.

It may be that you don't have to use migratable targets, as you may not have 
a use for "migration" at the moment - but it'll help in the future if
you 
ever plan to use the migration features.