Compiling Business Process Models into Executable Code

Compiling Business Process Models into Executable Code

Cesare Pautasso (University of Lugano, Switzerland)
Copyright: © 2009 |Pages: 120
DOI: 10.4018/978-1-60566-288-6.ch015
OnDemand PDF Download:
$37.50

Abstract

Model-driven architecture (MDA), design and transformation techniques can be applied with success to the domain of business process modeling (BPM) with the goal of making the vision of business-driven development a reality. This chapter is centered on the idea of compiling business process models for executing them, and how this idea 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 efficient execution. These transformations of process models are performed by the JOpera process compiler in a completely transparent way, where the generated executable artefacts are kept hidden from users at all times (i.e., even for debugging process executions, which is done by augmenting the original, high level notation). The author evaluates his 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 the corresponding workflow engine architecture.
Chapter Preview
Top

Introduction

New technologies, such as Web services and the semantic Web, are currently available for the development of information systems, where processes may be defined as a composition of services which can be selected dynamically to provide advanced personalized value added services and reactive/proactive systems. In order to employ the full potential of Web services, appropriate models and methods for service-based information systems and for workflows are being developed.

When considering service design and development, first of all the goals of designing a service need to be clarified, as several alternatives are possible [Pernici 2005]:

  • Integration (EAI): In this case the goal is to integrate different information systems in order to create new cooperative applications. It is important to define the granularity at which services are considered, and how existing systems are wrapped to offer their functionalities in a cooperative information system through a service-oriented approach [Papazoglou and Van den Heuvel 2006].

  • Redesign (e.g., in mobile, multi-channel applications): The goal is to modify existing functionalities in order to offer them in a variable environment setting, for instance allowing users to interact with the system from a variety of different devices and from different places. To provide the requested functionality, redesign has to take into consideration quality of service parameters and their variability and to manage the services dynamic selection and binding.

  • New added-value services: New services are created as a composition of existing services. Composition allows reusing services in several contexts and for different applications. Composition may be performed following a fixed process schema, or designing the composition structure dynamically.

The service oriented approach introduces some new issues in the process design strategies in comparison with the traditional software design. For example, the granularity of the service has to be defined and the interface of the service should clearly state all the functional and non functional properties. Possible solutions to some design problems have been proposed by using reference models and ontologies. Regarding models, the need for models with a rich set of elements as a basis for the design process is a clear prerequisite for all design methodologies. Models should include a variety of aspects, and in particular:

  • Business services modeling

  • Service composition and coordination

  • Interaction between clients and providers

  • Service modeling with its Quality of Service (QoS) properties

  • Transactional properties

  • Self description (metadata).

For each model element, a modelling language should be defined. Existing background in the area, which can be a basis for modelling Web services include the WS-stack, UML2, BPMN, EPC, Aris, and so on. No clear and unique background still emerges.

In order to better understand the complexity of Web services design and of the corresponding processes design, the classical life cycle is represented in Figure 1 [Pernici 2005]. Here, the typical phases are:

Figure 1.

Service design phases

Key Terms in this Chapter

Event-Condition-Action Rules: The “ECA” structure for specifying rules originates from active databases, where actions on the data are triggered by the occurrence of particular events subject to the satisfaction of the associated condition (a logical test on properties of the event itself).

Compiler: A software tool which transforms programs written in a source language into executable code for a target platform/architecture. Compilation may occur before a program is executed, but also—in the case of just-in-time compilers—during the execution of a program.

Process Monitor: A software tool used to watch the progress of the execution of one or more business processes.

Data Flow: Activities of a business process may exchange data during the execution of the process. The data flow graph of the process connects activities that exchange data and -- in some notations -- may also represent which input/output parameters of the activities are involved.

XML Serialization: A machine-processable, persistent, representation of a process model that uses the XML syntax to store the model’s information.

Control Flow: The flow of control defines a partial order relationship between the activities of a business process model, specifying in which temporal order they will be executed.

Model-Driven Engineering: This software development methodology is centered around the notion of modeling (as opposed to coding) to be the primary activity in the software development process. Model refinement, transformation and code generation techniques are then applied to produce executable software artifacts in a semi-automatic way.

Complete Chapter List

Search this Book:
Reset