[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Resolution to issue 10 - Implicit compensation Handler
I am thinking of cases where a BPEL extension translates into modified/enhanced behavior of the deployed process. As a potential user of that process, I would like to know in advance whether that extension is supported before I actually interact with the process. Ugo > -----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/le ave_workgroup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]