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

[Assaf Arkin <arkin@intalio.com>]

Satish Thatte wrote:

>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.  
>  
>
Again the assumption is that you have to do it anyway for the flow 
activity to determine that some activity A can access shared data 
written by some activity B, where A and B are executed in different 
paths but are synchronized using a link. Doing it for a sequence of 
activities is fairly trivial since you join condition tends to involve 
one mandatory input link ;-)

>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.
>  
>
 From an execution perspective I have a strict preferrence for linking 
activities approach and always did. My preference can be summed up as 
"the less constructs the better". If the execution engine already has to 
deal with the complexity of <flow>, then I don't see an evidence to 
support the need for <sequence>.

There's a different set of requirements when you start tackling modeling 
and addressing visual notations. A language that is intended to address 
modeling would also include requirements for modeling and visual 
representation. Such requirement would incidentally suggest the 
introduction of a <sequence> activity, more looping constructs and other 
notational aids.

Which category are we trying to fit in?

arkin

>Satish
>