RE: Issue: Synch/Asynch Web services

Right you are.  One thing at a time.  First understand what synchronous
and asynchronous messaging are, THEN apply these concepts as appropriate
to the higher level constructions (like Web services themselves).

You will recall I am claiming that, once the concepts are defined and
understood, there are a number of questions about Web services that can
be asked and discussed in this context.  One might have a tendency just
to leap into those questions, perhaps to illustrate that they are really
there awaiting us.

-----Original Message-----
From: Champion, Mike [mailto:Mike.Champion@SoftwareAG-USA.com] 
Sent: Monday, August 04, 2003 1:44 PM
To: www-ws-arch@w3.org
Subject: RE: Issue: Synch/Asynch Web services





> -----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.

Received on Monday, 4 August 2003 14:54:22 UTC