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
|