RE: [wsbpel] Issue 53 - Motion for consideration by the TC

["Furniss, Peter" <Peter.Furniss@choreology.com>]

Responding to another of Satish's points:


> 3.  We can already model these stylized patterns using
> existing BPEL mechanisms as I tried to illustrate with my 
> presentation at the F2F (just uploaded to TC site under 
> "related resources").

Yes, since there is no magic, and BPEL is extremely powerful it's
possible to do it in BPEL explicitly. The question is whether it is
wise. 

The normal and first-order failure paths are perhaps no problem. But,
taking your example, after replying to processPO, the process is
dependent on the client to close it off. Can we trust the client, in all
circumstances, to come back with a confirmAndShip or returnToInventory.
What if the client crashes ? Or gets into a relatively unusual error
state (perhaps some surprise exception from another partner) - can we
trust the client application programmer to ensure that all his error
paths emit returnToInventory if (and only if) they had received a
positive response from our process (and cancelOrder if they have sent
processPO to us and we haven't replied - and extra complications for
collisions). So perhaps we'll protect ourselves with an alarm that
triggers the return to inventory if the client takes too long. Now we've
got to add replies to the confirmAndShip in case we get the timing
wrong, and the client says yes after we've given up. Perhaps we ought to
have some way of indicating between the parties how long this might
take, so we can avoid mis-timings.

So the protocol quickly gets complicated, and even if it is fairly
simple, the desired behaviour on each side is dependent on the correct
implementation of the other side. And will this application protocol be
sufficiently fully worked through to catch all the cases.  Non-trivial
business processes are going to want to be able to exploit generalised
protocols and software to deal with this sort of stuff. We shouldn't be
forcing people to write what is really system software in a process
scripting language. At least let's keep and complete the process-level
finalisation handlers rather than abolish them.

Peter