RE: [wsbpel] Issue 147 - Proposal For Vote

["Trickovic, Ivana" <ivana.trickovic@sap.com>]

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
>
>