(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
>
>
>