RE: [wsbpel] Issue 27 - Proposal to vote - Setting link status in case of transitioncondition

["Satish Thatte" <satisht@microsoft.com>]

Maciej,

I agree with you that faults in transition conditions indicate a
malformed process.  This is true of many other faults, for instance
concurrent enablement of conflicting receives on the same operation.  We
have the whole issue of pessimistic vs optimistic treatment relating to
such faults.  I would say this is another example in the same category.

Satish

-----Original Message-----
From: Maciej Szefler [mailto:mbs@fivesight.com] 
Sent: Monday, October 27, 2003 9:52 AM
To: Satish Thatte; Assaf Arkin
Cc: wsbpel@lists.oasis-open.org
Subject: RE: [wsbpel] Issue 27 - Proposal to vote - Setting link status
in case of transitioncondition


Satish wrote:

> 1.  It would not be a good idea for us to introduce new fault handling
> scope-like concepts.  Designers are free to insert explicit scope
> boundaries wherever they like, including just around I1, to handle
> faults.
I'm not adovcating any new concepts, nor am I questioning that the fault
CAN
be handled, what I am questioning is where the fault OUGHT to be
handled.
Granted, a scope may be inserted around I1 to handle the fault, but is
this
what we want designers to do? Does this lead to clear and understandable
process defintions? In other words should a process fragement, say some
sequence of activities (book a car, book a flight, and book a hotel)
encapsulate error handling for transition conditions that do not relate
in
the slightest to that fragment? Say we enclose the sequence in a flow
and
add a transition condition from "book a flight" to some activity that
emails
directions from the airport to the car rent location. If that transition
condition errors out (car rental confirmation record did not have
optional
GPS coordinates for the car-rent location), should we have to change the
structure of the sequence to handle that fault, or ought that fault be
handled by the enclosing flow which exists to facilitate that
relationship ?


>
> 2.  We should strive to minimize runtime faults but allowing optional
> nodes in XSD schemas makes elimination impossible in this case.

I don't follow why this is impossible. Transitions are constraints, if
there
is an optional element in a variable referenced by a constraint, then to
be
correct that constraint would need to guard against the "element not
present" case. Assuming the constraint evaluator implements short
circuit
analysis, this would prevent runtime errors except in those cases where
the
constraint was incorrectly specified, which I suggest is a serious
condition
that indicates a malformed process definition.

