> -----Original Message-----
> From: Cutler, Roger (RogerCutler)
> [mailto:RogerCutler@chevrontexaco.com]
> Sent: Monday, August 04, 2003 1:52 PM
> To: Francis McCabe
> Cc: www-ws-arch@w3.org
> Subject: RE: Issue: Synch/Asynch Web services
>
>
>
> Well, whether I misunderstood it or not, it seems to me to be
> an interesting insight that at least certain classes of
> asynchronous operations (probably the more common ones)
> REQUIRE information to be passed that will allow a response
> to be identified properly when it gets back (or wherever it
> is going). The simplest SOAP message, I think, just has a
> body, no ID's or anything. If you are doing synchronous
> stuff, you can send a REAL simple SOAP message to a Web
> service and get a REAL simple one back -- because you are
> waiting and, essentially, "the next message is the one I am
> interested in". If, however, you are doing thiis
> asynchronously, I think that some extra information must be
> passed to the Web service and the Web service must properly
> pass it back so the requestor can recognize the message coming back.
This gets into the MEP discussion we had in North Carolina: One of the uses
of the MEP is to allow standardized bindings onto underlying protocols. So,
for example, synchronous request-response can be bound onto an HTTP POST, so
the SOAP processor doesn't have to be concerned with things like correlating
the request and response messages.
So, I think the "extra information" is the MEP and the protocol binding, in
many cases. Of course, if you are implementing a synchronous MEP on an
asynch protocol or vice versa, this extra information does have to be
exposed.
I'm not sure how this relates to the proposed wording in the doc, however
... I really hope we can maintain a focus on that because we seem to be
closer to agreement on wording than we are on underlying rationales.
I imagine that David would be happy to setup a straw poll once we have a
strawman definition or small set of definitions to choose from.