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

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

Hello,

Yaron, OK if we have validation in 160 passed then we can keep it in
here, too.

I see your point about concurrently editing the request, my solution
would be to explizitely require the for-each to work on a snap shot.
However this works better with the int-iterator, than with your
alias-iterator (because of the results).

How about having not only an request-part alias but also a response-part
alias? As you can see I dont think the integer solution is a perfect
one, just want to make sure whatever we use, it is at least as powerfull
as the integer solution.

For the topic of static vs dynamic request candidates: for me it would
be enough to asume a static set (i.e. snapshot or serialisation) - i am
not sure if I have use for the dynamic case. You can always have kind of
"dont process this branch" flag set from outside if it is really
required (which should be very seldom). Do you have a specific example
for this feature?

Greetings
Bernd


-----Original Message-----
From: Yaron Y. Goland [mailto:ygoland@bea.com] 
Sent: Tuesday, April 12, 2005 7:10 PM
To: Eckenfels. Bernd
Cc: wsbpeltc
Subject: Re: [wsbpel] RE: Issue 147 - some comemnts and questions


> A) validate=true - I think this is good, however I would not start to 
> introduce this attribute with for-each. I would expect a 
> validation-hint to be added globally in bpel or no where (i.e. only as

> vendor extensions). I am not sure we have it already somewhere?
> 

In issue 160 we passed an explicit validation switch to be used with
assign. The 147 proposal follows the same design.

> Design issues:
> 
> B) "removed from result set" I agree with Danny that this is a 
> implementation detail (actually a confusing one, especially in 
> combination with allowing for changes in the set). I would prefer 
> something like "the engine ensures to execute the virtual scope for 
> each EII in the result set (at the time the for-each was activated) 
> exactly once". This is imho a portable definition and less
complicated.
> 

Imagine that a serial for-each expression generates 4 results.

While the first iteration of the for-each is being processed a parallel
part of the BPEL flow edits the variable that the results were generated
from and deletes the remaining 3 values.

If we use the semantics suggested above then the for-each would continue
to iterate 3 more times, even though the values being iterated on no
longer exist. The result is that the iterator value in all three
remaining iterations would be uninitialized.

I believe such behavior to be counter intuitive.

> C) iteratorVariable - I have experiences with a similiar construct, 
> which however works as an integer counter instead of an iterator. This

> has the DISadvantage, that it is less "object oriented", however it 
> has the advantage that it is reuseable. I get the position of the EII 
> as an index and can address it with an assign (in the case of XPAth:
> /somewhere/resultnode[$intInter}).
> 
> Especiually I can use this integer also for another variable where i 
> want to accumulate the results (asuming some defined order of the EII
> however)
> 
> For-each query="$in/somewhere/resultnode" as="iter"
>   assign
>     from query="$in/somewhere/resultnode[$iter}"
>     to query="$out/elsewehere/node[$iter]"
> 
> This will avoid to introduce the new alias concept, since assignes 
> only know about their normal semantics (with the exception of a read 
> only integer).
> 
> If we go with the alias iterator, I am not sure about how to collect 
> results. I guess that was Ivanas question, too. We could assign the 
> results back to the request message, however I think this is untypical

> for process design and counter intuitive for modellers who like to 
> have a in-type and an out-type.
> 

There are actually a couple of downsides to the number approach. First,
it can be very misleading. If someone is editing the iterated variable
in parallel then it is possible for items to move around. Imagine that a
foreach expression generates 4 results. This will cause the for-each to
count from 1 to 4. On the second iteration the code looks ahead to the
third iteration to see what value is coming up and makes a decision on
that basis. But after the second iteration ends but before the third
iteration begins the variable being iterated over is modified so that
the third entry is missing. Now the third iteration begins but it is
actually processing the 4th value, not the 3rd value. But what's much
worse is that the decisions made on the 2nd iteration were based on the
value of the 3rd entry. But now the 3rd entry is gone but the foreach
doesn't know that! So it will process what is really the 4th entry,
thinking it is the 3rd entry and all hell will break lose. In addition
when the 4th iteration arrives the integer will point to an empty node
set (in XPATH 1.0 terminology) which will almost certainly break the
programmer's code unless they put in explicit checks.

Second, using iterators in this way is more complex for the programmer
because now they have to throw in XPATHs with iterator values all over
the place.

For what its worth I don't think the numeric iterator pattern is
necessarily a bad one. I just think it is less optimal than the alias
pattern.


> D) iteratorVariableType <- I guess it is allowed to do static checking

> if the type is possible? I would change the wording for the verify, so

> that the engine will asume the iterator is of the specified type, and 
> may check if it is assignment compatible. With the int-iterator it is 
> however a non-issue.
> 

That is what the validate attribute is for.

> Greetings
> Bernd
> 
> ---------------------------------------------------------------------
> To unsubscribe from this mail list, you must leave the OASIS TC that 
> generates this mail.  You may a link to this group and all your TCs in

> OASIS
> at:
> https://www.oasis-open.org/apps/org/workgroup/portal/my_workgroups.php
>