In the last years, the trade-o between exibility and support has become a leading issue in work ow technology. In this paper we show how an imperative modeling approach used to de ne stable and well-understood processes can be complemented by a modeling approach that enables automatic process adaptation and exploits planning techniques to deal with environmental changes and exceptions that may occur during process execution. To this end, we designed and implemented a Custom Service that allows the Yawl execution environment to delegate the execution of subprocesses and activities to the SmartPM execution environment, which is able to automatically adapt a process to deal with emerging changes and exceptions. We demonstrate the feasibility and validity of the approach by showing the design and execution of an emergency management process de ned for train derailments.
Process Management Systems (PMSs, a.k.a. Work ow Management Systems)
are applied to support and automate the enactment of processes with the aim to
increase their e ciency and e ectiveness. Classical PMSs o er adequate process
support as long as the processes are structured and do not require much
exibility. In the last years, the trade-o between exibility and support has become
a leading issue in work ow technology [
A PMS that supports automatic adaptivity is able to automatically change
the schema of a ected instances in such a way that they can still be completed,
according to the exceptions that have been raised. Process schemas are designed
in order to cope with potential exceptions, i.e., for each kind of exception that
is envisaged to occur, a speci c contingency process (a.k.a. exception handler
or compensation ow) is de ned, with the challenge that in many cases such a
compensation cannot be performed by simply undoing and then redoing certain
actions. Such an exception handler can be compared to the try-catch approach
used in some programming languages such as Java; the catch is the de nition
of the possible exception and the speci cation, de ned at design-time by the
process engineer, of how to deal with it. An interesting example is provided
by the exception handling capabilities of the Yawl system [
Taken Yawl's exception handling framework as a starting point, the
innovation of this work is the automatic construction of exception handlers at run
time, i.e. the automatic synthesis of the catch blocks. Currently, exception
handlers for exceptions that have not occurred before and have not been anticipated
beforehand have to be de ned by a process administrator and this is a manual
activity. The proposed demo shows how an imperative modeling approach used
to de ne stable and well-understood processes (we will illustrate this by
extending the Yawl environment as it provides strong support for plugging in external
tools and services) can be complemented by a modeling approach that enables
automatic process adaptation and exploits planning techniques to deal with
environmental changes and exceptions that may occur during process execution. To
this end, we designed and implemented a Custom Service that allows the Yawl
execution environment to delegate the execution of subprocesses and activities
to the SmartPM execution environment [
SmartPM (Smart Process Management) [
SmartPM provides mechanisms for adapting process schemas that require
no pre-de ned handlers. To this end, we use a specialized version of the
concept of adaptation from the eld of agent-oriented programming [
The service-oriented approach that characterizes the architecture of Yawl makes
the system easily extendable and provides direct support for implementing the
Flexibility as a Service approach [
A complete integration between Yawl and SmartPM has thus been achieved by designing and implementing a Yawl Custom Service, named SmartPM Service, that enables the interaction between the two environments. The SmartPM Service enables the decomposition of Yawl tasks into processes to be executed by SmartPM. At design-time, the process designer is thus able to associate atomic tasks in the Yawl speci cation with the SmartPM Service. The service requires as input variable a process to be performed by SmartPM, de ned according to the formalism introduced in the previous section. If the SmartPM process is already available at design-time, it can be directly associated with the input variable required by the service. However, a process to be delegated to SmartPM can also be built starting from an available template, which is con gured and nalized by exploiting data produced as output by other tasks in the main Yawl process. In this case, the executable SmartPM process has to be produced as output by a Yawl task that precedes the task associated with the SmartPM Service. The domain-dependent con guration of a SmartPM template can be done either manually by a process designer or automatically by a dedicated service. As any other Custom Service, the SmartPM service implements the service-side of Interface B and is thus able to receive noti cations from the Yawl engine when a new work-item is created and delegated to the service for execution. Invoking the speci c methods provided by the engine-side of Interface B, the SmartPM Service is then able to check-out a work-item (i.e., notify the engine that the work-item is going to be executed) and execute the corresponding SmartPM input process. Once the execution of the subprocess has been completed, the service can check-in the work-item (i.e., notify the engine of execution completion), again via Interface B, along with the corresponding output. Speci cally, the SmartPM Service produces as output, among other possible values, a boolean one that indicates whether the input subprocess was successfully completed or not. Control is then passed back to the Yawl environment, which can continue to carry out the main process. 4
As an application scenario, we consider an emergency management process dened for train derailments and inspired by a real process used by the main Italian Railway Company (that is \Reti Ferroviarie Italiane"). The corresponding Yawl process to be executed is shown in Figure 1. The process starts when the railway tra c control center receives an accident noti cation from the train driver and collects some information about the derailment, including the train ID code, the GPS location and the number of wagons and passengers. Then it could be required to cut o the power in the area and to interrupt the railway tra c near the derailment scene. In parallel, after having collected additional information about the train (e.g., security equipment) and about emergency services available in the area, an emergency response team can be sent to the derailment scene. The information collected so far are then used for de ning and con guring an incident response plan, which is de ned by the set of activities to be executed directly on the eld by rst responders. Such activities can instruct rst responders to act on location for evacuating people from train wagons, to take pictures and to assess the gravity of the accident. The high dynamism of the operating environment requires that such activities are executed by the SmartPM subsystem. We assume that operators are equipped with mobile devices and coordinate themselves through the SmartPM process execution environment. Here, context-awareness and managing frequent exogenous events (e.g., bad connections between devices and operators) is crucial. Let us suppose, for example, that a re breaks out in one of the wagons. From the SmartPM point of view, it means that an exogenous event changes asynchronously the value of the current physical reality, by turning the variable that represents the status of the red wagon from \safe" to \ red". Since in the expected reality it is forecast that every wagon is safe after passengers evacuation, the SmartPM execution monitor senses that the discrepancy between the two realities is relevant and starts reasoning on the basis of the available tasks and of the capabilities provided by rst responders. The target is to nd a recovery process that reduce the above gap. In this case, SmartPM automatically builds a recovery process that concerns reaching the location of the red wagon and starting extinguishing re. Such a couple of tasks is assigned to that rst responder that provides all the capabilities needed to execute them. When every wagon is evacuated and the situation is turned to the normality, the process control comes back again to Yawl, that can execute the last task about the restoring of the railway infrastructure. A screen-cast of the proposed demonstration is available at http://www.dis.uniroma1.it/~marrella/public/DemoBPM2011.zip. 5
In this demonstration paper we outlined how an imperative modeling approach used to de ne stable and well-understood processes can be complemented by a modeling approach that enables automatic process adaptation. To this end, we designed and implemented a Custom Service that allows the Yawl execution environment to delegate the execution of subprocesses and activities to the SmartPM execution environment, which is able to automatically adapt a process to deal with emerging changes and exceptions. We demonstrated the feasibility and validity of the approach by showing the design and execution of an emergency management process de ned for train derailments. Acknowledgments. The work of Andrea Marrella, Massimo Mecella and Alessandro Russo has been partly supported by the projects TESTMED, FARI 2010, SmartVortex and Greener Buildings.