[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: [wsbpel] Issue - 147 - Serial and Parallel For-Each
Hi, Regarding to Frank's question: "How is the output of the set of activities running in parallel combined?": If I understand what he means correctly, he may mean how to aggregrate individual data pieces received / generated by individual parallel flow into one bigger data E.g. aggregating the results of different RFQ into one business doc. In some cases, the order of aggregration / document order matters. Potential answers are: [sorry ... kind of heading back to Issue 11 :-) ]. (1) a sequential forEach to initialize a sequence of empty quotation in a particular order. e.g. <quotation supplier="..."> ...</quotation> (2) The parallel forEach will assign the data to specified location by looking up by supplier attribute: <to ...$var/quotation[@supplier=$supplierVar] /> If the aggregration order does not matter, we don't need to intialize a sequence. We just need to use "append" within the parallel forEach (Issue 11 here again ...) Thanks! Regards, Alex Yiu Yaron Y. Goland wrote: > Please see below > > Frank Leymann wrote: > >> >> >> Yaron – initial questions: >> >> >> >> How is the output of the set of activities running in parallel combined? >> > > I'm not sure I understand what you mean. None of our activities have > return values so what would we be combining? > >> >> >> What is the fault model, i.e. what happens if a subset of the forked >> activities fail? >> > > The parallel for-each is effectively a dynamic flow. The same fault > and completion conditions that apply to flows also apply to parallel > for-each. > >> >> >> >> >> Best regards, >> >> Frank Leymann >> >> Phone:......+49-711-7816 470 >> >> Mobile:.....+49-162-322 4444 >> >> e-Mail: Frank.Leymann@informatik.uni-stuttgart.de >> >> >> >> -----Ursprüngliche Nachricht----- >> *Von:* ws-bpel issues list editor [mailto:peter.furniss@choreology.com] >> *Gesendet:* Friday, July 16, 2004 3:10 PM >> *An:* wsbpel@lists.oasis-open.org >> *Betreff:* [wsbpel] Issue - 147 - Serial and Parallel For-Each >> >> >> >> This issue has been added to the wsbpel issue list. The issues list >> is posted as a Technical Committee document to the OASIS WSBPEL TC >> pages <http://www.oasis-open.org/apps/org/workgroup/wsbpel> on a >> regular basis. The current edition, as a TC document, is the most >> recent version of the document entitled in the "Issues" folder of the >> WSBPEL TC document list >> <http://www.oasis-open.org/apps/org/workgroup/wsbpel/documents.php> - >> the next posting as a TC document will include this issue. The list >> editor's working copy, which will normally include an issue when it >> is announced, is available at this constant URL >> <http://www.choreology.com/external/WS_BPEL_issues_list.html>. >> >> >> * Issue - 147 - Serial and Parallel For-Each * >> >> * Status: * open >> *Categories:* Syntax and validation <#category_syntax_and_validation> >> *Date added:* 16 Jul 2004 >> *Submitter:* Yaron Y. Goland <mailto:ygoland@bea.com> >> *Date submitted:* 15 June 2004 >> *Description:* For-each is a very common control structure that has >> special appropriateness to BPEL where one can routinely expect BPELs >> to need to iterate through XML structures. One can easily imagine two >> flavors of for-each. Serial and parallel. Note: These same ideas have >> been proposed in issue 63 <#Issue63> and issue 4 <#Issue4> but both >> of those issues could be resolved in ways that do not necessarily use >> the for-each construct. Therefore I am proposing for-each on its own. >> If 63 and 4 are closed by introducing serial and parallel for-each >> then this issue can also be closed. >> *Submitter's proposal:* >> >> >> <foreach iteratorVariableName="ncname" iteratorVariableType="qname"\ >> parallel="xs:Boolean" standard-attributes> >> standard-elements >> <expression expressionLanguage="anyURI">...</query> >> activity >> </foreach> >> The expression element would be responsible for returning a node-set >> with 0 or more nodes in it. Each node MUST be of the type specified >> by iteratorVariableType. >> >> If parallel equals false then each node would be assigned, serially >> and in document order, to the variable created in an implicit local >> scope by the attribute iteratorVariableName and the activity would be >> executed. After the activity successfully completes the variable >> would be assigned to the next node and the activity run again. >> >> If parallel equals true then a series of parallel scopes, with the >> same operational semantics as parallel executing event handlers, >> equal in number to the number of nodes in the node-set would be >> created and each node would be assigned to a variable local to each >> of the scopes. >> >> Note that the scope in which the iterator variable is defined is >> local to the foreach activity and does not contain either an implicit >> fault or compensation handler. The lack of these handlers is very >> similar to the logic that was discuss at the 6/2004 F2F for issue 126 >> <#Issue126>. >> >> For example: >> >> >> foreach iteratorVariableName="anOrder" iteratorVariableType="b:ar"/ >> expression >> >> expressionLanguage="http://www.w3.org/TR/1999/REC-xpath-19991116" >> parallel="false" >> $orderManifest/somePart/ordermanifest/orders >> ... >> Would be equivalent to: >> >> >> scope >> variables >> variable name="anOrder" type="b:ar" >> variable name="currentInstanceNum" type="xs:int" >> sequence >> assign >> replace >> from expressionLanguage="static" >> "1" >> to expressionLanguage="xpath" >> $currentInstanceNum >> while >> condition expressionLanguage="xpath" >> $currentInstanceNum <= >> count($orderList/somePart/ordermanifest/orders) >> sequence >> assign >> replace >> from expressionLanguage="xpath" >> >> $orderList/somePart/(ordermanifest/orders)[$currentInstanceNum] >> to expressionLanguage="xpath" >> $anOrder >> assign >> replace >> from expressionLanguage="xpath" >> $currentInstanceNum+1 >> to expressionLanguage="xpath" >> $currentInstanceNum >> ... >> >> *Links:* Yaron Y. Goland, 25 Mar 2004 >> <http://lists.oasis-open.org/archives/wsbpel/200403/msg00215.html> >> Yaron Y. Goland, 25 Mar 2004 >> <http://lists.oasis-open.org/archives/wsbpel/200403/msg00216.html> >> *Changes:* 16 Jul 2004 - new issue >> >> To comment on this issue, please follow-up to this announcement on >> the wsbpel@lists.oasis-open.org list (replying to this message should >> automatically send your message to that list), or ensure the subject >> line as you send it *starts* "Issue - 147 - [anything]" or is a reply >> to such a message. If you want to formally propose a resolution, >> please start the subject line "Issue - 147 - Proposed resolution", >> without any Re: or similar. >> >> To add a new issue, see the issues procedures document (but the >> address for new issue submission is the sender of this announcement). >> >> To unsubscribe from this mailing list (and be removed from the roster >> of the OASIS TC), go to >> http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. >> > > > To unsubscribe from this mailing list (and be removed from the roster > of the OASIS TC), go to > http://www.oasis-open.org/apps/org/workgroup/wsbpel/members/leave_workgroup.php. > >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]