Comments on Issue BINDINGS-94 and JMSReplyTo

[Simon Holdsworth <simon_holdsworth@uk.ibm.com>]

Folks,

We started looking at issue BINDINGS-94
(http://www.osoa.org/jira/browse/BINDINGS-94)
on the last call, and there was some concern expressed about the use of
JMSReplyTo in a callback scenario.  In order to move this issue along
I'd like to comment on that, however as far as issue BINDINGS-94 itself
is concerned I don't believe its directly relevant.  

BINDINGS-94 resolution:

BINDINGS-94 was raised to clarify exactly
how the callback destination identity is passed in the scaCallbackDestination
JMS user property.  That's independent of whether or not we allow
the JMSReplyTo to be used for one-way messages with callbacks - although
there is a normative statement that covers both cases.

Currently we just say scaCallbackDestination
holds "name of the JMS Destination", however that's vague and
could be interpreted in a number of ways.  The proposed resolution
(http://lists.oasis-open.org/archives/sca-bindings/200911/msg00008.html
) is to make this very specific and say that the value is a JMS URI, so
that the callback destination can be identified in exactly the same way
as request destinations can be specified via the binding.jms/@uri attribute
- an indeed if a reference has a callback service with JMS binding, that
binding's @uri attribute value would be copied directly into the scaCallbackDestination
user property of JMS messages sent by that reference.  The proposed
resolution requires updating a normative statement which also mentions
JMSReplyTo usage, but does not change the statement with respect to that
behaviour.

JMSReplyTo for callback destination:

The behaviour in question is documented
in the JMS binding specification as follows:

In section 6.4:  "Messages
that correspond to one-way or request/response operations on a bidirectional
interface use either the scaCallbackDestination user property or the JMSReplyTo
destination, or both, to identify the destination to which messages are
to be sent when operations are invoked on the callback interface. The use
of JMSReplyTo for this purpose is to enable interaction with non-SCA JMS
applications, as described below."

Section 6.4.3: "When interacting
with non-SCA JMS applications, the assembler can choose to model a request/response
message exchange using a bidirectional interface. In this case it is likely
that the non-SCA JMS application does not support the use of the scaCallbackDestination
user property. To support this, for one-way messages the JMSReplyTo header
can be used to identify the destination to be used to deliver callback
messages, as described in sections 6.4.1 and 6.4.2.

The point of allowing this as explained
here is that existing JMS applications are written to receive a JMS message,
and then to send response(s) to the JMSReplyTo destination in the received
message.  There's nothing in the JMS specification that explicitly
allows or disallows sending of multiple messages to the JMSReplyTo destination.

Given this behaviour, we allow the developer
to choose to model the interaction with the JMS application either using
a unidirectional interface with a request/response operation (one reply
expected), or using a bidirectional reference with one-way operations in
the forward and callback interfaces (multiple replies expected).  Without
the capability described here, the JMS application would be passed the
information on how to send the response(s) via the scaCallbackDestination,
which it is very unlikely to understand.  For one-way operations allowing
the JMSReplyTo to be set to the callback destination enables the backend
JMS application to continue to operate purely at the level of the JMS specification.
 For request/response operations in a bidirectional interface, the
JMSReplyTo is used for the response message, and the scaCallbackDestination
for callback requests.  This pattern cannot be supported by pure JMS
applications that are not SCA-aware, however with the JMSReplyTo behaviour,
the request/response operation could be replaced by a forward oneway "request"
operation and a specific callback oneway "response" operation
distinct from the other callback operations.

Now if there is still concern over either
whether we should support this capability, or the need to clarify the behaviour
in the specification, then I think a separate issue would be appropriate.

Regards, Simon

Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair,
AT&T and Boeing Lab Advocate
MP 211, IBM UK Labs, Hursley Park, Winchester SO21 2JN, UK
Tel +44-1962-815059 (Internal 245059) Fax +44-1962-816898
Internet - Simon_Holdsworth@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