Just wanted to make another point. Looking at the JMS 2.0 API, it seems
APIs related to application server support are still optional (e.g.
|ServerSessionPool|
<
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/javax/jms/ServerSessionPool.html>,
|ConnectionConsumer|
<
http://jms-spec.java.net/2.0-SNAPSHOT/apidocs/javax/jms/ConnectionConsumer.html>).
It would therefore be more consistent to make JCA support optional as well.
Chris
--
*Chris Barrow
**Senior Software Engineer
*kaazing-logo <http://www.kaazing.com/>
On 1/28/2013 4:28 PM, Chris Barrow wrote:
> Hi Nigel,
>
> My vote would be 1. B, because I do not believe JMS providers should
> be forced to be part of the Java EE world. Messaging (and Java) are
> useful outside of that world. As you put it yourself, "This obligation
> would apply to all JMS vendors, including those who are not otherwise
> interested in supporting Java EE. ". Why would you want to impose JCA
> support on vendors who are not interested in supporting Java EE?
>
> thanks,
> Chris
>
> On 1/28/2013 7:47 AM, Nigel Deakin 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.
>> 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
>>>>
>>>> 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
>>>
>>>
>>>
>