Re: [ebxml-iic] Use Case #2 Termination Cases (Nesting)

["Monica J. Martin" <Monica.Martin@Sun.COM>]

>         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.

>             (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)
>
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):

"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."

>         - 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?

>         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).

>             [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".
>
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)