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