Thinking some more about the
need to pass parameter values between concurrent Threads. Also, I am
not sure that we could "synchronize" so that two concurrent Threads would not
asume that THEY are the first to get a response (and set mutex="true").. (i.e.
two Threads both receiving a different/unique response could set the variable
value, and continue execution while other Threads would read that variable
value, and exit/fail if they also received a response) As a result, two
different response messages could still be received without being
detected. Synchronization issues between concurrent threads modifying a
"global" variable is something we were trying to avoid by restricting scope of
variables to their local Thread only.
One could avoid that situation
by performing any "common" action between all the Threads (single PutMessage,
followed by a single GetMessage) outside of those child Threads, and performing
any logical branching at a higher level, before splitting a Thread to perform
some specific set of transactions. For example, doing a PO Request, while
possibly getting back multiple different types of a response ( similary to your
scenario of concurrrent child threads)
<PutMessage>...PO request message
<Sleep>....some number of seconds to receive
all response messages... </Sleep>
<GetMessage>.. a generic response filter
...verify that only one business response message was received.. exit fail by
default if more than one type of response is received
... store response type in a variable ...
.... proceed to other testing
Scripting this way would avoid the synchronization
issue of concurrent Threads modifying the same global variable...
----- Original Message -----
Sent: Wednesday, September 01, 2004 4:24
Subject: RE: [ebxml-iic] Use Case #2
Termination Cases (Nesting)
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 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
[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.
Durand] Mike: my understanding is that your "serial thread"
actually correspond to an implicit pattern in using split/join (please
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.
(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
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
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".
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 thread.
<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
"The Success and Failure elements represent an aggregation
of a state
and a transition to this particular
state. This transition like regular
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
a business document of a particular type, or based on the
content of the response. It is important to note that the success
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
or acted upon to initiate other collaborations. If several
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
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,
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 <OrJoin>.
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. So far 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?)
[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
cause failure of an and-join (which aborts the
thread) [MIKE2] - My question is, why abort the
Thread as well? If a Join simply allows/disallows
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
> (ther parent's
mm1: Only as
long as one contained thread completed successfully correct?
<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
This "abort" is a little like an
[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
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
[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.
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
We may also choose to just introduce a simpler operator to
complete the thread, instead
(like jumping to its
[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).
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)
sets an <AbortThread> instruction based upon the
> result of that
[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 are
[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
occurrences of abort: I woudl only give it "flow" semantics (i.e.
the way the tset case executes, somewhat
similarly as an exception).
[MIKE3] - Agreed and
[Jacques 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 release.
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"
[MIKE3] - Agreed
So it appears we might need more time to reach a
consensus on "abort" and I would not
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.