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:58:29 -0700
Message-ID: <EDDE2977F3D216428E903370E3EBDDC9013A904E@MAIL01.stc.com>
To: "Cutler, Roger (RogerCutler)" <RogerCutler@chevrontexaco.com>, <www-ws-arch@w3.org>

Sorry, [2] should be:

[2] http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/meps-vs-iops/recommendations_clean.htm

> -----Original Message-----
> From: Ugo Corda 
> Sent: Monday, August 04, 2003 11:54 AM
> To: Cutler, Roger (RogerCutler); www-ws-arch@w3.org
> Subject: RE: Issue: Synch/Asynch Web services
> 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
> [2] 
> http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12

> -----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:58:55 UTC

This archive was generated by hypermail 2.4.0 : Friday, 17 January 2020 23:05:54 UTC