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

["Yaron Y. Goland" <ygoland@bea.com>]

I don't suppose that the assembled could be convinced that since 
appendix C is non-normative and since the group already has a ton of 
text to do full reviews on perhaps we could publish appendix C 
separately? This would be one less thing for the entire group to have to 
review in order to get out the main spec. Since the text is anyway 
non-normative what real damage is done if it is published stand alone?

	Just a thought,

		Yaron

Francisco Curbera wrote:
> 
> 
> 
> 
> 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
>