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

[Mark Little <Mark.Little@arjuna.com>]

>I have few issues that I will like to add to the list of "Review input
>from TC members" for the F2F meeting.
>
>a- We don't have distributed transactions on web services yet.  So how
>do we insure that an activity such as an "invoke" is executed exactly
>one time?  The following example illustrates the problem:

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.

>
>1. Process A begins execution of an invoke instruction, and sends an
>input message to Process B.  There is no output message defined on the
>invoke.
>2. Process B is defined with a receive instruction corresponding to the
>invoke of process A, and the receive instruction creates a new instance
>of the process.  So upon receipt of the message from process A, a new
>instance of process B is created, and this instance executes the receive
>instruction.
>3. The machine hosting process A crashes.
>4. Process B executes the next step, which is to debit an account and
>update a database.
>5. Process B terminates.  Process B has finished.
>6. The machine hosting process A is restarted.  Process A then
>re-executes the invoke instruction.
>
>On step 6, how can we prevent process A from executing the invoke a
>second time, creating another instance of process B, and debiting the
>account a second time?

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.

I'm not saying this is a perfect solution, since it isn't. But, transactions 
of the type offered by TP systems, WS-T or BTP (as examples) aren't necessary  
for this kind of interaction.

This is similar to what a lot of services offer today. When I try to reserve a 
seat on a train, for example, the service I use generates a tracking ID that I 
can re-submit to it if I don't get a response. From this ID it can then 
determine what answer to "book seat" I missed. If I don't get the ID at all 
(possibly, though unlikely) I'm in a different recovery scenario and I can 
fill in another form to return extra tickets, get them to cancel all work 
requested from me in the the last N days, etc. In many services, recovery 
tends to be an explicit interaction pattern that's been considered by the 
service developer. Obviously tying this into some automated workflow is new, 
but the operations to call are probably already there.

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

>
>>From the point of view of the process executing the invoke the operation
>is asynchronous in that the process blocks for the reply. But, from the
>point of view of the service implementing the receive reply pair; the
>operation is asynchronous, and there is no way to prevent the time
>between the receive and the reply from taking weeks. So, the invoking
>process is blocked, but it cannot maintain a connection open.
>
>c- I am also concerned with the use of WS-Addressing for end point
>references. I'm basically echoing the comment by Ron Ten-Hove.
>
>d- Just a note in the specification reference section, reference [16] is
>WS-Addressing. In appendix C, reference [16] seems to be for
>WS-Transaction.
>

Mark.