[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]
Subject: 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 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.
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. 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. |
[Date Prev] | [Thread Prev] | [Thread Next] | [Date Next] -- [Date Index] | [Thread Index] | [List Home]