[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation Handler
+1 Satish -----Original Message----- From: Yaron Goland [mailto:ygoland@bea.com] Sent: Wednesday, December 24, 2003 10:04 AM To: 'Ugo Corda'; 'Assaf Arkin'; Satish Thatte Cc: 'Sid Askary'; wsbpel@lists.oasis-open.org Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation Handler Why would someone who wants to interop with me need to know that my executable BPEL is using the patented Furby extension attributes? They only need to know what's in the WSDL and the abstract BPEL. The only entity that should care that my BPEL uses the patented Furby extension attributes is the BPEL engine and it only needs to know so it can be told if it can safely ignore the attributes or if it must fail the BPEL if it can't process them. > -----Original Message----- > From: Ugo Corda [mailto:UCorda@SeeBeyond.com] > Sent: Tuesday, December 23, 2003 10:15 AM > To: ygoland@bea.com; Assaf Arkin; Satish Thatte > Cc: Sid Askary; wsbpel@lists.oasis-open.org > Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation > Handler > > > > Ideally we would add the ability to make policy statements > inside of the > > BPEL's definition to provide information about any > non-backwards compatible > > extensions made to the BPEL. A BPEL engine, during > pre-processing, would > > read in the policy statements, see if there was any it > didn't support and if > > there were any then reject the BPEL. > > I would rather attach policy statements to the WSDL that > defines the BPEL interface. That way you can figure out > whether you want to use that particular BPEL process without > even having to read the process. And it would better aligned > with WSDL's direction on policies. > > Ugo > > > -----Original Message----- > > From: Yaron Goland [mailto:ygoland@bea.com] > > Sent: Tuesday, December 23, 2003 10:01 AM > > To: 'Assaf Arkin'; 'Satish Thatte' > > Cc: 'Sid Askary'; wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation > > Handler > > > > > > I think the current mechanism specified in the spec is about > > as complex as > > we can expect most users to handle. Any additional complexity > > will benefit a > > relatively small group of people at the cost of confusing > > everyone else. > > > > I can, however, imagine certain communities having a well > defined and > > compelling need for a different kind of default compensation > > handler. This > > kind of focused extensibility problem is something I expect > to be very > > common in BPEL. > > > > Ideally we would add the ability to make policy statements > > inside of the > > BPEL's definition to provide information about any > > non-backwards compatible > > extensions made to the BPEL. A BPEL engine, during > > pre-processing, would > > read in the policy statements, see if there was any it didn't > > support and if > > there were any then reject the BPEL. > > > > The scenario is that some community really needs a different > > kind of default > > compensation handler. So they decide to add an attribute to > > scopes defining > > what type of default compensation handler to use for that > > scope. The only > > problem is that if their extended BPEL is handed to an > > existing BPEL engine > > the existing BPEL engine will ignore the attribute and > > execute the BPEL > > using the standard compensation handler, which is not the > > expected behavior. > > > > To prevent this a policy statement is added as a child of > the process > > element stating "Do not run this BPEL unless you support the > > XYZ default > > compensation handler extension". An existing BPEL engine > would see the > > policy statement, realize it doesn't support that statement > > and so reject > > the BPEL. > > > > This kind of well defined extensibility mechanism allows BPEL > > to grow in a > > backwards/forwards compatible way. > > > > Yaron > > > > > -----Original Message----- > > > From: Assaf Arkin [mailto:arkin@intalio.com] > > > Sent: Friday, December 12, 2003 2:39 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 > > > > > > > > > Satish Thatte wrote: > > > > > > >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. > > > > > > > > > > > Anyway you look at it, to achieve the same flexibility as > a default > > > compensation algorithm would require extra footwork to track, > > > determine > > > and operate based on the order of completion. Considering the > > > complexity, most process definitions will gravitate towards using > > > default compensation. Any enhancement to default compensation is a > > > significant improvement of the language and so I would consider it > > > independently of whether or not we can achieve the same > thing using > > > custom compenstion handlers. > > > > > > At the moment, like you, I do not believe that we need to add more > > > capabilities to address custom compensations. I'm fine with the > > > compensate activity being able to either perform default > > > compensation or > > > naming direct children of the enclosing scope. > > > > > > Assaf > > > > > > >-----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/ > > > 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/l > > > eave_workgr > > > >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_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/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_workgr oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]