OASIS Mailing List ArchivesView the OASIS mailing list archive below
or browse/search using MarkMail.

 


Help: OASIS Mailing Lists Help | MarkMail Help

wsbpel message

[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



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


-----Ursprüngliche Nachricht-----
Von: Alex Yiu [mailto:alex.yiu@oracle.com] 
Gesendet: Saturday, July 17, 2004 2:33 AM
An: ygoland@bea.com
Cc: Frank Leymann; 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

 

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





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]