BPEL specification misconstruction

Hi All,

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 1^st Scenario.

3.) Scenario: Much like 1^st 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?

Thanks in advance!

Best Regards,

Genadi Genov

wsbpel message