[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 147 - Proposal For Vote
I am afraid he is talking about the iterator variable as an alias for some real data as in the semantics of subroutine parameters in FORTRAN (sorry couldn't resist :-)). But in a concurrent language where the thing aliased might vanish while you are trying to use the alias. ________________________________ From: Trickovic, Ivana [mailto:ivana.trickovic@sap.com] Sent: Wed 4/13/2005 7:16 AM To: ygoland@bea.com Cc: wsbpel@lists.oasis-open.org Subject: RE: [wsbpel] Issue 147 - Proposal For Vote Yaron, The iterator variable in your proposal is there for input variables. Or? My question was referring to the output variables of, for example, multiple <invoke>s. Maybe I misunderstood your explanation. Could you elaborate that further? Regards, Ivana >-----Original Message----- >From: Yaron Y. Goland [mailto:ygoland@bea.com] >Sent: Thursday, April 07, 2005 7:07 PM >To: Trickovic, Ivana >Cc: wsbpel@lists.oasis-open.org >Subject: Re: [wsbpel] Issue 147 - Proposal For Vote > > >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</e >xpression >> > >> <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 >> > >> > >> > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]