[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: RE: [ebxml-bp] Fork without Join
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.
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.
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.
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.