RE: [wsbpel] implicite links of the runtime engine (was: Implicit <sequence> macro)

["Satish Thatte" <satisht@microsoft.com>]

>  I'm putting out a particular opinion in the understanding that the
>  specification is geared towards the definition of executable
processes. 
>  Is that a wrong assumption?

We obviously support and will continue to support both abstract and
executable processes.  Abstract processes are clearly not relevant only
to execution engines.  As Yaron has pointed out, even execution oriented
BPEL models will be looked at and modified by humans whatever our
intention or recommendation.

>  For the record we looked at this long and hard within the context of 
>  BPML. 

Does BPML have a notion of links and graphs?  I must have missed that.

Satish

-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com] 
Sent: Friday, June 20, 2003 1:13 PM
To: Satish Thatte
Cc: Ron Ten-Hove; Maciej Szefler; Eckenfels. Bernd;
wsbpel@lists.oasis-open.org
Subject: Re: [wsbpel] implicite links of the runtime engine (was:
Implicit <sequence> macro)

Satish Thatte wrote:

>Not sure what you are proposing here - Pi calc linked to WSDL with a
>couple of your rules?
>  
>
On the contrary. I've justified my criteria by looking at the possibilty

of going all the way down to pi-calculus linked to WSDL, and rejected it

on the grounds that while it actually does not reduce the number of 
constructs and if anything further complicates the specification.

>Please keep in mind that no matter what criteria you have for
>minimality, it is extremely unlikely that the resulting "minimal
feature
>set" will be unique.  
>
Agreed.

I think what we lack here is coherence. If we are not striving for a 
minimal feature set than there are others features we should entertain 
that would simplify some definitions especially from the perspective of 
modeling and/or XML authoring. If we are looking for a minimal feature 
set what are our criteria? Is that strictly to address execution or do 
we need to look at a larger scope?

>I have heard people argue rather vociferously that links should be
>dropped (rather than sequence).  This is clearly possible if you do all
>intra and inter process synchronization uniformly through messaging,
>letting the implementation optimize the intra-process case, rather the
>way you are proposing that the implementation should optimize the
>sequential case.
>
So did I, but I could not imagine how that would simplify the
specification.

For the record we looked at this long and hard within the context of 
BPML. For the engine it makes absolutely no difference and the engine 
can definitely optimize intra-process messaging. But does it make the 
specification simpler? On the contrary. Not only do you have to define 
the same semantics of links, but you have to define a set of constraints

to ensure proper usage of messaging, and the resulting language ends 
being more complex to define and test.

So speaking purely from my experience having done this before I would 
suggest we don't do down this path a second time.

>So where would that leave us?  My minimal set is better than yours
>because "From an execution perspective I have a strict preferrence for
>linking activities approach and always did"?
>  
>
With the open question of what criteria we use to judge which constructs

are part of the specification.

I am not going to say that my opinion is valid in all possible contexts.

In other contexts I would have a different set of requirements and may 
actually favor having more language constructs. I am sure other members 
also have a list of requirements that are context sensitive.

I'm putting out a particular opinion in the understanding that the 
specification is geared towards the definition of executable processes. 
Is that a wrong assumption?

arkin

>Satish
>  
>