wsbpel message
[Date Prev]
| [Thread Prev]
| [Thread Next]
| [Date Next]
--
[Date Index]
| [Thread Index]
| [List Home]
Subject: Issue - 204 - Proposal to vote
- From: Alex Yiu <alex.yiu@oracle.com>
- To: wsbpeltc <wsbpel@lists.oasis-open.org>
- Date: Thu, 21 Jul 2005 12:52:27 -0700
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:
- introduces new variables without any explicit declaration
(<onEvent> implicitly declares message-related variables, while
<forEach> implicitly declares counter variable), and,
- introduces dynamic parallelism (i.e. having parallel branches of which number is not known ahead of time)
Due to these two special natures, there is no well-defined way to
compensate the work performed by these 2 constructs from perspectives
of:
- lack of a well-defined scope-snapshot
- lack of a way to refer to dynamic parallel work being done (e.g. <compensate scope="aScopeName" /> )
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:
- Implicit-Scope:
treating <onEvent>/<onAlarm> (under <eventHandler>)
and <forEach> constructs as a way to add an implicit scope,
similar to the <invoke> macro (i.e. <invoke> plus
<compensationHandler>/<faultHandler> shorthand)
- Explicit-Scope:
asking developers to use a <scope> explicitly as the child
activity under these constructs instead of adding any implicit scopes
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]