Semantic Business Process Management: Applying Ontologies in BPM

Introduction

The goal of this chapter is to present how model transformation and refinement techniques can be applied to produce executable code out of business process models. The chapter shows how model-driven architecture (MDA) techniques have been applied with success to the domain of business process modeling. More in detail, once a business process has been modeled using some language, there are two main alternatives to be considered in order to run the process model using a workflow execution engine (Figure 1). The first involves the direct interpretation of the model, the second the compilation of the model into a lower-level representation amenable to more efficient execution.

Figure 1.

Interpreted (left) vs. compiled (right) process execution

As an example case study, the chapter shows how the idea of compiling business process models has been driving the design of the JOpera for Eclipse workflow management tool. JOpera presents users with a simple, graph-based process modeling language with a visual representation of both control and data-flow aspects. As an intermediate representation, the graphs are converted into Event-Condition-Action rules, which are further compiled into Java bytecode for execution.

These transformations have been fully implemented in the JOpera process compiler in a completely transparent way, where the generated Java executable artifacts are kept hidden from users at all times (i.e., even for debugging process executions, which is done using the original, high level notation). We evaluate our approach by discussing how using a compiler has opened up the several possibilities for performing optimization on the generated code and also simplified the design and positively impacted the quality of the corresponding workflow engine architecture.

This chapter introduces with an example a hierarchy of business process meta-models, leading from abstract, high level and graphical representations suitable for human consumption, down to lower-level languages geared towards efficient execution by a machine. Whereas for didactical purposes (and space limitations) the example presented in this chapter is focused on representations for modeling control-flow aspects, JOpera follows a similar approach with respect to the data flow and the resource perspective of the workflow models. We define relationships and transformations between the representations, in order to support the automatic refinement, optimization and compilation of models in one direction. We also present the abstraction operations required in the reverse direction in order to provide support for “source-level” monitoring and interactive debugging of the execution of business process models.

The rest of this chapter is structured as follows. A motivation for introducing process compilation (as opposed to interpretation and model refinement) is presented in the following Section. We then briefly enumerate in Section ‘Process Representations’ different abstraction levels and viewpoints that can be used to represent a process model that is meant to be compiled for execution using JOpera. In the following section, we show a concrete example of how a process model can be transformed between these representations. In the ‘Architecture’ Section, we present the design of the architecture of the JOpera workflow engine, emphasizing the role played by its compiler. Before drawing some conclusions, we evaluate the benefits and limitations of our approach in the ‘Discussion’ Section.

Motivation

Workflow engines traditionally play the role of business process language interpreters. Why should a compiler be used instead of an interpreter? Direct interpretation of process descriptions is the typical approach of most workflow execution engines. In the simplest case, the model description as it is specified by the process modeler is directly fed into the workflow engine, which uses it to initialize the state of a new workflow instance (e.g., stored in a database) and navigate over (or analyze) the control flow dependencies between tasks to determine the partial order in which tasks should be executed. The advantage of this approach lies in the portability of the process models (which can be interpreted by engines running on different hardware/operating system/database platforms). As with most interpreted languages, however, the disadvantage lies in the higher runtime overhead of the execution and in the complexity of the runtime engine infrastructure featuring support for exception handling, late binding, and flexible, ad-hoc execution.