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 6 - Rough draft of proposal for vote


thanks for finding that sentence.  it was sufficiently buried that i 
couldn't pull it out.  however, i never would have inferred serializable 
from that, nor would i recommend it.  but i'll direct my comments to 
your issue when i see it.

Yaron Y. Goland wrote:

> Section 14.3 of the spec states: "An important characteristic of 
> assignment in BPEL4WS is that assignment activities are atomic. If 
> there is any fault during the execution of an assignment activity, the 
> destination variables are left unchanged as they were at the start of 
> the activity. This applies regardless of the number of assignment 
> elements within the overall assignment activity."
>
> I had been interpreting the previous such that atomic implied 
> serializable but that need not necessarily be the case.
>
> My own belief is that if assign's aren't inherently serializable then 
> programmers will kill themselves using BPEL. It is simply asking way 
> too much of programmers to make them understand that if they are 
> manipulating the same variable in two parallel flows that they can run 
> into problems like the one Danny's describes.
>
> In any case, I think this deserves its own issue so I just filed one.
>
>     Yaron
>
> Danny van der Rijn wrote:
>
>>
>>
>> I certainly don't see anything in that section that says that assign is
>> atomic.  And even if it were, in my mind at least, that doesn't speak at
>> all to concurrency.  My example still holds if the assigns are atomic on
>> separate control paths.
>>
>> Assaf Arkin wrote:
>>
>>  > section 14.3.
>>  >
>>  > this is one of those things that has huge implications regardless of
>>  > completion condition. so if it's not clarified properly, got removed
>>  > in one of the edits, etc, it should be added back, regardless of how
>>  > we intend to solve completion conditions.
>>  >
>>  > Assaf
>>  >
>>  > Danny van der Rijn wrote:
>>  >
>>  >> can you point me to a section in the spec?
>>  >>
>>  >> thanks
>>  >> danny
>>  >>
>>  >> Assaf Arkin wrote:
>>  >>
>>  >>> Danny van der Rijn wrote:
>>  >>>
>>  >>>> i apologize for not being more explicit to begin with  but imagine
>>  >>>> the following scenario, based on your example.  to borrow a 
>> phrase,
>>  >>>> this is based on my lay understanding of the spec, and i apologize
>>  >>>> again in advance if this reasoning is incorrect.
>>  >>>>
>>  >>>> - outer scope initializes and sets counter to 0.
>>  >>>> - flow initializes.
>>  >>>> - each of 3 scopes initializes in parallel
>>  >>>> - the ... section of the first 2 scopes completes at the same 
>> time;
>>  >>>> the 3rd one hangs "forever," or for close enough to forever to
>>  >>>> satisfy the forever test.
>>  >>>> - the assigns of the first 2 scopes evaluate the "from" portion
>>  >>>> simultaneously, yielding a value of 1.
>>  >>>> - the "to" portions of the assign happen in some order.  doeesn't
>>  >>>> matter.
>>  >>>
>>  >>>
>>  >>>
>>  >>>
>>  >>> Wouldn't happen, since the assign is atomic.
>>  >>>
>>  >>> Assaf
>>  >>>
>>  >>>
>>  >>>>
>>  >>>> now counter has miscounted, since 2 branches have completed, yet
>>  >>>> only 1 completion is "recorded."
>>  >>>>
>>  >>>> the flow will "never" complete.
>>  >>>>
>>  >>>> this would be solved if the leaf scopes were serializable.  have
>>  >>>> some implicit concurrency control would be the huge advantage IMO,
>>  >>>> of having built-in N of M syntax.  not that i'm necessarily
>>  >>>> advocating that complexity, but i think that if it is a common
>>  >>>> enough use case (which i think is really the crux of the issue)
>>  >>>> then asking people to get this right on their own is giving them
>>  >>>> enough rope to hang themselves, as well as giving them a boy scout
>>  >>>> knot-tying manual.
>>  >>>>
>>  >>>>
>>  >>>>
>>  >>>>
>>  >>>> Yaron Y. Goland wrote:
>>  >>>>
>>  >>>>> What the code implements is a 'at least N out of M'.
>>  >>>>>
>>  >>>>> Generally when we have N out of M scenarios (which are pretty
>>  >>>>> rare, most of our flow + break scenarios tend to be 'first to
>>  >>>>> finish') the goal is to make sure that at least N happens. If 
>> more
>>  >>>>> than N happens that's o.k. too.
>>  >>>>>
>>  >>>>> Put another way, try to imagine a scenario where you want exactly
>>  >>>>> N out of M. Why is 'exactly' important? Heck, what does 'exactly'
>>  >>>>> even mean? My suspicion is that any scenario where 'at least N 
>> out
>>  >>>>> of M' doesn't work requires either full serialization of all the
>>  >>>>> code or 2PC.
>>  >>>>>
>>  >>>>>     Just a guess,
>>  >>>>>
>>  >>>>>         Yaron
>>  >>>>>
>>  >>>>> Danny van der Rijn wrote:
>>  >>>>>
>>  >>>>>>
>>  >>>>>>
>>  >>>>>> in that case, don't you have some serious concurrency issues?
>>  >>>>>>
>>  >>>>>> Yaron Y. Goland wrote:
>>  >>>>>>
>>  >>>>>>  > Actually no. I just meant them as generic wrappers. I could
>>  >>>>>> just as
>>  >>>>>>  > easily have used sequence instead of scope.
>>  >>>>>>  >
>>  >>>>>>  > Danny van der Rijn wrote:
>>  >>>>>>  >
>>  >>>>>>  >>
>>  >>>>>>  >>
>>  >>>>>>  >> i assume that the leaf scopes are serializable and that's 
>> why
>>  >>>>>> they're
>>  >>>>>>  >> there?
>>  >>>>>>  >>
>>  >>>>>>  >> Yaron Y. Goland wrote:
>>  >>>>>>  >>
>>  >>>>>>  >>  > Below is an example of 2 out of 3, it is generalizable
>>  >>>>>> from there.
>>  >>>>>>  >>  >
>>  >>>>>>  >>  > scope
>>  >>>>>>  >>  >    variables
>>  >>>>>>  >>  >       variable name="counter" type="xs:int"
>>  >>>>>>  >>  >    sequence
>>  >>>>>>  >>  >       assign
>>  >>>>>>  >>  >          copy
>>  >>>>>>  >>  >             from literal="true"
>>  >>>>>>  >>  >                "0"
>>  >>>>>>  >>  >             to
>>  >>>>>>  >>  >                $counter
>>  >>>>>>  >>  >       flow
>>  >>>>>>  >>  >          scope
>>  >>>>>>  >>  >             ...
>>  >>>>>>  >>  >             assign
>>  >>>>>>  >>  >                copy
>>  >>>>>>  >>  >                   from
>>  >>>>>>  >>  >                      $counter + 1
>>  >>>>>>  >>  >                   to
>>  >>>>>>  >>  >                      $counter
>>  >>>>>>  >>  >             switch
>>  >>>>>>  >>  >                case
>>  >>>>>>  >>  >                   condition
>>  >>>>>>  >>  >                      $counter >= 2
>>  >>>>>>  >>  >                   break
>>  >>>>>>  >>  >          scope
>>  >>>>>>  >>  >             ...
>>  >>>>>>  >>  >             assign
>>  >>>>>>  >>  >                copy
>>  >>>>>>  >>  >                   from
>>  >>>>>>  >>  >                      $counter + 1
>>  >>>>>>  >>  >                   to
>>  >>>>>>  >>  >                      $counter
>>  >>>>>>  >>  >             switch
>>  >>>>>>  >>  >                case
>>  >>>>>>  >>  >                   condition
>>  >>>>>>  >>  >                      $counter >= 2
>>  >>>>>>  >>  >                   break
>>  >>>>>>  >>  >          scope
>>  >>>>>>  >>  >             ...
>>  >>>>>>  >>  >             assign
>>  >>>>>>  >>  >                copy
>>  >>>>>>  >>  >                   from
>>  >>>>>>  >>  >                      $counter + 1
>>  >>>>>>  >>  >                   to
>>  >>>>>>  >>  >                      $counter
>>  >>>>>>  >>  >             switch
>>  >>>>>>  >>  >                case
>>  >>>>>>  >>  >                   condition
>>  >>>>>>  >>  >                      $counter >= 2
>>  >>>>>>  >>  >                   break
>>  >>>>>>  >>  >
>>  >>>>>>  >>  >
>>  >>>>>>  >>  > Trickovic, Ivana wrote:
>>  >>>>>>  >>  >
>>  >>>>>>  >>  >>
>>  >>>>>>  >>  >>
>>  >>>>>>  >>  >> Yaron,
>>  >>>>>>  >>  >>
>>  >>>>>>  >>  >> Would you illustrate how break activity could be used?
>>  >>>>>> How does it
>>  >>>>>>  >>  >> resolve problems tackled by proposals we have on 
>> table at
>>  >>>>>> the
>>  >>>>>>  >> moment?
>>  >>>>>>  >>  >>
>>  >>>>>>  >>  >> Regards,
>>  >>>>>>  >>  >>
>>  >>>>>>  >>  >> Ivana
>>  >>>>>>  >>  >>
>>  >>>>>>  >>  >>  > -----Original Message-----
>>  >>>>>>  >>  >>  > From: Yaron Y. Goland [mailto:ygoland@bea.com]
>>  >>>>>>  >>  >>  > Sent: Dienstag, 14. September 2004 00:01
>>  >>>>>>  >>  >>  > To: Alex Yiu
>>  >>>>>>  >>  >>  > Cc: Trickovic, Ivana; Axel Martens; Frank Leymann; 
>> Dieter
>>  >>>>>>  >>  >>  > Roller; Dieter
>>  >>>>>>  >>  >>  > Koenig1; edwink@collaxa.com; satisht@microsoft.com;
>>  >>>>>>  >>  >>  > wsbpel@lists.oasis-open.org
>>  >>>>>>  >>  >>  > Subject: Re: [wsbpel] Issue 6 - Rough draft of
>>  >>>>>> proposal for vote
>>  >>>>>>  >>  >>  >
>>  >>>>>>  >>  >>  >
>>  >>>>>>  >>  >>  > I believe that the complexity of the current proposal
>>  >>>>>> is well
>>  >>>>>>  >>  >>  > above the
>>  >>>>>>  >>  >>  > capabilities of what I expect to be the average BPEL
>>  >>>>>> programmer.
>>  >>>>>>  >>  >>  > Completion conditions, ignorable faults, new XPATH
>>  >>>>>> functions,
>>  >>>>>>  >> etc.
>>  >>>>>>  >>  >>  > introduces a lot of complexity that I believe that
>>  >>>>>> average BPEL
>>  >>>>>>  >>  >>  > programmer would not be interested in dealing with.
>>  >>>>>>  >>  >>  >
>>  >>>>>>  >>  >>  > We know from many decades of language experience that
>>  >>>>>> average
>>  >>>>>>  >>  >>  > programmers can deal with break/continue. I know 
>> from at
>>  >>>>>>  >>  >>  > least our own
>>  >>>>>>  >>  >>  > experience at BEA that users can deal with the 
>> concept
>>  >>>>>> of a
>>  >>>>>>  >>  >>  > flow where a
>>  >>>>>>  >>  >>  > break in the flow results in the other members of the
>>  >>>>>> flow being
>>  >>>>>>  >>  >>  > terminated in the BPEL meaning of the term.
>>  >>>>>>  >>  >>  >
>>  >>>>>>  >>  >>  > Defining a break activity and specifying that if 
>> break
>>  >>>>>> is used
>>  >>>>>>  >> in the
>>  >>>>>>  >>  >>  > context of flow then this means that the flow 
>> activity
>>  >>>>>> ends
>>  >>>>>>  >> and any
>>  >>>>>>  >>  >>  > uncompleted members of the flow are terminated would
>>  >>>>>> both fit
>>  >>>>>>  >>  >>  > directly
>>  >>>>>>  >>  >>  > into BPEL's existing syntax and semantics and I
>>  >>>>>> believe be
>>  >>>>>>  >>  >>  > simple enough
>>  >>>>>>  >>  >>  > that the average programmer can handle it. I would
>>  >>>>>> therefore
>>  >>>>>>  >>  >>  > offer break
>>  >>>>>>  >>  >>  > (and it's relative 'continue') as an alternative.
>>  >>>>>>  >>  >>  >
>>  >>>>>>  >>  >>  >       Thanks,
>>  >>>>>>  >>  >>  >
>>  >>>>>>  >>  >>  >               Yaron
>>  >>>>>>  >>  >>  >
>>  >>>>>>  >>  >>  > Alex Yiu wrote:
>>  >>>>>>  >>  >>  >
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > > Hi,
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > > Ivana, thanks for sending out this proposal.
>>  >>>>>>  >>  >>  > > I believe a number of us (including me) like the
>>  >>>>>>  >>  >>  > <completionConditon>
>>  >>>>>>  >>  >>  > > construct from your proposal high level speaking.
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > > After reading the proposal, I guess we need to work
>>  >>>>>> on a
>>  >>>>>>  >> number of
>>  >>>>>>  >>  >>  > > details. I would like to ask a few questions /
>>  >>>>>> mention a few
>>  >>>>>>  >>  >> points:
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     * Minor syntax and semantics questions :
>>  >>>>>>  >>  >>  > >           o Do we want to allow expression for 
>> branch
>>  >>>>>>  >>  >>  > attribute? instead
>>  >>>>>>  >>  >>  > >             of just a constant integer?
>>  >>>>>>  >>  >>  > >           o We may need to some minor syntax
>>  >>>>>> adjustment for
>>  >>>>>>  >>  >>  > expression
>>  >>>>>>  >>  >>  > >             attribute because we have passed Isseu
>>  >>>>>> 13 already.
>>  >>>>>>  >>  >>  > >           o If answers to the above question are
>>  >>>>>> yes, then
>>  >>>>>>  >>  >>  > the condition
>>  >>>>>>  >>  >>  > >             syntax may become a choice (xsd:choice)
>>  >>>>>> of the
>>  >>>>>>  >>  >>  > following two:
>>  >>>>>>  >>  >>  > >             <condition
>>  >>>>>>  >>  >>  > >             >
>>  >>>>>>  >>  >> 
>> expressionLanguage="anyURI"?>boolean-expression</condition>
>>  >>>>>>  >>  >>  > >             <branchCondition
>>  >>>>>>  >>  >>  > >             >
>>  >>>>>>  >>  >> 
>> expressionLanguage="anyURI"?>integer-expression</condition>
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     * About completionConditionFailure : it looks
>>  >>>>>> like a
>>  >>>>>>  >>  >>  > nice idea so
>>  >>>>>>  >>  >>  > >       far ...
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     * About the new "isCompleted()" function :  
>> I am
>>  >>>>>> not
>>  >>>>>>  >>  >>  > against this
>>  >>>>>>  >>  >>  > >       function. But, I tend to think there are
>>  >>>>>> usually BPEL
>>  >>>>>>  >>  >>  > variables
>>  >>>>>>  >>  >>  > >       being modifed as the execution result of a 
>> flow
>>  >>>>>>  >>  >>  > activity. (See the
>>  >>>>>>  >>  >>  > >       train-or-plane-and-hotel example). Is it more
>>  >>>>>> typical
>>  >>>>>>  >> to have
>>  >>>>>>  >>  >>  > >       completionCondition to be evaluated on those
>>  >>>>>> variables?
>>  >>>>>>  >>  >>  > >       Also, after the completion of the whole flow,
>>  >>>>>> it is
>>  >>>>>>  >>  >>  > not uncommon
>>  >>>>>>  >>  >>  > >       for people to have logic to find out which
>>  >>>>>> branch is
>>  >>>>>>  >> finished
>>  >>>>>>  >>  >>  > >       (especially when "or" is involved in the
>>  >>>>>> condition). The
>>  >>>>>>  >>  >>  > >       "isComplete()" function would be available
>>  >>>>>> only within
>>  >>>>>>  >> the
>>  >>>>>>  >>  >>  > >       completionCondition within the flow. People
>>  >>>>>> may get
>>  >>>>>>  >>  >>  > confused and
>>  >>>>>>  >>  >>  > >       attempt to use the "isComplete()" function
>>  >>>>>> outside
>>  >>>>>>  >>  >>  > the flow. If
>>  >>>>>>  >>  >>  > >       the completionCondition relies on variables,
>>  >>>>>> the same
>>  >>>>>>  >>  >> logic is
>>  >>>>>>  >>  >>  > >       applicable outside of the flow.
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     * About the IgnoreFault semantics: I recall 
>> this
>>  >>>>>>  >>  >>  > ignoreFault idea
>>  >>>>>>  >>  >>  > >       back to March F2F. With ignoreFault 
>> semantics, it
>>  >>>>>>  >> essentially
>>  >>>>>>  >>  >>  > >       introduces two brand new semantics.
>>  >>>>>>  >>  >>  > >           o It turns <flow> into a semi-<scope> 
>> like
>>  >>>>>> construct
>>  >>>>>>  >>  >>  > >           o It adds this new "ignoreFault"
>>  >>>>>> semantics: which
>>  >>>>>>  >> catches
>>  >>>>>>  >>  >>  > >             certain fault and the catching action
>>  >>>>>> will not
>>  >>>>>>  >> cause
>>  >>>>>>  >>  >> any
>>  >>>>>>  >>  >>  > >             scope to be marked as faulted.
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     I tend to think this "ignoreFault" 
>> functionality
>>  >>>>>> has
>>  >>>>>>  >>  >>  > quite a heavy
>>  >>>>>>  >>  >>  > >     weight impact to <flow> and fault handling
>>  >>>>>> picture in
>>  >>>>>>  >>  >>  > BPEL. If there
>>  >>>>>>  >>  >>  > >     is an alternative way to achieve similar 
>> business
>>  >>>>>>  >>  >>  > logic, I would go
>>  >>>>>>  >>  >>  > >     for the alternative way.
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     Quoted from Ivana's email:
>>  >>>>>>  >>  >>  > >     " Not all activities must complete in order the
>>  >>>>>>  >> enclosing flow
>>  >>>>>>  >>  >>  > >     activity to complete. The way to identify 
>> that an
>>  >>>>>>  >>  >>  > enclosed activity
>>  >>>>>>  >>  >>  > >     did not complete is to propagate faults. "
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     I agree with the first sentence. But, I am 
>> not sure
>>  >>>>>>  >>  >>  > that propagating
>>  >>>>>>  >>  >>  > >     fault is the only way to identify an enclosed
>>  >>>>>> activity
>>  >>>>>>  >> did not
>>  >>>>>>  >>  >>  > >     complete. I would rather use a scope as an 
>> activity
>>  >>>>>>  >> enclosed by
>>  >>>>>>  >>  >>  > >     flow. If we wish to suppress any minor fault 
>> which
>>  >>>>>>  >>  >>  > happens during
>>  >>>>>>  >>  >>  > >     the execution of the scope, then we can just 
>> add a
>>  >>>>>>  >>  >>  > fault handler. If
>>  >>>>>>  >>  >>  > >     the fault that happen, the scope will be 
>> marked as
>>  >>>>>>  >> "faulted".
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     The completeConditon can identify the
>>  >>>>>> "incomplete" state
>>  >>>>>>  >> of the
>>  >>>>>>  >>  >>  > >     scope by two ways:
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >         * completeCondition can be evaluated based
>>  >>>>>> on BPEL
>>  >>>>>>  >>  >>  > variables,
>>  >>>>>>  >>  >>  > >           which are set to "incomplete" state by
>>  >>>>>> pre-flow
>>  >>>>>>  >>  >>  > initialization
>>  >>>>>>  >>  >>  > >           or related fault-handler logic.
>>  >>>>>>  >>  >>  > >         * branch-based condition will interprete a
>>  >>>>>> faulted
>>  >>>>>>  >> scope as
>>  >>>>>>  >>  >>  > >           "incomplete" branch and will not count
>>  >>>>>> them into
>>  >>>>>>  >>  >>  > the required
>>  >>>>>>  >>  >>  > >           N branches.
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     This will allow us to suppress minor fault 
>> with or
>>  >>>>>>  >> without the
>>  >>>>>>  >>  >>  > >     <completionCondition> construct. Please see the
>>  >>>>>>  >>  >>  > following example.
>>  >>>>>>  >>  >>  > >     It is already legal and working today. It shows
>>  >>>>>> how to
>>  >>>>>>  >> suppress
>>  >>>>>>  >>  >>  > >     "foo:barFault" without the <completeCondition>
>>  >>>>>> construct
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     <flow>
>>  >>>>>>  >>  >>  > >        <scope name="A">
>>  >>>>>>  >>  >>  > >           <faultHandler>
>>  >>>>>>  >>  >>  > >              <catch faultName="foo:barFault" ... >
>>  >>>>>> ... </catch>
>>  >>>>>>  >>  >>  > >           </faultHandler>
>>  >>>>>>  >>  >>  > >           <sequence>
>>  >>>>>>  >>  >>  > >              ...  <invoke name="doA" ... /> ...
>>  >>>>>>  >>  >>  > >           </sequence>
>>  >>>>>>  >>  >>  > >        </scope>
>>  >>>>>>  >>  >>  > >        <scope name="B"> ... <!-- similar to A -->
>>  >>>>>> ... </scope>
>>  >>>>>>  >>  >>  > >     </flow>
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     If the invoke of "doA" triggers 
>> "foo:barFault", the
>>  >>>>>>  >>  >>  > scope "A" will
>>  >>>>>>  >>  >>  > >     be marked as faulted. On the other hand, scope
>>  >>>>>> "B" will
>>  >>>>>>  >>  >>  > be allowed
>>  >>>>>>  >>  >>  > >     to continue and complete. After scope "B" is
>>  >>>>>> completed, the
>>  >>>>>>  >>  >>  > >     compensation handler of scope "B" will be
>>  >>>>>> installed.
>>  >>>>>>  >> And, the
>>  >>>>>>  >>  >>  > >     overall execution of flow is still considered a
>>  >>>>>> normal
>>  >>>>>>  >>  >>  > completion.
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     I hope I have illustrated we can achieve 
>> similar
>>  >>>>>> logic
>>  >>>>>>  >> without
>>  >>>>>>  >>  >>  > >     introducing a new "ignoreFault" construct and
>>  >>>>>> concept to
>>  >>>>>>  >> BPEL.
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     What "completionCondition" does should be just
>>  >>>>>>  >>  >>  > providing a way to
>>  >>>>>>  >>  >>  > >     pro-actively cancel/terminate other flows 
>> without
>>  >>>>>>  >>  >>  > waiting to them to
>>  >>>>>>  >>  >>  > >     complete or to be faulted.
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >     * About "Cancel-other-flows":   (Let me
>>  >>>>>> consolidate what
>>  >>>>>>  >> I am
>>  >>>>>>  >>  >>  > >       leaning towards so far.) We need to formal
>>  >>>>>> define the
>>  >>>>>>  >>  >>  > notion of a
>>  >>>>>>  >>  >>  > >       " cancel-other-flows " mechanism. This
>>  >>>>>> mechanism is
>>  >>>>>>  >>  >>  > specified and
>>  >>>>>>  >>  >>  > >       attached to <flow> construct (and future
>>  >>>>>> parallel forEach
>>  >>>>>>  >>  >>  > >       construct).  When this mechanism is triggered
>>  >>>>>> by one
>>  >>>>>>  >>  >>  > of parallel
>>  >>>>>>  >>  >>  > >       flows, it will cancel/terminate other 
>> parallel
>>  >>>>>> flows
>>  >>>>>>  >> which
>>  >>>>>>  >>  >> are
>>  >>>>>>  >>  >>  > >       still running, after the triggering flow is
>>  >>>>>> completed.
>>  >>>>>>  >> If the
>>  >>>>>>  >>  >>  > >       other flow activties are scope activities, 
>> the
>>  >>>>>> scope
>>  >>>>>>  >> will be
>>  >>>>>>  >>  >>  > >       marked as cancelled.
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >       This mechanism will be triggered upon the
>>  >>>>>>  >>  >>  > completionCondition is
>>  >>>>>>  >>  >>  > >       evaluated to be true.
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >       [Note: (a) since this mechanism is 
>> triggered by
>>  >>>>>>  >>  >>  > without using any
>>  >>>>>>  >>  >>  > >       fault directly. This will again decrease the
>>  >>>>>> need of
>>  >>>>>>  >>  >>  > "ignoreFault"
>>  >>>>>>  >>  >>  > >       construct (b) This mechanism will affect the
>>  >>>>>> wordings
>>  >>>>>>  >>  >>  > of Issue 135
>>  >>>>>>  >>  >>  > >       to an extent.]
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >       [Question: again, should we enforce 
>> scope-only
>>  >>>>>>  >> activity when
>>  >>>>>>  >>  >>  > >       completionCondition is used? I tend to say 
>> yes.]
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > > Thank you all for following and reading this email
>>  >>>>>> thread!!!
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > > Regards,
>>  >>>>>>  >>  >>  > > Alex Yiu
>>  >>>>>>  >>  >>  > >  > >
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > > Trickovic, Ivana wrote:
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> Here is a proposal for the completion condition 
>> - it
>>  >>>>>>  >>  >>  > addresses some
>>  >>>>>>  >>  >>  > >> issues not tackled so far (at least not in case of
>>  >>>>>>  >>  >>  > >> <completeCondition>). It is a version of the
>>  >>>>>> proposal for
>>  >>>>>>  >>  >>  > completion
>>  >>>>>>  >>  >>  > >> condition for the bundle element. This proposal
>>  >>>>>> includes
>>  >>>>>>  >>  >>  > comments from
>>  >>>>>>  >>  >>  > >> many people including Frank Leymann, Dieter 
>> Koenig,
>>  >>>>>> Dieter
>>  >>>>>>  >>  >>  > Roller and
>>  >>>>>>  >>  >>  > >> Satish Thatte. It does not mean that they 
>> completely
>>  >>>>>>  >> support the
>>  >>>>>>  >>  >>  > >> proposal - they may have issues with any part of
>>  >>>>>> the proposal.
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> Completion condition
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> =====================
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> The current semantics of the flow activity is 
>> that it
>>  >>>>>>  >>  >>  > waits for all
>>  >>>>>>  >>  >>  > >> concurrent activities to complete. The 
>> completion also
>>  >>>>>>  >>  >>  > means that an
>>  >>>>>>  >>  >>  > >> enclosed activity/scope may end abnormally or be
>>  >>>>>> skipped
>>  >>>>>>  >> (e.g. the
>>  >>>>>>  >>  >>  > >> join condition of the activity evaluated to 
>> false).
>>  >>>>>> If a
>>  >>>>>>  >> fault is
>>  >>>>>>  >>  >>  > >> thrown within an enclosed activity/scope and 
>> one of
>>  >>>>>> the
>>  >>>>>>  >>  >>  > local fault
>>  >>>>>>  >>  >>  > >> handlers catch the fault (and does not rethrow the
>>  >>>>>> fault), the
>>  >>>>>>  >>  >>  > >> enclosed activity/scope will be deemed to be 
>> completed
>>  >>>>>>  >>  >>  > (although ended
>>  >>>>>>  >>  >>  > >> abnormally). If a fault is not caught by any local
>>  >>>>>> fault
>>  >>>>>>  >>  >>  > handler (or
>>  >>>>>>  >>  >>  > >> is rethrown) the flow activity will terminate all
>>  >>>>>> active
>>  >>>>>>  >>  >>  > concurrent
>>  >>>>>>  >>  >>  > >> activities and corresponding fault handler may be
>>  >>>>>> initiated.
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> A completion condition for the flow activity is
>>  >>>>>> needed for
>>  >>>>>>  >>  >>  > scenarios
>>  >>>>>>  >>  >>  > >> where not all concurrent activities of a flow 
>> activity
>>  >>>>>>  >>  >>  > must complete
>>  >>>>>>  >>  >>  > >> in order the flow activity to complete. Note: We
>>  >>>>>> are not
>>  >>>>>>  >>  >>  > talking about
>>  >>>>>>  >>  >>  > >> "successful completion" of enclosed concurrent
>>  >>>>>> activities
>>  >>>>>>  >>  >>  > because that
>>  >>>>>>  >>  >>  > >> would not be consistent with the semantics of the
>>  >>>>>> current
>>  >>>>>>  >>  >>  > flow activity.
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> The completion condition may have different
>>  >>>>>> flavors, such as:
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> (1) N out of M
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> (2) The two most important requests completed
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> (3) A Boolean condition operating upon process
>>  >>>>>> variables
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> Not all activities must complete in order the
>>  >>>>>> enclosing
>>  >>>>>>  >>  >>  > flow activity
>>  >>>>>>  >>  >>  > >> to complete. The way to identify that an enclosed
>>  >>>>>> activity
>>  >>>>>>  >> did not
>>  >>>>>>  >>  >>  > >> complete is to propagate faults. We may 
>> distinguish
>>  >>>>>> between
>>  >>>>>>  >> severe
>>  >>>>>>  >>  >>  > >> faults and those that can be ignored. Severe 
>> faults
>>  >>>>>> cause the
>>  >>>>>>  >>  >>  > >> enclosing flow activity (or more precisely, 
>> enclosing
>>  >>>>>>  >> scope) to
>>  >>>>>>  >>  >>  > >> terminate the flow activity, including all active
>>  >>>>>> concurrent
>>  >>>>>>  >>  >>  > >> activities, and corresponding fault handler may be
>>  >>>>>>  >>  >>  > initiated. Other
>>  >>>>>>  >>  >>  > >> faults may be ignored - the flow activity is
>>  >>>>>> "informed" that a
>>  >>>>>>  >>  >>  > >> concurrent activity did not complete but still
>>  >>>>>> allows other
>>  >>>>>>  >> active
>>  >>>>>>  >>  >>  > >> concurrent activities to continue with execution.
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> Ignore semantics
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> =================
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> Faults thrown within enclosed concurrent
>>  >>>>>> activities/scopes
>>  >>>>>>  >> and not
>>  >>>>>>  >>  >>  > >> handled by local fault handlers are rethrown.
>>  >>>>>> Enclosing
>>  >>>>>>  >>  >>  > <flow> element
>>  >>>>>>  >>  >>  > >> decides which of these rethrown faults can be
>>  >>>>>> ignored. This
>>  >>>>>>  >> new
>>  >>>>>>  >>  >>  > >> "ignore" semantics should be part of the 
>> completion
>>  >>>>>>  >> condition and
>>  >>>>>>  >>  >>  > >> should apply to all enclosed activities. This new
>>  >>>>>>  >>  >>  > semantics does not
>>  >>>>>>  >>  >>  > >> introduce a new fault handling mechanism. It is
>>  >>>>>> needed for
>>  >>>>>>  >>  >>  > identifying
>>  >>>>>>  >>  >>  > >> how many of the enclosed activities failed.
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> Proposed syntax
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> ================
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> <flow standard-attributes>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>    standard-elements
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>    <completionCondition/>?
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>    <links>?
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>       <link name="ncname">+
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>    </links>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>    activity+
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> </flow>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> <completionCondition>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>    <conditions branch="xsd:integer"?
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>                expression=xpath?/>?
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>    <ignoreFaults>?
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>       <fault name="qname"? value="ncname"?/>*
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>       <ignoreAll/>?
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>    </ignoreFaults>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> </completionCondition>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> Attribute branch is used to specify a condition of
>>  >>>>>> flavor
>>  >>>>>>  >>  >>  > "wait for
>>  >>>>>>  >>  >>  > >> /N/ out of /M/ activities to complete", or more
>>  >>>>>> precisely
>>  >>>>>>  >> value N.
>>  >>>>>>  >>  >>  > >> Attribute expression is used to specify a Boolean
>>  >>>>>>  >>  >>  > condition operating
>>  >>>>>>  >>  >>  > >> upon process variables or a condition of flavor
>>  >>>>>> "the two most
>>  >>>>>>  >>  >>  > >> important requests completed".
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> Both conditions ( branch and expression) may be
>>  >>>>>> specified
>>  >>>>>>  >>  >>  > at the same
>>  >>>>>>  >>  >>  > >> time. They will be checked when one instance of 
>> the
>>  >>>>>> scope
>>  >>>>>>  >> activity
>>  >>>>>>  >>  >>  > >> reaches the end. If at least one condition
>>  >>>>>> evaluates to
>>  >>>>>>  >> true all
>>  >>>>>>  >>  >>  > >> active instances will be terminated.
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> Element <ignoreFaults> specifies faults that 
>> may be
>>  >>>>>>  >>  >>  > ignored. Element
>>  >>>>>>  >>  >>  > >> fault is used to specify a fault which may be 
>> ignored
>>  >>>>>>  >>  >>  > (fault name and
>>  >>>>>>  >>  >>  > >> fault data may be specified). Element <ignoreAll>
>>  >>>>>> would
>>  >>>>>>  >>  >>  > mean that all
>>  >>>>>>  >>  >>  > >> faults thrown/rethrown by any concurrent
>>  >>>>>> activity/scope may be
>>  >>>>>>  >>  >>  > >> ignored. If this element is specified <fault>
>>  >>>>>> element must
>>  >>>>>>  >>  >>  > be omitted.
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> Completion condition failure
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> =============================
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> A new standard fault, e.g. 
>> completionConditionFailure,
>>  >>>>>>  >> should be
>>  >>>>>>  >>  >>  > >> introduced to notify that the completion condition
>>  >>>>>> of a
>>  >>>>>>  >>  >>  > flow activity
>>  >>>>>>  >>  >>  > >> evaluated to false (note: all concurrent 
>> activities
>>  >>>>>> have been
>>  >>>>>>  >>  >>  > >> completed). The fault is thrown in the scope
>>  >>>>>> enclosing the
>>  >>>>>>  >>  >>  > flow element.
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> Completion condition and links
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> ==============================
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> There should be no difference between a flow
>>  >>>>>> activity with a
>>  >>>>>>  >>  >>  > >> completion condition and a flow activity without
>>  >>>>>>  >>  >>  > completion condition.
>>  >>>>>>  >>  >>  > >> For example, if the completion condition fails all
>>  >>>>>> links
>>  >>>>>>  >>  >>  > leaving the
>>  >>>>>>  >>  >>  > >> flow activity should have value "false" (or be
>>  >>>>>> reverted to
>>  >>>>>>  >>  >>  > a negative
>>  >>>>>>  >>  >>  > >> status).
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> There are just a few additional rules:
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> (1) Let's assume enclosed activity A is the source
>>  >>>>>> of a
>>  >>>>>>  >>  >>  > link. If the
>>  >>>>>>  >>  >>  > >> completion condition evaluates to true and 
>> activity
>>  >>>>>> A is
>>  >>>>>>  >>  >>  > not completed
>>  >>>>>>  >>  >>  > >> it will be terminated and the value of the link
>>  >>>>>> will be
>>  >>>>>>  >>  >>  > set to "false".
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> (2) Let's assume enclosed activity A is the source
>>  >>>>>> of a
>>  >>>>>>  >>  >>  > link and the
>>  >>>>>>  >>  >>  > >> activity failed but the fault is "ignored" by the
>>  >>>>>> enclosing
>>  >>>>>>  >> flow
>>  >>>>>>  >>  >>  > >> activity. The value of the link will be set to
>>  >>>>>> "false".
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> New function for completion condition of flavor
>>  >>>>>> "the two most
>>  >>>>>>  >>  >>  > >> important requests completed"
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  >
>>  >>>>>> ==============================================================
>>  >>>>>>  >>  >>  > ==============================
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >> For completion conditions of flavor "the two most
>>  >>>>>>  >>  >>  > important requests
>>  >>>>>>  >>  >>  > >> completed" standard attribute "name" must be
>>  >>>>>> specified for all
>>  >>>>>>  >>  >>  > >> enclosing activities in order to be able to
>>  >>>>>> distinguish
>>  >>>>>>  >> them. In
>>  >>>>>>  >>  >>  > >> addition a new function, e.g.
>>  >>>>>> isCompleted('activityName')
>>  >>>>>>  >> must be
>>  >>>>>>  >>  >>  > >> introduced. The semantics of the function is: if
>>  >>>>>> activity
>>  >>>>>>  >>  >>  > completed
>>  >>>>>>  >>  >>  > >> successfully the function returns value true.
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> Example
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>     <completionCondition expression=
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>            "isCompleted('A') AND
>>  >>>>>> isCompleted('B')"         >> > >>
>>  >>>>>>  >>  >>  > >>      </completionConditions>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> Regards,
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >> Ivana
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>  > >>
>>  >>>>>>  >>  >>  > >>     -----Original Message-----
>>  >>>>>>  >>  >>  > >>     *From:* Alex Yiu [mailto:alex.yiu@oracle.com]
>>  >>>>>>  >>  >>  > >>     *Sent:* Samstag, 11. September 2004 00:49
>>  >>>>>>  >>  >>  > >>     *To:* Axel Martens
>>  >>>>>>  >>  >>  > >>     *Cc:* 'edwink@collaxa.com
>>  >>>>>>  >>  >>  > <mailto:edwink@collaxa.com>'; Trickovic,
>>  >>>>>>  >>  >>  > >>     Ivana; 'satisht@microsoft.com
>>  >>>>>>  >> <mailto:satisht@microsoft.com>';
>>  >>>>>>  >>  >>  > >>     'wsbpel@lists.oasis-open.org
>>  >>>>>>  >>  >>  > >>     <mailto:wsbpel@lists.oasis-open.org>'; Alex 
>> Yiu
>>  >>>>>>  >>  >>  > >>     *Subject:* Re: [wsbpel] Issue 6 - Rough 
>> draft of
>>  >>>>>>  >>  >>  > proposal for vote
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>     Hi, Axel,
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>     Thanks for liking parts of my proposal so far.
>>  >>>>>>  >>  >>  > >>     Actually, the idea of my proposal is borrowed
>>  >>>>>> from a
>>  >>>>>>  >> part of
>>  >>>>>>  >>  >>  > >>     presentation from Ivana and Dieter Roller in
>>  >>>>>> March F2F.
>>  >>>>>>  >> I just
>>  >>>>>>  >>  >>  > >>     generalize it to apply to <flow> also.
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>     About using links or not:
>>  >>>>>>  >>  >>  > >>     I don't have a huge opposition to Axel's 
>> proposal
>>  >>>>>>  >>  >>  > which enriches
>>  >>>>>>  >>  >>  > >>     the semantics of joinCondition evaluation.
>>  >>>>>> However, it
>>  >>>>>>  >>  >>  > is not that
>>  >>>>>>  >>  >>  > >>     difficult for people to make mistakes in
>>  >>>>>> joinCondition.
>>  >>>>>>  >>  >> Look at
>>  >>>>>>  >>  >>  > >>     the 2-out-of-3 example. The join condition
>>  >>>>>> already gets so
>>  >>>>>>  >>  >>  > >>     complicated. If people make a mistake in their
>>  >>>>>>  >>  >>  > joinCondition, the
>>  >>>>>>  >>  >>  > >>     whole flow can get struck for no good reasons.
>>  >>>>>> (The
>>  >>>>>>  >>  >>  > >>     completeCondition approach will less likely to
>>  >>>>>> have
>>  >>>>>>  >>  >>  > the whole flow
>>  >>>>>>  >>  >>  > >>     struck. Because, it does not introduce a new
>>  >>>>>> parallel
>>  >>>>>>  >>  >>  > activity in
>>  >>>>>>  >>  >>  > >>     the flow). But, if this is what
>>  >>>>>> Petri-net-oriented and
>>  >>>>>>  >>  >>  > >>     control-link-oriented audience really want, 
>> I can
>>  >>>>>>  >>  >>  > accept it in a
>>  >>>>>>  >>  >>  > >>     sense, as long as this is not the only way to
>>  >>>>>> achieve
>>  >>>>>>  >> similar
>>  >>>>>>  >>  >>  > >>     business logic.
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>     About static vs dynamic parallelism:
>>  >>>>>>  >>  >>  > >>     Static parallelism is basically <flow>
>>  >>>>>> construct in
>>  >>>>>>  >>  >>  > BPEL. Dynamic
>>  >>>>>>  >>  >>  > >>     parallelism is "parallel forEach" or "bundle".
>>  >>>>>> Issue 4
>>  >>>>>>  >>  >>  > and 147 are
>>  >>>>>>  >>  >>  > >>     related issues.
>>  >>>>>>  >>  >>  > >>     >
>>  >>>>>>  >>  >>
>>  >>>>>> 
>> http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue4
>>  >>>>>>  >>  >>  > >>     >
>>  >>>>>>  >>  >>
>>  >>>>>> 
>> http://www.choreology.com/external/WS_BPEL_issues_list.html#Issue147
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>     About "Terminating still running tasks versus
>>  >>>>>>  >> proceeding in
>>  >>>>>>  >>  >>  > >>     control flow while those tasks are
>>  >>>>>>  >>  >>  > >>     still running":
>>  >>>>>>  >>  >>  > >>     I am not 100% that I understand your question.
>>  >>>>>> Let me
>>  >>>>>>  >> try to
>>  >>>>>>  >>  >>  > >>     answer it anyway. The completeCondition is 
>> about
>>  >>>>>>  >> triggering
>>  >>>>>>  >>  >>  > >>     termination of still-running tasks. The
>>  >>>>>> "proceeding in
>>  >>>>>>  >> control
>>  >>>>>>  >>  >>  > >>     flow" (if I understand you correctly) will be
>>  >>>>>> handled
>>  >>>>>>  >>  >>  > by an outter
>>  >>>>>>  >>  >>  > >>     flow. [I guess it is related to (hotel and
>>  >>>>>> (train or
>>  >>>>>>  >>  >>  > plane)) flow??]
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>     About changes of "forcedTermination" fault
>>  >>>>>> handler:
>>  >>>>>>  >>  >>  > >>     If you got a chance to see some recent emails
>>  >>>>>> on Issue
>>  >>>>>>  >>  >>  > 135, Satish
>>  >>>>>>  >>  >>  > >>     has recently suggested to remove the notion
>>  >>>>>>  >>  >> "forcedTermination"
>>  >>>>>>  >>  >>  > >>     fault and replace its fault handler with
>>  >>>>>> cancelHandler.
>>  >>>>>>  >> Frank,
>>  >>>>>>  >>  >>  > >>     Yaron, Edwin and I all agree with this
>>  >>>>>> direction. Because,
>>  >>>>>>  >>  >>  > >>     overloading fault with the concept of
>>  >>>>>>  >> "forcedTermination" is a
>>  >>>>>>  >>  >>  > >>     "false economy" and it creates quite a bit of
>>  >>>>>>  >>  >>  > unnecessary confusion.
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>     I don't think we should go back to this route
>>  >>>>>> or even
>>  >>>>>>  >> further
>>  >>>>>>  >>  >>  > >>     overload the "forcedTermination" fault handler
>>  >>>>>>  >>  >>  > semantics. Because,
>>  >>>>>>  >>  >>  > >>     fault handling is way too generic and the
>>  >>>>>> changes you
>>  >>>>>>  >>  >> mentioned
>>  >>>>>>  >>  >>  > >>     will create even more confusion. (e.g. Will 
>> this
>>  >>>>>>  >>  >>  > change of marking
>>  >>>>>>  >>  >>  > >>     as "completed" apply to all 
>> "forcedTermination"
>>  >>>>>> fault
>>  >>>>>>  >>  >> handler /
>>  >>>>>>  >>  >>  > >>     cancel handler of all scopes? )
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>     I guess most of us agree that we should 
>> have a new
>>  >>>>>>  >>  >> mechanism to
>>  >>>>>>  >>  >>  > >>     kill / do an early completion of a flow in a
>>  >>>>>> nice and
>>  >>>>>>  >>  >>  > clean way.
>>  >>>>>>  >>  >>  > >>     However, overloading a standard fault handler
>>  >>>>>> does not
>>  >>>>>>  >>  >>  > seem to be
>>  >>>>>>  >>  >>  > >>     the best one. I would rather introduce a 
>> construct
>>  >>>>>>  >>  >>  > which is very
>>  >>>>>>  >>  >>  > >>     specific to <flow> or parallel-forEach. For
>>  >>>>>> example, this
>>  >>>>>>  >>  >>  > >>     <completeCondition> construct or maybe a new
>>  >>>>>> activity
>>  >>>>>>  >> called
>>  >>>>>>  >>  >>  > >>     <completeFlow />.  I will send out more 
>> emails on
>>  >>>>>>  >>  >>  > joint thinking
>>  >>>>>>  >>  >>  > >>     of both Issue 6 and Issue 135.  Please stay 
>> tuned.
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>     Thanks!
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>     Regards,
>>  >>>>>>  >>  >>  > >>     Alex Yiu
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>     Axel Martens wrote:
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Hi,
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     I like the simplicity of the syntax of Alex's
>>  >>>>>>  >>  >>  > proposal. Although,
>>  >>>>>>  >>  >>  > >>>     for me it is quite easy to model in terms of
>>  >>>>>> links and
>>  >>>>>>  >> join
>>  >>>>>>  >>  >>  > >>>     conditions, and I want to keep my proposal 
>> alive
>>  >>>>>>  >>  >>  > (because of the
>>  >>>>>>  >>  >>  > >>>     minimal changes to BPEL's syntax and
>>  >>>>>> semantics), it
>>  >>>>>>  >>  >>  > looks like a
>>  >>>>>>  >>  >>  > >>>     nice macro to provide more convenience to the
>>  >>>>>> customers.
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Alex, could you shortly explain to me, 
>> what do
>>  >>>>>> you
>>  >>>>>>  >>  >>  > mean by static
>>  >>>>>>  >>  >>  > >>>     and dynamic parallelism? How do you handle 
>> the
>>  >>>>>> two
>>  >>>>>>  >>  >>  > different cases
>>  >>>>>>  >>  >>  > >>>     after evaluating the completeCondition:
>>  >>>>>> Terminating
>>  >>>>>>  >>  >>  > still running
>>  >>>>>>  >>  >>  > >>>     tasks versus proceeding in control flow while
>>  >>>>>> those
>>  >>>>>>  >> tasks are
>>  >>>>>>  >>  >>  > >>>     still running (Sorry, I missed your previous
>>  >>>>>> emails)?
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     I agree to Alex's opinion, that we need a
>>  >>>>>> mechanism to
>>  >>>>>>  >> kill
>>  >>>>>>  >>  >>  > >>>     parallel flow nice and clean. This could 
>> be done
>>  >>>>>>  >>  >>  > either by a new
>>  >>>>>>  >>  >>  > >>>     mechanism which does not throw a fault or by
>>  >>>>>> changing
>>  >>>>>>  >> the way
>>  >>>>>>  >>  >>  > >>>     fault are handled. I have discussed 
>> already an
>>  >>>>>> example
>>  >>>>>>  >> of the
>>  >>>>>>  >>  >>  > >>>     second case with Ivana, and I like to tell
>>  >>>>>> you, what I
>>  >>>>>>  >>  >> have in
>>  >>>>>>  >>  >>  > >>>     mind. Look at the following example:
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     <scope name="scopeFlow">
>>  >>>>>>  >>  >>  > >>>       ...
>>  >>>>>>  >>  >>  > >>>       <flow>
>>  >>>>>>  >>  >>  > >>>         <link name="linkA"/>
>>  >>>>>>  >>  >>  > >>>         <link name="linkB"/>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>         <scope name="scopeA">
>>  >>>>>>  >>  >>  > >>>           ...
>>  >>>>>>  >>  >>  > >>>           <invoke name="A" ...>
>>  >>>>>>  >>  >>  > >>>             <source linkName="linkA" ...>
>>  >>>>>>  >>  >>  > >>>           </invoke>
>>  >>>>>>  >>  >>  > >>>         </scope>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>         <scope name="scopeB">
>>  >>>>>>  >>  >>  > >>>           ...
>>  >>>>>>  >>  >>  > >>>           <invoke name="B" ...>
>>  >>>>>>  >>  >>  > >>>             <source linkName="linkB" ...>
>>  >>>>>>  >>  >>  > >>>           </invoke>
>>  >>>>>>  >>  >>  > >>>         </scope>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>         <throw name="C"
>>  >>>>>> faultName="bpws:forcedCompletion"
>>  >>>>>>  >>  >>  > >>>                joinCondition="linkA OR linkB"
>>  >>>>>>  >>  >>  > >>>     joinEvaluation="immediate">
>>  >>>>>>  >>  >>  > >>>             <target linkName="linkA" ...>
>>  >>>>>>  >>  >>  > >>>             <target linkName="linkB" ...>
>>  >>>>>>  >>  >>  > >>>         </throw>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>       </flow>
>>  >>>>>>  >>  >>  > >>>     </scope>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     First, I explain the situation: In the 
>> example
>>  >>>>>> above,
>>  >>>>>>  >>  >>  > activity C
>>  >>>>>>  >>  >>  > >>>     will be executed if one of the two activities
>>  >>>>>> A and B was
>>  >>>>>>  >>  >>  > >>>     successfully completed. Activity C throws the
>>  >>>>>> fault
>>  >>>>>>  >>  >>  > >>>     "forcedCompletion". Like each other fault, 
>> this
>>  >>>>>>  >>  >>  > forces the scope
>>  >>>>>>  >>  >>  > >>>     "scopeFlow" to terminate still running
>>  >>>>>> activities.
>>  >>>>>>  >>  >>  > Assume, there
>>  >>>>>>  >>  >>  > >>>     was a fault handler defined in this scope 
>> which
>>  >>>>>>  >>  >>  > catches the fault
>>  >>>>>>  >>  >>  > >>>     "forcedCompletion" (omitted in here), the 
>> process
>>  >>>>>>  >>  >>  > continues after
>>  >>>>>>  >>  >>  > >>>     scope "scopeFlow". A problem arises, if scope
>>  >>>>>>  >>  >>  > "scopeFlow" should
>>  >>>>>>  >>  >>  > >>>     be compensated. Because it was exited from a
>>  >>>>>> fault
>>  >>>>>>  >>  >> handler, no
>>  >>>>>>  >>  >>  > >>>     compensation handler was installed.
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Now, I explain my solution: In the example, I
>>  >>>>>> have
>>  >>>>>>  >>  >>  > chosen a new
>>  >>>>>>  >>  >>  > >>>     "standard" fault name: "forcedCompletion". 
>> The
>>  >>>>>> only
>>  >>>>>>  >> necessary
>>  >>>>>>  >>  >>  > >>>     change is to allow a fault handler that
>>  >>>>>> catches this
>>  >>>>>>  >> fault to
>>  >>>>>>  >>  >>  > >>>     install a compensation handler for the same
>>  >>>>>> scope,
>>  >>>>>>  >>  >>  > i.e. to mark
>>  >>>>>>  >>  >>  > >>>     the scope "scopeFlow" as "completed" instead
>>  >>>>>> of "exited".
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     The standard compensation mechanism will only
>>  >>>>>> undo those
>>  >>>>>>  >>  >>  > >>>     ("scoped") activities within the scope, which
>>  >>>>>>  >>  >>  > actually have been
>>  >>>>>>  >>  >>  > >>>     successfully completed, i.e. scopeA or scopeB
>>  >>>>>> or may
>>  >>>>>>  >> be both.
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Axel.
>>  >>>>>>  >>  >>  > >>>     ----------------------------------------
>>  >>>>>>  >>  >>  > >>>     Axel Martens
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Post Doc Researcher
>>  >>>>>>  >>  >>  > >>>     Component Systems Group
>>  >>>>>>  >>  >>  > >>>     IBM TJ Watson Research Center
>>  >>>>>>  >>  >>  > >>>     Hawthorne, NY (USA)
>>  >>>>>>  >>  >>  > >>>     Phone: (914) 784-7480
>>  >>>>>>  >>  >>  > >>>     E-mail: amarten@us.ibm.com
>>  >>>>>> <mailto:amarten@us.ibm.com>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     *Alex Yiu <alex.yiu@oracle.com>
>>  >>>>>>  >> <mailto:alex.yiu@oracle.com>*
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     09/10/2004 12:10 AM
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>           > >>>     To
>>  >>>>>>  >>  >>  > >>>           Alex Yiu <alex.yiu@oracle.com>
>>  >>>>>>  >>  >>  > <mailto:alex.yiu@oracle.com>
>>  >>>>>>  >>  >>  > >>>     cc
>>  >>>>>>  >>  >>  > >>>           "Trickovic, Ivana"
>>  >>>>>> <ivana.trickovic@sap.com>
>>  >>>>>>  >>  >>  > >>>     <mailto:ivana.trickovic@sap.com>, Axel
>>  >>>>>>  >>  >>  > Martens/Watson/IBM@IBMUS,
>>  >>>>>>  >>  >>  > >>>     "'edwink@collaxa.com'"
>>  >>>>>> <mailto:%27edwink@collaxa.com%27>
>>  >>>>>>  >>  >>  > >>>     <edwink@collaxa.com> 
>> <mailto:edwink@collaxa.com>,
>>  >>>>>>  >>  >>  > >>>     "'satisht@microsoft.com'"
>>  >>>>>>  >>  >> <mailto:%27satisht@microsoft.com%27>
>>  >>>>>>  >>  >>  > >>>     <satisht@microsoft.com>
>>  >>>>>> <mailto:satisht@microsoft.com>,
>>  >>>>>>  >>  >>  > >>>     "'wsbpel@lists.oasis-open.org'"
>>  >>>>>>  >>  >>  > >>>     <mailto:%27wsbpel@lists.oasis-open.org%27>
>>  >>>>>>  >>  >>  > >>>     <wsbpel@lists.oasis-open.org>
>>  >>>>>>  >>  >>  > >>>     <mailto:wsbpel@lists.oasis-open.org>, Alex 
>> Yiu
>>  >>>>>>  >>  >>  > >>>     <alex.yiu@oracle.com>
>>  >>>>>> <mailto:alex.yiu@oracle.com>
>>  >>>>>>  >>  >>  > >>>     Subject
>>  >>>>>>  >>  >>  > >>>           Re: [wsbpel] Issue 6 - Rough draft of
>>  >>>>>> proposal
>>  >>>>>>  >> for vote
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>           > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Hi,
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Here are some examples how to use
>>  >>>>>> completeCondition to
>>  >>>>>>  >>  >> express
>>  >>>>>>  >>  >>  > >>>     similar business logic in Axel's previous 
>> email:
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     (A) "Select one out of three" example:
>>  >>>>>>  >>  >>  > >>>     <flow>
>>  >>>>>>  >>  >>  > >>>        <completeCondition *branch="1"* />
>>  >>>>>>  >>  >>  > >>>        <invoke name="CheckAirlineA" ... />
>>  >>>>>>  >>  >>  > >>>        <invoke name="CheckAirlineB" ... />
>>  >>>>>>  >>  >>  > >>>        <invoke name="CheckAirlineC" ... />
>>  >>>>>>  >>  >>  > >>>     </flow>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     (B) "Select two out of three" example:
>>  >>>>>>  >>  >>  > >>>     <flow>
>>  >>>>>>  >>  >>  > >>>        <completeCondition *branch="2"* />
>>  >>>>>>  >>  >>  > >>>        <invoke name="AskRefereeA" ... />
>>  >>>>>>  >>  >>  > >>>        <invoke name="AskRefereeB" ... />
>>  >>>>>>  >>  >>  > >>>        <invoke name="AskRefereeC" ... />
>>  >>>>>>  >>  >>  > >>>     </flow>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     As you guys can see, the completeCondition
>>  >>>>>> declaration is
>>  >>>>>>  >>  >> very
>>  >>>>>>  >>  >>  > >>>     straight forward and simple. No complicated
>>  >>>>>> links and
>>  >>>>>>  >>  >>  > >>>     joinCondition usage.
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     (C) "(Plane or Train) and Hotel" example: It
>>  >>>>>> would
>>  >>>>>>  >> become two
>>  >>>>>>  >>  >>  > >>>     flow constructed (nested).
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     <assign> ... <to 
>> variable="planeResult"></assign>
>>  >>>>>>  >>  >>  > >>>       <!-- initialize "planeResult" with NOT-OK
>>  >>>>>> value -->
>>  >>>>>>  >>  >>  > >>>     <assign> ... <to 
>> variable="trainResult"></assign>
>>  >>>>>>  >>  >>  > >>>       <!-- initialize "trainResult" with NOT-OK
>>  >>>>>> value --> *
>>  >>>>>>  >>  >>  > >>>     <flow name="checkIterinary">*
>>  >>>>>>  >>  >>  > >>>        *<flow name="PlaneOrPlane">*
>>  >>>>>>  >>  >>  > >>>           <completeCondition>
>>  >>>>>>  >>  >>  > >>>                fn:planeOK(planeResult) *or*
>>  >>>>>>  >>  >>  > fn:trainOK(trainResult)
>>  >>>>>>  >>  >>  > >>>           </completeCondition>
>>  >>>>>>  >>  >>  > >>>           <invoke name="CheckPlane"
>>  >>>>>>  >>  >>  > outputVariable="planeResult" ... />
>>  >>>>>>  >>  >>  > >>>           <invoke name="CheckTrain"
>>  >>>>>>  >>  >>  > outputVariable="trainResult" ... />
>>  >>>>>>  >>  >>  > >>>        *</flow> *
>>  >>>>>>  >>  >>  > >>>        <invoke name="checkHotel" /> *
>>  >>>>>>  >>  >>  > >>>     </flow>
>>  >>>>>>  >>  >>  > >>>     <switch name="bookingSwitch">*
>>  >>>>>>  >>  >>  > >>>        <case>
>>  >>>>>>  >>  >>  > >>>            <condition>
>>  >>>>>>  >>  >>  > >>>            (fn:planeOK(planeResult) *or*
>>  >>>>>>  >> fn:trainOK(trainResult))
>>  >>>>>>  >>  >>  > >>>     *and* fn:hotelOK(hotelResult)
>>  >>>>>>  >>  >>  > >>>            </condition>
>>  >>>>>>  >>  >>  > >>>            <invoke name="invokeBooking" ... />
>>  >>>>>>  >>  >>  > >>>        </case>
>>  >>>>>>  >>  >>  > >>>        <otherwise>
>>  >>>>>>  >>  >>  > >>>              <invoke name="writeInformation" 
>> ... />
>>  >>>>>>  >>  >>  > >>>        </otherwise> *
>>  >>>>>>  >>  >>  > >>>     </switch>*
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Please note that regardless whether we pick a
>>  >>>>>>  >> link-oriented
>>  >>>>>>  >>  >>  > >>>     approach or completeCondition approach:
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>         * The initialization of result 
>> variables are
>>  >>>>>>  >>  >>  > needed because
>>  >>>>>>  >>  >>  > >>>           of potential cancellation of one of the
>>  >>>>>> invoke
>>  >>>>>>  >> between
>>  >>>>>>  >>  >>  > >>>           train and plane
>>  >>>>>>  >>  >>  > >>>         * The "fn:*()" represents the logic to
>>  >>>>>> determine
>>  >>>>>>  >>  >> whether a
>>  >>>>>>  >>  >>  > >>>           traveling resource is available. They
>>  >>>>>> are used in
>>  >>>>>>  >>  >> either
>>  >>>>>>  >>  >>  > >>>           the transitionCondition of links or the
>>  >>>>>>  >> condition of
>>  >>>>>>  >>  >>  > >>>           switch/case.
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     As you guys see, we don't need declare to six
>>  >>>>>> links. The
>>  >>>>>>  >>  >>  > >>>     completeCondition and case-condition are much
>>  >>>>>> simpler
>>  >>>>>>  >>  >>  > and easier
>>  >>>>>>  >>  >>  > >>>     to understand.
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     I attach a diagram to illustrate the above 
>> flows.
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     I guess we can still more time in terms of
>>  >>>>>> refiniment of
>>  >>>>>>  >>  >>  > >>>     joinCondition evaluation. However, I don't
>>  >>>>>> think that
>>  >>>>>>  >>  >>  > should be
>>  >>>>>>  >>  >>  > >>>     the only approach to achieve complete
>>  >>>>>> condition related
>>  >>>>>>  >>  >> logic.
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Thanks!!!
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Regards,
>>  >>>>>>  >>  >>  > >>>     Alex Yiu
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Alex Yiu wrote:
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Hi,
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     +1 to what Ivana said in general.
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Few points to add:
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>         * Axel's proposed enhancement to control
>>  >>>>>> links
>>  >>>>>>  >> evaluation
>>  >>>>>>  >>  >>  > >>>           works to an extent for static
>>  >>>>>> parallelism  > (e.g.
>>  >>>>>>  >>  >> <flow>).
>>  >>>>>>  >>  >>  > >>>           However, control links do not work well
>>  >>>>>> in dynamic
>>  >>>>>>  >>  >>  > >>>           parallelism (e.g. "parallel forEach" or
>>  >>>>>>  >>  >>  > "bundle"). I think
>>  >>>>>>  >>  >>  > >>>           the notion of completeCondition
>>  >>>>>> (borrowed from
>>  >>>>>>  >> Ivana
>>  >>>>>>  >>  >> and
>>  >>>>>>  >>  >>  > >>>           DK) is general enough and it should be
>>  >>>>>> applied
>>  >>>>>>  >> to both
>>  >>>>>>  >>  >>  > >>>           static and dynamic parallelism. A 
>> general
>>  >>>>>>  >>  >>  > completeCondition
>>  >>>>>>  >>  >>  > >>>           mechanism will be easier for BPEL users
>>  >>>>>> to learn.
>>  >>>>>>  >>  >>  > >>>         * Even in a pure static parallelism case,
>>  >>>>>>  >>  >>  > completeCondition
>>  >>>>>>  >>  >>  > >>>           has much better code clarity. It is 
>> more
>>  >>>>>>  >> declarative
>>  >>>>>>  >>  >> and
>>  >>>>>>  >>  >>  > >>>           easier for BPEL users to understand. It
>>  >>>>>> will
>>  >>>>>>  >> eliminate
>>  >>>>>>  >>  >>  > >>>           significant amount of joinCondition
>>  >>>>>>  >>  >>  > programming, which may
>>  >>>>>>  >>  >>  > >>>           be error prone. (I will send another
>>  >>>>>> email later to
>>  >>>>>>  >>  >> show
>>  >>>>>>  >>  >>  > >>>           how completeCondition can be used to
>>  >>>>>> express the
>>  >>>>>>  >> same
>>  >>>>>>  >>  >>  > >>>           semantics of Axel's example).
>>  >>>>>>  >>  >>  > >>>         * In one of my previous emails, I also
>>  >>>>>> tried to
>>  >>>>>>  >>  >>  > use a "macro"
>>  >>>>>>  >>  >>  > >>>           way to illustrate how outstanding
>>  >>>>>> running flows
>>  >>>>>>  >> can be
>>  >>>>>>  >>  >>  > >>>           cancelled by throwing a fault within a
>>  >>>>>> scope. The
>>  >>>>>>  >>  >>  > >>>           illustration has the same compensation
>>  >>>>>> handler
>>  >>>>>>  >>  >>  > installation
>>  >>>>>>  >>  >>  > >>>           problem that Ivana has pointed out. The
>>  >>>>>>  >> "illustraction
>>  >>>>>>  >>  >>  > >>>           macro" does NOT carry a desirable and
>>  >>>>>> intended
>>  >>>>>>  >>  >>  > semantics.
>>  >>>>>>  >>  >>  > >>>           We need to create / describe a new
>>  >>>>>> mechanism to
>>  >>>>>>  >> cancel
>>  >>>>>>  >>  >>  > >>>           parallel flow without throwing a fault.
>>  >>>>>> (That
>>  >>>>>>  >>  >>  > was discussed
>>  >>>>>>  >>  >>  > >>>           briefly between Edwin and me at 
>> Oracle).
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Thanks!
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Regards,
>>  >>>>>>  >>  >>  > >>>     Alex Yiu
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>>     Trickovic, Ivana wrote:
>>  >>>>>>  >>  >>  > >>>     Axel,
>>  >>>>>>  >>  >>  > >>>      > >>>     I find the idea interesting. In
>>  >>>>>> fact, I was
>>  >>>>>>  >>  >> discussing the
>>  >>>>>>  >>  >>  > >>>     completion condition issue with Dieter Koenig
>>  >>>>>> during
>>  >>>>>>  >>  >>  > the last f2f
>>  >>>>>>  >>  >>  > >>>     meeting and his suggestion was also to try to
>>  >>>>>> resolve
>>  >>>>>>  >>  >>  > this issue
>>  >>>>>>  >>  >>  > >>>     using links. And we identified that several
>>  >>>>>> changes need
>>  >>>>>>  >>  >> to be
>>  >>>>>>  >>  >>  > >>>     done, including removing restriction for
>>  >>>>>>  >>  >>  > jonCondition, that "the
>>  >>>>>>  >>  >>  > >>>     join condition is evaluated as soon as all
>>  >>>>>> incoming
>>  >>>>>>  >>  >>  > links of the
>>  >>>>>>  >>  >>  > >>>     activity are determined" - so definitely
>>  >>>>>> "immediate"
>>  >>>>>>  >>  >> semantics
>>  >>>>>>  >>  >>  > >>>     needs to be introduced.
>>  >>>>>>  >>  >>  > >>>      > >>>     I have the following comments 
>> on your
>>  >>>>>>  >> proposal.
>>  >>>>>>  >>  >>  > >>>     1. In your proposal you are using a fault
>>  >>>>>>  >>  >>  > >>>     (bpws:forcedTermination) to terminate all
>>  >>>>>> active parallel
>>  >>>>>>  >>  >>  > >>>     branches. But this changes the outcome of the
>>  >>>>>> flow
>>  >>>>>>  >>  >>  > activity. It
>>  >>>>>>  >>  >>  > >>>     will always end abnormally and compensation
>>  >>>>>> handler
>>  >>>>>>  >> (if it is
>>  >>>>>>  >>  >>  > >>>     defined) will never be installed. Although
>>  >>>>>> completion
>>  >>>>>>  >>  >>  > condition
>>  >>>>>>  >>  >>  > >>>     has evaluated to true and needed 
>> activities have
>>  >>>>>>  >> completed
>>  >>>>>>  >>  >> the
>>  >>>>>>  >>  >>  > >>>     enclosing flow activity will end abnormally.
>>  >>>>>> Is this
>>  >>>>>>  >> really
>>  >>>>>>  >>  >>  > >>>     intended semantics?
>>  >>>>>>  >>  >>  > >>>      > >>>     2. Your proposal does not address
>>  >>>>>> some pain
>>  >>>>>>  >>  >> points.
>>  >>>>>>  >>  >>  > For example,
>>  >>>>>>  >>  >>  > >>>     in case of "N out of M", N<M there many 
>> possible
>>  >>>>>>  >>  >> "variations":
>>  >>>>>>  >>  >>  > >>>     (A) One enclosed activity may experience
>>  >>>>>> problems but
>>  >>>>>>  >>  >>  > the <flow>
>>  >>>>>>  >>  >>  > >>>     activity may succeed
>>  >>>>>>  >>  >>  > >>>     (B) One of enclosed activities may experience
>>  >>>>>> a severe
>>  >>>>>>  >> error,
>>  >>>>>>  >>  >>  > >>>     which may have impact on the <flow> activity
>>  >>>>>>  >>  >>  > >>>     The question is what to do with running
>>  >>>>>> activities?
>>  >>>>>>  >>  >>  > In the latter
>>  >>>>>>  >>  >>  > >>>     case, reasonable behavior would be: if one
>>  >>>>>> enclosed
>>  >>>>>>  >>  >>  > activity does
>>  >>>>>>  >>  >>  > >>>     not succeed other running activities 
>> should be
>>  >>>>>>  >>  >>  > cancelled and the
>>  >>>>>>  >>  >>  > >>>     flow activity should try to recover. In the
>>  >>>>>> former
>>  >>>>>>  >> case, we
>>  >>>>>>  >>  >>  > >>>     should allow active parallel activities to
>>  >>>>>> complete
>>  >>>>>>  >>  >>  > their work.
>>  >>>>>>  >>  >>  > >>>     This is not supported in your proposal.
>>  >>>>>>  >>  >>  > >>>      > >>>     Regards,
>>  >>>>>>  >>  >>  > >>>      > >>>
>>  >>>>>>  >>  >>  > >>>     Ivana
>>  >>>>>>  >>  >>  > >>>
>>  >>>>>>  >>  >>  > >>     [stuff deleted]
>>  >>>>>>  >>  >>  > >>
>>  >>>>>>  >>  >>  > >
>>  >>>>>>  >>  >>  >
>>  >>>>>>  >>  >>  > 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/le
>>  >>>>>>  >>  >>  > ave_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. 
>>
>>  >>>>>>
>>  >>>>>>  >>
>>  >>>>>>  >>
>>  >>>>>>  >
>>  >>>>>>
>>  >>>>>> 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]