[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
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.
>
>
>
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]