RE: [ebxml-bp] Fork without Join

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.