RE: Use case 6

>From: public-ws-async-tf-request@w3.org 
...
>>* Can we achieve this case now with the current specs?  With how much
>>"squinting"?
>>  
>>
>As I understand it, WSDL cannot properly advertise such behavior.  The 
>HTTP binding is hard-wired to send replies and the faults on the 
>back-channel.
>

<kevin>It depends how the wsdl interface/portType is defined. 
- If the interface is defined as request-response, then wsdl binding can
not support such case as I explained in the expenseReport use case.

- If we model this use case using multiple interfaces (or operations if
same binding type is in use), then it's do-able. One interface can be
defined for the sync request-response, one interface for the in-only one
way, another interface in the client side for a async call back. Client
makes its choice by choosing the right interface to use, not by changing
the binding on the fly.


>>* What is the minimal change that would be necessary to what 
>spec(s) in
>>order to achieve this case?
>>  
>>
>If WSDL bindings supported a "dynamic" indicating that a particular 
>endpoint or endpoints in a MEP are dynamically specified, e.g., via 
>WS-A.  In practice, this would mean the reply and fault addresses for 
>request/reply and robust out-only, and possibly analogously for 
>solicit/response (or whatever we call it these days) and 
>robust in-only.
>
>>* What would be the "ideal" solution if we could change 
>anything to get
>>this case covered?
>>  
>>
>I think the above would work fine.
>
>>Could you take a swipe at integrating those?
>>
>>--Glen
>>
>>  
>>
>>>-----Original Message-----
>>>From: public-ws-async-tf-request@w3.org 
>>>[mailto:public-ws-async-tf-request@w3.org] On Behalf Of David Hull
>>>Sent: Friday, February 11, 2005 4:06 PM
>>>To: public-ws-async-tf@w3.org
>>>Subject: Use case 6
>>>
>>>Actors:
>>>
>>>
>>>*	A server implementing a request/reply operation
>>>*	A client invoking that operation
>>>*	Optionally, a third party receiving the reply.
>>>
>>>Subcase 1:
>>>
>>>
>>>	At the application level, the client simply sees a 
>>>request/reply operation.  The client-side infrastructure 
>>>would like to be able to decide, as dynamically as possible, 
>>>whether to invoke the operation synchronously or 
>>>asynchronously.  In the first case, the anonymous reply-to 
>>>will be fine (assuming the usual SOAP/HTTP binding).  In the 
>>>second case, the reply-to will have to be a callback address.
>>>	
>>>
>>>Subcase 2:
>>>
>>>
>>>	The party sending the request to the server is not the 
>>>same as the party receiving the reply.  For example, the 
>>>actual client sends a request to some broker, who forwards it 
>>>to the proper server.  There is no reason for the server not 
>>>to send the reply directly to the actual client (as opposed 
>>>to forwarding it through the broker).  In other words, the 
>>>broker's value add is finding the server, not forwarding per 
>>>se.  Note that if the client supplied an anonymous reply-to 
>>>(as with current proxies), the broker will have to forward 
>>>the reply anyway.

Received on Wednesday, 16 February 2005 16:55:40 UTC