Further discussion around issue BINDINGS-96 proposal

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

Per the discussion on last week's call,
here is some more background to the BINDINGS-96 proposal, around changing
the use of the scaCallbackDestination for oneway operations.  I'd
appreciate your reactions to this so that we can determine if changes are
required to the current proposal.

The assumption I am making here is that
most JMS applications that are going to be connected to SCA components
via binding.jms are not aware of SCA, and in particular do not understand
the SCA definition for the use of scaCallbackDestination.  For this
reason I believe we need to ensure that the message exchange patterns that
we define for binding.jms fit with existing usage of JMS, and the standard
behaviour of JMS headers.  I'm also assuming that an SCA binding,jms
implemenation does not know whether the JMS application it is communicating
with is SCA aware.

Common MEPs for JMS are as follows:

1) one-way, with no JMSReplyTo
This case is best modelled in SCA using
a oneway operation, no callback.

2) request with single correlated response,
 using JMSReplyTo destination, and correlation using JMS correlation
ID or JMS message ID.
In this case the client expects to receive
a single response, identified by correlation identifier.  It will
typically read that specific message from the reply queue, so the reply
queue could be used for multiple parallel requests or shared by multiple
clients.
This case is best modelled in SCA using
a request/response operation, no callback.  This limits the interaction
to a single response.

3) request with multiple responses,
using JMSReplyTo destination, correlation done through application-level
data in the message.
In this case, the application reading
the response destination is typically going to process every message as
a response message without regard to the correlation identifier, and so
these shouldn't be mixed on the same destination as reply messages from
the previous case.
This case is best modelled in SCA using
a oneway operation with a callback interface with oneway operation.  This
allows the possibility of multiple callback messages whilst leveraging
the SCA callback concept.

4) request with multiple callbacks,
using JMSReplyTo destination, and correlation using JMS correlation ID.
The use of correlation for multiple
callbacks was provided by our conversational support but this is out of
the scope of current specs so I'm not sure we should support this case.
 This would not really make sense for a reference as without conversations
there's no meaning to having a callback correlated with a request within
SCA.  For an SCA service, we may want to support this as for 3), with
an additional attribute on the service binding to specify the callback
correlation scheme (default no correlation), so that the correlation identifier
can be set as needed by the JMS client application.

I don't believe the pattern of request
with single correlated response and multiple additional callbacks is a
common one for JMS applications today. This kind of interaction is not
handled by the JMS spec.

Given the different ways of handing
correlated responses from callbacks I don't think we should require that
the same destination be used for both.  That in turn requires that
we have a place to specify responses (JMSReplyTo) and an additional element
to specify the callback destination for request/response operations at
least.  

The current text in JMS binding CD03
allows for 3) by saying that for oneway requests on bidirectional interfaces,
you MAY set the JMSReplyTo in addition to the scaCallbackDestination, to
cater for the possibility that the JMS application is not SCA-aware.  The
concern raised in the issue is that the SCA runtime sending the request
message does not necessarily know whether the JMS application is SCA-aware.
 In order to be "safe" the sender would need to always set
the callback destination as both JMSReplyTo and scaCallbackDestination,
resulting in duplication of that information in the JMS message.

All of the above cases can be handled
using the JMSReplyTo destination if required along with appropriate correlation,
so I believe that we should define our protocol to fit with this.  
An additional destination identifier is only required for request/response
with callbacks, and so the protocol should only use that additional value
for that case.  I don't see any value in always setting scaCallbackDestination
in addition to JMSReplyTo for 3) and 4) above, for instance.  Any
runtime sending or receiving JMS messages has to understand whether it
is doing so as part of a request/response or oneway interaction, so I don't
see this as any significant implementation overhead.

In summary I think we have the following
options:

A) Don't support callbacks for non-SCA-aware
JMS applications.  Only support case 1) and 2) above, and require
use of scaCallbackDestination for all operations invoked on a bidirectional
interface.

B) Support callbacks as described above,
with scaCallbackDestination only being used for the case that cannot be
handled by JMSReplyTo, i.e. request/response with callback (current proposal).

C)  Support callbacks as described
above, with scaCallbackDestination always being used for bidirectional
operations, with JMSReplyTo duplicating that destination for oneway operations
with callback (i.e. just change the current MAY to MUST).

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