After writing a simple test for the flow activity and
testing the bpws:joinFailure fault, I encountered certain ambiguities
in the way my test process would behave. The test process that I am about to
discuss is attached to the current mail. So let’s get down to the point:

I’ll explain the scenario from starting point the flow activity
onward. It has two scopes and a single link used for synchronization dependency
targeted at the first scope name="FirstFlowScope". The execution of
the second scope is not obstructed by any link or serialization issues so it proceeds
(name="SecondFlowScope"). After executing the assign (first activity
from the inner sequence for the corresponding parent scope), a throw activity
throws a fault. The parent sequence is notified accordingly for the fault occurrence
of its child and takes the proper measures for such a case.

We reach the third element from the latter sequence (a sequence which
contains the source of the link defined in the parent flow). Because of the
abnormal situation, the state of the third element (sequence) is changed to
dead path (it has never been invoked) and all its source links are evaluated
with status ‘false’. So here we come to the unresolved behavior for
the process (or me personally).

1.)Scenario:
The sequence that contains the source for the link name="firstLink"
notifies immediately the target activity of that link, that its status has
changed. This would mean the next activity that is going to be executed is the
first child scope for the flow element scope name="FirstFlowScope". However
it throws a bpws:joinFailure which is caught from the scope parent of the present
flow – scope name="FlowScope". Before handling the fault, it
terminates its root activity and then it handles the fault that has been thrown
thus ‘suppressing’ somehow the fault that has been thrown by the
throw activity.

2.)Scenario:
The sequence doesn’t notify the target activity right away but waits
until the thrown fault is (un)handled. In this case the fault is handled by the
scope name="SecondFlowScope". So the fault that occurred from the
throw activity is properly handled and consequently the target activity of the
link name="firstLink" is notified. Subsequent execution is as
mentioned above in 1st Scenario.

3.)Scenario:
Much like 1st Scenario but the fault thrown from the throw activity
is not suppressed and after executing the fault handler for scope
name="FlowScope" (all children including flow, children scopes and
their relevant fault handlers have been disabled. So there is no proper fault handler
to handle the occurred fault and the process terminates abnormally.

What should be the proper behavior of the process modeled for this simple
test case of mine?