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:]
> Sent: Wednesday, December 24, 2003 10:04 AM
> To: Ugo Corda; 'Assaf Arkin'; 'Satish Thatte'
> Cc: 'Sid Askary';
> 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:]
> > Sent: Tuesday, December 23, 2003 10:15 AM
> > To: ; Assaf Arkin; Satish Thatte
> > Cc: Sid Askary;
> > 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:]
> > > Sent: Tuesday, December 23, 2003 10:01 AM
> > > To: 'Assaf Arkin'; 'Satish Thatte'
> > > Cc: 'Sid Askary';
> > > 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:]
> > > > Sent: Friday, December 12, 2003 2:39 PM
> > > > To: Satish Thatte
> > > > Cc: ; Sid Askary;
> > > > 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:]
> > > > >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/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.
