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

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

All true, except for the simple matter of analyzing the implications of
concurrency for access to shared data or being able to recognize the
patterns where concurrency is absent and thus concurrency control is not
required.  In particular, if a sequence has incoming and outgoing links,
and is now replaced with a flow with links itself, I submit that
recovering the original pattern and its simple inexpensive
implementation would be challenging.  

In other words, we would be raising the bar for implementers of both
tools and runtime engines, especially if we expect them to cater to the
prejudices of those who prefer the "block structured" approach rather
than the "linking activities" approach that Assaf seems to like these
days.

Satish

-----Original Message-----
From: Maciej Szefler [mailto:mbs@fivesight.com] 
Sent: Wednesday, June 18, 2003 9:46 AM
To: Assaf Arkin; Eckenfels. Bernd
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] implicite links of the runtime engine (was:
Implicit <sequence> macro)

+1, BPEL is an abstract virtual machine, it should have the minimum
constructs necessary to express the universe of supported programs; if
there is no "if-then-else" because "switch" has all the expressive power
(and then some) of "if-then-else",  then there should not be a
"sequenence" by the same reasoning. 

-Maciej

> -----Original Message-----
> From: Assaf Arkin [mailto:arkin@intalio.com]
> Sent: Tuesday, June 17, 2003 2:46 PM
> To: Eckenfels. Bernd
> Cc: wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] implicite links of the runtime engine (was:
> Implicit <sequence> macro)
> 
> 
> 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
> 
> 

---------------------------------------------------------------------
To unsubscribe, e-mail: wsbpel-unsubscribe@lists.oasis-open.org
For additional commands, e-mail: wsbpel-help@lists.oasis-open.org