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

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

I think this should be allowed as long as there's a callback binding 
available on the forward call target service that is able to talk to the 
callback address.  If no suitable binding exists, then an error should be 
raised, either when the forward call is made or when the callback is made 
(the spec should say which).

It's not guaranteed that the forward binding can be used to carry 
callbacks, for example if the client is behind a firewall.  This might be 
a good use case for why it should be possible to use a different binding 
for callbacks from the binding used for forward calls.

Even if we restrict the callback binding type to be the same as the 
forward binding type, there could be different named callback binding 
instances of the same type (e.g., with different policy intents).  This 
seems to imply a need to define how a callback binding is selected if more 
than one valid alternative exists.  The same need to define a selection 
mechanism applies if we allow the callback binding type to be different 
from the forward binding type.

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

To
"Peshev, Peter" <peter.peshev@sap.com>
cc
Simon Nash/UK/IBM@IBMGB, sca-bindings@lists.oasis-open.org
Subject
Re: [sca-bindings] ISSUE 2 - Callback support over the Web Service binding






I think this is a separate issue.

Given that callback information/addresses are binding dependent (or at 
least relegated to the binding), I don't see how this could work, in 
general. My initial reaction is to say that we should not allow it.

-Anish
--

Peshev, Peter wrote:
> Hi
> 
> When speaking about redirecting the callback, by API it is possible to
> redirect it to another component, whose services could be lacking
> binding.ws and instead having only some other binding /*let's say
> binding.jms due to the current lack of other bindings in the OASIS TC :)
> */. 
> 
> If that should be a supported scenario (outbound one binding, inbound
> another) that looks that the callbackId-s should be something SCA
> specific, and hardly rely on some WS-standard. I am little bit confused
> in which TC (java, assembly, bindings) that should be addressed.
> 
> Any thoughts / comments? 
> 
> Btw, I personally dislike refirecting the callback since that is
> actually dynamic appearance of wires (invocation paths) via java code
> usage. 
> 
> That introduces hidden dependencies among components, which cannot be
> analyzed and displayed by any tooling (except some heuristic code
> parsing), cannot be overridden by the assembler via SCDL files and
> somewhat hinders the main focus of component reuse and SOA. In addition
> such dynamic redirecting is likely to complicate any implementation
> which spans beyond one JVM.
> 
> 
> Best Regards
> Peter
> 
> 
> -----Original Message-----
> From: Simon Nash [mailto:NASH@uk.ibm.com] 
> Sent: Tuesday, 2. October 2007 13:51
> To: sca-bindings@lists.oasis-open.org
> Subject: Re: [sca-bindings] ISSUE 2 - Callback support over the Web
> Service binding
> 
> 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).  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.  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.
> 
> 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.
> 
>     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