Yes, this is one way in which one could extend the custom capability to
match the capability required by what I proposed. I am reluctant to add
this complication though.
-----Original Message-----
From: Assaf Arkin [mailto:]
Sent: Friday, December 12, 2003 12:38 PM
To: Satish Thatte
Cc: ; Sid Askary;
Subject: Re: [wsbpel] Resolution to issue 10 - Implicit compensation
Handler
The current specification requires each scope, upon it's successful
completion, to install a compensation handler within the enclosing
scope. That could be a compensation handler that was explicitly defined,
or a default compensation handler (implicit). But a compensation handler
is always installed in the enclosing scope by the completing scope.
The new proposal changes that behavior. It requires each scope to
support an invocation of its compensation handler by the enclosing
scope, and that could be an explicit or a default compensation handler.
However, when a scope completes, it installs its compensation handler in
the enclosing scope only if one is explicitly defined. If the scope does
not define a compensation handler, it installs the compensation handlers
of its child scopes within its enclosing scope.
To achieve the same behavior with custom handlers, the custom handlers
must be able to invoke any compensation handler installed in their
scope, and not just those coming from direct children. It therefore
needs an understanding of when a compensation handler is installed in
the scope, vs assuming that each child scope installs a compensation
handler upon successful completion.
Assaf
Satish Thatte wrote:
>Sid and Yaron,
>
>My main concern with my own proposal is the fact that the default
>behavior cannot be achieved with custom handlers, which is a fault in
my
>proposal. Someone (cannot recall who) brought that up during the face
>to face and it gave me pause. Need to think about that some more. In
>the mean while let us wait for Peter's comments.
>
>Satish
>
>-----Original Message-----
>From: Yaron Goland [mailto:]
>Sent: Thursday, December 11, 2003 3:42 PM
>To: 'Sid Askary';
>Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation
>Handler
>
>+1
>
>
>
>>-----Original Message-----
>>From: Sid Askary [mailto:]
>>Sent: Tuesday, December 09, 2003 1:46 PM
>>To:
>>Subject: [wsbpel] Resolution to issue 10 - Implicit
>>compensation Handler
>>
>>
>>Satish,
>>As I said, I think your solution (the reverse temporal order)
>>is a good one. I think I have a simple compromise: that we
>>add a sentence to the effect that
>>
>>" Note: Sole reliance on implicit compensation handlers as a
>>programming construct or as a means of defining default
>>system behavior is not recommended."
>>
>>This may address both the "programmatic" (Yaron's) and
>>default behavior (my own) assumptions.
>>
>>Not sure about Peter's concern.
>>
>>- Sid.
>>
>>
>>
>>To unsubscribe from this mailing list (and be removed from
>>the roster of the OASIS TC), go to
>>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/le
>>ave_workgroup.php.
>>
>>
>>
>>
>
>To unsubscribe from this mailing list (and be removed from the roster
of
>the OASIS TC), go to
>http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workg
r
>oup.php.
>
>
>
>
>To unsubscribe from this mailing list (and be removed from the roster
of the OASIS TC), go to
http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgr
oup.php.
>
>
--
"Those who can, do; those who can't, make screenshots"
----------------------------------------------------------------------
Assaf Arkin
Intalio Inc. www.intalio.com
The Business Process Management Company (650) 577 4700
This message is intended only for the use of the Addressee and
may contain information that is PRIVILEGED and CONFIDENTIAL.
If you are not the intended recipient, dissemination of this
communication is prohibited. If you have received this communication
in error, please erase all copies of the message and its attachments
and notify us immediately.
