[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
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]