RE: [wsbpel] Topics for the "Review input from TC members" session of the F2FSome

["Maciej Szefler" <mbs@fivesight.com>]

>The question is, do you really need it to be exactly once? Isn't at most once 
>semantics sufficient? For example, if the message from the client application 
>gets lost then the client application will find out eventually and can take 
>some application-level (or workflow specific) course of action to correct 
>(e.g., retry or do an alternate task). By saying we need exactly once 
>semantics we're placing more of a burden on the delivery mechanism than is 
>perhaps needed in general. That's not to say that some service interactions 
>won't need to be exactly once, only that I don't think it's the general case.

The idea of allowing messages to be lost and having the process recover from such a condition seems much less appealing  than mandating a mechanism for detecting duplicate messages. With such a mechanism in place a questionable message may simply be resent, while the alternative requires cluttering the proces definition or client application with logic to detect the error condition. Although exactly-once semantics may not be "needed" they do greatly simplify process design when they can be taken for granted.

>In at least one workflow system I examined in HP, the solution to this was to 
>use the equivalent of a session-id that accompanied every request and a form 
>of retained-results, so that if a duplicate request was seen by a service, it 
>didn't re-execute (unless the operation was explicitly marked as being 
>idempotent) but obtained the result from a cache of previously generated 
>results.

Correlation Sets could be used to provide this kind of functionality; instead of identifying the process instance, a correlation set would identify an "invocation instance", with a caching mechanism of the sort you describe consulted before the process is actually invoked. 

>>b- Invoking an operation, with input and output, that is implemented by
>>a process using receive and replay requires the WSDL operation to be
>>asynchronous. A process may take days or weeks between the receive and
>>the reply, so the client cannot keep a connection open waiting for the
>>reply. Although WSDL 1.1 talks about asynchronous operations; it does
>>not seems to be any support for it in the WSDL specification.

>Agreed. The use of the correlation ID (tracking ID) helps here because I can 
>return hours, days or weeks later to see what happened, even if I expected to 
>get an explicit ack.

I have seen so far no mention of handling for long-running synchronous invocations and would suggest that they be explictly  mentioned in the specification. Using asynchronous callbacks for all long-running interactions is a bit of a burden; with increased adoption of web services technology it seems inevitable that more web services will be deployed on reliable asynchronous messaging systems where the issue is very pronounced. Specifically I am proposing that the notion that a synchronous request/reply operation is always completed in a "reasonable amount of time"  (ie in one HTTP session) be eliminated.

Maciej Szefler
Vice President - Product Development
FiveSight Technologies Inc.
213 N. Morgan Street
Suite 1A
Chicago, Illinois 60607
phone: 312-432-0556 ext 226
email: mbs@fivesight.com