[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Resolution to issue 10 - Implicit compensation Handler
Ugo, You make a very good point; BPEL extensions are only the business of BPEL engines. This does bring up an interesting topic: should the BPEL process designer, who uses extension elements, be allowed to designate them as "required" or "optional", in much the same fashion as WSDL 2 extension elements? Just a thought. -Ron Ugo Corda wrote: 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 HandlerIdeally we would add the ability to make policy statementsinside of theBPEL's definition to provide information about anynon-backwards compatibleextensions made to the BPEL. A BPEL engine, duringpre-processing, wouldread in the policy statements, see if there was any itdidn't support and ifthere 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 - ImplicitcompensationHandler 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 welldefined andcompelling need for a different kind of default compensation handler. This kind of focused extensibility problem is something I expectto be verycommon 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 ofthe processelement stating "Do not run this BPEL unless you support the XYZ default compensation handler extension". An existing BPEL enginewould see thepolicy 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 - ImplicitcompensationHandler Satish Thatte wrote:Yes, this is one way in which one could extend the customcapability tomatch the capability required by what I proposed. I amreluctant to addthis complication though.Anyway you look at it, to achieve the same flexibility asa defaultcompensation algorithm would require extra footwork to track, determine and operate based on the order of completion. Considering the complexity, most process definitions will gravitatetowards usingdefault compensation. Any enhancement to defaultcompensation is asignificant improvement of the language and so I wouldconsider itindependently of whether or not we can achieve the samething usingcustom compenstion handlers. At the moment, like you, I do not believe that we needto add morecapabilities 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 - ImplicitcompensationHandler The current specification requires each scope, upon it'ssuccessfulcompletion, to install a compensation handler within theenclosingscope. That could be a compensation handler that wasexplicitly defined,or a default compensation handler (implicit). But acompensation handleris always installed in the enclosing scope by thecompleting scope.The new proposal changes that behavior. It requireseach scope tosupport an invocation of its compensation handler by theenclosingscope, and that could be an explicit or a defaultcompensation handler.However, when a scope completes, it installs itscompensation handler inthe enclosing scope only if one is explicitly defined. Ifthe scope doesnot define a compensation handler, it installs thecompensation handlersof its child scopes within its enclosing scope. To achieve the same behavior with custom handlers, thecustom handlersmust be able to invoke any compensation handlerinstalled in theirscope, and not just those coming from direct children.It thereforeneeds an understanding of when a compensation handler isinstalled inthe scope, vs assuming that each child scope installs acompensationhandler upon successful completion. Assaf Satish Thatte wrote:Sid and Yaron, My main concern with my own proposal is the fact thatthe defaultbehavior cannot be achieved with custom handlers, which isa fault inmyproposal. Someone (cannot recall who) brought that upduring the faceto face and it gave me pause. Need to think about thatsome more. Inthe 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 - ImplicitcompensationHandler +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 tohttp://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php.To unsubscribe from this mailing list (and be removed fromthe rosterofthe OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. To unsubscribe from this mailing list (and be removed fromthe rosterof the OASIS TC), go to http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_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_workgroup.php. To unsubscribe from this mailing list (and be removed from the roster of the OASIS TC), go tohttp://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_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_workgroup.php. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]