Hi Mike,
You appear to have repeated work that Simon already did:
http://lists.oasis-open.org/archives/sca-bindings/201104/msg00010.html
and I just noticed that I sent my response just to Simon, rather
than the mailing list. I just re-sent it to the mailing list,
although I cannot seem to pull the URL for it from the archives,
yet.
-Eric.
On 4/8/11 1:40 AM, Mike Edwards wrote:
OFF727BABD.35C8BD10-ON8025786C.002B6ADE-8025786C.002ECE0A@uk.ibm.com"
type="cite">
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
|