RE: [wsbpel] Issue 115 - RE: [wsbpel] appendix C revision

["Satish Thatte" <satisht@microsoft.com>]

This has nothing to do with matching BPEL.  This is about the purpose
and scope of the diagram.  It is not a complete descriptiopn of BPEL
semantics, obviously. 

Satish
 

-----Original Message-----
From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] 
Sent: Wednesday, September 22, 2004 1:58 PM
To: Satish Thatte; Green, Alastair J.; Francisco Curbera
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 115 - RE: [wsbpel] appendix C revision

So you don't want the diagram to match bpel ? Or rather, not to match
the text of with it ?

One could map to a particular distribution protocol. Then there would be
N texts, each reflecting N diagrams (which would pre-exist in the
distribution p'col specs) (and there would be different texts, just as
there are different diagrams for ws-ba 2002 and 2003, amongst others

Or one could map to an abstract protocol, with its own diagram. Then
there are N mapping statements.


Peter

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: 22 September 2004 21:50
> To: Furniss, Peter; Green, Alastair J.; Francisco Curbera
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 115 - RE: [wsbpel] appendix C revision
> 
> 
> I am objecting to showing a trqansition internal to the nested scope 
> in this diagram, which should be about the interaction between the 
> nested and enclosing scopres only.
> 
> 
>  
> 
> -----Original Message-----
> From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
> Sent: Wednesday, September 22, 2004 1:42 PM
> To: Satish Thatte; Green, Alastair J.; Francisco Curbera
> Cc: wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Issue 115 - RE: [wsbpel] appendix C revision
> 
> Satish,
> 
> I'm not clear whether you are saying our diagram is wrong or the ws-ba

> diagram was wrong (or inappropriate to ws-bpel, since it was right for
> ws-ba)
> 
> The old appendix C said
> 
> o	If the fault is handled and not rethrown, the scope exits
> gracefully from the work of its parent scope. This is modeled as an 
> Exited signal from the nested scope to its parent scope.
> 
> and there was no reference to sending Exited other than after a fault.

> To represent this we split the Active state into Running and Faulting,

> as a reflection of the statement in the bullet 2(old)/3(new).
> 
> Or are you complaining that we've renamed Exited to Failed - that's 
> the terminology of the spec body - well, I think that normally says 
> "unsuccessful" ?
> 
> Peter
> 
> > -----Original Message-----
> > From: Satish Thatte [mailto:satisht@microsoft.com]
> > Sent: 22 September 2004 21:24
> > To: Green, Alastair J.; Francisco Curbera; Furniss, Peter
> > Cc: wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] Issue 115 - RE: [wsbpel] appendix C revision
> > 
> > 
> > I disagree on the conflation of the original exited transition with 
> > the faulted transition.  From the viewpoint of the enclosing
> > (coordinator) scope, the behavior of the nested scope is
> distinctily
> > different based on whether it exits with fault or without, and this 
> > distinction needs to be maintained in order to maintain a fully 
> > faithful reflection of BPEL semantics.
> > 
> > This is separate from the issue of whether we should make the effort

> > to reintroduce a new Appendix C, just reacting to the
> technical issue.   
> > 
> > 
> >  
> > 
> > -----Original Message-----
> > From: Green, Alastair J. [mailto:Alastair.Green@choreology.com]
> > Sent: Monday, September 20, 2004 12:45 PM
> > To: Francisco Curbera; Furniss, Peter
> > Cc: wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] Issue 115 - RE: [wsbpel] appendix C revision
> > 
> > Dear Paco,
> > 
> > We strongly agree that Appendix C, in some form, has great value in 
> > tersely (and pictorially) summarizing the interactions surrounding 
> > compensatory scopes. We think one would lose a great deal more than 
> > extra text to review if it were excised altogether. Issues
> 6, 135 and
> > 142 are all usefully illuminated by this. We have also
> found Appendix
> > C useful in discussing, designing, interfacing and implementing 
> > distributed coordination of process-driven services, and would 
> > recommend its retention. Vendors who desire to create federated or 
> > fully distributed BPEL implementations will benefit, we
> believe, from
> > this helpful and concise view on the content of the normative spec.
> > 
> > The changes we made (beyond removing the term "WS-BA") boil down to
> > 
> > a) clarifying the meaning of "local" vs "distributed" in
> this context
> > b) changing the names of messages/states to correspond to their 
> > ordinary names in BPEL
> > c) aligning the diagram with the normative text of the
> specification
> > as it has developed during the TC's work, and with the
> original text
> > of the Appendix (with which it was previously at some
> variance). The
> > original diagram derived from WS-BA (2002) was inadequate, and also 
> > does not reflect the current WS-BA draft.
> > 
> > On your two specific points:
> > 
> > 1. Either we go the whole hog, and (as you suggest) specify all the 
> > messages required for a distributed coordination protocol,
> which would
> 
> > permit implementation of a BPEL process engine as a federation of 
> > independently existing processing units, which neither
> share state nor
> 
> > can be assumed to be failure-coupled. Or, we take the route of the 
> > original Appendix C, and omit messages which are needed to 
> > resynchronize in the event of failures. We chose to stick
> as closely
> > as possible to the original Appendix C. We have no problem
> with going
> > the whole hog, if that makes things clearer or more complete.
> > 
> > 2. On exit handling: the key point is that a nested scope can still 
> > unilaterally exit, either rethrowing its fault as it does so, or 
> > containing the fault, and reporting that the inner scope
> has completed
> 
> > erroneously. These two paths to the Ended state now travel through a

