Cedric Beust wrote:
> > From: Evan Ireland [mailto:[EMAIL PROTECTED]]
>
> > > - for all active instances listening to a Topic, how many should receive
> the
> > > message?
> >
> > One.
>
> Then how does JMS tell a replicated listener from a regular listener?
>
> Because based on what you're saying, JMS will magically know what listeners
> should be ignored because they're redundant instances in the cluster.
Evan's comment about a "single system image" is interesting because it brings
into focus the fact that a cluster, while made up of several nodes, must
administer itself as a single system. In the same way that distributed
operating systems attempt to maintain one logic memory system, a J2EE cluster
must maintain one logical deployment of message driven beans. This really
becomes an issue when dealing with Topics requiring the cluster to interpose on
delivery of p2p messages to ensure that a single, logical MDB deployment only
process the same message once, no matter how many nodes the MDB actually resides
on.
This makes it difficult to bind a MDB to an outside JMS provider. In other
words, it would be very difficult to model this behavior when using MDB from
vendor A that subscribes to a JMS provider of vendor B. The MDB vendor must
have an intimate knowable and control of the JMS provider it using if its going
to realize the concept of a "single system image".
One of the disadvantages of using MDB with J2EE platforms in that many of them
must use a specific JMS provider. Weblogic, for example, requires that its
native JMS provider be used with MDBs (this may change). While this allows the
vendor to have a tighter integration between the MDB and its provider, and there
for better performance, it's not a flexible enough solution for real world
deployments. Many developers will want to use MDB as an integration point with
other systems, such as MQSeries. The solution to this problem are bridges that
allow different JMS providers to interoperate, but then you loose the intimate
control of the JMS provider which allows you to have a "single system image".
In the end it may turn out to be impractical to use topics and clustering
together with disparate platforms (mixed EJB and JMS vendors). A situation that
the community needs to be aware of.
Richard
--
Richard Monson-Haefel
Author of Enterprise JavaBeans, 2nd Edition (O'Reilly 2000)
Co-Author of Java Message Service (O'Reilly 2000)
http://www.jMiddleware.com
===========================================================================
To unsubscribe, send email to [EMAIL PROTECTED] and include in the body
of the message "signoff EJB-INTEREST". For general help, send email to
[EMAIL PROTECTED] and include in the body of the message "help".
