The transitions called task1 and task2 represent the logistic of the tasks. They are represented as non-instantaneous transitions with token reservation (indicated by the letter “R” in the transitions). In this type of transition, tokens do not stay in input places waiting for the firing, but they are removed from that places and some time later (firing time) are added to the output places.

Figure 3: Coordination Mechanism for Task 1 equals Task 2 with timeoutA.

Since the goal of the coordination mechanisms is to deal with relations between tasks that sometimes belongs to complex procedures, it is interesting to add mechanisms to avoid frequent deadlocks. For example, in relation Task1 equals Task2, the first task could be blocked if the second workflow has an alternative path that does not execute Task2. This kind of problem can be minimized by the use of timeouts.

A possible timeout for temporal dependencies is shown in Figure 3. This kind of timeout (called timeoutA) defines an alternative task (task’) to be executed after a certain waiting time if the original task has not been executed.

Another kind of timeout is shown in Figure 4. This kind of timeout (timeoutB), is modeled by a timed transition that removes the token from start_task and returns it to the input places of the task after a certain waiting time. This enables the following of alternative paths that do not execute the blocked task. In this kind of timeout, it is also necessary to put a token in release_resource if the task have requested a specific resource.

Figure 4: Coordination Mechanism for Task 1 equals Task 2 with timeoutB.

Initially, we have modeled coordination mechanisms for all dependencies using ordinary PNs. However, a typical problem in the use of ordinary PNs is the state explosion, which can occur in our context when the number of interdependencies increases. High level PNs reduce this problem because they generate simpler models, with less places and transitions. Therefore, we remodeled them using high level PNs. The mechanism modeled using high level PN is shown in Figure 5.

Figure 5: High Level PN Coordination Mechanism for Task 1 equals Task 2.

Note that in Figure 5, there is a common place start_tasks and also a common finish_tasks for both tasks. This can be done because tokens are identified in high level PNs. Also note that places request_resources, assigned_resources and release_resources are not shown in the figure (they are only used in resource management dependencies; therefore we made a simplification here).

<< Back