Re: [wsbpel] RE: Issue 147 - some comemnts and questions

["Yaron Y. Goland" <ygoland@bea.com>]

To me the issue of foreach versus flow is one of 'least surprise'.

Personally I think it is less surprising to have a serial foreach turn 
into a parallel foreach then it is to have a flow which normally means 
"do these things in parallel" turn into "do these things in parallel 
except certain things which should be done in parallel more than once".

But this is really a question of art, not science.

	Yaron

andrew.francis@mail.mcgill.ca wrote:
> Quoting "Eckenfels. Bernd" <B.Eckenfels@seeburger.de>:
> 
>  > I also think the for-each construct is very important and
>  > I like the general idea Yaron is going with his proposal.
>  > However I have some additional comments (partially
>  > agreeing with Danny).
> I think for-each is an important construct too. Most scripting
> languages have some variant. However my main concern with
> issue 147 is the mingling of a control flow with
> concurrency. I feel it is good to be able understand what
> the program isdoing from a quick glance. I am uncomfortable with an
> important concurrency detail being hidden in an attribute
> of which most programmers consider a looping construct.
> 
> I can appreciate the desire in WS-BPEL to do the equivalent of:
> 
> while()
> {
>    fork()
>    {
> 
>    }
> }
> 
> However I suspect for-each will prove to be too low
> level and complicated to use (this is great for a system
> programming language).
> I would prefer to see dynamic "branching" done by
> extending the <flow> activity. And opposed to introducing
> another construct, bundles (if I understand Bundles
> correctly). Issue 6.x is already going to increase the
> complexity of <flow>.
> 
>  From what I have seen (Bundles, the essence of a good
> solution will have <flow>, premature termination,
> iteration, and some form of sub-process/modularization
> working together.
> 
> I can see use cases such as:
> 
> I want to contact X buyers and Y sellers in parallel. I
> decide whom and how many at runtime. I construct the
> arguments for each buyer and each seller and collect
> them in an iterator.
> 
> The <prototype> is a directive. A new instance
> of whatever is within the prototype is created.
> For simplicity let us assume only scopes are
> allowed. <prototype> takes an attribute, iterator.
> The iterator is used to initialise activities
> within the prototype.
> 
> 
> <flow>
>    <prototype argumentList="buyerArgumentsIterator">
>       <scope>
>    </protype>
> 
>    <prototype argumentList="sellerArgumentsIterator"
>      <scope>
>    </prototype>
> </flow>
> 
> In the absense of a parameterized activity, we can
> pretend that <flow>, using arguments from the iterator,
> is initializing local variables in a specific scope.
> In turn the iterator item, argument, is a name/RHS pair.
> 
> This does what Yaron's 147 does with some differences.
> First a new construct is not added. Secondly I can use
> many different iterators within the same concurrency
> construct without adding difficult control logic. I
> also suspect this construct is more readable.
> 
> I know this is just a sketch of a solution.....
> 
> Cheers,
> Andrew
> 
> 
>