OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


Subject: Re: AW: [wsbpel] RE: Issue - 207 - Revised description


Sure, I fully understand that half and would agree if it was the complete
story.

Unfortunately, this approach introduces more complexity as it removes.
Maybe it is just me, but I had to read the idea of "activating one type of
compensation handler at scope start time and the other type of compensation
handler at scope termination time and introducing two different compensate
activities" multiple times.

Just saying "<compensate/> runs the compensation handlers of the child
scopes" does it all.

The fact that this is all what a default compensation handler does is easy
to explain.

Kind Regards
DK



                                                                       
             "Yaron Y. Goland"                                         
             <ygoland@bea.com>                                         
                                                                        To
             22.06.2005 19:43          Dieter Koenig1/Germany/IBM@IBMDE
                                                                        cc
                                       Frank Leymann                   
             Please respond to         <Frank.Leymann@informatik.uni-stutt
                  ygoland              gart.de>,                       
                                       wsbpel@lists.oasis-open.org     
                                                                   Subject
                                       Re: AW: [wsbpel] RE: Issue - 207 -
                                       Revised description             
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       
                                                                       




The question becomes - is there economy in introducing two ideas where
one would do?

You claim it is simple to say that compensate on faults leads to the
children's compensation handlers being called but that is exactly the
semantics of the default compensation handler.

So what we end up doing is defining the default compensation handler
twice, once for faults and once for completed scopes and in so doing
introduce possible ambiguities as people are forced to wonder why
exactly the same idea seems to show up in two different places with two
different descriptions.

It seems to me to be simpler to just define the concept of a default
compensation handler once and then re-use it.

             Yaron

Dieter Koenig1 wrote:
> To me, "<compensate/> runs the compensation handlers of the child scopes"
> is much less confusing than saying different compensation handlers
(default
> vs custom) are installed at different points in time. The simple rule
that
> a compensation handler can only run on successfully completed scopes
would
> no longer apply, which adds complexity instead of removing it.
> Kind Regards
> DK
>
>
>
>

>              "Yaron Y. Goland"

>              <ygoland@bea.com>

>
To
>              21.06.2005 18:28          Frank Leymann

>
<Frank.Leymann@informatik.uni-stutt
>                                        gart.de>

>              Please respond to
cc
>                   ygoland              wsbpel@lists.oasis-open.org

>
Subject
>                                        Re: AW: [wsbpel] RE: Issue - 207 -

>                                        Revised description

>

>

>

>

>

>

