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


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


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