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

["Furniss, Peter" <Peter.Furniss@choreology.com>]

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
.