Re: [sca-bindings] ISSUE 2 - Callback support over the Web Service binding

[Simon Nash <NASH@uk.ibm.com>]

I have been out of the offiice for the last two weeks and I'm catching up 
with email now.  My comments are within <scn>....</scn> below.

    Simon

Simon C. Nash, IBM Distinguished Engineer
Member of the IBM Academy of Technology
Tel. +44-1962-815156  Fax +44-1962-818999



Anish Karmarkar <Anish.Karmarkar@oracle.com> 
04/10/2007 08:00

To
Simon Nash/UK/IBM@IBMGB
cc
sca-bindings@lists.oasis-open.org
Subject
Re: [sca-bindings] ISSUE 2 - Callback support over the Web Service binding






Simon Nash wrote:
> Using the wsa:ReplyTo header for the callback endpoint does not seem to 
> exactly match SCA callback semantics, which allow callback messages to 
be 
> directed to a different endpoint from the endpoint that receives the 
reply 
> to the original request (by calling setCallbackObject() with a 
> ServiceReference).

I agree. It should be possible to say send the reply to the current 
request to my home address, but my callback address is my office 
address. Overloading ReplyTo for callback (as defined by SCA) would 
require introducing a new attribute/element of some sort in ReplyTo to 
distinguish between the two types of ReplyTos. If we are going to define 
a new element/attribute then I would prefer to define something like 
sca:Callback element of type EndpointReference.
<scn>I agree that this would be better than defining different types
of ReplyTo, but I don't much like the idea of defining SCA-specific
protocol elements either.</scn>

>  Using wsa:ReplyTo also requires a message ID to be 
> added to the original request and the same message ID to be returned on 
> the reply and any callbacks in the wsa:RelatesTo header.

That is only true if you think of callback messages as "responses".
<scn>Yes, that was my point.  If they are directed to the ReplyTo address,
then they are responses and this part of WS-Addressing would apply.</scn> 

>  This is more of 
> an observation than a problem, though it does require extra state to be 
> maintained for the message IDs being exchanged.
> 
> In Tuscany, we did not use wsa:Reply To.  Instead we used the 
> WS-Addressing wsa:To endpoint reference with reference parameters to 
> represent the callback endpoint (as a wsa:EndpointReference), the 
callback 
> ID, and the conversation ID for stateful callbacks.
> 

Did you mean wsa:From and not wsa:To? wsa:To is a URI not an EPR.
<scn>You are correct about this difference between wsa:To and wsa:From.
Thanks for pointing this out.  In fact we did use wsa:To in Tuscany, and
this was evidently a mistake.  We are having a discussion now on the
Tuscany mailing list about what we should do instead.</scn>

Between ReplyTo and From, I would most certainly pick From. But there is 
still some overloading going on here. It is assumed that the sender of 
the message and the callback address is the same. It may not be.
The reason I prefer From over ReplyTo is because From is optional for 
all the WSDL MEPs and not many implementations rely on it. So the 
overloading problem is less of a problem than that in the case of ReplyTo.
<scn>I agree that From is better than ReplyTo, but it doesn't cover the
case where callbacks can be directed elsewhere.  It would be possible
to use a reference parameter within the From endpoint reference to handle
this situation.</scn>

> I did not propose a specific solution when opening this issue because I 
> wanted to open this up to as many suggestions and options as possible. 
The 
> discussion around wsa:ReplyTo has been interesting.  Perhaps someone 
will 
> have an idea on we can overcome the semantic mismatch that I mentioned 
> above.  I agree that defining a new header for SCA callbacks would be 
> undesirable.  Even the use of SCA-specific reference parameters seems 
less 
> than ideal, but without them I'm not sure how additional information 
like 
> the callback ID could be transmitted.  We can't use wsa:MessageID for 
> this, because of the statement in the WS-Addressing spec that "No two 
> messages with a distinct application intent may share a [message id] 
> property."  Perhaps the callback ID could be mapped into a wsa:MessageID 

> by adding a unique discriminator, so different callback requests could 
use 
> distinct message IDs from which the same callback ID could be extracted.
> 

I agree that inventing a new header (another WS-* spec anyone?) should 
be the last alternately. But I don't see how MessageId would do anything 
for callbacks (it is a URI not an EPR and it has completely different 
semantics). I also don't see how sca-specific refps would solve the 
problem.
<scn>I was thinking of possibly using MessageId to convey the callback ID,
but MessageId is a URI, so this wouldn't work.</scn>

Of the solutions that have been brought up only From and a new SOAP 
header block seem viable to me.
<scn>Yes, I agree.  If using From, there would also need to be 
SCA-specific
reference parameters for the redirected callback endpoint and the callback 
ID.
If using a new SOAP header block, it would need to contain elements for 
the
callback endpoint and the callback ID.</scn>

Comments?

-Anish
--

>     Simon
> 
> Simon C. Nash, IBM Distinguished Engineer
> Member of the IBM Academy of Technology
> Tel. +44-1962-815156  Fax +44-1962-818999
> 
> 
> 
> Khanderao Kand <khanderao.kand@oracle.com> 
> 01/10/2007 22:47
> 
> To
> Michael Rowley <mrowley@bea.com>
> cc
> sca-bindings@lists.oasis-open.org
> Subject
> Re: [sca-bindings] ISSUE 2 - Callback support over the Web Service 
binding
> 
> 
> 
> 
> 
> 
> Michael Rowley wrote:
>> One problem with using WS-Addressing wsa:ReplyTo is that it is usually
>> used to send the response message of a request/response pair.  I don't
>> think that WS-Address forbids its use for subsequent messages
>> (callbacks), but it would at least be unconventional.
>>
> [khanderao] IMHO WS-Addressing does not make any assumptions on the 
> number of returned messages. It is upto the integration scenario to have 

> one or many.
>> However, if we can't use wsa:ReplyTo, that would seem to imply that we
>> have to devise our own header to use, but that would be getting
>> dangerously close to inventing a wire-level protocol, which we don't
>> want to be doing.
>>
> [khanderao] Introducing SCA specific correlation / replyTo parameters 
> would not be essential. As far as possible we should be using the 
> available standards,  like WSA / WS-Coordination etc..
>> Michael
>>
>> -----Original Message-----
>> From: Eric Johnson [mailto:eric@tibco.com] 
>> Sent: Monday, October 01, 2007 12:16 PM
>> To: sca-bindings@lists.oasis-open.org
>> Subject: Re: [sca-bindings] NEW ISSUE: Callback support over the Web
>> Service binding
>>
>> Created as: http://www.osoa.org/jira/browse/BINDINGS-2
>>
>> -Eric.
>>
>> Simon Nash wrote:
>>
>>> TARGET:
>>>
>>> Web Service Binding specification, section TBD
>>>
>>> DESCRIPTION:
>>>
>>> The Web Service binding provides no example or suggestion for how SCA 
>>> callback semantics could be carried over Web services.  There is an 
>>> example in section 2.2.3 for how conversation semantics could be 
>>> supported.  It would be good to give some guidance (somewhere in the
>>>
>> range 
>>
>>> between example and normative) for what could be done for callbacks.
>>>
>> One 
>>
>>> possibility is to make use of the capabilities provided by
>>>
>> WS-Addressing.
>>
>>> PROPOSAL:
>>>
>>> None yet.
>>>
>>>
>>>
>>>
>>>
>>>
>>> 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
> 
> 
> 
> 
> 
> 







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