RE: [ebxml-bp] Fork without Join

["Moberg Dale" <dmoberg@axway.com>]

Hi TC,

 

Here are some initial comments on one recently received ebBP comment.

 

Please add to this or modify as needed.

 

It would be good to document both the issues and some discussion of the issues and store them for transfer to the maintenance effort within ebCore.

 

I will forward also to Andreas Schonberger.

 

Fork without Join

The ebBP standard states (page 64):
The semantics of Fork and Join are such that for instance a Fork MAY be
defined without a corresponding Join. In this case, the TimeToPerform element MUST NOT be used.

If a Fork without Join is specified as an OR-Fork, then such an operation may create multiple threads that are not joined together later on. One of these threads may reach an end state while others are still active. Are the other threads of execution killed then?

 

It is important to remember that ebBP models do not specify an execution semantics. That is, a transition from one state to another more indicates what “can happen” instead of what “does or must happen.” The links that specify these accessibility relations of “states” with one another then abstract from most details relating to process starting and stopping—in fact, any starting or stoppings of activities that emit messages in accordance with the model satisfy the model. If you need synchronization, a join with a “waitForAll” is available, but that would only be used if another state were able to happen.

 

The situation you envision would typically have some ConditionExpressions under which each path in the Fork could be realized. So all that can be said is that eventually all the transitions to states that are specified can occur. There is no cancellation semantics present (except when NOF is used as a signal, and that discussion is actually a special case) just as there does not have to be an initiation or termination of the underlying executed processes. From the ebBP level of abstraction, the processes could always be running and they simply service requests and subsequently issue confirmations or responses. There is of course some encompassing temporal ordering imposed, especially by the TTP values, but also by waitForAll synchronization. We have probably not been as rigorous about these as we should have been.

An OR-Fork without a Join taken together with Loops may create arbitrary many Threads of control.

It was recognized that this was completely indeterminate in ebBP 2.0, and though loops are allowed we have no synchronization or temporal relations to handle this situation. Our use cases were driven by currently used business processes. Iteration semantics were to be driven by business use cases. I will check but we found iteration was not really prevalent or necessary to describe the choreographies under consideration. It was put on the agenda for a future version when the requirements in this area for BP description were clearer. We are assembling use cases for future work and would welcome ones that make essential use of iteration.

Is it simply the responsibility of the designer to avoid such cases (like in many other languages) or is a Fork without Join restricted to only XOR-Forks?

For the moment, no semantics is provided so tools would have to decide whether to reject iteration or augment the description. Tools could offer simulation for processes, and produce a collection of traces with as many allowed combinations of behavior as they wished. Or request constraints on simulations to give more determinate results.

 

It is certainly true that the ebBP language does not prevent nonsensical process descriptions from being produced; there were only a few constraints placed amounting to “pointer typing” and even those (as subsequent replies will show) are not always followed strictly in practice and because of legacy patterns.