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

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

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.
> 
>