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



Dear Yaron, Alex, Ivana, Dieter, Vinky and others

I have listed to your discussion, and I am really afraid of the
tendency to introduce a new structure (syntax and/or semantics)
for each use case separately. We really should come up with an
generic and small solution that is hopefully easily usable as well.

Because most of you do like the completionCondition approach,
let's stick to this approach, but make it as simple as possible. I
like Ivana's "isCompleted('A')", because brings in a touch of a
final joinCondition, although no links are present. But, I want to
generalize it, to get rid of ignorable faults etc.

(1) Because we need the status of each activity within the flow,
its is natural to me, to introduce predicates that deliver this
status:
  - Each activity of the flow is either running or ended. I
  propose a predicate "isEnded('A')" which yields true, iff the
  activity is ended (both, normally or faulty), and false otherwise.
  - Each scope within the flow might catch faults. To distinguish
  the two way of a scope's ending, I propose the two predicates
  "isCompleted('A')" and "isFaulted('A')", which yields the final
  status of the scope. (Remark: the predicate "isEnded('A')" is
  applicable to scopes as well.)
I guess, each middleware implementation has to keep track of those
status information. Hence, it must be easy to implement the
predicates.

(2) The completionCondition should be a boolean predicate built
out of those predicates only. Otherwise, part of the
completionCondition might not be defined at evaluation time (e.g.
variables have not been written yet).

(2a) To make one simple case very simple, I would agree on an
additional macro "numberOfEndedActivities(N)". If we have the
activities A, B and C, the completionCondition
"numberOfEndedActivities(2)" would be equivalent to the condition
"(isEnded('A') and isEnded('B')) or (isEnded('A') and isEnded('C')) or (isEnded('B') and isEnded('C'))"

(3) The completion condition is evaluated each time on of the
predicates changes its truth value. The flow is ended, iff
    (a) the completionCondition could be evaluated true or
    (b) all activities of the flow are ended.
In the first case, still running activities are terminated. In the
second case, the fault "completionConditionFailure" is thrown if
the completionCondition was evaluated to false.

(4) Employing the already existing power of fault handling, nested
scopes, etc. - all special cases of severe and ignorable faults
could expressed without additional changes to BPEL.

Regards, 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


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