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

HI Mike,

 

some comments 
inside with <php>, 

That's my understanding of the proposal, perhaps the 
originator has a different one :)

 

Best Regards

Peter

 

From: Mike Edwards 
[mailto:] 
Sent: Thursday, 10. January 2008 
15:26
To: 
Subject: Re: 
[sca-bindings] Re: ISSUE 18 - Clarify the rules on which queues and topics are 
used for responses and callbacks

Folks, 

Unless I've misunderstood the new wording, I think there 
is a problem with the proposal here - 
comments inline as <mje>...</mje> 

Yours,  Mike.

Strategist - Emerging Technologies, SCA 
& SDO.
Co Chair OASIS SCA Assembly TC.
IBM Hursley Park, Mail Point 
146, Winchester, SO21 2JN, Great Britain.
Phone & FAX: +44-1962-818014 
   Mobile: +44-7802-467431  
Email: 
  

  
  

    Simon 
      Holdsworth/UK/IBM@IBMGB 
      
09/01/2008 13:22 

    
      
        
        

          
            
To

           
        

          
            
cc

          
        

          
            
Subject

          [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. 

 

2) Where a service receives a message without a replyTo 
destination specified (typically from a sender outside the SCA domain), the 
responses are sent to the destination resource identified by the 
/binding.jms/response attribibute of the service.  If no destination is 
specified by either means, it is an error and an exception is raised. 

....did I get it 
right???  

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

 

<php>

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> 
 

<php>

+1 to this

Java code can potentially cache the reference to the 
callback object (requestContext.getCallback() or @Callback)  and use 
it much later after the request has ended.

 

I think there is some room for simplification or at least a 
lot of examples for the whole callback / scoping story in the java 
spec

</php> 

 
If the received message includes a value for the scaCallbackQueue, then 
that should be used in preference to any that may be defined on the service's 
callback binding. Note that the use of a fixed callback queue is primarily for 
interaction with non-SCA JMS applications, as SCA JMS applications should set 
the scaCallbackQueue JMS user property. 

<mje> 
What if scaCallbackQueue is NOT present, but replyTo is 
set? 
</mje> 

 

<php>

That in my understanding can happen in two cases 
:

 

   There is one way operation and there is also a 
bidirection interface (i.e. callbacks). In that case replyTo is used for the 
callback.

   There is request\ 
response operation. In that case replyTo is used for the 
response.

 

</php> 

 

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 - 

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 

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