Issue - 119 - Transition Conditions and Invoke Fault Handlers

[ws-bpel issues list editor<peter.furniss@choreology.com>]

This issue has been added to the wsbpel issue list. The issues list is posted as a Technical Committee document to the OASIS WSBPEL TC pages on a regular basis. The current edition, as a TC document, is the most recent document with the title in the "Issues" folder of the WSBPEL TC document list - the next posting will include this issue. The list editor's working copy, which will normally include an issue when it is announced, is available at this constant URL.

Issue - 119 - Transition Conditions and Invoke Fault Handlers

Status: open
Categories: Scopes, State management
Date added: 19 Apr 2004
Submitter: Maciej Szefler
Date submitted: 16 April 2004
Document: Language Specification
Description: The catch-inside-invoke syntactic "shortcut" described in Section 13.4 is unclear with respect to
the manner in which transition conditions should be evaluated in case of a fault.

The text currently provides an example as to how the shortcut should be interpreted, that goes as follows :

<invoke partnerLink="Seller"
	portType="SP:Purchasing"
	operation="SyncPurchase"
	inputVariable="sendPO"
	outputVariable="getResponse">
     <catch faultName="SP:POFault" faultVariable="POFault">
	<!-- handle the fault -->
     </catch>
</invoke>

is equivalent to / can be re-written as:

<scope>
     <faultHandlers>
	<catch faultName="SP:POFault" faultVariable="POFault">
	     <!-- handle the fault -->
	</catch>
    </faultHandlers>
    <invoke partnerLink="Seller"
	portType="SP:Purchasing"
	operation="SyncPurchase"
	inputVariable="sendPO"
	outputVariable="getResponse">
    </invoke>
</scope>

This leads to the quesiton of how to "rewrite" an invoke that is also the source of a link:

<invoke partnerLink="Seller"
	portType="SP:Purchasing"
	operation="SyncPurchase"
	inputVariable="sendPO"
	outputVariable="getResponse">
     <source linkName="foo" />
     <catch faultName="SP:POFault" faultVariable="POFault">
	<!-- handle the fault -->
     </catch>
</invoke>

The options are either:

<scope>
     <faultHandlers>
	<catch faultName="SP:POFault" faultVariable="POFault">
	     <!-- handle the fault -->
	</catch>
    </faultHandlers>
    <invoke partnerLink="Seller"
	portType="SP:Purchasing"
	operation="SyncPurchase"
	inputVariable="sendPO"
	outputVariable="getResponse">
     <source linkName="foo" />
    </invoke>
</scope>
or 
<scope>
     <source linkName="foo" />
     <faultHandlers>
	<catch faultName="SP:POFault" faultVariable="POFault">
	     <!-- handle the fault -->
	</catch>
    </faultHandlers>
    <invoke partnerLink="Seller"
	portType="SP:Purchasing"
	operation="SyncPurchase"
	inputVariable="sendPO"
	outputVariable="getResponse">
    </invoke>
</scope>

The two versions do not have the same semantics (according to issue 27). In the former case the transition condition will be set to false in the event of a fault. In the latter case the transition condition is evaluated (because the fault is caught and the scope "completes"). While the former interpertation is suggested by the example, the latter interpretation is the more consistent with the resolution of issue 27. This question boils down to the nature of implicit scopes, that is: are implicit scopes merely macros for placing a <scope> around an <invoke>, or does an <invoke> essentially "mix-in" scope features (fault handling).
Links: issue 27 : Setting link status in case of transition condition
Changes: 19 Apr 2004 - new issue

---

To comment on this issue, please follow-up to this announcement on the wsbpel@lists.oasis-open.org list (replying to this message should automatically send your message to that list), or ensure the subject line as you send it starts "Issue - 119 - [anything]" or is a reply to such a message.

To add a new issue, see the issues procedures document (but the address for new issue submission is the sender of this announcement).