geronimo-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From David Jencks <>
Subject Re: MDB support
Date Fri, 26 Sep 2003 07:01:14 GMT
Yes, but James can probably write an mbean that uses the jca 1.5 
message delivery contracts and starts the tx appropriately with just 
the WorkManager implemented.  I did this with the JBoss 4.0 jca 1.5 
support testcases until I wrote the jca 1.5 deployment stuff.  I.e., 
don't use actual jms, just fake the message delivery part of an adapter.

BTW my opinion ATM is that mdbs don't need an instance pool, the jca 
1.5 inbound adapter does that work.  All you need is to create 
MessageEndpoints as requested up to the maximum number you want...

* David Jencks
* Partner
* Core Developers Network

On Thursday, September 25, 2003, at 11:51 PM, Richard Monson-Haefel 

> 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. 
> 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 
> 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 
> vendor, it meant that the JMS vendor and the EJB vendor had reached an
> agreement to use a native contract.
> </side-bar>
> I hope that helps,
> Richard
> -- 
> 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