RE: [sca-bindings] Re: ISSUE 18 - Clarify the rules on which queues and

Subject: RE: [sca-bindings] Re: ISSUE 18 - Clarify the rules on which queues and topics are used for responses and callbacks

Here's the proposal for issue BINDINGS-18
http://www.osoa.org/jira/browse/BINDINGS-18

Solution proposal:
Messages sent from a JMS reference with a response queue have the JMS replyTo queue set to the response queue name. For messages received by a service, by default the replyTo, if present, overrides any defined response element. If scaCallbackQueue is present in a message, the callback binding destination is ignored. Clarify that in the callback/conversation section that the use of replyTo and service callback queue are there for interacting with non-SCA applications

Specific updates, referencing sca-jmsbinding-1.1-spec-WD-01.pdf:

Section 4, JMS Binding Schema, line 175/176, replace with the following text:

/binding.jms/response – defines the resources used for handling response messages. References use this element to define the resources used to receive responses, in which case the replyTo destination in messages sent from such a reference should be set to the identified destination. Services use this element to define the resources used to send responses. In this case the replyTo destination in messages received by such a service, if present, should be used in preference to the destination element.

<mje>
I had to scan these words many times before I grasped the meaning. So let me try and spell it out to see if it can be made clearer:

When a Reference communicates with a Service using JMS, there is the need to consider the case where the message exchange pattern is request/response. In particular, when the service receives the request message, it needs to know where to send the response message - and when using JMS, this means defining the destination resource to which the response messages are sent.
The destination resource for the response messages can be defined in a number of ways:

1) For a message sent from a reference, the resource for the response messages may be carried in the replyTo destination in the message itself
For an SCA reference, the value of the replyTo destination can be set by the reference using its /binding.jms/response attribute. If one is not set, the SCA runtime will generate one automatically.

<php>

I believe so

Just another wording to be sure everything is understood :

The implementation of SCA runtime that has jms.binding enabled will set the replyTo value of each message sent with the value defined in its /binding.jms/response.

When the component that receives the message (i.e. the one that has exposed the service) tries to send the response, it will try to use first the replyTo, if it is missing (i.e. typically a sender not from the SCA domain) than the value of /binding.jms/response attribibute is used.

The interesting question what should happen in case both are missing is an interesting one. Since that can be detected at runtime only (message comes with empty ReplyTo) and a runtime will have no idea who is the caller, to whom an exception should be thrown. (Otherwise it would sent the response there.) So how to raise an exception ?

Perhaps the SCA runtime could throw a runtime exception to the onMesage() method and rely on the JMS vendor specific way of handling such exceptions (dead letter queues in some terminologies)

A small clarification : that whole description is for request\response style of operation. See the next comment for oneways

</php>

</mje>

Section 7.2, line 282-291, replace with the following text:

When an SCA component with a reference with a bidirectional interface and JMS binding ("the sender") invokes an operation on that interface, the JMS message that is sent may identify the target for callbacks using the "scaCallbackQueue" user property, or for one way operations the JMS replyTo header may be used, to allow a level of interoperation with non-SCA JMS applications.
<mje> I'm probably being a bit slow here, but a) why do we need a separate scaCallbackQueue if JMS replyTo can also be used? and b) why are one way operations different from request/response ?
</mje>

The JMS spec allows a replyTo destination that can be set on each JMS message, so that framework and applications can model request \ response style.

In case the SCA interfaces are oneway, than this "replyTo" placeholder of the transport mechanism is free to be used for other purposes (I.e. for example to hold the JMS destination for callbacks ).

In case the SCA interfaces are NOT one way (i.e. there is request\response style) than the "replyTo" placeholder is taken, and there is a need for some other place to propagate the callback( scaCallbackQueue)

</php>

The invoked SCA component ("the receiver") can only invoke operations on the callback interface during the execution of the target operation for such a message, or when the service's callback binding identifies a fixed callback queue.
<mje>
I'm having real trouble with this notion. Basically, this way of thinking about callbacks does not jive with the Assembly view of callbacks, in my opinion.

Let's see if I can explain the gist of it:

Where there is a service interface with a callback, all that SCA says is that IF an operation is called on the service, then the service may call back to the invoker, using any of the operations in the callback interface - and that the invoker is expected to supply those operations. SCA does NOT say which of the operations are called, how many operations are called (0, 1, many are allowed), what order they are called or how long it will take to complete those calls.

Now, that phrase "can only invoke operations on the callback interface during the execution of the target operation" is a problem. It is perfectly reasonable to consider a service provider that has some long running process which is invoked by a client - and the initial invocation operation will complete and return long before the process itself is completed (think "days"). It should be reasonable for the provider component to access the callback object (thinking in Java implementation terms for a moment) on the initial invocation and for the provider to store that callback object for later use. The callback object should have all the information needed to execute a successful invocation of any of the callback operations - and should also allow for any number of operations to be invoked at any later time. With this, it is clear that there should NOT be a limit on when the callback operations can be invoked - all that is necessary is that the callback information is preserved until it is needed.

So, bascially, I don't agree with the phrase.
</mje>

The sender's callback queue can be specified on the reference's JMS callback binding, or it can be left to the runtime to provide one, by omitting the callbackService element, the JMS callback binding, or omitting the uri and destination from the JMS callback binding.

Simon Holdsworth
STSM, SCA Bindings Architect; Master Inventor; OASIS SCA Bindings TC Chair
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

sca-bindings message