[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)
As I argued during my presentation at the first F2F, the idea that a neutral description of multi-party interaction is essential for business protocol definition is erroneous, and worse, too restrictive. In particular protocols using full duplex communication are almost impossible to describe without separately describing the external behavior of each party, because the number of states corresponding to races becomes unmanageable and incomprehensible. Think of a supply chain protocol where an order may be canceled at arbitrary points. Most neutral protocol descriptions tend to be reduced to finite state machines that are also very poor at describing data dependent aspects, error recovery protocols, etc. I expect this is what Peter is referring to when he speaks of "heading towards somehting much like on abstract bpel". I therefore consider Yaron's objection to be groundless and advocate keeping the paragraph as is. -----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/leave_workgr oup.php.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]