>
>
>
>
> Because what you describe is exactly what a default compensation handler
> does - it runs the compensation handlers of the child scopes. So it
> looks to me that in both cases the default compensation handler is being
> executed.
>              Yaron
>
> Frank Leymann wrote:
>  > Compensation is enabled for completed scopes only. A faulted scope
cannot
> be
>  > compensated itself, because it is not completed, i.e. the work done
> inside
>  > of it is only partially performed. But its associated fault handler
can
> try
>  > to fix the situation and if it cannot fix, try to semantically undo
the
>  > partially performed work, e.g. by running the compensation handlers of
> its
>  > nested scopes that have been completed. Why do you think this is
> confusing?
>  >
>  > Gruss / Regards
>  > Frank Leymann
>  >
>  >
>  > -----Ursprüngliche Nachricht-----
>  > Von: Yaron Y. Goland [mailto:ygoland@bea.com]
>  > Gesendet: Freitag, 17. Juni 2005 18:52
>  > An: dieterkoenig@de.ibm.com
>  > Cc: wsbpel@lists.oasis-open.org
>  > Betreff: Re: [wsbpel] RE: Issue - 207 - Revised description
>  >
>  > The issue is how does one view a default compensation handler.
>  >
>  > The spec requires that when calling <compensate/> from inside of a
fault
>  > handler the resulting behavior be exactly, in every possible way,
>  > identical to what would happen if the scope had successfully
completed,
>  > had only a default compensation handler defined on it and that scope
was
>  > then compensated.
>  >
>  > What I'm arguing is that the spec's way of describing the issue is
>  > hopelessly confusing. I believe it would be much more straight forward
>  > to just state that when a scope is created a default compensation
>  > handler is placed on that scope.
>  >
>  > This change in model has, near as I can tell, no change on our actual
>  > behavior but it makes everything else we say much clearer.
>  >
>  >                 Yaron
>  >
>  > Dieter Koenig1 wrote:
>  >  > Sorry, but I am completely lost. I am not clear where the notion of
>  >  >   (a) creating a default compensation handler when a scope is
created
>  >  >   (b) invoking a scope's own compensation handler with
<compensate/>
>  >  > have been introduced.
>  >  >
>  >  > Can you point me to a corresponding issue resolution? Please ignore
> this
>  >  > mail if I missed such a change.
>  >  >
>  >  >
>  >  > Otherwise, corresponding terminology in 207 and the complete issue
217
> is
>  >  > just not applicable and should be removed.
>  >  >
>  >  >
>  >  > The spec currently defines:
>  >  >
>  >  > 13.3.3. Invoking a Compensation Handler
>  >  > "(...) This activity can be used only in the following parts of a
> business
>  >  > process:
>  >  >   - In a fault handler of the scope that ***immediately encloses***
> the
>  >  > scope for which compensation is to be performed.
>  >  >   - In the compensation handler of the scope that ***immediately
>  >  > encloses*** the scope for which compensation is to be performed.
>  >  > (...)
>  >  > (...) The <compensate/> form, in which the scope name is omitted in
a
>  >  > compensate activity, causes the default compensation ***behavior***
> for
>  > the
>  >  > current scope to be invoked explicitly. (...) Note that the
> <compensate/>
>  >  > activity in a fault or compensation handler attached to scope S
causes
> the
>  >  > default-order invocation of compensation handlers for completed
scopes
>  >  > directly ***nested within*** S."
>  >  >
>  >  > ==> compensate ***never*** calls the compensation handler of its
own
>  > scope.
>  >  >
>  >  > 13.4.1. Implicit Fault and Compensation Handlers
>  >  > "(...) Compensation handler: Run all available compensation
handlers
> for
>  >  > all directly and indirectly enclosed scopes in any order consistent
> with
>  >  > the rules for default compensation order defined below. Note that a
>  >  > compensation handler is available for a scope exactly when that
scope
> has
>  >  > completed successfully"
>  >  >
>  >  > ==> this applies to all compensation handlers -- explicit and
implicit
> --
>  >  > there is no language about compensation handlers being created at
> scope
>  >  > creation time.
>  >  >
>  >  >
>  >  > I assume we agree that
>  >  >    <compensationHandler>
>  >  >       <compensate/>
>  >  >    </compensationHandler>
>  >  > means that all installed compensation handlers of directly nested
> scopes
>  >  > are executed. Exactly the same behavior applies when <compensate/>
> appears
>  >  > in <catch>, <catchAll>, or <terminationHandler>.
>  >  >
>  >  >
>  >  > Kind Regards
>  >  > DK
>  >  >
>  >  >
>  >  >
>  >  >
>
>  >  >              "Yaron Y. Goland"
>
>  >  >              <ygoland@bea.com>
>
>  >  >
> To
>  >  >              07.06.2005 00:23          Dieter
> Koenig1/Germany/IBM@IBMDE
>  >  >
> cc
>  >  >                                        "Furniss, Peter"
>
>  >  >              Please respond to
<Peter.Furniss@choreology.com>,
>
>  >  >                   ygoland              wsbpel@lists.oasis-open.org
>
>  >  >
> Subject
>  >  >                                        Re: [wsbpel] RE: Issue - 207
-
>
>  >  >                                        Revised description
>
>  >  >
>
>  >  >
>
>  >  >
>
>  >  >
>
>  >  >
>
>  >  >
>
>  >  >
>  >  >
>  >  >
>  >  >
>  >  > The way I look at it when foo was created so was its default
>  >  > compensation handler. What was not created was foo's custom
> compensation
>  >  > handler (if any). When a fault was thrown this guaranteed that
foo's
>  >  > custom compensation handler (if any) would never be installed. But
the
>  >  > throwing of the fault in foo did nothing to foo's default
compensation
>  >  > handler.
>  >  >
>  >  > Once inside of the catchAll the call to <compensate> causes foo's
>  >  > default compensation handler to be invoked. It is then foo's
default
>  >  > compensation handler which is responsible for calling all of foo's
> child
>  >  > scopes (if any) and activating their compensation handlers (if
any).
>  >  >
>  >  > In my mind there is a fundamental difference between the default
and
>  >  > custom compensation handlers. The former always exists from the
> instant
>  >  > the scope is created while the later is only installed if the scope
>  >  > exits successfully.
>  >  >
>  >  >                          Yaron
>  >  >
>  >  >
>  >  > Dieter Koenig1 wrote:
>  >  >  > I am confused by this one. In your example:
>  >  >  >
>  >  >  >    scope name="foo"
>  >  >  >        faultHandlers
>  >  >  >           catchAll
>  >  >  >              compensate
>  >  >  >        ...
>  >  >  >
>  >  >  > the compensate activity invokes compensation handlers of scopes
> nested
>  >  >  > inside of "foo", not the compensation handler of "foo" itself.
>  >  >  >
>  >  >  > In particular, as a fault handler of "foo" is running, the scope
> "foo"
>  >  > will
>  >  >  > terminate abnormally and will not even have its compensation
> handler
>  >  >  > installed.
>  >  >  >
>  >  >  > Kind Regards
>  >  >  > DK
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >
>  >  >  >              "Yaron Y. Goland"
>  >  >
>  >  >  >              <ygoland@bea.com>
>  >  >
>  >  >  >
>  >  > To
>  >  >  >              23.05.2005 22:47          "Furniss, Peter"
>  >  >
>  >  >  >
> <Peter.Furniss@choreology.com>
>  >  >
>  >  >  >
>  >  > cc
>  >  >  >              Please respond to
wsbpel@lists.oasis-open.org
>  >  >
>  >  >  >                   ygoland
>  >  > Subject
>  >  >  >                                        Re: [wsbpel] RE: Issue -
207
> -
>  >  >
>  >  >  >                                        Revised description
>  >  >
>  >  >  >
>  >  >
>  >  >  >
>  >  >
>  >  >  >
>  >  >
>  >  >  >
>  >  >
>  >  >  >
>  >  >
>  >  >  >
>  >  >
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >  > My understanding of BPEL's existing semantics require that fault
>  >  >  > handlers be able to call the default compensation handler of the
> same
>  >  >  > scope the fault handler is defined on.
>  >  >  >
>  >  >  > scope name="foo"
>  >  >  >     faultHandlers
>  >  >  >        catchAll
>  >  >  >           compensate
>  >  >  >     ...
>  >  >  >
>  >  >  > The call to compensate will call "foo"'s default compensation
> handler.
>  > I
>  >  >  > agree, btw, that the spec's existing language make this
situation
> at
>  >  >  > best 'ambiguous'. That's part of the motivation of 207, to make
it
>  >  >  > absolutely clear.
>  >  >  >
>  >  >  > But in general your conclusion is the same as mine - whatever
the
>  >  >  > resolution to these issues there are clearly ambiguities here.
By
>  >  >  > opening the issue we only agree as to the existence of the
> ambiguities,
>  >  >  > not necessarily their resolution.
>  >  >  >
>  >  >  >                          Yaron
>  >  >  >
>  >  >  >
>  >  >  > Furniss, Peter wrote:
>  >  >  >  > ok, on re-reading very carefully, you aren't quite suggesting
> what I
>  >  >  >  > thought you were - that a handler in scope A could fire the
>  >  > compensation
>  >  >  >  > handler for scope A. Except you are, in the assertion that
>  > <compensate
>  >  >  >  > /> in a fault handler runs the default compensation handler.
And
>  > then
>  >  >  >  > find yourself in contradiction to the rule that compensation
>  > handlers
>  >  >  >  > are only installed on successful completion of their scope.
>  >  >  >  >
>  >  >  >  > This would seem to be more easily coped with by saying that
>  >  >  >  > <compensate/> performs the compensations, but does not
trigger
> the
>  >  >  >  > default handler - i.e. it is another way of doing the same
> thing,
>  > but
>  >  >  >  > isn't the same packaging.
>  >  >  >  >
>  >  >  >  > But most of the issue is concerned with sorting out what
happens
> if
>  > a
>  >  >  >  > handler contains a scope, with compensation handler, which
I'm
> not
>  >  > sure
>  >  >  >  > is necessarily the related to <compensate /> in handlers. It
> might
>  > be
>  >  >  >  > simpler to deem the handler to be scope in its own right. Or
ban
>  > inner
>  >  >  >  > scopes in handlers ? or handlers in handlers.
>  >  >  >  >
>  >  >  >  > But these are resolutions of the issue, which hasn't been
> accepted
>  >  > yet.
>  >  >  >  > I do agree (now) that both cases could be clarified, so I
think
> the
>  >  >  >  > issue should be accepted.
>  >  >  >  >
>  >  >  >  > Peter
>  >  >  >  >
>  >  >  >  >
>  >  >  >  >  > -----Original Message-----
>  >  >  >  >  > From: Yaron Y. Goland [mailto:ygoland@bea.com]
>  >  >  >  >  > Sent: 19 May 2005 18:55
>  >  >  >  >  > To: Furniss, Peter
>  >  >  >  >  > Cc: wsbpel@lists.oasis-open.org
>  >  >  >  >  > Subject: Re: [wsbpel] RE: Issue - 207 - Revised
description
>  >  >  >  >  >
>  >  >  >  >  >
>  >  >  >  >  > I'm not sure what you mean. Today it is legal and
appropriate
>  >  >  >  >  > to use the
>  >  >  >  >  > compensate activity from inside of a fault handler. I've
>  >  >  >  >  > reviewed this
>  >  >  >  >  > mail twice and I'm still not clear as to your concern.
>  >  >  >  >  >
>  >  >  >  >  > Could you please give a short example of something that
you
> think
>  >  > is
>  >  >  >  >  > illegal in the spec today that this issue would now make
>  >  >  >  >  > legal that is
>  >  >  >  >  > causing you concern?
>  >  >  >  >  >
>  >  >  >  >  >       Thanks,
>  >  >  >  >  >
>  >  >  >  >  >               Yaron
>  >  >  >  >  >
>  >  >  >  >  >
>  >  >  >  >  > Furniss, Peter wrote:
>  >  >  >  >  > > Looking at the substance of this proposed issue, it
seems
> to be
>  >  >  >  >  > > proposing a
>  >  >  >  >  > > rather different model from the existing one.  Surely
the
>  >  >  >  >  > existing model is
>  >  >  >  >  > > that, until a scope exits, anything that it has done but
>  >  >  >  >  > that will need
>  >  >  >  >  > > unwinding in the event of fault has to be coped with by
the
>  >  >  >  >  > fault handler; after
>  >  >  >  >  > > the scope has exited, it is the responsibility of that
>  >  >  >  >  > scope's compensation handler.
>  >  >  >  >  > >
>  >  >  >  >  > > There will be cases where some more sophisticated
pattern
>  >  >  >  >  > might seem
>  >  >  >  >  > > more
>  >  >  >  >  > > convenient - if scope B does operation b1, then b2, then
>  >  >  >  >  > b3, all directly in B,
>  >  >  >  >  > > then the fault handler may need to know if b2 has been
done
>  >  >  >  >  > to work out if it
>  >  >  >  >  > > must undo it. The solution of course is to put the
>  >  >  >  >  > operations each in its own
>  >  >  >  >  > > scope, in which case B can leave it to the default fault
>  >  >  >  >  > handler to undo things
>  >  >  >  >  > > backwards, but only of the things that have finished.
>  >  >  >  >  > >
>  >  >  >  >  > > The issue does raise some questions of what happens if a
>  >  >  >  >  > compensation
>  >  >  >  >  > > handler
>  >  >  >  >  > > itself contains a scope.
>  >  >  >  >  > >
>  >  >  >  >  > >
>  >  >  >  >  > > Peter
>  >  >  >  >  > >
>  >  >  >  >  > > -----------------------------------
>  >  >  >  >  > > Chief Scientist
>  >  >  >  >  > > Choreology Ltd
>  >  >  >  >  > > 68 Lombard Street, London EC3V 9LJ, UK
>  >  >  >  >  > > web: www.choreology.com
>  >  >  >  >  > > mobile:  +44 7951 536168
>  >  >  >  >  > >
>  >  >  >  >  >
>  >  >  >  >  >
>  >  >  >  >
>  >  >  >
>  >  >  >
>  >  >  >
> ---------------------------------------------------------------------
>  >  >  > To unsubscribe from this mail list, you must leave the OASIS TC
> that
>  >  >  > generates this mail.  You may a link to this group and all your
TCs
> in
>  >  >  > OASIS
>  >  >  > at:
>  >  >  >
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>  >  >  >
>  >  >  >
>  >  >  >
>  >  >
>  >  >
>  >  >
>  >
>  >
>  > ---------------------------------------------------------------------
>  > To unsubscribe from this mail list, you must leave the OASIS TC that
>  > generates this mail.  You may a link to this group and all your TCs in
> OASIS
>  > at:
>  > https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>  >
>  >
>  >
>
>
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that
> generates this mail.  You may a link to this group and all your TCs in
> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>
>
>





[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]