Sunday, October 4, 2009

The N-out-of-M join has M incoming branches, and the follow-up activityis triggered once N branches have completed. This behaviour can in part beexpressed in YAWL by multiple instances, as shown in Figure 4.67. The ideais to start M instances and to define a threshold of N instances, so once Ninstances have completed, the multiple instances task completes.While multiple instances can be used to represent an N-out-of-M joinwith identical activities, this approach falls short of representing concurrentbranches comprised of different activities. Therefore, only a very specific typeof N-out-of-M join can be realized in YAWL using multiple instances. Hence,the N-out-of-M join is not completely expressed, since it should be able tosynchronize different branches of a process and not only multiple instances ofa given task.

Multiple Instances Tasks

Yet Another Workflow Language is tailored towards supporting multiple instancespatterns. The multiple instances without synchronization pattern isshown in Figure 4.68. In this example, A spawns two concurrent branches,consisting of multiple instances of task B and a single instance of task C.The multiple instances of task B are not synchronized, which means thatB cannot have outgoing edges, because outgoing edges would indicate thatthe follow-up activity can only be started if the task instances of task B havecompleted.The multiple instances with design time knowledge is shown in Figure 4.69.In this pattern, the number of instances of task B is known at design time.Therefore, the multiple instances attributes of task B can be set accordingly.By setting the minimum number of instances, the maximum number ofinstances, and the threshold to n, where n is the number of required instancesof task B, this pattern can be realized. The control flow edge from B to Cindicates that C can only start when all instances of task B have completed.If the number of instances is known only at run time, but before the first instanceof B starts, a function is required to determine the number of instancesof B, as shown in Figure 4.70. This difference with the previous pattern is reflectedby using q for the number of instances, where q is determined at run time of the process instance, but before the start of multiple instances taskB. For example, the number of line items in an order can be determined atrun time. In the example, q reflects this number, so that exactly q instancesof task B are performed.Figure 4.71 shows multiple instances without a priori run time knowledge.In this pattern, the number of instances of B becomes available only whileinstances of task B run. This means that new instances of B need to becreated dynamically. Parameters q1 and q2, and also the threshold value, canbe subject to change while task instances run, providing maximum flexibilityin determining the number of instances of a multiple instances task.

Discussion Yet Another Workflow Language has a number of advantages, but also somedrawbacks. The graphical representation of process models is closely related to workflow nets, so that people familiar with workflow nets can use YAWLimmediately.The execution semantics of YAWL is well-specified by state transitionsystems. The representation of executing tasks by state transition systemscombines state transition diagrams—to describe the dynamic behaviour ofprocess activities, as shown in Figure 3.10—with Petri net markings.One of the conceptual issues when representing business process activitiesby Petri nets is the timeliness of the transition firing. Business process activitiestake time, they have a start, they are active for a time interval, beforethey complete. In contrast to Petri nets, the durations of process activitiesare well captured by state transition systems in YAWL. At the same time,process instances are represented by tokens, similar to markings in Petri nets.YAWL has excellent support for multiple instances patterns. The specificationof multiple instances actually goes one step ahead of the control flowpatterns in that it allows us to define a threshold of completed task instances.The construct to model multiple instances tasks in YAWL is very useful andhas many applications in real-world business processes.The semantics of multiple instances tasks is handled very well by statetransition systems in YAWL. The add transition allows the dynamic creationof new task instances while task instances are active; the exit transition canrealize the threshold semantics by cancelling all remaining task instances whenthe threshold number of completed instances has been reached.The state transition systems also capture in a very elegant way compositetasks. By recursively applying the concept, subprocesses can easily be attachedto composite tasks. The multiple-instances property is orthogonal totasks being composite, so that any composite task can at the same time havemultiple instances.The remove function rem associated to tasks allows us defining regionsof the workflow specification from where to withdraw tokens when the taskcompletes. Conceptually it is rather simple to “remove tokens” from processinstances to cancel tasks. It becomes much harder, however, when we look atthe concrete realization of these tasks.In real-world business processes, many tasks are realized by software systems.Removing a token from a task means to cancel the invocation of thesystem. If the software system has transactional capabilities then the transactioncan be aborted, rolling back the software system to a consistent state.Not all software systems used in business processes are, however, are transactional. In this case, the software might have already performed its workpartially at the time, the token is removed. In such situations, it is unclear,how the business process management system should behave. In many cases,human involvement is required to solve the resulting problems manually.We have already discussed in some detail the weaknesses of YAWL inrepresenting some advanced control flow patterns, including the discriminatorand the M-out-of-N join. Despite these drawbacks, YAWL is a well-designedprocess modelling language that also comes with prototypical implementationsfor modelling and enactment, as referenced in the bibliographical notes.