- From: David Hull <dmh@tibco.com>
- Date: Tue, 15 Feb 2005 11:57:31 -0500
- To: public-ws-async-tf@w3.org
Glen Daniels wrote: >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"? > > 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. >* 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 Tuesday, 15 February 2005 16:58:05 UTC