Yaron Y. Goland wrote:
> 147 - Serial and Parallel For-Each
>
> Proposal: Introduce a foreach to BPEL with both serial and parallel
> semantics.
>
> Rationale: Just check the issue list for issue 147. There is a whole
> series of mails attesting to how important this activity is.
>
> Introduce a section 12.6
>
> Note: This proposal assumes that issue 126 is adopted.
>
> 12.6 - Foreach
>
> <foreach iteratorVariableName="ncname" iteratorVariableType="qname"\
> parallel="xs:Boolean" validate="yes|no"? standard-attributes>
> standard-elements
> <expression expressionLanguage="anyURI">...</query>
> activity
> </foreach>
>
> A foreach activity is used to iterate over a variable, either serially
> or in parallel. The foreach activity specifies an expression that is
> to return a set of element information items (EIIs). The foreach also
> specifies a variable name in the iteratorVariableName attribute and a
> variable type in the iteratorVariableType attribute. All the EIIs
> returned by the expression MUST be of the type specified by the
> variable type. By default however a BPEL engine is not required to
> validate variable types, if the programmer wishes to guarantee that
> the output of the expression will be validated to be of the
> appropriate type then the validate attribute should be set to 'yes'.
> If the validate attribute is set to 'yes' and the output of the
> expression are not all EIIs of the type specified by
> iteratorVariableType then a mismatchedAssignment failure MUST be
> thrown. Note that variable validation, if activated, is performed
> before any of the 'notional' virtual scopes described below are created.
>
> If parallel="no" then the foreach is a serial foreach. In that case,
> conceptually, a new 'notional' virtual scope is created that does not
> contain a fault handler nor a compensation handler. In fact, this
> 'notional' virtual scope cannot be said to exist for purposes of
> determining which scopes are children of other scopes. Please refer to
> section 13.5.1 for a full description of the compensation handle of
> this 'notional' virtual scope. This 'notional' virtual scope contains
> a single variable declaration with the name given in
> iteratorVariableName and the type given in iteratorVariableType. The
> virtual scope conceptually contains a virtual sequence. The first
> entry in the sequence is an assign that assigns an EII from the
> returned set, in document order where possible, in random order where
> not, to the scope's only variable. Once an EII from the return set is
> assigned to the local variable that EII is removed from the return
> set. The next activity in the sequence is then the activity specified
> in the body of the foreach activity. If the virtual scope exits
> without error and if there are remaining EIIs in the returned set then
> the process repeats until the returned set is empty.
-1 to the notion of spelling out the "returned set" and removing
elements from it. Why specify to such detail how the iterator works?
>
> The EIIs in the returned set are aliases to real EII instances held in
> BPEL variables. It is possible for one of the EIIs being pointed to,
> to be deleted while the for-each is executing. Such a deletion would
> occur if the EII being pointed to was removed from the BPEL variable
> that contained it. In that case the EII disappears from the returned
> set and is not iterated over.
-1 to the above paragraph.
>
> The foreach virtual scope local variable in the foreach iteration
> instance is also an alias to an actual EII in a BPEL variable. While
> the iteration instance is executing the EII could have its value
> changed. If that happens then the situation is similar to what happens
> if a BPEL variable is shared by two simultaneously executing sections
> of a BPEL, the change made in one section is instantly visible to the
> other. If, however, the EII instance is deleted then the virtual scope
> local variable will become null. It is legal to assign to the virtual
> scope local variable after it becomes null but the value will be lost
> when that iteration ends, just as with any other scope local variable.
> To prevent other parts of a BPEL from altering the return set or the
> scope local variable the foreach can be placed in a serialized scope.
All this talk of references/aliases is going to expand the scope of the
spec. I'm sure you have a proposal in the wings, but why not alias
variables?
>
> If the parallel attribute is set to 'yes' then a parallel foreach is
> created. In a parallel foreach a virtual flow is created that contains
> a series of virtual scopes, one for each EII in the returned value
> set, defined as given previously. As with a serial foreach the local
> variables in the parallel scopes are aliases to actual BPEL values
> with the same behavior as given above. While the possibility of
> interference can be reduced by placing a parallel foreach into a
> serialized scope this cannot prevent parallel virtual scopes generated
> by the foreach from interfering with each other since they all exist
> inside of the same serialized scope. A parallel foreach ends using the
> same logic that controls any flow's behavior. That is, either all the
> scopes in the flow successfully exit or one of the scopes throws an
> unhandled fault and the flow is terminated.
>
> Addition to Appendix A:
>
> mismatchedAssignment Thrown from a for-each if the returned iterator
> set is validated and contains entries of a type other than that
> specified in iteratorVariableType.
>
>
> ---------------------------------------------------------------------
> To unsubscribe, e-mail:
> For additional commands, e-mail:
>
>
