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

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

I'm not suggesting that processes are independent of one another, only
that their *behaviors* should be specified from a local perspective.
Processes are influenced by one another's state all the time - but they
do it by exchanging messages. Coordination protocols have the potential
to communicate information about state in a way that might not even be
directly visible to BPEL, but that's a whole other discussion and
orthogonal to the questions about abstract processes, I think.

I agree that an issue should be raised in this area, but I don't think I
have the cycles to champion it. In fact, I recently "demoted" myself to
observer status in the TC given the limited amount of time I have to
spend on this. If someone else wants to take a stab at it though, I'd be
happy to help refine the wording.

In terms of my demo, "successful" means that:

1) all BPEL processes complete without becoming blocked on a message
that will never be sent, and without throwing any of the defined BPEL
faults (i.e. no invalid request/response sequences, no uninitialized
messages sent, no references to uninitialized variables, etc.)
2) all transmitted messages have been consumed

John has agreed to show the demo for me to anyone who's interested at
the next F2F if I decide not to go.

Tony

> -----Original Message-----
> From: Ben Bloch [mailto:ben_b54@hotmail.com] 
> Sent: Thursday, October 23, 2003 1:02 PM
> To: Tony Andrews; Furniss, Peter; Yaron Y. Goland; John 
> Evdemon; wsbpel@lists.oasis-open.org
> 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/le
> ave_workgroup.php.
> 
> 
>