Re: Issue: Synch/Asynch Web services

As Roger noted, you need a means of message correlation to make 
asynchronous interactions work. This could be an abstract notion, with a 
specific binding detailing how it should be done for a particular transport.

The problem is that WSDL MEPs are not connected with any concept of 
correlation, even an abstract one. The result is that MEPs are in danger 
of being irrelevant for true asynchronous messaging.

There are supplementary specifications to handle correlation. These 
solve the problem but they do it outside the realm of MEPs, which are 
effectively ignored (e.g. WS-Callback just models everything as a 
one-way MEP: the real MEP semantics are not specified at the WSDL 
layer). See also the recent Context Service specification draft.

--Jon

Ugo Corda wrote:
> 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 15:30:56 UTC