sca-bindings message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Optional Conformance Items in the JMS Binding Spec
- From: Mike Edwards <mike_edwards@uk.ibm.com>
- To: "OASIS Bindings" <sca-bindings@lists.oasis-open.org>
- Date: Fri, 8 Apr 2011 09:40:22 +0100
Folks,
Here is an analysis of the Optional
conformance items in the JMS Binding specification and a discussion of
what we should do with
them - this is similar to the examination
of the Web Services binding specification done by Simon Holdsworth. This
note
is a preamble to the creation of one
or more issues to deal with these optional items and either make them mandatory
or make them
non-normative.
First a list of the normative statements
that are optional in some way or other:
30006
30028
30030
40001
40007
60001
60009
60016
Looking at each one in turn:
[BJM30006]
SCA runtimes MAY allow other values
of the @correlationScheme attribute to indicate other correlation schemes
Proposal: This should be turned
into non-normative commentary:
"SCA runtimes can allow other values
of the @correlationScheme attribute to indicate other correlation schemes."
[BJM30028]
SCA runtimes MAY place restrictions
on the properties of the resource adapter Java bean that can be set using
the resourceAdapter element
Proposal: This should be turned into
non-normative commentary:
"SCA runtimes can place restrictions
on the properties of the resource adapter Java bean that can be set using
the resourceAdapter element"
[BJM30030]
The SCA runtime SHOULD make the operationProperties
element corresponding to the selectedOperation available to the wireFormat
implementation
Proposal: This should be turned into
non-normative commentary:
"It is regarded as good practice
for the SCA runtime to make the operationProperties element corresponding
to the selectedOperation available to the wireFormat implementation"
[BJM40001]
The SCA runtime MUST support the default
JMS wire format and operation selector behavior, and MAY provide additional
means to override it
Proposal: Split into two parts - retain
the normative MUST part but split off the second MAY clause into a non-normative
comment.
"The SCA runtime MUST support the
default JMS wire format and operation selector behaviour. The SCA
runtime can provide additional means to override the default JMS wire format
and
operation selector behaviour"
[BJM40007]
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
Proposal: This should be turned into
non-normative commentary:
"When using the default wire format
an SCA runtime can provide additional configuration to allow selection
between JMS text or bytes messages to be sent"
[BJM60001]
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
Proposal: Harden into a mandatory
requirement:
"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 MUST 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"
[BJM60009]
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
Proposal: Harden into a mandatory
requirement:
"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 MUST
be raised by the SCA runtime"
[BJM60016]
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
Proposal: Harden into a mandatory
requirement:
"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 MUST raise an error and throw an
exception to the caller of the callback operation"
Yours, Mike
|
|
Dr Mike Edwards
| Mail Point 137, Hursley
Park
|
|
STSM
| Winchester, Hants SO21
2JN
|
SCA & Services
Standards
| United Kingdom
|
Co-Chair OASIS SCA
Assembly TC
|
|
|
IBM Software Group
|
|
|
Phone:
| +44-1962 818014
|
|
|
Mobile:
| +44-7802-467431 (274097)
|
|
|
e-mail:
| mike_edwards@uk.ibm.com
|
|
|
|
|
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]