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: [wsbpel] Issue - 63 - For Each?


If we did introduce break I would expect it to be able to break any 
iterating construct including while, foreach and parallel foreach.

For example:

foreach
    ...
    break
    ...

would be conceptually similar to:

scope
    faultHandlers
       catch faultName="bpel:break"
          empty
       foreach
          ...
          <!-- E.g. break -->
          throw faultName="bpel:break"
          ...

In other words, break would have similar functionality in terms of 
termination behavior as a throw with an implicit scope and an empty 
fault handler but without the implicit negative connotation associated 
with a fault.

I think it will be possible to use break badly, especially in the case 
of parallel for-each. For example, if one has multiple parallel threads 
and each thread is signing on to a remote system, identifying itself, 
making a couple of context set up requests and then making a query, 
having one thread throw a 'break' would mean that the other threads, in 
the middle of the previous sequence and with resources open on the 
destination server, will just disappear without any chance to 'clean 
up'. In such a case it would be better to use a flag that gets checked 
rather than break. But this doesn't mean break is bad, it just means 
that we need to educate users on good usage patterns.

BTW, my use case for wanting break with parallel for-each was provided 
to me yesterday by a BEA engineer, Michael Rowley:

A system receives a message with a list of possible suppliers for a 
part. The system needs to look through the list and find at least one 
supplier with the part, price isn't an issue. The system starts a 
parallel for-each iterating over the suppliers list and sends out 
requests. As soon as a successful response is returned the system will 
break and move on.

Obviously this is just a degenerate case of an or-join, e.g. the type of 
thing the bundles proposal was trying to achieve. Break also provides 
something like the type of 'quit but don't fail' semantics that bundles 
were trying to achieve with their new type of fault. I wonder what 
bundles would look like if break was used.

I suspect, btw, that as far as bundles go, our best path forward is to 
start with parallel for-each (e.g. a really simple proposal) and then 
see what we need to add to it in order to meet the requirements of 
bundles (e.g. start simple and build to complexity).

	Just a thought,

		Yaron


Alex Yiu wrote:

