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:]
> Sent: Thursday, October 23, 2003 12:35 PM
> To: Tony Andrews; 'Furniss, Peter'; ; John
> Evdemon;
> 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:]
> Sent: Thursday, October 23, 2003 2:30 PM
> To: Furniss, Peter; ; John Evdemon;
>
> 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:]
> > Sent: Wednesday, October 22, 2003 4:42 PM
> > To: ; John Evdemon;
> > 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:]
> > > Sent: 22 October 2003 23:09
> > > To: 'John Evdemon';
> > > Subject: RE: [wsbpel] FAQ
> > >
> > >
> > > Some comments
> > >
> > > > -----Original Message-----
> > > > From: John Evdemon [mailto:]
> > > > Sent: Tuesday, October 21, 2003 12:44 PM
> > > > To:
> > > > 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.
>
>
>
>
