OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]


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


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


S/MIME Cryptographic Signature



[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]