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: Re: [sca-bindings] Further discussion around issue BINDINGS-96 proposal

Thanks for the time you took to write this out clearly.  No surprise, I
still find myself supporting (B) above all the other options you presented.

Dave Booz
STSM, BPM and SCA Architecture
Co-Chair OASIS SCA-Policy TC and SCA-J TC
"Distributed objects first, then world hunger"
Poughkeepsie, NY (845)-435-6093  or  8-295-6093

| From:      |
  |Simon Holdsworth <simon_holdsworth@uk.ibm.com>                                                                                                    |
| To:        |
  |sca-bindings@lists.oasis-open.org                                                                                                                 |
| Date:      |
  |01/19/2010 10:09 AM                                                                                                                               |
| Subject:   |
  |[sca-bindings] Further discussion around issue BINDINGS-96 proposal                                                                               |

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
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]