W3C home > Mailing lists > Public > www-ws-arch@w3.org > August 2003

RE: Issue: Synch/Asynch Web services

From: Ugo Corda <UCorda@SeeBeyond.com>
Date: Mon, 4 Aug 2003 11:54:15 -0700
Message-ID: <EDDE2977F3D216428E903370E3EBDDC9081267@MAIL01.stc.com>
To: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>, <www-ws-arch@w3.org>

Roger,

I think your point of declaring sync/async at the description (WSDL) level is an important one.

On the other hand, I am confused about what the WSD group is doing in this area. If you look at the latest WSDL Part 2 draft at [1], there is some indication that the WSD group wanted to address the issue. It distinguishes the In-Out MEP from the Request-Response MEP, and defines the latter as: "This pattern is identical to In-Out with the following exception: Any message with {direction} 'out' is sent on the same channel as the message with {direction} 'in'". 

But the just published "Recommendations from WSD Patterns Task Force" at [2] seems to have decided to drop the Request-Response MEP in favor of just using the In-Out MEP. Somebody from the WSD group might be able to shed some light over this.

Ugo

[1] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-patterns.html#request-response
[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-patterns.html#request-response

> -----Original Message-----
> From: Cutler, Roger (RogerCutler) 
> [mailto:RogerCutler@chevrontexaco.com]
> Sent: Monday, August 04, 2003 10:52 AM
> 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.
> 
> I think that this means that not only the requestor but the 
> Web service itself needs to be aware that the operation may 
> be asynchronous.  Or, put another way, there are some WS's 
> that CANNOT be used asynchronously because they do not handle 
> the messaging in such a way that the requestor can recognize 
> the result.
> 
> Of course, I could be wrong here because I'm not expert on 
> all the ins and outs of SOAP and WSDL -- so please correct me 
> if I'm confused.
> 
> Incidentally, I would also think that there are some WS's 
> that CANNOT be used synchronously -- for example if the WS 
> accepts the request and then goes off for some time that 
> might be a week or a month before returning  the answer.  
> Probably a grey area here, but this example seems pretty clear.
> 
> And then, I would think, there are WS's that can be used BOTH 
> s and a/s.  
> 
> So does a WS declare itself somehow in one of these classes 
> or is the requestor just supposed to find out by examining 
> the WSDL for suitable identifiers and trial and error on the 
> response time?  If you're thinking in terms of late binding 
> that seems a bit ... Less than optimal.
> 
 
Received on Monday, 4 August 2003 14:54:27 GMT

This archive was generated by hypermail 2.2.0+W3C-0.50 : Tuesday, 3 July 2007 12:25:22 GMT