[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)
> And, no, I won't be > going to the conference you speak of, but I'd love to somehow see it anyway. +1 ----- Original Message ----- From: "Ben Bloch" <ben_b54@hotmail.com> To: "Tony Andrews" <tandrews@microsoft.com>; "Furniss, Peter" <Peter.Furniss@choreology.com>; "Yaron Y. Goland" <ygoland@bea.com>; "John Evdemon" <jevdemon@microsoft.com>; <wsbpel@lists.oasis-open.org> Sent: Thursday, October 23, 2003 1:01 PM Subject: Re: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ) > Tony, > > I absolutely concur that the spec can and probably should do a better job of > describing what abstract processes are, including their relationship to and > potential unboundedness from executable processes. In fact, if this could > somehow be raised as an issue, perhaps the editors (of which I am one) can > take a swag at this. It would make the spec more readable and show the > value(s) of abstract processes themselves. > > I also agree that individual abstract processes should not be dependent upon > one another to be able to operate. However, one process IMO should be able > to learn or at least be influenced by the state (eg failure) of another > process, perhaps from the process in question itself, a coordination or > monitoring service (more likely) or some other mechanism. > > And lastly, if I could focus in on the last sentence about your 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." > Could you please define "successful" on this context? And, no, I won't be > going to the conference you speak of, but I'd love to somehow see it anyway. > > Ben > > > > how they compare to WSDL. > ----- Original Message ----- > From: "Tony Andrews" <tandrews@microsoft.com> > To: "Furniss, Peter" <Peter.Furniss@choreology.com>; <ygoland@bea.com>; > "John Evdemon" <jevdemon@microsoft.com>; <wsbpel@lists.oasis-open.org> > Sent: Thursday, October 23, 2003 2:30 PM > 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_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]