>
> Satish
>
>
> -----Original Message-----
> From: Maciej Szefler [mailto:mbs@fivesight.com]
> Sent: Monday, October 27, 2003 7:06 AM
> To: Assaf Arkin; Satish Thatte
> Cc: wsbpel@lists.oasis-open.org
> Subject: Re: [wsbpel] Issue 27 - Proposal to vote - Setting link
status
> in case of transitioncondition
>
> Sattish, Assaf,
>
> This transition evaluation issue has me a bit uneasy; evaluating the
> transition condition in the scope enclosing the activity seems a bit
> arbitrary. For example consider this flow:
>
> <flow name="F1">
>    <link name="a">
>    <sequence name="S1">
>        <invoke name="I1"...>
>            <source link="a" transitionCondition="doSomethingBad()" />
>        <invoke name="I2" .../>
>   </sequence>
>   <invoke name="I3"...>
>        <target link ="a"/>
>   </invoke>
> </flow>
>
> In this case evaluation of the transition condition "doSomethingBad()"
> in
> the enclosing scope, means evaluating it in the scope of the sequence
> activity S1, which will result in S1 faulting, preventing the
evaluation
> of
> I2. In my view S1 has nothing to do with the control relationships
> between
> I1 and I3 (which belong to F1), why should S1 have to deal with a
fault
> relating to this control relationship? Would it not make more sense to
> place
> the evaluation of the transition condition in the scope of "F1" (which
> is
> active at this point and perfectly capable of performing this task),
> where
> an evaluation fault would not disrupt the progress of S1?
> Alternatively, if
> as Assaf points out "Conditions are not evaluated by a construct" then
> really why are they allowed to generate faults at all? Isn't a
> transition
> condition generating an exception indicative of a faulty process
> definition?
> Is it realistic for process designers to handle such exceptions?
>
> -maciej
>
>
>
> ----- Original Message -----
> From: "Assaf Arkin" <arkin@intalio.com>
> To: "Satish Thatte" <satisht@microsoft.com>
> Cc: "Ron Ten-Hove" <Ronald.Ten-Hove@Sun.COM>;
> <wsbpel@lists.oasis-open.org>
> Sent: Monday, October 20, 2003 7:22 PM
> Subject: Re: [wsbpel] Issue 27 - Proposal to vote - Setting link
status
> in
> case of transitioncondition
>
>
> > Satish Thatte wrote:
> >
> > >Assaf,
> > >
> > >As Ron points out, the setting of link status is meaningful only
> after
> > >the evaluation of the transition condition is completed.  When a
> fault
> > >occurs in the scope within which the condition is to be evaluated,
> > >before the evaluation of the condition is complete, the link status
> is
> > >always set to false.  This is quite independent of the nature and
> source
> > >of the fault, and there is nothing special about the faults that
may
> > >occur within transition conditions as far as this rule is
concerned.
> > >Again, this matters only when the corresponding link is leaving the
> > >scope that faulted.
> > >
> > >
> > I understand the intent, but I'm not sure if the text makes that
point
> > clear. The way the spec is written that would be true for all the
> > activities that have not completed, but we're at a point where the
> > activity has completed but the transition condition is being
> evaluated,
> > and I don't think the text clarifies that point. Hopefully it does
> after
> > we introduce the change discussed by this issue. But it's hard for
me
> to
> > see, since I understand the intent, I may be reading too much into
it.
> >
> > The current text as far as I read it does not explicitly state that
if
> > two transitions conditions exist for the same activity and one
> generates
> > a fault, both would set the link status to false. The intent may be
> > there, but if another interpretation is possible, we need to clarify
> that.
> >
> > >I would not exactly say that "the transition condition is always
> > >evaluated by the enclosing construct" although the idea is correct.
> > >Conditions are not evaluated by a construct.  I think the most
> > >meaningful thing to say is that "transition conditions are
evaluated
> in
> > >the scope immediately enclosing the source activity of a link".
> > >
> > >
> > Consider the case where a <flow> nested within another <flow>
enclosed
> > in a scope, and both flows declare a link with the same name.
> Currently
> > this behavior is not prohibited. Now the question becomes how the
> scope
> > evaluates these two links with the same name? Obviously the intent
> could
> > be that those are two different links inspite of having the same
name,
> > but there could be other interpretations of the spec. I think it's
> safe
> > to conclude at this point that some readers would get horribly
> confused
> > by this without further clarification.
> >
> > arkin
> >
> > >Satish
> > >
> > >-----Original Message-----
> > >From: Assaf Arkin [mailto:arkin@intalio.com]
> > >Sent: Saturday, October 18, 2003 6:43 PM
> > >To: Satish Thatte
> > >Cc: Ron Ten-Hove; wsbpel@lists.oasis-open.org
> > >Subject: Re: [wsbpel] Issue 27 - Proposal to vote - Setting link
> status
> > >in case of transitioncondition
> > >
> > >Would it be fair to say that the transition condition is always
> > >evaluated by the enclosing construct?
> > >
> > >In other words, if activity X is a source activity and has a
> transition
> > >condition, and is encapsulated by activity Y, then activity Y is in
> fact
> > >
> > >responsible to evaluate the transation condition using the
variables
> > >accessible in its scope and throw a fault if the transition
condition
> > >fails? An enclosing construct may also refuse to evaluate any
> transition
> > >
> > >conditions (e.g. a while activity or an event handler).
> > >
> > >Another point that I don't think was answered so far is what
happens
> > >when there are two transition conditions and a fault occurs when
> > >evaluating one of them? Are both of them set to false, or only the
> one
> > >that generated a fault? I believe for consistency both of the links
> > >should have their status set to false.
> > >
> > >arkin
> > >
> > >Satish Thatte wrote:
> > >
> > >
> > >
> > >>You are right, my sentence is misleading.  The link status is
false
> > >>because of the fault not because the transition condition is not
yet
> > >>evaluated.  Thanks for the correction.  Incidentally, the link
> status
> > >>matters only if the link target is outside the scope that faulted.
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> >
>
>-----------------------------------------------------------------------
> -
> > >
> > >
> > >>*From:* Ron Ten-Hove [mailto:Ronald.Ten-Hove@Sun.COM]
> > >>*Sent:* Friday, October 17, 2003 1:22 PM
> > >>*To:* Satish Thatte
> > >>*Cc:* wsbpel@lists.oasis-open.org
> > >>*Subject:* Re: [wsbpel] Issue 27 - Proposal to vote - Setting link
> > >>status in case of transitioncondition
> > >>
> > >>
> > >>
> > >>Satish Thatte wrote:
> > >>
> > >>The link status issue is really more general than this as Goran
> > >>pointed out during the call.  A scope can always fault in an
> unrelated
> > >>
> > >>
> > >
> > >
> > >
> > >>place while one or more transition conditions within it are being
> > >>evaluated, in this case, transition conditions on other links
> sourced
> > >>at the same source scope.  It is impossible to specify the exact
> > >>behavior in such races in the presence of true (multi-processor)
> > >>concurrency.  If the evaluation of the conditions is not complete
> > >>(i.e., the link has not actually set its status) then the link
> status
> > >>is False.  In the case of the fault occurring in the evaluation of
> the
> > >>
> > >>
> > >
> > >
> > >
> > >>transition condition itself the evaluation of the condition is not
> > >>complete and therefore the link status is False.
> > >>
> > >>My understanding is that links are tri-state: empty, true, or
false.
> > >>Until the transition condition is evaluated, the link remains
marked
> > >>as empty, not false as you suggested. Faulting the scope should
case
> > >>the link given in this case to marked as false, as part of
dead-path
> > >>elimination.
> > >>
> > >>-Ron
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> >
>
>-----------------------------------------------------------------------
> -
> > >
> > >
> > >>*From:* Prasad Yendluri [mailto:pyendluri@webmethods.com]
> > >>*Sent:* Thursday, October 16, 2003 3:48 PM
> > >>*To:* Ashwini Surpur; Assaf Arkin
> > >>*Cc:* wsbpel@lists.oasis-open.org
> <mailto:wsbpel@lists.oasis-open.org>
> > >>*Subject:* Re: [wsbpel] Issue 27 - Proposal to vote - Setting link
> > >>status in case of transitioncondition
> > >>
> > >>
> > >>
> > >>True. This aspect was clarified in the discussions related to this
> > >>issue but did not make into the
> > >>proposed resolution (we voted on!).
> > >>
> > >>I also see the need to address what the status of the link ends up
> > >>being in this scenario. The
> > >>obvious answer seems to that "a transition condition evaluation
> error
> > >>would be same as the
> > >>transition condition having evaluated to 'not ture'/false'." But,
I
> > >>somehow feel some will not
> > >>see it this way. In any case we need to make a definitive
statement
> > >>here and not leave a
> > >>loose end dangling.
> > >>
> > >>Regards, Prasad
> > >>
> > >>-------- Original Message --------
> > >>
> > >>*Subject: *
> > >>
> > >>
> > >>
> > >>Re: [wsbpel] Issue 27 - Proposal to vote - Setting link status in
> case
> > >>
> > >>
> > >
> > >
> > >
> > >>of transitioncondition
> > >>
> > >>*Date: *
> > >>
> > >>
> > >>
> > >>Thu, 16 Oct 2003 13:18:25 -0700
> > >>
> > >>*From: *
> > >>
> > >>
> > >>
> > >>Ashwini Surpur <ashwini.surpur@oracle.com>
> > >><mailto:ashwini.surpur@oracle.com>
> > >>
> > >>*Organization: *
> > >>
> > >>
> > >>
> > >>Oracle Corporation
> > >>
> > >>*To: *
> > >>
> > >>
> > >>
> > >>Assaf Arkin <arkin@intalio.com> <mailto:arkin@intalio.com>
> > >>
> > >>*CC: *
> > >>
> > >>
> > >>
> > >>wsbpel@lists.oasis-open.org <mailto:wsbpel@lists.oasis-open.org>
> > >>
> > >>
> > >>
> > >>Also from the discussion on issue 27 I get that the local
variables
> of
> > >>
> > >>
> > >the scope
> > >
> > >
> > >>cannot be used to evaluate the transition condition of the links
and
> > >>
> > >>
> > >only the
> > >
> > >
> > >>variables of the parent scope should be used. This needs to be
> > >>
> > >>
> > >documented
> > >
> > >
> > >>explicitly as well.
> > >>
> > >>
> > >>
> > >>-Ashwini
> > >>
> > >>
> > >>
> > >>Assaf Arkin wrote:
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>>Proposal to resolve issue 27 by adding the following paragraph to
> the
> > >>>
> > >>>
> > >>>specification in the description of how links are handled (pages
> > >>>
> > >>>
> > >64/65):
> > >
> > >
> > >>>Note that the transition condition is evaluated after the
activity
> > >>>
> > >>>
> > >has
> > >
> > >
> > >>>completed. If an error occurs while evaluating the transition
> > >>>
> > >>>
> > >condition,
> > >
> > >
> > >>>that error does not affect the completion status of the activity
> and
> > >>>
> > >>>
> > >is
> > >
> > >
> > >>>handled by the activity's enclosing scope. In the case of
> > >>>
> > >>>
> > >>>scopes, completion does not necessarily imply successful
> completion.
> > >>>
> > >>>
> > >A
> > >
> > >
> > >>>scope may suffer an internal fault and yet complete
> (unsuccessfully)
> > >>>
> > >>>
> > >if
> > >
> > >
> > >>>there is a corresponding fault handler associated with the scope
> and
> > >>>
> > >>>
> > >>>that fault handler completes without throwing a fault.
> > >>>
> > >>>
> > >>>arkin
> > >>>
> > >>>
> > >>>(This is the same proposal sent on Sep 30, resent for your
> > >>>
> > >>>
> > >convenience)
> > >
> > >
> > >>
> > >>
> > >>
> > >>
> > >>
> > >>
> >
>
>>----------------------------------------------------------------------
> -
> > >>
> > >>
> > >-
> > >
> > >
> > >>
> > >>
> > >>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_workg
> r
> > >oup.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_workg
> r
> > >oup.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_workgr
> oup.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_workgr
> oup.php.
> >
> >
>
>
>
>
>