- From: David Hull <dmh@tibco.com>
- Date: Tue, 29 Mar 2005 12:58:06 -0500
- To: public-ws-async-tf@w3.org
Someone (Dave O?) wondered what value there might be in explicitly flagging what SOAP MEP is in effect. I think it's a very pertinent question, and I was getting ready to argue that we don't need it, but then something occurred to me. It would be useful for an intermediary (whether in the SOAP sense or just a proxy) to know whether it can close the back-channel or not. In the extant case of SOAP/HTTP req/rep, it knows that it can't. In the async case, however, it's not easy to tell. At the very least, the proxy would need to look at the MAP headers and know about anonymous endpoints and/or the defaulting rules for missing MAP endpoints. This is leaving aside i054. On the other hand, if the sender knows that it doesn't expect a reply (i.e., no endpoints are directed to the back-channel), it could express this by using "fire and forget" one-way. If a reply may or may not come back (i.e., the various async cases we've been discussing), it uses in-[out]. If a reply is definitely expected, it uses in-out. It seems clear that these three cases could all be treated under one umbrella, with a three-way "reply expected" flag, or perhaps a binary "send back at least an ACK" flag. It's less clear to me whether such an umbrella should or need be considered a "SOAP MEP". Maybe so and maybe not.
Received on Tuesday, 29 March 2005 17:58:44 UTC