Hi, Yaron and Danny,
Even though I would not oppose renaming <compensate /> to
something else.
(e.g. <compensateChildScopes /> ) to avoid any further
confusion. (Because, one of my customers got confused also.)
But, there was a major misunderstanding in the issue
description expressed by Yaron:
"The semantics of <compensate/> are to call the local
compensation handler for the enclosing scope."
That is incorrect.
<compensate /> serves a higher level activity which calls the
compensation handlers of all completed CHILD scopes in
the compensation order as specified by Issue 1 and 10. Vaguely
speaking, one (Satish was the main driver of these 2 issues, while
Nick and I were the major backer of those 2 issues as well as IBM
folks).
Only activity in faultHandler/terminationHandler/compensation of parent
scope can call the compensation handler.
Example to clarify:
--------------------------
<scope name="A">
<faultHandler>
<catch ... >
<sequence>
<compensate />
<invoke ... />
<!-- invoke some extra operations
as a part of fault logic -->
</sequence>
</catch>
</faultHandler>
<compensateHandler>
<sequence>
<compensate />
<invoke ... />
<!-- invoke some extra operations
as a part of compensation logic -->
</sequence>
</compensateHandler>
<sequence>
<scope name="B">
...
</scope>
<scope name="C">
...
</scope>
</sequence>
</scope>
--------------------------
The <compensate/> in the fault handler and compensation handler
of scope "A" will invoke the compensationHander of scope "C" and scope
"B" (if they are completed.) The <compensationHandler> of scope
"A" will NOT get touched by the <compensate /> activities in
scope "A".
I hope that clarifies the picture.
Thanks!
Regards,
Alex Yiu
Danny van der Rijn wrote:
+1. We
would also need to clarify in the schema and spec text when each of
these is allowed, as currently, I believe that there are cases when one
should be allowed, but not the other.
Danny
ws-bpel issues list editor wrote:
This issue has been added to the wsbpel issue
list with a status of "received". The status will be changed to "open"
if the TC accepts it as identifying a bug in the spec or decides it
should be accepted specially. Otherwise it will be closed without
further consideration (but will be marked as "Revisitable")
The issues list is posted as a Technical Committee document to the
OASIS WSBPEL TC pages
<http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a
regular basis. The current edition, as a TC document, is the most
recent version of the document entitled ** in the "Issues" folder of
the WSBPEL TC document list
<http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php>
- the next posting as a TC document 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
<http://www.choreology.com/external/WS_BPEL_issues_list.html>.
Issue - 217 - Need new name for <compensate>
*Status:* received
*Date added:* 8 Jun 2005
*Categories:* Compensation <#category_compensation>
*Date submitted:* 07 June 2005
*Submitter:* Yaron Y. Goland <mailto:ygoland@bea.com>
*Description:* The semantics of <compensate/> are to call the
local compensation handler for the enclosing scope, an activity that
can occur even in a fault handler. The semantics of <compensate
scope=".."/> is to call the installed compensation handler on a
successfully completed child scope. The semantics of these two actions
are very different but they share the same activity name which leads to
confusion.
*Submitter’s proposal:* I would propose splitting these into two
activities. <defaultCompensate> and <compensate
scope="..."/>.
*Changes:* 8 Jun 2005 - new issue
------------------------------------------------------------------------
To comment on this issue (including whether it should be accepted),
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 - 217 - [anything]" or is a reply
to such a message. If you want to formally propose a resolution to an
open issue, please start the subject line "Issue - 217 - Proposed
resolution", without any Re: or similar.
To add a new issue, see the issues procedures document (but the address
for new issue submission is the sender of this announcement).
Choreology Anti virus scan completed
---------------------------------------------------------------------
To unsubscribe from this mail list, you must leave the OASIS TC that
generates this mail. You may a link to this group and all your TCs in
OASIS
at:
https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
|