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
>
>