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

["Maciej Szefler" <mbs@fivesight.com>]

I'd argue that the distinction between executable and abstract is really quite small. Both executable and abstract process will be "executed", either by a "real" machine implementing the physical side-effects of the reductions implied by the process definition in the context of the physical environment, or by a machine that attempts to determine the bisimilarity of two BPEL processes. Consequently, I see the value of constructs such as "sequence" to be unaffected by the abstractness of the process. 

One could even make an argument (although I would not) that from the perspective of manual inspection of BPEL process definitions, it is better to NOT have <sequence>, simply because it is a bit harder to see that concrete process <seq> A B C </seq> accurately implements abstract process <seq><flow> A B </flow> C </seq>.


-Maciej Szefler

> -----Original Message-----
> From: Satish Thatte [mailto:satisht@microsoft.com]
> Sent: Friday, June 20, 2003 4:47 PM
> To: Assaf Arkin
> 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)
> 
> 
> >  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
> >  
> >
> 
> 
> 
>