OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.


Help: OASIS Mailing Lists Help | MarkMail Help

sca-bindings message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]

Subject: Comments on Issue BINDINGS-94 and JMSReplyTo


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

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]