RE: Use case 6

Hi Dave:

This is great stuff, but didn't include a couple of pieces we were
looking for in these case writeups.  In particular:

* Can we achieve this case now with the current specs?  With how much
"squinting"?

* What is the minimal change that would be necessary to what spec(s) in
order to achieve this case?

* What would be the "ideal" solution if we could change anything to get
this case covered?

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 Tuesday, 15 February 2005 16:18:35 UTC