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