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


On 4/7/2011 6:43 AM, Simon Holdsworth wrote:
> 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.

The issue stems from the exit criteria which requires that 2 or more 
implementations implement all normative portions. My interpretation of 
that is we need 2 or more impl. to implement all the mandatory and 
optional bits. So we need tests for all of those. Some of the normative 
stuff just isn't testable (regardless of whether it is optional or 
mandatory) -- in which case we just ask the implementers to assert 
whether they implement that feature or not. I think in all this 
optionality isn't relevant.

Now if we convert any of the conformance items (those that contain RFC 
keywords MAY, SHOULD, MUST) to non-normative text then we don't need 
tests. Again optionality isn't relevant IMHO.

-Anish
--

> 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 */@correlationScheme/*attribute."
>
> 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."
>
> 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."
>
> 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.
>
> 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."
>
> 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.
>
> Other notes:
>
> The word "should" appears non-normatively on line 216 and needs to be
> changed to "is to"
>
> 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]