> 
> I just would like to mention that the "break" ability may be better 
> considered in a more general context: e.g. a generalized 
> "complete-condition" in the light of Issue 4 / parallel for-each 
> (another suggestion made by Yaron).
> 
> Regards,
> Alex
> 
> 
> Kristofer Agren wrote:
> 
>>In my opinion, throwing faults to control the normal flow is not the way to
>>go since breaking out a loop is well-defined action and should not be
>>treated as an exception to the process flow.
>>
>>I think introducing a for-each activity is a good idea, but it would be
>>somewhat crippled without a "break" ability. And if we introduce a "break"
>>activity, is there any reason why we would not want to be able to use it
>>with the "while" activity?
>>
>>Thanks,
>>
>>Kristofer
>>
>>-----Original Message-----
>>From: Yaron Y. Goland [mailto:ygoland@bea.com] 
>>Sent: Monday, April 12, 2004 1:57 PM
>>To: Kristofer Agren
>>Cc: wsbpeltc
>>Subject: Re: [wsbpel] Issue - 63 - For Each?
>>
>>Personally I'm o.k. with not introducing a break and instead raising a 
>>fault but I'm pretty open minded on the issue.
>>
>>Kristofer Agren wrote:
>>
>>  
>>
>>>Yaron,
>>>
>>>Thank you for the clarification. When applying the "for-each" construct in
>>>the various structured languages where it is supported, it is also fairly
>>>common to use the "break" construct to discontinue the iteration for some
>>>reason. Without a break action, you would be forced to raise a fault to 
>>>stop
>>>the iteration.
>>>
>>>Thanks,
>>>
>>>Kristofer
>>>
>>>-----Original Message-----
>>>From: Yaron Y. Goland [mailto:ygoland@bea.com]
>>>Sent: Friday, April 09, 2004 5:36 PM
>>>To: Kristofer Agren
>>>Cc: wsbpeltc
>>>Subject: Re: [wsbpel] Issue - 63 - For Each?
>>>
>>>The syntax I proposed is directly adapted from Issue 13. That is where
>>>we introduced an explicit query element and a local override for the
>>>query language specified on the process element.
>>>
>>>        Thanks,
>>>                Yaron
>>>
>>>Kristofer Agren wrote:
>>>
>>> >
>>> >
>>> > Yaron,
>>> >
>>> > I agree with you in that adding a for-each construct, like the one you
>>>have
>>> > detailed, would both be a good way to solve issue 63 and would also
>>> > simplify
>>> > writing BPEL since iterating over a node list is a very common 
>>>scenario. I
>>> > am just curious why you have added the query as a separate element 
>>>and not
>>> > an attribute, like the <from> construct for example, and why not use
>>>    
>>>
>>the
>>  
>>
>>> > query language that can be specified on the <process> element?
>>> >
>>> > Regards,
>>> >
>>> > Kristofer
>>> >
>>> > -----Original Message-----
>>> > From: Yaron Y. Goland [mailto:ygoland@bea.com]
>>> > Sent: Thursday, March 25, 2004 4:17 PM
>>> > To: wsbpeltc
>>> > Subject: [wsbpel] Issue - 63 - For Each?
>>> >
>>> > The following are thoughts I've had on how we could address issue 63.
>>> > Although these thoughts are still fairly rough I wanted to release them
>>> > now because 63 is on the agenda for the F2F. Since these are early
>>> > thoughts I reserve the right to disavow them at any time.
>>> >
>>> > I thought an easy way to provide the feature asked for in 63 is to
>>> > provide a macro that has proven its utility in numerous structured
>>> > languages - For Each.
>>> >
>>> > I was thinking of a syntax like:
>>> > <foreach sourceVariable="ncname" part="ncname"? \
>>> >           iteratorVariableName="ncname" iteratorVariableType="qname"
>>> >           standard-attributes>
>>> >     standard-elements
>>> >     <query language="anyURI">...</query>
>>> >     activity
>>> > </foreach>
>>> >
>>> > The idea is that the query element would be an expression that
>>>    
>>>
>>generates
>>  
>>
>>> > zero or more nodes. Each generated node would be assigned to a local
>>> > variable whose name is given in iteratorVariableName and whose type is
>>> > iteratorVariableType. The foreach would then walk through each node one
>>> > by one in document order. If no nodes are returned then the activity
>>> > would do nothing.
>>> >
>>> > For example:
>>> > foreach sourceVariable="orderManifest" part="somePart"\
>>> >          iteratorVariableName="anOrder" iteratorVariableType="b:ar"
>>> >     query language="http://www.w3.org/TR/1999/REC-xpath-19991116"; <http://www.w3.org/TR/1999/REC-xpath-19991116>
>>> >        ordermanifest/orders
>>> >     ...
>>> >
>>> > Would be a Macro for:
>>> > scope
>>> >     variables
>>> >        variable name="anOrder" type="b:ar"
>>> >        variable name="currentInstanceNum" type="xs:int"
>>> >     sequence
>>> >        assign
>>> >           copy
>>> >              from
>>> >                 "1"
>>> >              to variable="currentInstanceNum"
>>> >        while condition="$currentInstanceNum <=\
>>> >
>>>    
>>>
>>count($orderList/somePart/ordermanifest/orders)"
>>  
>>
>>> >           assign
>>> >              copy
>>> >                 from variable="orderList" part="somePart"
>>> >                    query
>>> >                       "(/ordermanifest/orders)[$currentInstanceNum]"
>>> >                 to variable="anOrder"
>>> >           assign
>>> >              copy
>>> >                from
>>> >                   expression
>>> >                      "$currentInstanceNum+1"
>>> >                to variable="currentInstanceNum"
>>> >           ...
>>> >
>>> > 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]