geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Richard Monson-Haefel <>
Subject Re: MDB support
Date Fri, 26 Sep 2003 06:51:15 GMT
On 9/25/03 12:23 PM, in article, "James Strachan"
<> wrote:
> Once we can deploy stateless SBs then I'd have thought doing MDBs
> should be similar yes? Basically I was just gonna do something
> extremely simple for now - write  a  dummy little JMS subscriber MBean
> that can mock the JCA connection manager until the JCA part is ready,
> and then get some MDBs working. Then folks could try hooking the mail
> stuff into the same MDB service.
> So does this all sound like a reasonable plan? Anyone working on this
> stuff or on the EJB side of things care to correct any of my mistaken
> assumptions.

I'm pretty sure that your stop-gap solution won't work because I worked on
this problem almost exactly two years ago - before JCA 1.5. The following
explains the problem with using the JMS API as a "moch" connector for
Message Driven Beans. It's kind of complicated.

Any messages received and processed by an MDB must be consumed in the
context of a transaction managed by the MDB's container.  This means that
the MDB container must start a transaction immediately *before* consuming a
message so that the message can be consumed in the context of the new
transaction.  This allows resources and other EJBs accessed by the MDB to be
included in the same transaction as the message itself. If you don't start a
transaction just before consuming the JMS message, the message will not be
part of the transaction initiated by the MDB container.

To start a transaction immediately *before* a message is consumed requires
that the MDB container have some kind of notification that a message is
about to be delivered.  This kind of "prior-knowledge" is not supported in
the JMS API. For this reason vendors were forced, in the past, to write very
tightly coupled integration logic between their MDB containers and the
specific JMS providers.  The result was an M x N problem. For every
combination of EJB vendor and JMS vendor, a special adapter was required.

This is why JCA was extended in version 1.5 to support MDB containers. JCA
provides a protocol that allows the MDB container to initiate a transaction
before the a message is delivered. If both the MDB container and the JMS
vendor support the JCA 1.5 contract, there is automatic plugability.  The M
x N problem is solved. All JCA 1.5 complaint EJB vendors (that's all J2EE
1.4 vendors) are automatically compatible with any JCA 1.5 compatible
messaging system. This is why JCA 1.5 is so important. It allows any J2EE
1.4 vendor to support any messaging system.

Without JCA, you'll have to write a special adapter for each JMS vendor you
want to support. This requires that you have a native mechanism that
provides you with "prior-knowledge" of message delivery. As far as I know,
these natative mechanisms are guarded jealously by vendors. You can
certainly do this with OpenJMS, provided you can create the native API and
get it patched into the OpenJMS code base, but you might as well build in
JCA 1.5 support instead since the amount of work is about equal.

<side-bar comment="this is anecdotal" >

Think back to when EJB 2.0 platforms first came out. Most of them
implemented their own JMS provider. They did this so that they could control
message delivery and have prior-knowledge.  Later, vendors started
announcing compatibility  with 3rd party JMS vendors (e.g. WebLogic with
SonicMQ). Every time an EJB vendor announced support for a different JMS
vendor, it meant that the JMS vendor and the EJB vendor had reached an
agreement to use a native contract.


I hope that helps,

Richard Monson-Haefel
Co-Founder\Developer, Apache Geronimo
Author of:
  J2EE Web Services (AW 2003)
  Enterprise JavaBeans, 4ed (O'Reilly 2004)
  Java Message Service (O'Reilly 2000)

View raw message