users@ejb-spec.java.net

[ejb-spec users] Re: [jsr345-experts] Re: [jsr342-experts] proposed MDB improvements

From: Marina Vatkina <marina.vatkina_at_oracle.com>
Date: Wed, 13 Mar 2013 11:00:29 -0700

Guys,

May be resource adapters will become so cool, that everybody will be
writing them :). The hope is that in EE 8 we would not even need a
marker interface, and there will be other (e.g. annotations-based) ways
to match an MDB to the RA. I think that it will be the JMS spec that
would define standard annotations, and the RA if used, will do its job,
and if not used, some other container tools will do it.

And the EJB 3.3 spec will document those annotations (or if the list
becomes too long) we will replace those sections with the references to
the corresponding sections of the JMS spec.

Best,
-marina

On 3/13/13 10:00 AM, Nigel Deakin wrote:
> John,
> On 13/03/2013 12:59, John D. Ament wrote:
>> Nigel,
>>
>> The only difference I see is that currently, the endpoint interface
>> is defined by the JMS spec. The fact that it's the
>> endpoint interface is defined by the EJB spec.
>
> The EJB spec also defines a set of standard JMS activation properties.
>>
>> So, I think to make it consistently used, JMS should define a marker
>> interface that could represent this type of MDB,
>> likewise try to push EJB spec to define some standard JMS/MDB
>> annotations for dealing with queues/topics using this
>> approach.
>
> Indeed.
>
> The question I'm asking is: when we define the new marker interface
> and annotations for this new type of JMS
> MDB, will the EJB spec require that they be supported for *all*
> application servers, or only for those which use the
> JCA API to integrate with their built-in JMS provider?
>
> My view is that if we want these new JMS MDBs to be portable between
> application servers then we must require all
> application servers to support them, whether or not they use JCA to
> integrate with their built-in JMS provider.
>
> The alternative is to require application servers to use JCA to
> integrate with their built-in JMS provider. That's not something the
> EJB spec has required so far.
>
> Nigel
>
>>
>> John
>>
>>
>> On Wed, Mar 13, 2013 at 8:34 AM, Nigel Deakin
>> <nigel.deakin_at_oracle.com <mailto:nigel.deakin_at_oracle.com>> wrote:
>>
>> On 11/03/2013 17:57, John D. Ament wrote:
>>
>> All,
>>
>> Sorry, I responded only to David RE this. Here's my email,
>> but with an extra line.
>>
>> David,
>>
>> Thanks. I think the big issue is that the RA is stuck taking
>> ownership of instantiating the MDB. It would be
>> ideal if
>> it's moved up a level. Probably not a big push for this in
>> this given iteration.
>>
>> Also, I think your point RE queues is somewhat moot. I
>> haven't checked with all app servers, but I believe I can
>> consistently define multiple MDBs that point to the same
>> queue, with the limitation that the message only gets
>> delivered
>> once. I think the difference is that it's delivered to the
>> RA once now, and now the RA has to distribute the
>> message to
>> an appropriate listener. Might be none, in which nothing
>> happens or it could be several and now they all
>> receive it.
>> Since we might consider these MDBs as components in the
>> same application it's not in conflict with the JMS
>> spec to
>> distribute to multiple listeners.
>>
>> Also, need to reiterate a point. Who would be responsible
>> for defining annotations if say we wanted to create a
>> JMS RA
>> based on this approach for MDBs?
>>
>>
>> Once this feature is added to Java EE there will be nothing to
>> stop users creating resource adapters that take
>> advantage of it. However since the annotations would be
>> non-standard and non-mandatory then any MDB implementation
>> would be tied to that specific resource adapter.
>>
>> I think it should be a goal of both JMS and EJB to allow MDBs to
>> be written which take advantage of this new feature
>> which are portable between different application servers and
>> between different JMS providers, just like JMS MDBs are
>> now.
>>
>> The EJB 3.2 spec (and the CTS tests) requires an application
>> server to support JMS MDBs which implement
>> javax.jms.MessageListener and which are configured using the
>> activation properties defined in section 5.4.16 "JMS
>> Message-Driven Beans". However it does not require application
>> servers to support this using a resource adapter, at
>> least for the built-in JMS provider. (Oracle's WebLogic is an
>> example of an application server which does not use a
>> resource adapter to implement MDBs for its built-in JMS provider)
>>
>> So the issue I'd like to ask is: when we define the new marker
>> interface and annotations for this new type of JMS
>> MDB, will the EJB spec require that they be supported for *all*
>> application servers, or only for those which use the
>> JCA API to integrate with their built-in JMS provider?
>>
>> My view is that if we want these new JMS MDBs to be portable
>> between application servers then we must require all
>> application servers to support them, whether or not they use JCA
>> to integrate with their built-in JMS provider.
>>
>> Nigel
>>
>>