[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: Fw: [wsbpel-spec-edit] RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)
Diane, I am on road this week so and may have a hard time doing so for next week. When would it need to be circulated to be able to be included? We may need to shoot for the following call - would that be OK? In any event, I will try to circulate a draft by the weekend. Sorry. Ben >From: Diane Jordan <drj@us.ibm.com> >To: "Ben Bloch" <ben_b54@hotmail.com> >CC: "Furniss, Peter" <Peter.Furniss@choreology.com>, Frank Leymann ><LEY1@de.ibm.com>, "Yaron Y. Goland" <ygoland@bea.com>, bpel spec ><wsbpel-spec-edit@lists.oasis-open.org> >Subject: Fw: [wsbpel-spec-edit] RE: [wsbpel] Abstract BPEL (was RE: >[wsbpel] FAQ) >Date: Tue, 4 Nov 2003 15:35:38 -0500 > >Thanks, Ben. >Do you think its possible to have a proposal for vote circulated for next >week's TC call? >Regards, Diane >IBM Dynamic e-business Technologies >drj@us.ibm.com >(919)254-7221 or 8-444-7221, Mobile: 919-624-5123 > >----- Forwarded by Diane Jordan/Raleigh/IBM on 11/04/2003 03:34 PM ----- > > >"Ben Bloch" <ben_b54@hotmail.com> >11/04/2003 10:01 AM > > To: "Furniss, Peter" <Peter.Furniss@choreology.com>, Diane >Jordan/Raleigh/IBM@IBMUS, "Yaron Y. Goland" <ygoland@bea.com> > cc: "bpel spec" <wsbpel-spec-edit@lists.oasis-open.org>, >"Frank Leymann" <LEY1@de.ibm.com> > Subject: Re: [wsbpel-spec-edit] RE: [wsbpel] Abstract BPEL >(was RE: [wsbpel] FAQ) > > >Peter, I am happy to champion this if we need one. > >Ben >----- Original Message ----- >From: "Furniss, Peter" <Peter.Furniss@choreology.com> >To: "Diane Jordan" <drj@us.ibm.com>; "Yaron Y. Goland" <ygoland@bea.com> >Cc: "bpel spec" <wsbpel-spec-edit@lists.oasis-open.org>; "Frank Leymann" ><LEY1@de.ibm.com>; <ben_bloch@hotmail.com> >Sent: Tuesday, November 04, 2003 8:28 AM >Subject: [wsbpel-spec-edit] RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] >FAQ) > > >Diane, Yaron > >Ben Bloch put in an issue description which arrived while I was away and >didn't get caught by the rule that propagated to Tony Fletcher, for some >reason. It is now issue 82 - I've linked in the prior discussion. > >I've not put up a champion for it yet - I'm not sure if Yaron will want >it (it's one of few threads he hasn't been involved in :-). I started >it, referencing some comments Yaron made on the FAQ, hoping it would >stir in Tony Andrews (which it did). > >Ben or Frank might be a suitable champions. > >Peter > > > -----Original Message----- > > From: Diane Jordan [mailto:drj@us.ibm.com] > > Sent: 27 October 2003 14:40 > > To: Yaron Y. Goland > > Cc: bpel spec; Frank Leymann; Fletcher, Tony; Furniss, Peter > > Subject: Fw: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ) > > > > > > Hi Yaron, > > Sounds like the resolution of this thread (which I think you > > initiated) > > may be close and that some enhancement to the spec is being > > suggested. It > > never made it to an issue and I'm unsure whether its > > necessary to open one > > - I'm inclined to say yes just from a housekeeping perspective, but > > understand we also want to minimize bureaucracy. At least, I > > want to make > > sure that someone takes the lead to figure out the right > > approach (ie, > > issue or not) and makes sure that somehow spec editing team gets the > > appropriate input for this. Should that be you? The > > others who were > > most involved in the discussion and the spec editing team > > may also want > > to comment. I've not copied the full TC as this question is more > > procedural - if there is further discussion on the content, please > > continue it on the main list. > > > > Regards, Diane > > IBM Dynamic e-business Technologies > > drj@us.ibm.com > > (919)254-7221 or 8-444-7221, Mobile: 919-624-5123 > > > > ----- Forwarded by Diane Jordan/Raleigh/IBM on 10/27/2003 > > 09:25 AM ----- > > > > > > "Frank Leymann" <LEY1@de.ibm.com> > > 10/25/2003 02:49 AM > > > > To: wsbpel@lists.oasis-open.org > > cc: > > Subject: RE: [wsbpel] Abstract BPEL (was RE: > > [wsbpel] FAQ) > > > > > > > > This helped - we are in agreement. Better describing both, > > separate and joint usage of executable and abstract processes > > will help a lot. The > > same > > is true for motivating the restrictions we put on abstract processes. > > > > Regards, > > Frank > > > > ------------------- > > Prof. Dr. Frank Leymann, Distinguished Engineer > > IBM Software Group > > Member, IBM Academy of Technology > > > > Phone 1: +49-7031-16 39 98 > > Phone 2: +49-7056-96 50 67 > > Mobile: +49-172-731 5858 > > -------------------- > > > > > > > > > > > > To: Frank Leymann/Germany/IBM@IBMDE, <wsbpel@lists.oasis-open.org> > > cc: > > Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ) > > > > > > I think we may be in agreement, Frank. I wasn't suggesting > > that there be any kind of view or projection between abstract > > and executable processes > > - only that their separate and joint usage scenarios be more > > clearly described. The notion of an executable process as an > > implementation of an abstract process (or processes!) doesn't > > seem to be coming through clearly to our readers. > > > > Wrt formal methods, I suggest only that we motivate better > > the restrictions on abstract processes by more clearly > > stating the kinds of formal approaches that benefit from > > them. As it reads today, the restrictions look rather arbitrary. > > > > Tony > > > > -----Original Message----- > > From: Frank Leymann [mailto:LEY1@de.ibm.com] > > Sent: Thursday, October 23, 2003 11:38 PM > > To: wsbpel@lists.oasis-open.org > > Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ) > > > > > > I am in full support of... > > > > 1. Abstract processes are purely descriptive (similar to WSDL) > > > > 2. The mechanism used to combine (abstract) processes into > > an aggregated artifact is independent from BPEL > > > > 3. An abstract process says nothing about the implementation > > of the underlying service(s) > > > > > > I disagree that we should.... > > > > A. Describe the relation between abstract and executable > > processes - - > > - in case you had in mind to specify some sort of > > view-mechanism or projection-mechanism or extension-mechanism > > to contruct abstract processes from executable processes, or > > extend abstract processes into executable ones. This is > > non-trivial and more research like... > > > > > > I do not understand what you have in mind about "formal methods"...? > > > > > > Regards, > > Frank > > > > ------------------- > > Prof. Dr. Frank Leymann, Distinguished Engineer IBM Software > > Group Member, IBM Academy of Technology > > > > Phone 1: +49-7031-16 39 98 > > Phone 2: +49-7056-96 50 67 > > Mobile: +49-172-731 5858 > > -------------------- > > > > > > > > > > > > To: "Furniss, Peter" <Peter.Furniss@choreology.com>, > > <ygoland@bea.com>, > > "John Evdemon" <jevdemon@microsoft.com>, > > <wsbpel@lists.oasis-open.org> > > cc: > > Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ) > > > > > > Thanks for jumping in on this Peter. That's a pretty good > > summary of my position. Certainly, what's missing from BPEL > > today is a way of describing how individual BPEL abstract > > processes can be combined together in a precise way. That is > > a non-trivial problem in itself, and while such a description > > would be of great interest to BPEL, I don't think that the > > two should be dependent on one another. One might well wish > > to describe the connection of web services whose behaviors > > are not specified (or are not specified using BPEL). > > > > Satish pointed to some of the rationale for describing the > > behavior of the individual participants rather than taking a > > more neutral view of the interaction. On a very practical > > level, a single-party view has other benefits as well. It > > allows systems to be composed using either a unilateral or > > bi/multi-lateral approach. Each abstract process represents > > the behavior of one service, so it's in a form that can be > > directly leveraged by developers to seed or verify their > > implementations. > > > > Historically, I believe this approach has also been widely > > used in network protocol design. The TCP connection protocol, > > for example, speaks of server states (CLOSED, LISTEN, > > SYN-RECEIVED, ESTABLISHED) and client states (CLOSED, > > SYN-SENT, ESTABLISHED) and describes the behavior of each > > party in terms of its own local observations and state > > transitions. And as Satish was saying, in a neutral model the > > (potentially many) race conditions that might arise would > > have to be modeled explicitly while in an individual view > > they still exist but need not be enumerated. > > > > I'll also just echo a couple of important points that Peter > > raised. First, the existence of an abstract BPEL process says > > *nothing* about the way in which it is implemented. In fact, > > we'll probably start describing existing services long before > > the first BPEL-compliant execution engine runs its first > > process. In that respect, it's very much like WSDL - purely > > descriptive. > > > > Second, the interface/implementation relationship is a key > > point and gives users a great deal of flexibility. Multiple > > implementations of a single interface will be routine. But I > > think it will also be common for services to implement > > multiple abstract process behaviors simultaneously > > - perhaps as a "server" in one protocol and a "client" in another. > > > > > > I don't think abstract processes are very well motivated in > > the spec today. We should probably say more about their > > independence from implementation and about their relationship > > to executable processes. We should also say something about > > the formal methods that they are intended to support - > > certainly, the limitations on abstract processes were put in > > place with very specific analytic approaches in mind (i.e. > > model-checking). > > > > I have a demonstration of this that I'll be showing at the > > Microsoft developer conference in Los Angeles next week. If > > anyone in the TC will be attending, please stop by the > > Microsoft Research booth to say hello and see the demo. In a > > nutshell, it shows how we can verify that web service systems > > (described by BPEL abstract processes) will communicate > > successfully, and how we can detect and visualize errors. > > > > Tony > > > > > -----Original Message----- > > > From: Furniss, Peter [mailto:Peter.Furniss@choreology.com] > > > Sent: Wednesday, October 22, 2003 4:42 PM > > > To: ygoland@bea.com; John Evdemon; wsbpel@lists.oasis-open.org > > > Subject: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ) > > > > > > Some of Yaron's comments on the FAQ (most of which I agree > > > with) seem to relate to the power of abstract BPEL > > > > > > paragraph from the proposed FAQ: > > > > > > <quote> > > > The Business Process Execution Language is a XML-based language for > > > formally describing interoperable business processes and business > > > interaction protocols. It defines how web services are connected > > > together and in what sequence in order to accomplish a > > particular task > > > > > > </quote> > > > > > > to which Yaron comments : > > > > > > <quote> > > > BPEL only provides a description of the behavior of a > > single player in > > > > > a business process protocol. Since protocols require, by > > definition, > > > more than one player BPEL is by definition unable to completely > > > describe a business process protocol or to specify how different > > > processes interact beyond describing the behavior of a single > > > participant. Therefore I think this paragraph should be struck. > > > </quote> > > > > > > which was very much my view until I had a conversation with Tony > > > Andrews and got a better understanding of his presentation from the > > > first face-to-face ( > > > http://www.oasis-open.org/archives/wsbpel/200305/msg00172.html > > > ). It seemed some things I had thought would be necessary, > > and which I > > > > > hadn't seen stated, and so assumed were not in view, were definitely > > > intended/expected: > > > > > > - there can be multiple abstract definitions for > > a single > > > executable, each specifying the dynamic behaviour of one (or set of > > > related) interfaces, with the other interfaces handled by opaque > > > assignment; the choice of how many of these there are, > > their level of > > > opacity and the interfaces covered is a design/viewpoint question > > > > > > - there can be (and need to be for the "global" > > > picture) abstract bpel definitions for processes that are > > never going > > > to be in bpel - not least because some are "leaf" processes in the > > > web-service world, and do real work on databases or visible > > effect on > > > GUIs etc. rather than just defer to yet another > > web-service, which is > > > all executable bpel can do > > > > > > - there can be multiple executable processes matching a > > > single abstract definition - this is just an > > interface:implementation > > > relationship > > > > > > (Apologies to Tony if I've mis-represented him). They > > obviously have > > > some exciting implications for what bpel tools in general might do > > > (especially the middle one - how on earth do you show compatibility > > > between abstract bpel and a legacy app written in cobol with a > > > web-service front end) > > > > > > But these don't seem to be in the spec. (last one might > > be). Should it > > > be left to interpretation (and, no doubt, some books) ? > > > > > > There's also the possibility of stating the rules (guidelines ? > > > constraints ?) involved in the two abstract bpel > > definitions that make > > > > > up either side of a business protocol. > > > > > > > > > (I should possibly mention that I was for a long time very > > sceptical > > > about whether bpel or things like it was the way to do this, and > > > thought it could be done with a simpler, less procedural > > approach. but > > > > > gradually I found my vague "ideal" > > > was getting necessarily more complex and needing more > > functionality - > > > in fact heading towards somehting much like on abstract bpel) > > > > > > Peter (speaking for himself) > > > > > > > > > > > > > -----Original Message----- > > > > From: Yaron Goland [mailto:ygoland@bea.com] > > > > Sent: 22 October 2003 23:09 > > > > To: 'John Evdemon'; wsbpel@lists.oasis-open.org > > > > Subject: RE: [wsbpel] FAQ > > > > > > > > > > > > Some comments > > > > > > > > > -----Original Message----- > > > > > From: John Evdemon [mailto:jevdemon@microsoft.com] > > > > > Sent: Tuesday, October 21, 2003 12:44 PM > > > > > To: wsbpel@lists.oasis-open.org > > > > > Subject: [wsbpel] FAQ > > > > > > > > > > > > > > > <<WSBPEL DRAFT FAQ.txt>> Hello all, > > > > > > > > > > A while ago I asked for feedback on a TC FAQ. I have > > attached a > > > > > draft that incorporates some initial feedback from > > Monica and Ugo. > > > > > Please respond with any additional questions or concerns. > > > > > > > > > > If there is no feedback by 10/28 I will assume the TC is > > > happy with > > > > > the current version (attached) and submit it to OASIS. > > > > > > > > > > Thanks! > > > > > > > > > > John > > > > > > > > > > > > > > > > > > > > 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_workgroup.php. > > > > > > > > > > > > > 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 >. > > > > > > > >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_workgr >oup.php. > > > > >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_workgr >oup.php > >. > > > > > > > >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_workgr >oup.php >. > > > >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-spec-edit/members/leave_workgroup.php >. > > _________________________________________________________________ MSN Shopping upgraded for the holidays! Snappier product search... http://shopping.msn.com
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]