[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: Re: AW: AW: [wsbpel] Issue - 147 - Serial and Parallel For-Each
I would very much like to see your proposal since attempts to date to introduce a completion condition were so complex, especially when it came to dealing with over all semantics, faults, compensations, etc. that I did not believe them to be workable. It will be interesting to see how yours differs. As for me, I have already proposed what I believe to be a good workable solution to the issue of N out of M parallel for-eachs - named Breaks. See issue 142. Yaron Alex Yiu wrote: > > Frank, > > You are welcome. :-) It kinds of feels good that I can guess what you > had in mind. ;-) > > Regarding to the N out of M conditions, we discussed that briefly in the > March F2F in Germany. > I believe we need to add a <completionCondition> into the forEach and we > need to add a new special standard fault semantics (let's call it > bpws:earlyCompletion for now for the parallel cases) to accomplish that > kind of logic. > > I do have a (relatively detailed) proposal on how to achieve that. > However, it is in the pipeline of our internal review / discussion > process. That's why I have not it brought up to the TC table yet. > > > Thanks. > > > Regards, > Alex Yiu > > > > Frank Leymann wrote: > >>Alex, >> >>thank your very much, and sorry for causing work because I was a bit terse >>(I promise improvement): That's exactly what I had in mind ;-) >> >>Next is special kind of fault mechanism: Often, the execution of such a >>"for each" does not necessarily fail if some of the spawned activities fail >>but it's o.k. as long as "enough" activities successfully completed (like in >>an RFQ scenario). Explicitly realizing corresponding "N out of M" conditions >>or that like might be cumbersome in BPEL today. >> >> >>Mit besten Grüßen, >>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: Alex Yiu [mailto:alex.yiu@oracle.com] >>Gesendet: Saturday, July 17, 2004 2:33 AM >>An: ygoland@bea.com <mailto:ygoland@bea.com> >>Cc: Frank Leymann; wsbpel@lists.oasis-open.org <mailto:wsbpel@lists.oasis-open.org>; Alex Yiu >>Betreff: 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 <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"; <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. >> >> >> >
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]