Re: AW: [wsbpel] Issue - 147 - Serial and Parallel For-Each

[Maciej Szefler <mbs@fivesight.com>]

+1, Any construct that is dynamic in nature, whether parallel-foreach,
serial-foreach, while, or until is rather crippled without the ability
to iterate over sets or aggregate results. If we want to have these
constructs without compromising the programming-in-the-large philosophy
we should define proper high-level abstractions for dealing with this
issue: i.e some sort of iterator (e.g. multi-node query-driven
variables) and aggregator abstractions. Using BPEL variables as indexes
into other BPEL variables (through XPATH) is programming in the small.
-maciej

On Tue, 2004-07-20 at 21:52, Assaf Arkin wrote:
> I want to echo the sentiments regarding the utility of foreach, and also 
> regarding XML manipulation, properties, etc.
> 
> We are running into a lot of use cases where some form of data 
> manipulation is precisely what the business process (and business use 
> case) is all about, and what customers expect from a language that does 
> programming in the large. The only way we can migrate customers to BPEL 
> is if we can offer them these capabilities..
> 
> I'm not talking about replacing Java or C, but more along the lines of 
> business utilility at the same level as Excel. While I don't see 
> customers utilizing more than the basic features of XPath, they seem to 
> want to combine them with ability to change fields in a structure, 
> operate on lists, iterate over lists, etc.Wide not deep, as the higher 
> level business process dictates.
> 
> A foreach is quite a common use case (RFQ comes to mind). If the user 
> has to code a foreach using a while loop, then the resulting sphagetti 
> code is not programming in the large. And if they have to exit to some 
> Web service to orchestrate the iteration, then the process becomes so 
> dependent on the Java (or whatever) code, that it's now officially 
> programming in the small.
> 
> Assaf
> 
> 
> 
> Yaron Y. Goland wrote:
> 
> > In our experience using for-each to work through an incoming message 
> > variable is a common design pattern. Furthermore our experience tells 
> > us that when folks are iterating through the variable they will also 
> > be sending and receiving messages. So if we force them to go down into 
> > a 'programming in the small' language to do the iteration we will 
> > create a really painful inversion where they will find themselves 
> > having to figure out how to call out into BPEL from inside of the 
> > 'programming in the small' language in order to send/receive messages 
> > from inside of the for-each. That's why I think we should allow for 
> > iterator manipulation in BPEL itself.
> >
> > Like many things in BPEL this is a judgment call. Go talk to your 
> > customers, look at their code and see if they are doing the sorts of 
> > things I'm describing. If your experience is similar to ours then 
> > supporting for-each with iterator manipulation in BPEL will make sense 
> > for you too.
> >
> > As for issue 11, I thought I had been more public in my comments that 
> > after living with it for a while I'm a lot friendlier to it. As I have 
> > talked to more of our customers and our field folks it has become 
> > clear that there is a real demand for BPEL to be able to do basic XML 
> > manipulation. Yes, I know, another slippery slope.
> >
> > My attitude towards issue 11 is very similar to my attitude towards 
> > issue 2. I would love to have it but I'm not willing to hold up the 
> > spec to get it. Given my own experiences trying to fully define copy 
> > (19 pages for an incomplete definition) I am dubious as to our ability 
> > to deliver on a fully baked definition for the commands in issue 11 
> > without significantly delaying the spec. But I would be very happy to 
> > turn out to be wrong.
> >
> >         Yaron
> 
>

This is a digitally signed message part