Logged as: http://www.osoa.org/jira/browse/BINDINGS-141
-Eric
On 10/21/10 8:48 AM, Simon Holdsworth wrote:
OFBEF58FBD.445F1CF5-ON802577C3.00544BC8-802577C3.005696F3@uk.ibm.com"
type="cite">TARGET: SCA JMS
Binding Specification cd04-rev1
DESCRIPTION:
In implementing the test case for
BJM60003:
"For an SCA reference with a JMS binding that has a destination
specified via the response element, the SCA runtime MUST receive
response
messages as defined by the binding's @correlationScheme
attribute [BJM60003]"
it is apparent that in order to receive responses according to
all
the various @correlationScheme attributes, that there is a
requirement
for specific behaviour on the SCA binding runtime when sending
the original
requests.
The correlationScheme attribute
has
three values with specific behaviours. These are partially
defined
by the existing normative statements 30003, 4 and 5. However
these
statements and the text prior to them is really focussed on the
sending
of response messages, not on the sending of request messages.
The particular case that is a
problem
in the test case is when the @correlationScheme attribute is set
to "sca:correlationID".
There is nothing in the JMS binding spec or the JMS spec that
says
that request messages must contain correlationID values.
However
when using the correlationID scheme, the reference runtime needs
to receive
the response message which has the same correlation ID as the
original
request. This implies that the original request MUST include a
correlation
ID, but nowhere is this stated in the specification.
When the @correlationScheme is
"sca:messageID"
there is no additional requirement on the SCA runtime when
sending requests
as JMS messages always have message IDs. When it is "sca:none"
there is no additional requirement on the SCA runtime when
sending requests
as no message or correlationID value is needed.
PROPOSAL:
The issue is specifically with
the sca:correlationID
scheme. The need for the SCA runtime to set the correlationID
is requests is implicitly there in order to be able to satisfy
BJM60003,
however I feel that we should make some changes to the existing
text and
normative statements in order to make this clear.
The proposal is to change the
definition
of the @correlationScheme attribute, on lines 164 onwards, from:
/binding.jms/@correlationScheme –
identifies
the correlation scheme used when sending reply or callback
messages, default
value is “sca:messageID”.
To
/binding.jms/@correlationScheme –
identifies
the correlation scheme used when sending and receiving messages,
default
value is “sca:messageID”. Three specific behaviours are
provided.
"sca:messageID" indicates that response messages can be
correlated with their requests by looking for the request's
messageID header
value in the response's correlationID header;
"sca:correlationID"
indicates that response messages can be correlated with their
requests
by looking for the request's correlationID header value in the
response's
correlationID header; "sca:none" indicates that the response's
correlationID header is not to be used for this purpose and some
other
means is used for the correlation.
Add BJM30007:
If the value of the
@correlationScheme
attribute is “sca:correlationID” the SCA runtime MUST set a
non-null
correlation ID value in requests that it sends. [BJM30004].
Change BJM30005 from:
If the value of the
@correlationScheme
attribute is “sca:none” the SCA runtime MUST NOT set the
correlation
ID [BJM30005].
To:
If the value of the
@correlationScheme
attribute is “sca:none” the SCA runtime MUST NOT set the
correlation
ID in responses that it sends [BJM30005].
An alternative approach would be
to
modify BJM30005 to talk about both requests and responses,
however I think
that will make the statement too muddled. A further alternative
would
be to simply explain the implication of BJM30004/BJM60003 that
when sca:correlationID
is used then request messages have to include a correlationID,
however
I think its clearer just having the normative statement.
Note that there is no need to
have a
normative statement saying that the message ID must be set in
requests
when the correlation scheme is "sca:messageID" because JMS
always
sets the message ID in messages that are sent.
Regards, Simon
Simon Holdsworth
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
|