[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
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/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_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/leave_workgroup.php .
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]