> > new state, Faulting, which was introduced in order to elucidate the 
> > textual point (bullet 2 of the original appendix/ bullet 3 of our
> > revision) that either route to Ended must begin with the
> raising of an
> 
> > internal fault, breaking the inner scope out of its Active state. In

> > other words, we separated Active into Running and Faulting, to make 
> > the genesis of these transitions clear. There is no loss of content 
> > or functionality, only greater
> precision
> > and alignment with the specification as a whole, and the
> appendix in
> > particular.
> > 
> > Yours,
> > 
> > Alastair and Peter
> > 
> > 
> > -----Original Message-----
> > From: Francisco Curbera [mailto:curbera@us.ibm.com]
> > Sent: 14 September 2004 17:59
> > To: Furniss, Peter
> > Cc: wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] Issue 115 - RE: [wsbpel] appendix C revision
> > 
> > Hi Peter,
> > 
> > Here is IBM's feedback on your proposed resolution.
> > 
> > We agree that Appendix C  provides important value in
> helping clarify
> > the interaction between BPEL and distributed protocols.
> That was the
> > original motivation for the appendix; in its current form (modulo 
> > references to the WS-BA spec) it does this job
> appropriately and that
> > is why we agreed that it should not be removed. Our major
> concern with
> 
> > the proposed changes is that the new text only deals with localized 
> > behavior and does not help anymore in interoperability
> scenarios. In
> > that case we think it would be better to leave it out of
> the document.
> > 
> > More specifically, these are the two issues that concern us:
> > 
> > 1. Missing fault and compensation-fault acknowledgements: The state 
> > diagrams are meant to accommodate any underlying infrastructure and 
> > therefore we believe that every transition requires some form of 
> > protocol-level acknowledgement to assure the partner has
> processed the
> 
> > signal.
> > 
> > 2. Exit Handling: We need to allow a nested scope to unilaterally 
> > leave the workscope.
> > 
> > Regards,
> > 
> > Paco
> > 
> > 
> > 
> >  
> > 
> >                       "Furniss, Peter"
> > 
> >                       <Peter.Furniss@chor        To:       "Satish
> > Thatte" <satisht@microsoft.com>, 
> > <wsbpel@lists.oasis-open.org>         
> >                       eology.com>                cc:
> > 
> >                                                  Subject:
> > RE: [wsbpel]
> > Issue 115 - RE: [wsbpel] appendix C revision                      
> >                       08/25/2004 02:04 PM
> > 
> >  
> > 
> > 
> > 
> > 
> > 
> > Sounds reasonable  - "Success" should be changed to
> "Succeeded" by the
> 
> > same count.
> > 
> > Peter
> > -----Original Message-----
> > From: Satish Thatte [mailto:satisht@microsoft.com]
> > Sent: 25 August 2004 18:15
> > To: Furniss, Peter; wsbpel@lists.oasis-open.org
> > Subject: RE: [wsbpel] Issue 115 - RE: [wsbpel] appendix C revision
> > 
> > Peter,
> > 
> > It would be helpful to follow the original convention of ending all 
> > signals from a nested scope with 'ed - by this convention "Fault"
> > would be "faulted".  Thus all these signals look informative as 
> > opposed to imperative.
> > 
> > Satish
> > 
> > 
> > From: Furniss, Peter [mailto:Peter.Furniss@choreology.com]
> > Sent: Wednesday, August 18, 2004 7:19 AM
> > To: wsbpel@lists.oasis-open.org
> > Subject: [wsbpel] Issue 115 - RE: [wsbpel] appendix C revision
> > 
> > Forgot to set the title so my own scripts will link the thread. 
> > Please reply to this thread, not my original one.
> > 
> > Peter
> >  -----Original Message-----
> >  From: Furniss, Peter
> >  Sent: 18 August 2004 14:57
> >  To: wsbpel@lists.oasis-open.org
> >  Subject: [wsbpel] appendix C revision  At last, the
> proposed text for
> 
> > appendix C from Alastair and myself.  Thanks also to Tony
> Fletcher for
> 
> > comments.
> > 
> >  The bit that gave us pause was the introduction - the difference 
> > between a  notionally monolithic BPEL implementation and a general 
> > distributed case  becomes questionable if in fact the BPEL 
> > implementation is federated
> > -  especially when, e.g., different flows are running in separate 
> > processes  that could fail independently.
> > 
> >  Peter
> > 
> >  ------------------------------------------
> >  Peter Furniss
> >  Chief Scientist, Choreology Ltd
> >  web: http://www.choreology.com
> >  email: peter.furniss@choreology.com
> >  phone: +44 870 739 0066
> >  mobile: +44 7951 536168
> > 
> > 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_workgr
> > oup.php.
> > 
> > 
>