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


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


[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]