It's important to keep in mind that the JCA spec is due to be updated in
Java EE 7 as well so we can get what we need from that spec that might
be missing currently in order to make the standard RA/XA interface for
JMS plugability purposes more generic.
I agree with Nigel that the non-Java EE RA client is not that big a deal
since most such clients will use something like Spring that does support
JCA.
I don't see interoperability with other languages as being that high of
a priority. In my experience, most people interested in such
interoprability typically opt to use SOAP or REST and not asynchronous
messaging.
Cheers,
Reza
On 7/13/2011 10:07 PM, John D. Ament wrote:
> 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
> <mailto: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>
> [mailto: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
> <mailto: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
> <mailto: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 <http://www.avg.com>
> >
> > Version: 10.0.1388 / Virus Database: 1516/3751 - Release Date:
> 07/08/11
> >
> >
> >
> >
> >
> >
> >
> >
>
>
> ------------------------------------------------------------------------
>
> No virus found in this message.
> Checked by AVG - www.avg.com <http://www.avg.com>
> Version: 10.0.1390 / Virus Database: 1516/3763 - Release Date: 07/13/11
>