RE: [ebxml-bp] Detailed semantics of Links/Transitions

1. Detailed semantics of Links/Transitions

IMHO, it is not completely clear, when a Transition or Link is fired. The condition guards/expression that can be defined on links are just enablers and if I understand the ebBP standard right, there could be multiple Links that are enabled at the same time. So,

1. If the guard of a Link is true, does that link have to be fired or is this optional?

2. If there is no guard at all, is a Link fired then immediately or at any point in time?

3. If there are multiple Links enabled at the same time, then any of the enabled Links is chosen non-deterministically to be fired, correct?
Could it also be the case that there are multiple enabled Links and non is fired?

Several types of usage of ebBP models are possible. The primary one is to document the contract with respect to potential messages emitted and their quality of service, including the important time bounds given by TimeToPerform. Other tasks that can make use of ebBP “knowledge” of business processes would be simulation, testing, and monitoring. (The OASIS TC TaMie is currently devising ways to compile ebBP 2.0 descriptions into testing and/or monitoring scripts. Simulation uses are more speculative.)

The first clarification is that transitions or links are not “fired” but are rather evaluated during some time interval bounded by governing TTP values (when present). The ConditionExpressions provide the first order propositional functions that events can satisfy. By convention, if a ConditionalExpression is omitted on a link, the transition is taken (so that an absent CE is equivalent in effect to a constant value of “true” on the link).

A procedural or programming or execution interpretation of links and transitions is not intended. The “flow” semantics of BPMN or similar workflow notations for links is then not provided. (Some temporal constraints such as “eventually is succeeded by or times out” are present but not documented rigorously. That would be a very nice additional note to help implementers understand the BP contract expressed in ebBP choreographies, IMO.)

For these reasons it is really not good that I try to directly answer the questions 1 through 3. For a simulation usage, the semantics would need to be augmented and clarified and the questions you raise would certainly be ones to clarify. It might be possible, though I have not investigated, to embed ebBP constraints within a YAWL simulator, or some such environment, and then investigate, using that mainly token-based approach to firing, how various models made of tokens satisfied the choreographic constraints.

I would say that when there are multiple transitions possible during the unfolding of a choreography, the transitions can be taken before, after, concurrently, one another, or not at all! So I would think some non-deterministic approach is called for in whatever event models these descriptions are embedded.

Yes, it is possible that when there are multiple links, none is fired. Safety properties are not enforced by the descriptive apparatus. Generally however if you describe in the spirit of the notation, there will always be a FromLink for a state ending in Failure, and so when TTP values exist, a condition guard value on that FromLink of Failure will always take that transition. There are undoubtedly a lot of tacit good practice rules that we have not articulated, and we welcome modelers experience in building up a guide to using the notation for real business process descriptions with the kinds of QOS captured in ebBP.

(Andreas: I will try to respond to one of these comment list remarks a day until finished. I am alerting other contributors and encourage them to clarify or expand my comments to help address your concerns. It may be good to add some of these very excellent questions to our FAQ because I think ebBP does differ in its approach to BP description from many other notations in part because of its concern with the business contractual aspects of the process. (I know it took me a while to discern the semantics when I joined the effort.) The investigation of flow, execution, temporal semantics, and other distinctively CS concerns with process modeling, such as proofs concerning safety properties, is not of primary interest for these levels of description.)

ebxml-bp message