RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)

["Tony Andrews" <tandrews@microsoft.com>]

I don't know yet whether I'll be attending, but if I do I'll definitely
have it on my laptop.

Tony 

> -----Original Message-----
> From: Harvey Reed [mailto:hreed@sonicsoftware.com] 
> Sent: Thursday, October 23, 2003 12:35 PM
> To: Tony Andrews; 'Furniss, Peter'; ygoland@bea.com; John 
> Evdemon; wsbpel@lists.oasis-open.org
> Subject: RE: [wsbpel] Abstract BPEL (was RE: [wsbpel] FAQ)
> 
> Hi Tony,
> 
> Will you have this implementation available at the December 
> F2F meeting in Melbourne?
> 
> ++harvey
> 
> -----Original Message-----
> From: Tony Andrews [mailto:tandrews@microsoft.com]
> Sent: Thursday, October 23, 2003 2:30 PM
> To: Furniss, Peter; ygoland@bea.com; John Evdemon; 
> wsbpel@lists.oasis-open.org
> 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_workgroup.
> php.
> 
> 
> 
>