[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue 1 - Proposal to vote
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
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]