+1
(I have talked to Jesper Pedersen some time ago (spec lead of JCA)) and he
had a similar idea.
Jesper actually offered to have a talk with us whenever needed.
On , Reza Rahman <reza_rahman_at_lycos.com> wrote:
> Nigel,
> I think this should be pruned in favor of JCA.
> Cheers,
> Reza
> On 7/8/2011 12:01 PM, Nigel Deakin wrote:
> I also logged this this JIRA issue:
> http://java.net/jira/browse/JMS_SPEC-26
> Essentially, this stated that Chapter 8 of the JMS 1.1
> specification, "JMS Application Server Facilities", defines an API for
> use by application servers. It has two parts: API to allow concurrent
> processing of a subscription's messages, and API to support distributed
> (XA) transactions. This API is optional and has no compliance tests.
> Should this API be made mandatory, like the rest of the JMS spec, or
> should it be formally pruned from the spec?
> This really depends on the outcome of JMS_SPEC-25 (Standardise the
> interface between a JMS provider and a Java EE application server). If it
> is decided that the interface between a JMS provider and a Java EE
> application server should use these interfaces (rather than the Java EE
> Connector API) then clearly they should become mandatory.
> However, irrespective of the outcome of JMS_SPEC-25 it may be beneficial
> to keep this API and make it mandatory since that would
> 1. allow the creation of a generic JMS resource adapter that can work
> with any JMS 2.0 implementation, and
> 2. allow the creation of non-Java EE frameworks that provide services
> such as XA transactions and async delivery to multiple consumers, but
> which don't support the Java EE Connector Architecture
> However these potential benefits need to be offset against the additional
> burden this may place on JMS vendors.
> Note that if it is decided that these interfaces are _not_ needed, they
> would not be deleted from the spec but remain in their current optional
> state, in accordance with chapter EE.6.1.3 "Pruned Java Technologies" of
> the Java EE 6 specification.
> So effectively the choice is:
> 1. Make them mandatory
> 2. Do nothing (so they remain an optional part of the spec)
> 3. Formally prune them by making an explicit statement to that effect,
> whilst leaving them in the spec.
> I suggest we focus our discussion on the other thread initially, and come
> back to this when we've come to a consensus there.
> Nigel
> -----
> No virus found in this message.
> Checked by AVG - www.avg.com
> Version: 10.0.1388 / Virus Database: 1516/3751 - Release Date: 07/08/11