[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
Just want to say few quick points here: (1) Programming construct similar to parallel forEach is quite needed to implement any RFQ pattern. It looks like "programming in small" but actually it facilitates the goal of "programming in big" of BPEL (2) forEach (serial/parallel) in general gives a good abstraction level of functionalities. It is similar to "for"-clause in XQuery. It will make the blending between BPEL and XQuery smoother. (3) Serial forEach is a good "serial" version of mirror image of forEach. A "serial" forEach gives chances to BPEL engine to optimize iteration over a large collection of data. (4) Regarding to Yaron's previous-previous reply: (a) "We would specify the iterator variable as effectively a pointer at the information item in the source variable." (b) "The programmer would then be able to edit that variable directly and thus change the source document." I agree with (a) in general. But, (b) makes me worry quite a bit. It may open a big can of worms which I am not sure we have enough to deal with. Thanks! Regards, Alex Yiu Yaron Y. Goland wrote: > In our experience using for-each to work through an incoming message > variable is a common design pattern. Furthermore our experience tells > us that when folks are iterating through the variable they will also > be sending and receiving messages. So if we force them to go down into > a 'programming in the small' language to do the iteration we will > create a really painful inversion where they will find themselves > having to figure out how to call out into BPEL from inside of the > 'programming in the small' language in order to send/receive messages > from inside of the for-each. That's why I think we should allow for > iterator manipulation in BPEL itself. > > Like many things in BPEL this is a judgment call. Go talk to your > customers, look at their code and see if they are doing the sorts of > things I'm describing. If your experience is similar to ours then > supporting for-each with iterator manipulation in BPEL will make sense > for you too. > > As for issue 11, I thought I had been more public in my comments that > after living with it for a while I'm a lot friendlier to it. As I have > talked to more of our customers and our field folks it has become > clear that there is a real demand for BPEL to be able to do basic XML > manipulation. Yes, I know, another slippery slope. > > My attitude towards issue 11 is very similar to my attitude towards > issue 2. I would love to have it but I'm not willing to hold up the > spec to get it. Given my own experiences trying to fully define copy > (19 pages for an incomplete definition) I am dubious as to our ability > to deliver on a fully baked definition for the commands in issue 11 > without significantly delaying the spec. But I would be very happy to > turn out to be wrong. > > Yaron > > Danny van der Rijn wrote: > >> >> this sounds like you're trying to "program in the small." >> >> are you ready to support my previous proposals (issue 11) of >> expanding the data handling capabilities of BPEL? IMO they are far >> more useful and general purpose than this one. >> >> ----- Original Message ----- >> *From:* Yaron Y. Goland <mailto:ygoland@bea.com> >> *To:* Alex Yiu <mailto:alex.yiu@oracle.com> >> *Cc:* Frank Leymann <mailto:Frank.Leymann@t-online.de> ; >> wsbpel@lists.oasis-open.org <mailto:wsbpel@lists.oasis-open.org> >> *Sent:* Monday, July 19, 2004 9:31 AM >> *Subject:* Re: AW: [wsbpel] Issue - 147 - Serial and Parallel >> For-Each >> >> I also think that we should make it possible to directly edit the >> iterator variable itself. We would specify the iterator variable as >> effectively a pointer at the information item in the source >> variable. >> The programmer would then be able to edit that variable directly and >> thus change the source document. >> >> Alex Yiu wrote: >> > >> > >> > 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 >> <mailto: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 >> <mailto: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 >> <mailto: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. >> >> >> > >> > > >> > > >> > >> > >> >> 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]