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

[Dieter Koenig1 <dieterkoenig@de.ibm.com>]

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