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: [wsbpel] Issue 115 - RE: [wsbpel] appendix C revision


+1

----- Original Message -----
From: "Yaron Y. Goland" <ygoland@bea.com>
To: "Francisco Curbera" <curbera@us.ibm.com>
Cc: "Furniss, Peter" <Peter.Furniss@choreology.com>;
<wsbpel@lists.oasis-open.org>
Sent: Thursday, September 16, 2004 8:29 PM
Subject: Re: [wsbpel] Issue 115 - RE: [wsbpel] appendix C revision


> 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
> >
>
> 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/leave_workgroup.
php.
>
>



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