[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Issue - 260 - [Fwd: Re: Chapter 11 review meeting scheduled (wordingfor Issue 260)]
Hi all, Resend with a proper subject line ... Just in case if we need to discuss in the F2F next week. Thanks! Regards, Alex Yiu -------- Original Message --------
Hi, all, Last time we stopped around: "Suppressing the bpel:joinFailure fault is similar to surrounding each affected activity with a activity that defines an empty faultHandler for the bpel:joinFailure fault. For example, the following:" ... right before rewording a couple of paragraphs needed for Issue 260 ... Here are my suggested changes (highlighted in GREEN) for discussion tomorrow: From: ------------------------------ <process...> <scope name="invokeA"> <faultHandlers> <catch faultName="bpel:joinFailure"> <empty/> </catch> </faultHandlers> <invoke name="invokeA" ... /> <targets> <target ... /> </targets> </invoke> </scope> </process> ------------------------------ To: ------------------------------ <process...> <scope name="virtual scope"> <faultHandlers> <catch faultName="bpel:joinFailure"> <empty/> </catch> </faultHandlers> <invoke name="invokeA" ... /> <targets> <target ... /> </targets> </invoke> </scope> </process> ------------------------------ From: ------------------------------ The faultHandler behavior is an <empty> activity, that is, the faultHandler suppresses the fault and does nothing about it. Note that ------------------------------ To: ------------------------------ The faultHandler behavior is an <empty> activity, that is, the faultHandler suppresses the fault and does nothing about it. Note that the "virtual scope" mentioned above only is just for illustration only and is not meant for normative semantics equivalence. Except suppressing join failure, this "virtual scope" does not carry any other scope-related semantics, such as compensation. ------------------------------ From: ------------------------------ The name of the scope created to suppress the bpel:joinFailure fault that immediately encloses an activity with a join condition is the same as the name of the activity itself. In case of an <invoke> activity (see 10.3. Invoking Web Service Operations) with an inlined fault or compensationHandler, join failure suppression is applied to the implied scope of the <invoke> activity. Effectively two scopes are implied: an outer scope containing an empty faultHandler for the bpel:joinFailure fault and an inner scope containing the links, faultHandlers, and compensationHandlers of the original <invoke> activity. Identical rules apply to <scope> activities: a <scope> with join failure suppression enabled implies an additional surrounding scope. ------------------------------ To: ------------------------------ encloses an activity with a join condition is the same as the name of the activity itself. case of an <invoke> activity (see 10.3. Invoking Web Service Operations) with an inlined fault or compensationHandler, join failure suppression is applied to the implied scope of the <invoke> activity. Effectively two scopes are implied: an outer "virtual scope" containing an empty faultHandler for the bpel:joinFailure fault and an inner scope containing the links, faultHandlers, and compensationHandlers of the original <invoke> activity. To highlight the contrary again, the inner implied scope is indeed a real scope with all scope related semantics without the actual <scope> syntax, while the outer "virtual scope" does not carry any real scope semantics (e.g. compensation) except suppressing join failure. Identical rules apply to <scope> activities: a <scope> with join failure suppression enabled implies an additional surrounding "virtual scope". That is, when join failure happens, the inner scope does not even get started. ------------------------------ Thanks! Regards, Alex Yiu Alex Yiu wrote:
|
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]