Jacques and all,
My comments in
----- Original Message -----
Sent: Wednesday, September 01, 2004
Subject: RE: [ebxml-iic] Use Case
#2 Termination Cases (Nesting)
Monica J. Martin [mailto:Monica.Martin@sun.com]
Sent: Friday, August 27, 2004 4:17 PM
To: Jacques Durand
Cc: 'Michael Kass';
ebXML IIC - main list (E-mail) (E-mail);
Subject: Re: [ebxml-iic] Use Case #2
Termination Cases (Nesting)
[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.
[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
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
[Jacques Durand] Mike: my understanding
is that your "serial thread" actually correspond to an implicit pattern
in using split/join (please confirm):
is so, then we still need to define what it means to join an "aborted"
thread. The issue does not exist for "Return", which just completes the
thread right away.
[MIKE4] - I did not see the need for "splitting" and
"joining" of a Serial Thread, since that would not seem to be necessary
(i.e. your' re already serializing the process, so no split or join is
necessary) Execution continues with the logical completion of the
Thread. Execution stops if any explicit exits or exceptions are
encountered in the serial Thread.
my syntax is simply:
yes, that works, but my point was to find the semantic equivalent with
split/join. We need to map your optimized syntax to a canonical
representation, since split / join are the only way to relate threads
(yours is an implicit split).
(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
[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
mm1: This follows what we discussed as endsWhen, re:
'endthread.' However, I'll have to
think a bit more about the Main
containing threads because of this in the previous v1.1 ebXML
BPSS (I've cc: Dale Moberg so he can comment as
[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
[Jacques Durand] OK , we still have to
make it clear that there is always such thing as a "main" or top thread,
whether explicitly declared or not. The "TestCase container" is the main
thread, if no other explicit declaration is made. It is just a
convenience feature to not have to declare a main
[MIKE4] - OK
<JD> the main thread can be implicit, as Mike
suggests (but then the container of
case script still has thread semantics) again a convenience
"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
be used to indicate that a
binary collaboration ends in success or
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
the individual business transaction
activities, which compose the binary
collaboration. In particular, the nature of the commitments is
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
completion states are specified within a
collaboration definition, the
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
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,
exit on failure if mutex="true" at the time it does the
[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
[Jacques Durand] Using Or-join is not enough to exit
on failure if more than one of these threads is executing.
(Or-join does not preclude joining several threads) . When you
split several "exclusive" threads, they may still run concurrently up to
a point (say a GetMessage) where only one of them should proceed further
(say each thread handles a particular message profile, e.g. based on
company type). Now the business process under test is supposed to
generate a single message of this kind. If more than one is generated,
several threads will proceed further and that is what we want to detect.
[MIKE4] - I understand now
I don't see other ways than setting a variable and getting every thread
to check this var at the right step... but I believe we can do that in
our release - assuming different threads can share a var , e.g. from
parent thread (right Mike?)
[MIKE4] - In our current release, different child
Threads can share a common variable value from a parent Thread.. but
they cannot SET that value. That value MUST be set by the parent
Durand] <JD4> that would be a problem for
If that is required, then we need a <SetParameter
scope="parent"/>. Currently, parameter scope is defined
as eitiher "self" or "selfAndDescendents" (i.e. current Thread and its
descendent Threads). Such a modification may not make it into our
release based upon time constraints, but if we need to put this in the
specification in order to satisfy Business Process testing requirements,
then I can certainly do this.
[Jacques Durand] <JD4> if we have it easily specified, why not add it
in this release: we don't have to make it a "core" feature for
conformance. In other words, we can make it optional to implement
for TFk 1.1.
Also, we will have to add a
<VerifyParameter> operation to
<TestAssertion> We currently have
<VerifyTimeDifference>. I can add this to the spec as
well. Will see if we can implement it.
[Jacques Durand] <JD4> can't we just use some typical relational
operator / expression, instead of adding new
[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
execution, and return control to IT's parent Thread
mm1: Only as long as one contained thread completed successfully
<JD> at the bottom of this, we have to decide
(1) a thread can have three states
only: not started, in execution (including hanging),
[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
Now, my main priority at this point, is ease of
implementation, and avoid
- 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
[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
[Jacques Durand] we need to define precisely
the semantics of Abort, and in case we can't agree quickly on this, we
should leave it out of this release.
[MIKE4] - We can disable/remove if this is the
We may also choose to just introduce a simpler operator
to complete the thread, instead
(like jumping to
[MIKE3] - That would be equivalent to what we have
now really (i.e. <Abort> and <Return> essentially do that
[Jacques Durand] so your interpretation of Abort
seems to overlap largely with Return, so we could keep "Return" for this
release (semantics is straightforward).
[MIKE4] - Abort and Return are the same except in the
context of a <Join>. An <Abort> tells the Test Driver
to end the <Thread>, and treat it as it it never completes
(i.e. a "hanging Thread") for any future <Join> operations.
A <Return> tells the Test Driver to end the <Thread>, and
treat it as it it successfully completed for future <Join>
operations. So they overlap when there is no <Join>, or when
the Thread is a "serial" Thread (and no Join is possible).
[Jacques Durand] <JD4> right but even so, we need more time to think
of semantics of abort for the entire test case, etc. So I would
postpone it to a next
the and/or Join result precludes workflow continuation...
fine... The logic rules have been followed, and again, control
returned to the "parent's parent Thread". No abort is
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
<JD> there is always a "top" thread, whether it is
called "main" or not. Every other thread
"split" from there (or from previously split thread).
[MIKE3] - Agreed. As written now,
<TestCase> is the "main" <Thread> .. from which all others
[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
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
Durand] so lets define precisely the Abort semantics, and see
if we can agree on it.
wouldn't spend much time on it for this
[MIKE4] - Then I will tell my implementer to stop work
on <Abort>. Please let me know if <Return> is a "go"
Durand] <JD4> return is much more
straightforward: just a shortcut to complete the thread. So we can keep
it if noone objects.
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
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
problem postponing this to a future release.
[MIKE3] - We can exercise it in use cases with our
mm1: I've referenced the original section for Dale's
benefit for comment
(if he has time).
least the start of a long trail of
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.