Title: RE: [ebxml-iic] Use Case #2 Termination Cases (Nesting)
Jacques and all,
My comments in
italics
Mike
----- Original Message -----
From:
Jacques
Durand
To: 'Monica J. Martin' ; Jacques
Durand
Cc: 'Michael Kass' ; ebXML IIC - main list (E-mail)
(E-mail) ; ; ; Dale Moberg
Sent: Wednesday, September 01, 2004 12:15
AM
Subject: RE: [ebxml-iic] Use Case #2
Termination Cases (Nesting)
inline <JD>
-----Original Message-----
From:
Monica J. Martin [mailto:]
Sent: Friday, August 27, 2004 4:17 PM
To: Jacques Durand
Cc: 'Michael Kass'; ebXML
IIC - main list (E-mail) (E-mail);
; ;
Dale Moberg
Subject: Re: [ebxml-iic] Use Case #2
Termination Cases (Nesting)
> 24 August
2004:
>
>
[MIKE2] - Additionally, I would suggest (just to keep the
>
rules as simple as possible) that <AbortThread> be
>
permitted for "serial" Threads as well. I do not see any
>
reason why/how this would have a negative effect on
>
execution flow. Basically, this would say that an
>
"aborted" serial Thread simply exits ( for whatever
>
<TestAssertion> result in that Thread) and workflow
>
continues wiht the next instruction after that Thread.
>
This can be thought of as the serial version of the
>
"dangling concurrent thread", whose result is not
>
consequential to the ultimate result of the Test Case.
>
This keeps the rules simple for all Threads.
>
>
Comments?
>
>
[Jacques Durand] Everything above and before is OK to me,
>
with some reserve on the notion of "serial" thread. I
>
assume "serialization of threads" has the following
>
semantics (since I assume that splitting/joining are the
>
only way to combine threads here):
>
mm1: In workflow (process), you may have several concurrent
threads that
when one becomes active, the others are
disabled. It seems this still
follows your logic,
Mike, I believe.
<JD> I believe Mike has more in mind the fact that
threads could just be chained
one after the other (no
concurrency assumed like in the "exclusive-or" fork of BPSS)
so I suspect just a convenience feature from Mike... (right Mike?), as
threads others
than the "root" or main, must always be
forked (split), so "serial" just means some
implicit
way to split them (that I previously described).
[MIKE3]- That was my intention with <Abort> of a
"serial" Thread. However, we have now introduced "<Return> as well (
your symmetric counterpart to <Abort>). My question now is: what
would be the difference between <Abort> or <Return> for a "serial"
Thread? (Since their meaning only applies to a <Join>
operation). Both exit the Thread, both kill that Thread. Since a
"serial" Thread is not "joined" is there any semantic difference between
<Abort>ing or <Returning>ing a serial Thread? Perhaps this is a
"moot'" point, and the test writer can use either one, since both permit
continued execution of workflow.
>
(2) if for some reason you want the thread to jump
>
directly to "successful completion" if TestAssertion =
>
True/False, then we need a 4th action besides "continue",
>
"abort", "exit[testcase]": we could call it "endthread".
>
In that case that is just one more way to terminate
>
positively a thread (so join semantics is same as for
>
normal completion)
>
[MIKE3] - We chose <Return> instead of
<EndThread>.. but the semantics you describe above are the
same.
So you have your "symmetry" of <Abort>
and <Return>.. which have different meanings for a <Join>
operation.
mm1: This follows what we discussed as endsWhen, re: ends
when
'endthread.' However, I'll have to think a bit
more about the Main
thread and containing threads
because of this in the previous v1.1 ebXML
BPSS (I've
cc: Dale Moberg so he can comment as well):
[MIK3] - The "main" Thread is now the <TestCase> in
the specifcation. Rules would be: <Abort>ing the <TestCase>
(i.e. the "main thread") sets a final <TestCase> result of
"undetermined". <Return>ning at the <TestCase> level sets a
final state of "pass".
<JD> the main thread can be implicit, as Mike suggests
(but then the container of
the test case script still
has thread semantics) again a convenience feature.</JD>
"The Success and Failure elements represent an aggregation of
a state
and a transition to this particular state.
This transition like regular
transitions can be
guarded by a conditionGuard. The conditionGuard can
be
used to indicate that a binary collaboration ends in success or
failure based on the fact that the last business
transaction activity
response is a business document
of a particular type, or based on the
content of the
response. It is important to note that the success or
failure of the collaboration does not affect the success or failure of
the individual business transaction activities, which
compose the binary
collaboration. In particular, the
nature of the commitments is not
changed when the
collaboration ends in a specific state. The success or
failure of a collaboration is rather an indication, which can be
reported on, or acted upon to initiate other
collaborations. If several
completion states are
specified within a collaboration definition, the
business collaboration run-time instance state is “complete” as soon as
one of the completion state is reached. It is the
responsibility of the
designer to ensure that all
completion states are mutually exclusive and
that once
one of them is reached there are no further Business Activity
open. A timeout exception will be generated by the BSI in such a
case."
<JD> Using variables, our script can verify mutual
exclusive threads execution:
i.e. as soon as a thread
is "elected", it sets a variable, say mutex="true".
Each mutually exclusive thread tests this var in a TestAssertion
somewhere at their beginning,
and exit on failure if
mutex="true" at the time it does the verification.
[MIKE3] - I believe our <Split> and <Join>
operations, together with the <Abort> and <Return> operations
available within <Thread>s will handle the above scenario (multiple,
mutually exclusive succcess/failure states). If there are multiple
concurrent branches, any one of which may signal "success" for the current
Binary Collaboration (i.e. the "parent" Thread)... those branches can be
represented as concurrent <Thread>s, any one of which may <Return>
or <Abort>.. signaling "success" or "failure". Providing an
<OrJoin> for those mutually exclusive <Thread>s would allow
immediate determination of success of the parent <Thread> (i.e.
the Binary Collaboration) and also immediate termination of all other
<Thread>s that are part of that <OrJoin>.
[MIKE3] - We are staying away from "variable driven"
execution.. primarly because of the "side effect" issue of permitting
concurrent Threads to modify "global" variable values. Variable scope is
currently limited to the <Thread> in which it is defined, and any
"descendent" <Thread>s.
> - when
threads are joined, an aborted thread will
> automatically
cause failure of an and-join (which aborts the
> container thread)
[MIKE2] - My question is, why abort the
> container Thread
as well? If a Join simply allows/disallows
> (gates) workflow
continuation based upon the result of the
> Join, then it
appears that in either case (whether Join
> condition is
satisfied or not), there is no reason to "abort"
> the parent Thread.
There is no "error" (that I can see) either
> way with the Join
that would require an "abort" of the parent
> Thread. If the
and/or Join result allows continuation of
> workflow , then
the parent Thread would simply finish its
> workflow
execution, and return control to IT's parent Thread
> (ther parent's
parent).
>
mm1: Only as
long as one contained thread completed successfully correct?
<JD> at the bottom of this, we have to decide
whether:
(1) a thread can have three states only: not
started, in execution (including hanging),
and
complete.
[MIKE3] - We've implemented this..
(2) a thread can have one more state: aborted. If that's
the case, we need
to escalate the semantics of a
thread "aborting" ,for the container thread,
and I'd
suggest that it depends on the way the thread is split and joined.
This "abort" is a little like an exception.
[MIKE3] - One could add this to the spec, but it is really
the equivalent of a "hanging" (or "in execution" ) Thread. And although
it is "like' an exception, it is not semantically treated that way by the Test
Driver.. but simply as part of the logic flow.
Now, my main priority at this point, is ease of
implementation, and avoid
unnecessary complexity - and
delay. So if we feel time is a little short to do (2) properly, I'd rather
skip the "abort" for now - remember that there is room for other
releases.
[MIKE3] - We've already implemented <Abort>..
but we can leave it out of the spec. I see it has having great
value, particularly for the scenario Monica described above (mutually
exclusive "Success" states, any one of which signals an end to the other
<Thread>s) That is how our <Abort>, <Return> and
<Join> operations work.
We may also choose to just introduce a simpler operator to
complete the thread, instead
(like jumping to its
end).
[MIKE3] - That would be equivalent to what we have now
really (i.e. <Abort> and <Return> essentially do that
now).
> If the
and/or Join result precludes workflow continuation...
> fine... The logic
rules have been followed, and again, control
> is returned to the
"parent's parent Thread". No abort is
> necessary. The
only scenario that I can see that would require
> the parent Thread
to "abort" is if a <TestAssertion> operation
> run IN THAT Parent
Thread implicilty or (as I would prefer)
> explicitly sets an
<AbortThread> instruction based upon the
> result of that
<TestAssertion>.
>
>
[MIKE] - There are a couple of issues here: The only way a
>
"Main" Thread could abort (based on your suggested logic
>
for concurrent Threads) is if it is concurrently run (i.e.
>
the Main Thread is <Split>). But if it is the Main thread,
>
why would you <Split> it?
>
mm1: We did have a case on start that there was a split in the previous
specification (fork).
<JD> there is always a "top" thread, whether it is
called "main" or not. Every other thread
is "split"
from there (or from previously split thread).
[MIKE3] - Agreed. As written now, <TestCase>
is the "main" <Thread> .. from which all others are
<Split>
>
[MIKE2] - I would like to suggest setting the final state
>
of the Test Case to "undetermined" if a child (of the
>
<TestCase>) <TestAssertion> encounters an
<AbortThread>
>
instruction during its workflow. Otherwise, all other
>
<Thread>s simply "abort" and pass control back to their
>
parent Thread. If execution proceeds to logical conclusion
>
without an exception conditions or explicit exits, then
>
the Test Case final result is "pass".
>
<JD> again - if we introduce abort - I would not give
test case termination semantics
to occurrences of
abort: I woudl only give it "flow" semantics (i.e. affecting
the way the tset case executes, somewhat similarly as an
exception).
[MIKE3] - Agreed and implemented
So only when the top (main) thread is itself aborting
(either from one of its
TestAssertion, or from
and-joining an aborted child thread), then I would worry about
the meaning for termination, and favor "undetermined"
here.
[MIKE3] - Agreed
So it appears we might need more time to reach a consensus
on "abort" and I would not
have problem postponing
this to a future release.
[MIKE3] - We can exercise it in use cases with our
implementation.
Jacques
mm1: I've referenced the original section for Dale's benefit
for comment
(if he has time). Thanks.
Reference:
http://www.oasis-open.org/archives/ebxml-iic/200408/msg00023.html
(at
least the start of a long trail of
comments)
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/ebxml-iic/members/leave_workgroup.php.
