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

[Ron Ten-Hove <Ronald.Ten-Hove@Sun.COM>]

Title:

    If BPEL were to be strictly a modelling language, then the inclusion
of both <sequence> and <flow> would be justifiable from the modelling
perspective. Perhaps we can make this claim for abstract BPEL?

    On the other hand, "concrete" BPEL has a different purpose: it is an
executable description of a process. It may be appropriate for the
TC to create a formal semantics for the execution of each BPEL element, in
order that we may analyse and better understand what we are creating. Even
if we don't go as far as formalising the semantics, it is true that the simpler
the language, the easier it is to reason about. From this perspective, it
is entirely appropriate for Arkin to ask that the <sequence> activity
justify its existence, when equivalent structures exist elsewhere.

    So what is our rational moving forward? Is this (primarily) a modelling
language, or an executable artifact? Or are there better criteria for resolving
these issues?

-Ron

Assaf Arkin wrote:
> I agree. 
>  
> If the distinction was made between doings thing in order or in  parallel,
> then I understand why you need two different activities. But  we wouldn't
> need links or serializable scopes. Currently the flow  activity covers all
> the cases from strictly serialized to strictly  concurrent and all shades
> in between, making the sequence activity  nothing more than a convinience.
> You need to support the complexity of  synchronized activities to support
> the flow activity, that's not easy  but if you have the capability you might
> as well use it all the way. 
>  
> So the sequence activity does need to justify its existence, and it  needs
> a generic rational so we can decide what to do with other existing  or proposed
> "simplifications" to the language. 
>  
> arkin 
>  
> Eckenfels. Bernd wrote: 
>  
> > Hello Satish, 
> >  
> >   
> >  
> > > I honestly don't think <sequence> needs
> > > to justify its existence. 
> > > Concurrency with synchronization can emulate sequentiality but that is 
> > > clearly a convoluted and expensive way to do the simplest kind of 
> > > orchestration. 
> > >      
> > >     
> >  
> > This may be true from the standpoint of writing bpel by hand, but for sure
> > it is a non issue for implementation. Depending on your internal runtime
> > data model, a sequence is only an additional complication, provided the fact,
> > that you need to offer a implementation for flow, anyway. And since a sequence
> > does not forbid to have links in and out, it also means your engine has to
> > support the notion of synchronisation, anyway. 
> >  
> > So we should make clear in the spec, that it is only a shortcut, for skipping
> > those links inside a sequential flow, but all other properties will apply,
> > anyway. 
> >  
> > Greetings 
> > Bernd 
> >  
> > --------------------------------------------------------------------- 
> > To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org 
> > For additional commands, e-mail: wsbpel-help@lists.oasis-open.org 
> >   
> >  
> >   
>  
>  
>  
> --------------------------------------------------------------------- 
> To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org 
> For additional commands, e-mail: wsbpel-help@lists.oasis-open.org 
>