Tom,
Maybe it's just my naive interpretation, but does including a standardized
JCA preclude the ability to integrate via another fashion? E.g. can Chapter
8 and Standardized JCA coexist?
John
On Fri, Jul 8, 2011 at 8:59 PM, Tom Barnes <tom.barnes_at_oracle.com> wrote:
> 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 m! ore 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
> >
> >
> >
> >
> >
> >
> >
> >****
>