Issue 1 - Proposal to vote

["Satish Thatte" <satisht@microsoft.com>]

The core problem in Issue 1 is that we have no way to control the firing
of links in cases where the source activity may be compensated after the
link has fired and thus "revoke the promise" of prerequisite fulfillment
that the link may represent.

The proposal is to strengthen the meaning of
"variableAccessSerializable" to also control the visibility of link
status, by attaching the meaning of isolation to the attribute.  In
order to reflect this we propose that the name of the attribute be
changed to "isolated".  Thus we would have

   <scope isolated="yes"> <!-- serializable, non-permeable -->
       <faultHandlers ...> ... </faultHandlers>
       <compensationHandler ...> ... </compensationHandler>
       ...
   </scope>

   <scope isolated="no"> <!-- non-serializable, permeable -->
       <faultHandlers ...> ... </faultHandlers>
       <compensationHandler ...> ... </compensationHandler>
       ...
   </scope>

Where a scope is said to be permeable if link status can travel freely
across its boundaries as in the present specification.  The status of
links leaving (source inside target outside) a non-permeable scope will
not be visible at the target until the scope completes, whether
successfully or unsuccessfully.  If the scope completes unsuccessfully,
the status of links leaving the scope is false regardless of what it was
at the time the source activity completed.  There is no change for links
entering (source outside target inside) the non-permeable scope.

Note that this gives the BPEL process designer the discretion to use
isolated="no" when s/he cares to protect the target from revocable
promises.  The downside of the protection is potential loss of
concurrency.

Nick Kavantzas
Frank Leymann
Dieter Roller
Satish Thatte
Alex Yiu