Re: [wsbpel] Issue 147 - Proposal For Vote

["Yaron Y. Goland" <ygoland@bea.com>]

The iterator variable is just an alias for the content in the BPEL 
variable(s) that the iterator content was generated from. So one could, 
for example, copy the results of the operation directly into the 
iterator variable which would then show up in the BPEL variables from 
which the iterator content was taken. Thus allowing for collection of 
information.

		Yaron

Trickovic, Ivana wrote:
> Yaron,
> 
> In case of parallel for-each multiple instances of the enclosed activity
> may be executed. The number of these instances is not specified at
> design time (otherwise, the <flow> element would be sufficient).
> 
> Let's assume we have the following simple example:
> 
> <foreach iteratorVariableName="sendPO" iteratorVariableType="..."
> parallel="yes">
>       <expression
> expressionLanguage="...">for_each_element_in_the_list_of_POs</expression
>  >
>       <scope>
>             <variables>
>                <variable name="getResponse" messageType="..."/>
>             </variables>
>         <invoke partnerLink="Seller"
>                   portType="..."
>                   operation="SyncPurchase"
>                   inputVariable="sendPO"
>                   outputVariable="getResponse">
>               </invoke>
>       </scope>
> </foreach>
> 
> The question is how these multiple outcomes -getResponses- will be
> collected. The proposal is silent on that. The BPEL language does not
> provide such a capability. So, it seems to me that we need a proprietary
> extension to deal with data aggregation/collection. It seems to me that
> the parallel for-each is not really usefully without proper data
> handling capabilities. Or?
> 
>  >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.
> 
> What would be the scenario where this complex behavior is needed?
> 
> Regards,
> 
> Ivana
> 
> 
>  >-----Original Message-----
>  >From: Yaron Y. Goland [mailto:ygoland@bea.com]
>  >Sent: Tuesday, March 15, 2005 10:34 PM
>  >To: wsbpeltc
>  >Subject: [wsbpel] Issue 147 - Proposal For Vote
>  >
>  >
>  >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.
>  >
>  >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.
>  >
>  >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.
>  >
>  >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: wsbpel-unsubscribe@lists.oasis-open.org
>  >For additional commands, e-mail: wsbpel-help@lists.oasis-open.org
>  >
>  >
>