[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue - 10 - (resolution to) Implicit compensation Handler
I found I had left a message incomplete in my Drafts folder over Christmas. Changing the subject line to make the issue list script pick it up (I've now added in the other ones - though the discussion diverges into extensibility from about Yaron's message of Dec 23) At the face-to-face, I made some comments in the issue 10 discussion, and the email discussion seemed to expect me to clarify, thouh I never had any fully formulated view. There was mention of the principle of least surprise (from Yaron I think). It seemed to me that, given the scenario with crossing links that Satish put forward at the ftf, *any* default solution would be fairly surprising, and that the user would be unlikely to guess what would happen, or if they guessed be confident of it. I think the inability to mimic the default behaviour with custom is fairly important - if in testing a script it doesn't always seem to to what I think it should, I'd like to be able put in what I think the default behaviour is, but explicitly, and see if it was just I'd not realised the implications. Having a whole set of behaviour that, though sometimes useful, I can't reproduce easily or at all would be worrying. So I'm inclined to make the default behaviour merely a simplish case of customisable. But with a subscope in a loop, reverse completion order really does seem better. But I'd make it depth-first, so each compensation handler is only concerned with its immediate childrens' compensation handlers, rather than with grand-childrens'. I've kind of lost track of where that actually takes us as a proposal. Peter > -----Original Message----- > From: Satish Thatte [mailto:satisht@microsoft.com] > Sent: 12 December 2003 21:59 > To: Assaf Arkin > Cc: ygoland@bea.com; Sid Askary; wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Resolution to issue 10 - Implicit > compensation Handler > > > 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:arkin@intalio.com] > Sent: Friday, December 12, 2003 12:38 PM > To: Satish Thatte > Cc: ygoland@bea.com; Sid Askary; wsbpel@lists.oasis-open.org > 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:ygoland@bea.com] > >Sent: Thursday, December 11, 2003 3:42 PM > >To: 'Sid Askary'; wsbpel@lists.oasis-open.org > >Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation > >Handler > > > >+1 > > > > > > > >>-----Original Message----- > >>From: Sid Askary [mailto:saskary@nuperus.com] > >>Sent: Tuesday, December 09, 2003 1:46 PM > >>To: wsbpel@lists.oasis-open.org > >>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/l > eave_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/le ave_workgr oup.php. > > -- "Those who can, do; those who can't, make screenshots" ---------------------------------------------------------------------- Assaf Arkin arkin@intalio.com 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. 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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]