Fair warning - this is one of the few areas where Nigel and I may publically offer somewhat different viewpoints.
I'm going to try and fight the tide here and suggest a middle path that requires both an RA +plus+ "simplified" Chapter 8 support, where a simplified Chapter 8 could, in its most limited from, consist of removing all of the current Chapter 8 and replacing it with a single "getXAResource()" call on a regular javax.jms.Session. (A more complex version could consist of hardening/cleaning-up the Chapter 8 ConnectionConsumer API to more clearly define its XA interaction.)
Why? If I understand correctly, there a few significant drawbacks to a JCA-only (no Chapter 8) approach:
- Expanding on Nigel's #1: First, without something like Chapter 8, it would be impractical/impossible to have a single "generic RA" , "generic MDB", or "generic bridge" that supports XA transparently with multiple JMS vendors. Anyone working with multiple vendors will have to separately learn how to use each specific vendor's RA configuration, monitoring, capabilities/extensions, and limitations. I think this reduces the portability and transparency of JMS.
- Expanding on Nigel's #2: Second, requiring an RA for XA support implies that a full Java EE app server will be required to support JMS/XA interaction. A stand-alone client that has a built-in JTA/TM capability may not also be able to easily integrate an arbitrary RA (the client may not have a connector container framework). Stand-alone clients aren't necessarily clients in the purest sense of the word - they can include things like simple servlet containers, etc.
- And a new third: If we eventually choose to also standardize .NET and C "J"MS APIs, standardizing XA support in way similar to the Java API would be problematic: these environments have no equivalent to JCA.
- Plus a new fourth: With a simplified chapter 8 support, JMS providers that don't have the time or desire to write their own RA could instead provide simplified Chapter 8 support and leverage a third party RA that works with any simplified Chapter 8 implementation.
Tom
From: clebert.suconic_at_gmail.com [mailto:clebert.suconic_at_gmail.com]
Sent: Friday, July 08, 2011 2:36 PM
To: jsr343-experts_at_jms-spec.java.net
Subject: [jsr343-experts] Re: (JMS_SPEC-26) Decide on the future of the optional Chapter 8 API "JMS Appli
+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
>
>
>
>
>
>
>
>