- From: Ugo Corda <UCorda@SeeBeyond.com>
- Date: Mon, 4 Aug 2003 11:58:29 -0700
- 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 -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:58:55 UTC