You are viewing a plain text version of this content. The canonical link for it is here.
Posted to dev@geronimo.apache.org by James Strachan <ja...@yahoo.co.uk> on 2003/09/25 19:23:20 UTC
MDB support
I'd like us to be able to deploy MDBs inside Geronimo ASAP - however
I'm not totally sure how to go about this, hence this email :).
To properly manage JMS connections and the like we need the JCA
implementation. Though until then I was gonna focus on the MDB hosting
side, where we can treat MDBs as just like a special stateless session
bean.
I've had a hunt around the code & it looks like the stateless session
beans stuff is in the core module in o.a.g.ejb.cache, e.g.
StatelessInstanceFactory right? First question - has anyone tried to
deploy any stateless SBs into Geronimo yet? I couldn't find any test
cases using it - is there something elsewhere I should be looking at?
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.
James
-------
http://radio.weblogs.com/0112098/
Re: MDB support
Posted by David Jencks <da...@snappydsl.net>.
We agree.
/**********************************
* David Jencks
* Partner
* Core Developers Network
* http://www.coredevelopers.net
**********************************/
On Friday, September 26, 2003, at 12:04 PM, Richard Monson-Haefel wrote:
> Yes, I agree. That's a solution you can use to get your unit tests in
> place,
> because it allows you to control the delivery of messages and the
> interaction between the faux JCA resource and the MDB container. I
> guess I
> was talking about a production system. Still, the MDB container itself
> should be designed to adhere to the JCA message-delivery contract even
> if
> the resource you are using is designed purely for testing. Did I
> understand
> your post, or am I off on a tangent?
>
> 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)
> http://www.Monson-Haefel.com
>
>
> On 9/26/03 2:01 AM, "David Jencks" <da...@snappydsl.net> wrote:
>
>> 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
>> * http://www.coredevelopers.net
>> **********************************/
>> <snip>
Re: MDB support
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
Yes, I agree. That's a solution you can use to get your unit tests in place,
because it allows you to control the delivery of messages and the
interaction between the faux JCA resource and the MDB container. I guess I
was talking about a production system. Still, the MDB container itself
should be designed to adhere to the JCA message-delivery contract even if
the resource you are using is designed purely for testing. Did I understand
your post, or am I off on a tangent?
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)
http://www.Monson-Haefel.com
On 9/26/03 2:01 AM, "David Jencks" <da...@snappydsl.net> wrote:
> 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
> * http://www.coredevelopers.net
> **********************************/
>
>
> On Thursday, September 25, 2003, at 11:51 PM, Richard Monson-Haefel
> wrote:
>
>> On 9/25/03 12:23 PM, in article
>> F5B100B7-EF7C-11D7-9F7C-000A959D0312@yahoo.co.uk, "James Strachan"
>> <ja...@yahoo.co.uk> 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.
Re: MDB support
Posted by David Jencks <da...@snappydsl.net>.
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
* http://www.coredevelopers.net
**********************************/
On Thursday, September 25, 2003, at 11:51 PM, Richard Monson-Haefel
wrote:
> On 9/25/03 12:23 PM, in article
> F5B100B7-EF7C-11D7-9F7C-000A959D0312@yahoo.co.uk, "James Strachan"
> <ja...@yahoo.co.uk> 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.
>
> </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)
> http://www.Monson-Haefel.com
>
>
>
Re: MDB support
Posted by Richard Monson-Haefel <Ri...@Monson-Haefel.com>.
On 9/25/03 12:23 PM, in article
F5B100B7-EF7C-11D7-9F7C-000A959D0312@yahoo.co.uk, "James Strachan"
<ja...@yahoo.co.uk> 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.
</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)
http://www.Monson-Haefel.com
Re: MDB support
Posted by Aaron Mulder <am...@alumni.princeton.edu>.
I posted a message a while back with a plan for action to get a
deployer working (as far as I know right now the deployer handles server
components but not application components). However, I haven't had time
to work on it yet. It looks like I'll have some more time to work on it
next week.
Aaron
On Thu, 25 Sep 2003, James Strachan wrote:
> I'd like us to be able to deploy MDBs inside Geronimo ASAP - however
> I'm not totally sure how to go about this, hence this email :).
>
> To properly manage JMS connections and the like we need the JCA
> implementation. Though until then I was gonna focus on the MDB hosting
> side, where we can treat MDBs as just like a special stateless session
> bean.
>
> I've had a hunt around the code & it looks like the stateless session
> beans stuff is in the core module in o.a.g.ejb.cache, e.g.
> StatelessInstanceFactory right? First question - has anyone tried to
> deploy any stateless SBs into Geronimo yet? I couldn't find any test
> cases using it - is there something elsewhere I should be looking at?
>
> 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.
>
> James
> -------
> http://radio.weblogs.com/0112098/
>
Re: MDB support
Posted by Dain Sundstrom <da...@coredevelopers.net>.
On Thursday, September 25, 2003, at 12:23 PM, James Strachan wrote:
> I'd like us to be able to deploy MDBs inside Geronimo ASAP - however
> I'm not totally sure how to go about this, hence this email :).
>
> To properly manage JMS connections and the like we need the JCA
> implementation. Though until then I was gonna focus on the MDB hosting
> side, where we can treat MDBs as just like a special stateless session
> bean.
>
> I've had a hunt around the code & it looks like the stateless session
> beans stuff is in the core module in o.a.g.ejb.cache, e.g.
> StatelessInstanceFactory right? First question - has anyone tried to
> deploy any stateless SBs into Geronimo yet? I couldn't find any test
> cases using it - is there something elsewhere I should be looking at?
All the code to run a Stateless Session Bean is there. What is missing
is the wiring. I did test the code by replacing the Stateless and
Stateful containers in Elba and running the test suite. Anyway, there
is not way to deploy it right now.... sorry.
> 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.
Looks good to me. I think the hard part is getting the management of
the MDB right. I'm thinking of things like thread pool management and
statistics gathering.
-dain