Nigel,
Q1: B
Q2: If an implementer decides to implement the feature then it should be a
portable implementation. A failure to implement the feature as a portable
resource adapter would simply mean that the implementer does not support
portability to other containers. (e.g. this shouldn't block them from being
a JMS implementation).
On Mon, Jan 28, 2013 at 10:47 AM, Nigel Deakin <nigel.deakin_at_oracle.com>wrote:
> (Please read and respond to the two questions below on this important
> issue - especially if you are a JMS vendor)
>
> Back in July 2011, one of our first decisions as an expert group was to
> approve my proposal to make it mandatory for a JMS vendor to provide a JCA
> resource adapter "to allow their JMS client to be used from any Java EE
> application server".
>
> (See http://java.net/projects/jms-**spec/lists/jsr343-experts/**
> archive/2011-07/message/42<http://java.net/projects/jms-spec/lists/jsr343-experts/archive/2011-07/message/42>.
> In addition to that thread I also discussed it directly on the phone with
> several expert group members including those who represent JMS vendors)
>
> You may remember that the reason for this requirement was to make JMS
> providers more useful to users. Currently there is no requirement for a JMS
> provider to work in a Java EE environment at all.
>
>
> This is what it now says in the JMS 2.0 public draft:
>
> ------------------------------**------------------------------**
> -------------------
> 12. Resource Adapter
>
> The Java EE Connector Architecture (JCA) specification defines a standard
> architecture for connecting the Java EE platform to enterprise information
> systems (EISs).
>
> A JMS provider (whether it forms part of a Java EE application server or
> not) is required to include a resource adapter which connects to that JMS
> provider and which conforms to the Java EE Connector Architecture
> specification and as further specified in this chapter. Such a resource
> adapter is referred a "JMS standard resource adapter".
>
> The version of the Java EE Connector Architecture specification which
> should be used is 1.7.
>
> This chapter is not intended to prevent the creation and use of additional
> resource adapters for connecting to a JMS provider which do not conform to
> the specifications in this chapter. However Java EE applications which use
> such resource adapters may be less portable.
> ------------------------------**------------------------------**
> -------------------
>
> This text introduces a significant new requirement on the developers of
> "standalone" JMS providers. I would therefore like to be absolutely certain
> that the expert group and community is in favour of it, and, if so, exactly
> what this requirement means in practice.
>
> The wording above places an obligation on JMS vendors to implement a JCA
> resource adapter. This obligation would apply to all JMS vendors, including
> those who are not otherwise interested in supporting Java EE. A JMS vendor
> who did not implement a resource adapter could not describe their product
> as supporting JMS 2.0.
>
> *** Question 1: Do you agree with the existing wording of JMS 2.0, which
> says that "A JMS provider (whether it forms part of a Java EE application
> server or not) is required to include a resource adapter".
>
> A: Yes
>
> B: No
>
> If we are happy with this, then there is a further issue which needs to be
> clarified. This is whether the resource adapter that is provided should be
> able to work with *any* Java EE application server. Although I think we did
> agree on this, the current JMS 2.0 public draft does not explicitly require
> it, which means that it would be valid for a vendor to provide a resource
> adapter that only works with a Java EE application server of their choice.
> Typically this would be the case if the resource adapter, although
> implementing the required JCA API, is dependent on the use of private APIs
> with the application server.
>
> If your answer to question (1) was (A) then I'd like to ask a further
> question.
>
> *** Question 2: Do you think that the resource adapter should be required
> to be "portable" and work with "any" Java EE 7 application server, or
> whether it need only work with a Java EE 7 resource adapter chosen by the
> vendor?
>
> A: The resource adapter should be required to be "portable"
>
> B: The resource adapter need only work with a Java EE 7 resource adapter
> chosen by the vendor
>
> This is an important issue because in addition to determining how a
> resource adapter may be implemented it also determines what kind of
> compliance tests are required. Choosing option (B) means that the
> compliance tests can simply test the RA against the Java EE reference
> implementation or a standalone JCA test harness. Choosing option (A) means
> that the RA must be testing in conjunction with a application server
> specified by the vendor.
>
> Please express your views on both questions.
>
> Thanks,
>
> Nigel
>
>
>
> On 21/07/2011 14:56, Nigel Deakin wrote:
>
>> On 08/07/2011 17:01, Nigel Deakin wrote:
>>
>>> I'd like to start a disscussion about this JIRA issue:
>>> http://java.net/jira/browse/**JMS_SPEC-25<http://java.net/jira/browse/JMS_SPEC-25>
>>>
>>> This issue is about the best way to support the portability of JMS
>>> providers between Java EE application servers. At the
>>> moment there is no (mandatory) API that allows this to be done in a
>>> generic fashion which works with every such
>>> combination.
>>>
>>
>> All responses I have received on this topic so far have supported making
>> it mandatory for a JMS vendor to provide a JCA
>> resource adapter to allow their JMS client to be used from any Java EE
>> application server. No-one has objected or argued
>> that this is an excessive burden on JMS vendors.
>>
>> Some experts proposed making the existing Chapter 8 APi mandatory API as
>> in addition to this. This remains unresolved
>> and will be considered separately as JMS-SPEC_26.
>>
>> I feel we might be approaching our first decision-by-consensus! Unless
>> anyone wants to jump in and disagree, I will
>> consider this agreed in principle, and we can move on.
>>
>> I will now
>>
>> * draft some suitable modifications to the wording in the JMS spec which
>> I will ask you to review in due course
>> (actually trying to write the actual words may raise new issues of
>> detail).
>>
>> * consult the Java EE spec lead about any wider implications of adding
>> this new dependency betweeen specs.
>>
>> * add a note to this effect in the JIRA issue, and create a subtask to
>> cover the task (for me) of drafting the necessary
>> changes for what will be the JMS 2.0 Early Draft.
>>
>> Thanks,
>>
>> Nigel
>>
>>
>>
>>