The behavior of the default compensation handler is the same in both cases.
In the spirit of the current spec, specifying that
(1) <compensate/> calls the compensation handlers of all successfully
completed CHILD scopes
(2) the default compensation handler just calls <compensate/>
avoids
(a) the complexity of activating compensation handlers at different times
(b) the complexity of defining two compensate activities
(c) the complexity having active (default) compensation handlers for
running scopes
Kind Regards
DK
"Yaron Y. Goland"
<ygoland@bea.com>
To
27.06.2005 19:25 Rania Khalaf
<rkhalaf@watson.ibm.com>
cc
Please respond to Dieter Koenig1/Germany/IBM@IBMDE,
ygoland Alex Yiu <alex.yiu@oracle.com>,
Danny van der Rijn
<dannyv@tibco.com>,
wsbpel@lists.oasis-open.org
Subject
Re: [wsbpel] Issue - 217 - Need new
name for <compensate>
Now someone explain to me how Alex's description of compensate is in any
material way different than the behavior of the default compensation
handler?
Yaron
Rania Khalaf wrote:
Yup, exactly +1 :)
Dieter Koenig1 wrote:
>+1.
>
>This is basically the same observation I made in a couple of appends on
>207.
>
>>From my point of view, 217 cannot be opened as a bug issue as it makes
>assumptions about the behavior of <compensate/> that are not described
in
>the spec.
>
>Kind Regards
>DK
>
>
>
>
> Alex Yiu
> <alex.yiu@oracle.
> com>
To
> Alex Yiu <alex.yiu@oracle.com>
> 23.06.2005 23:41
cc
> Danny van der Rijn
> <dannyv@tibco.com>, "Yaron Y.
> Goland" <ygoland@bea.com>,
> wsbpel@lists.oasis-open.org
>
Subject
> Re: [wsbpel] Issue - 217 - Need
new
> name for <compensate>
>
>
>
>
>
>
>
>
>
>
>
>Sorry, I accidentally hit the send button before I finished my last
>sentence.:-)
>-----------------------------------
><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 would consider
><compensate /> as an "intelligent" version "macro" that represents a
series
>of <compensate scope="scopeName" /> activities.
>-----------------------------------
>
>
>Regards,
>Alex Yiu
>
>
>Alex Yiu wrote:
>
> 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
>
>
>
---------------------------------------------------------------------
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