OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: [sca-bindings] Untested conformance items in the JMS binding


Hi Simon,

Quick response:

On 4/7/11 6:43 AM, Simon Holdsworth wrote:
OF4B1F53BA.ADE45F39-ON8025786B.004686C5-8025786B.004B4FBB@uk.ibm.com" type="cite">Anish,

I interpreted the action item differently - I was expecting to look at all the MAY and SHOULD statements in the JMS binding spec and decide whether each should stay as is, become non-normative, or be strengthened into MUST statements.  Here's my analysis.  If we agree this is needed, I can open an issue to get the changes made, and then we can asses the impacts to the test cases.

Overall summary, if the changes below are agreed, there are no optional parts to the JMS binding spec and it would be sufficient to have two implementations which pass the test suite.

MAY statements:

1) SCA runtimes MAY allow other values of the @correlationScheme attribute to indicate other correlation schemes [BJM30006].

Proposed change: make this non-normative, change the text to: "SCA runtimes which support other correlation schemes can define additional values for the @correlationSchemeattribute."


+1

OF4B1F53BA.ADE45F39-ON8025786B.004686C5-8025786B.004B4FBB@uk.ibm.com" type="cite">

2) SCA runtimes MAY place restrictions on the properties of the resource adapter Java bean that can be set using the resourceAdapter element [BJM30028].

Proposed change: make this non-normative, change the text to: "The set of valid properties of the resource adapter Java bean are defined by each resource adapter and SCA runtime."


+0: How about: "The SCA runtime and each resource adapter define the set of valid properties for configuring the resource adapter."

OF4B1F53BA.ADE45F39-ON8025786B.004686C5-8025786B.004B4FBB@uk.ibm.com" type="cite">

3) The SCA runtime MUST support the default JMS wire format and operation selector behavior, and MAY provide additional means to override it [BJM40001].

Proposed change: remove the MAY clause from the statement. Add the following sentence at the end of the paragraph currently ending on line 368:  "The operationSelector and wireFormat elements allow a binding element to specify behaviour defined by the binding specification or custom behaviour provided by an SCA runtime."


+1

OF4B1F53BA.ADE45F39-ON8025786B.004686C5-8025786B.004B4FBB@uk.ibm.com" type="cite">

4) When using the default wire format an SCA runtime MAY provide additional configuration to allow selection between JMS text or bytes messages to be sent [BJM40007].

Proposed change: make this non-normative, change the text to: "The default wire format allows a choice of text or bytes format when sending messages; an SCA runtime can restricted this to one or other via additional configuration.

+0: s/restricted/restrict/

OF4B1F53BA.ADE45F39-ON8025786B.004686C5-8025786B.004B4FBB@uk.ibm.com" type="cite">

SHOULD statements:

1) The SCA runtime SHOULD make the operationProperties element corresponding to the selectedOperation available to the wireFormat implementation [BJM30030].

Proposed change: I don't see the value of having this as a normative statement as we have no direct control over implementations.  Make this non-normative, change the text to continue the previous non-normative text on line 299:  "; an SCA runtime can pass these values to the wireFormat implementation for each message received."


+1

OF4B1F53BA.ADE45F39-ON8025786B.004686C5-8025786B.004B4FBB@uk.ibm.com" type="cite">

2) For an SCA reference with a JMS binding and unidirectional interface, when a request message is sent as part of a one-way MEP, the SCA runtime SHOULD NOT set the JMSReplyTo destination header in the JMS message that it creates, regardless of whether the JMS binding has a response element with a destination defined [BJM60001]

For an SCA service with a JMS binding, when a response message is sent as part of a request/response MEP where the request message included a null JMSReplyTo destination and the JMS binding does not include a response/destination then an error SHOULD be raised by the SCA runtime [BJM60009]

For an SCA service with a JMS binding, when a callback request message is sent and no callback destination can be identified then the SCA runtime SHOULD raise an error, and MUST throw an exception to the caller of the callback operation [BJM60016]

Proposed change: no change.  For these three, this is behaviour which we recommend and an SCA runtime would need to document the reason for not following this, so I believe "SHOULD" is correct in this case.  I don't believe this constitutes optional behaviour, we don't need to have 2 implementations which break each of these statements.


+0

OF4B1F53BA.ADE45F39-ON8025786B.004686C5-8025786B.004B4FBB@uk.ibm.com" type="cite">

Other notes:

The word "should" appears non-normatively on line 216 and needs to be changed to "is to"


+1

-Eric.
OF4B1F53BA.ADE45F39-ON8025786B.004686C5-8025786B.004B4FBB@uk.ibm.com" type="cite">


Simon Holdsworth




From:        Anish Karmarkar <Anish.Karmarkar@oracle.com>
To:        OASIS Bindings <sca-bindings@lists.oasis-open.org>
Date:        06/04/2011 21:33
Subject:        [sca-bindings] Untested conformance items in the JMS binding





I went through the JMS binding spec to look for untested conformance
items. Below is the list along with my recommendations for how to deal
with it. Simon already has an AI to go through this and file issues, so
I won't file any issues.

1) Mark the following as untested/untestable (it is already marked as
untested, but in some cases it is marked as untested because it is
optional. Optionality of the feature should not be relevant):
BJM30006, BJM30010, BJM30013, BJM30028, BJM30030, BJM30037, BJM40007

2) Add new tests for the following, as I think these are testable:
BJM300019, BJM30022, BJM50002, BJM60001, BJM60006, BJM60009, BJM60010,
BJM60018

-Anish
--

---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail.  Follow this link to all your TCs in OASIS at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php








Unless stated otherwise above:
IBM United Kingdom Limited - Registered in England and Wales with number 741598.
Registered office: PO Box 41, North Harbour, Portsmouth, Hampshire PO6 3AU








[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]