[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [wsbpel] Issue 27 - Setting link status in case of transition condition
Yes, that text captures the essence. I would just add: "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."
Satish
-----Original Message-----
From: Assaf Arkin [mailto:arkin@intalio.com]
Sent: Tuesday, September 30, 2003 2:06 PM
To: Satish Thatte
Cc: wsbpel@lists.oasis-open.org; Frank Leymann; Dieter Roller
Subject: Re: [wsbpel] Issue 27 - Setting link status in case of
transition condition
I don't have a problem with the fact that the transition condition is
evaluated outside the activity, even if the syntax puts it inside the
activity element.
So would the following text be consistent with this semantic:
"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."
arkin
Satish Thatte wrote:
>Assaf,
>
>Although I believe I correctly understood your issue, my feeling now is
>that my gut reaction was hasty. Triggered by a syntactic cue rather
>than consistent interpretation of how links work. Link source
>declarations are always scopes inside the source activity syntactically
>to make the identity of that activity unambiguous, but the semantics is
>always that the link status including transition condition is evaluated
>upon completion of the source activity. Thus the transition condition
>should be evaluated *outside* the scope after its completion. And in
>the case of scopes, completion does not necessarily mean successful
>completion.
>
>Thus my current answer to my earlier questions is now
>
>A. We do not allow 'amount' to be declared inside the source scope.
>B. The transition condition is evaluated in the scope enclosing the
>source scope, and if it faults, the fault is deemed to have occurred in
>that enclosing scope.
>
>Satish
>
>-----Original Message-----
>From: Satish Thatte [mailto:satisht@microsoft.com]
>Sent: Thursday, September 25, 2003 9:14 PM
>To: Assaf Arkin
>Cc: wsbpel@lists.oasis-open.org; Frank Leymann; Dieter Roller
>Subject: RE: [wsbpel] Issue 27 - Setting link status in case of
>transition condition
>
>Assaf,
>
>I finally see what you are talking about. You are talking about the
>case
>
><scope>
> <source linkName="myLink"
> transitionCondition=
> "bpws:getVariableData('amount')>=10000"/>
> <variables>
> ...
> </variables>
> Activity
></scope>
>
>Two questions seem to arise.
>
>A. Do we allow the variable 'amount' to be declared as a local
variable
>of the scope even though in this case it is part of an expression that
>is supposed to be evaluated after the scope has "successfully
>completed"?
>
>B. What happens if the evaluation of the transition condition faults.
>In which scope is the fault deemed to have occurred?
>
>Good catch. My gut says treat the evaluation of the transition
>condition as part of the scope's work because I would expect to be
>allowed to use a local variable like 'amount' but this is clearly a
>tricky border case.
>
>Satish
>
>-----Original Message-----
>From: Assaf Arkin [mailto:arkin@intalio.com]
>Sent: Thursday, September 25, 2003 7:24 PM
>To: Satish Thatte
>Cc: wsbpel@lists.oasis-open.org
>Subject: Re: [wsbpel] Issue 27 - Setting link status in case of
>transition condition
>
>The text I propose refers to computation within the source activity in
>general.
>
>When the source activity is enclosed within a scope then a fault in the
>transition condition would propagate to the fault handler of that
scope.
>
>The specification already provides for this behavior.
>
>The issue seems to emerge when the scope activity is also the source
>activity. Since it did not establish the correct value for the outgoing
>links it is dangerous for other activities to depend on the source link
>status. If the source/scope activity throws a fault then it does not
>install a compensation handler, which makes it impossible to recover
for
>
>the work. IMO it needs to be able to catch the fault and deal with it
>using a fault handler defined for the source/scope activity.
>
>What would you propose to do in this case?
>
>arkin
>
>Satish Thatte wrote:
>
>
>
>>Assaf,
>>
>>Did you mean ".. computation within the [source] activity .." as
>>
>>
>opposed
>
>
>>to computation within the scope enclosing the source activity?
>>
>>Satish
>>
>>-----Original Message-----
>>From: Assaf Arkin [mailto:arkin@intalio.com]
>>Sent: Thursday, September 18, 2003 12:12 PM
>>To: wsbpel@lists.oasis-open.org
>>Subject: [wsbpel] Issue 27 - Setting link status in case of transition
>>condition
>>
>>Proposed change to the text based on the F2F discussion:
>>
>>Page 65 describes how incoming and outgoing links are handled. I would
>>recommend adding the following text to the first bullet item, or as a
>>remark just below the bullet-item list:
>>
>>"Note that the transition condition is evaluated as part of the
>>computation within the activity. If an error occurs while evaluating
>>
>>
>the
>
>
>>transition condition, a fault would be thrown and can be caught
locally
>>
>>
>
>
>
>>by the activity. The status of all outgoing links will be set to
>>
>>
>false."
>
>
>>This would clarify that in the event of a transition condition
throwing
>>
>>
>
>
>
>>a fault, and that transition condition defined for a <scope> activity,
>>the fault handler is still installed and able to catch the fault, and
>>the activity would complete as if a fault was generated before the
>>transition conditions were evaluated.
>>
>>arkin
>>
>>
>>
>>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_work
g
>>
>>
>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.
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]