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

["Eckenfels. Bernd" <B.Eckenfels@seeburger.de>]

Hello,

Andrew actually I agree with you, that maybe two constructs would be
better to ensure that the modelelrs intention is more expliciteley
stated.

One could be the sequential for-each you know from programming languages
which support iterators,  collections or lambda expressions (kind of
simple while-makro).

The other construct will be a dynamic flow as you describe it. I think
the lack of parallel constructs in most programming languages is only a
proof for BPEL beeing a high level process language (which needs it).
And I dont think it should look like a fork thing. It is better desribed
as a work-item submission mechanism. Like an "invoke-multi". The work
items can be processed in an event handler and all the snapshot and
compensation stuff is solved here, too. I think we had that idea before.
The weak point of this is mainly the synchronisation on results. 

Greetings
Bernd

PS: from my productive BPEL projects I do have the experience that some
coding gets pretty low level of we talk about data splitting, forking,
merging and picking. But my goal is to improve BPEL not to use
extensions for that. Since this kind of data flow belongs to the high
level aspects of process control.

-----Original Message-----
From: andrew.francis@mail.mcgill.ca
[mailto:andrew.francis@mail.mcgill.ca] 
Sent: Tuesday, April 12, 2005 7:38 PM
To: Eckenfels. Bernd
Cc: wsbpel@lists.oasis-open.org; ygoland@bea.com
Subject: Re: [wsbpel] RE: Issue 147 - some comemnts and questions

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>.