Abstract BPEL (was RE: [wsbpel] FAQ)

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

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
> > 
> > 
>