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

["Mark Little" <mark.little@arjuna.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.
>

I agree, but the point I was making was whether they should be the default
case and I've yet to see a good argument for that. It may well be that
something like WS-Reliability or WS-Reliable Messaging will be supported
eventually, and that'll take care of the problem *if* you want to use it.
But *should* you have to use it? No, I don't think so.

> >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.
>

Agreed.

> >>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.
>

I'm not sure this is realistic. Using reliable messaging imposes an
overhead: you don't get something for nothing, especially in the area of
fault-tolerance. There are many situations where fault handling can be more
efficiently managed at the application level simply because it has the
necessary semantic information to do that. I think we have to be pragmatic
and support what people are using now as well as what they *may* use in the
future - I for one don't have a scrying glass to see the future ;-)

Mark.