OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Issue - 204 - Proposal to vote



Hi all,

The attached HTML is the proposal to vote for Issue 204.

Thanks!


Regards,
Alex Yiu

Title: Clarify on how to compensate an EventHandler

Proposal Draft for Issue 204

Last modified: July 18, 2005 - 1pm PDT

Summary:
To restrict that the child activity of:
(a) an <onEvent> and <onAlarm> under <eventHandler>
(b) a <forEach> activity (introduced by Issue 147)
MUST be a <scope> activity.

Rationale:
Currently, <eventHandlers> and <forEach> are two constructs in BPEL which:

Due to these two special natures, there is no well-defined way to compensate the work performed by these 2 constructs from perspectives of:
Some clarification is needed to fill in the gap between BPEL's compensation model and semantics introduced by these constructs.

(Note: <catch> also introduces variable to hold fault related data without any explicit declaration. However it is used in "backward" work, while <onEvent>, <onAlarm> and <forEach> can be used in "forward" work. Hence, this kind of clarification is not needed for <catch>.)

Choices:

To fill in the gap between the compensation model and these two constructs, two choices were presented:
The implicit-scope approach is relatively acceptable in the case of <invoke> because there is no nested activity within <invoke> which performs "forward" work. If an implicit scope is added as a result of <forEach> or <onEvent>, any lexically direct child scopes under those constructs will NOT be accessible by the fault handler / compensation handler of the related parent scope.

For example:

<scope name="A">
   <faultHandler>
      <catchAll>
         <compensate scope="C" />
      </catchAll>
   </faultHandler>
   <eventHandlers>

      <onEvent ... >
         <sequence>
           ...
           <scope name="C"> ... </scope>
           ...
         </sequence>
      </onEvent>
   <eventHandlers>
   ...

</scope>


If the implicit-scope approach is adopted, <compensate scope="C" /> will become illegal. This kind of semantics is perceived as too implicit and surprising to users. Therefore, the implicit-scope approach is not preferred. Also, <onEvent> and <onAlarm> will be "upgraded" to become an activity, because it will need an activity name if the implicit-scope-marco is applied.

After the explicit-scope approach is adopted, the example would look like the following:

<scope name="A">
   <faultHandler>
      <catchAll>
         <compensate scope="B" />
      </catchAll>
   </faultHandler>
   <eventHandlers>

      <onEvent ... >
        <scope name="B">
           <sequence>
             ...
             <scope name="C"> ... </scope>
             ...
           </sequence>
        </scope>
      </onEvent>
   <eventHandlers>
   ...

</scope>


With the explicit scope introduced, the semantics of scope-snapshot and scope-specific <compensate> activity becomes well-defined now.

(Note: The above choices discussion was briefly conducted during Palo Alto F2F June-2005.)


Recap and More Details:
To restrict that the child activity of:
(a) an <onEvent> and <onAlarm> under <eventHandler>
(b) a <forEach> activity
MUST be a <scope> activity.

This restriction MUST be enforced during static analysis. (XSD will be updated to reflect this restriction).

Variables introduced by these constructs (i.e. message related variables at <onEvent> and counter variable at <forEach>) will be declared implicitly as local variables of <scope> under <onEvent> and <forEach>. (Hence, scope snapshot semantic is clarified.)



END




[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]