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

[Assaf Arkin <arkin@intalio.com>]

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