Business process management (BPM) promises an efficient and simple application of business processes. Although there are many approaches belonging to BPM, BPM suffers from the wide heterogeneity of tools and approaches and their missing integration into a homogenous workflow. In this paper, we argue for a consistent system, which supports each step of BPM. The system consists of a virtual machine, a process intermediate representation, a compiler, and analyses. Thereby, the major focus lies on the derivation of requirements on a virtual machine for business processes and its intermediate representation. In a first conceptual approach, we present our proposals for such a virtual machine.
The state of the art in research of business process management (BPM) conveys
a simple and efficient application in practice. Popular business process modeling
languages, e.g., the Business Process Model and Notation (BPMN) [
However, Koehler et al. already recognized the lacks in the life cycle [
Improvement ig n r nio t o 4.M
the majority of processes is performed manually and only an insignificant part of processes of an organization is executed by a process engine. In short: BPM would benefit from a system, which combines research approaches and which homogenizes the life cycle by new research results furthermore. In this paper, we focus on such a system and, especially, on requirements and on a conception of a homogenous virtual machine for the execution of business processes.
The remainder of this paper is as follows: At first, we explain our overall
system’s approach [
Our approach is a system, which is organized into a producer side (where
the business process is developed) and a consumer side (where the process
is then executed), inspired by Amme et al. [
Starting from these coniderations, the first step should be the definition of a (virtual) machine, which realizes the execution of a (technical) process. In e d i s r e c u d o r
P
C o n s u m e r s i d e the second step, we should develop a technical and general process description language (process intermediate representation (PIR)). Afterwards, in the third step, existing process description languages should be modified in such that the automatic transformation into the PIR is possible. It is not the goal, in doing so, that the iterative derivation of a process from an abstract model to a technical process should be automated, since the inclusion of the process analyst is essential (cf. requirements analysis in software engineering). The goal is to define limitations for which such a transformation is possible at all and to allow a stepwise refinement of the business process into a technical one. In the last step, verifiable properties of processes based on the PIR should be found and some analyses should be developed which seriously support a solution-oriented failure diagnostic. Especially, in the context of business processes, such analyses must be applied to minimize the enormous costs in cases of malfunctions.
As mentioned before, in this paper, we focus on the first two steps: a conception of a virtual machine for the execution of business processes and the definition of a PIR. For this, we derive requirements for such a virtual machine in the next section. 3
One of the most famous virtual machines is the Java Virtual Machine (JVM). The JVM supports the execution of Java Bytecode (JBC), which is generated from Java programs by a compiler. The advantage is, that also other programming languages can be compiled to JBC and, therefore, programs based on multiple programming languages are possible. A process engine should follow that approach as it grows its flexibility. For this, (R.1) a virtual machine has to allow for the execution of a process code, i.e., the conception of such a machine affiliates with the language to be executed.
Popular process modeling languages have a quite large common subset of description elements on closer considerations. (R.1.1) A virtual machine should allow the handling of basic elements to model the control flow, e.g., exclusive decisions, parallelisms, inclusive decisions, and simple tasks. (R.1.2) These elements should be extended by explicit exception and error handling, high-language loops, events and signals, as they are frequently used in processes. Furthermore, (R.1.3) the inclusion of roles also is essential to ensure organizational structures as well as access permissions and common security. Eventually, (R.2) a process modeling language should naturally enable the usage of instructions and data structures for the modification of data and branch conditions. Such instructions are currently rare in previous languages as mentioned before. (R.2.1) The reception and sending of messages besides the usage of documents and conditions naturally are very important. With traditional programming languages in mind, (R.2.2) arithmetic operations, comparisons, objects, and method invocations on objects should be part of a process modeling language to modify and compare data. For this, documents are special cases of objects. Method invocations encapsulate the access on object fields and have to be restricted on state changes of objects, in such that side effects are rare and the analysis of processes is more simple. The start of sub processes is incumbent upon the "super" process.
(R.3) A virtual machine has to be able to load processes, which are ready to be started. As re- P1 sult, (R.3.1) the virtual machine should have a separate storage for processes. Besides the stor- 1 define A age for processes, it needs a further data storage since a process being executed modifies objects. sFeupratrhaetremdo(rwe,it(hRr.e3f.e2r)entchee tdoataasisntogrleagceonsthrooul lfldobwe) P2 23 uussee AB P3 4 define B in a local and a global part as processes have commonly different parallel control flows with their own (private) data. (R.3.3) Each of those concurrent control flows should have its own local storage.
It then has only the permission to access the local storages of those control flows leading to its aFnigduursees3.datAa process defines execution, i.e., those local storages are global with regard to that single control flow. This is mandatory as some information is not safe on some points of the process. With this in mind, consider the process P 1 of Fig. 3 in BPMN. This process defines a local object A in a task and starts two parallel sub processes P 2 and P 3. Both sub processes get the global object A and have access on it (like done in process P 2). However, the process P 2 has no permission to access the local object B of process P 3 since P 3 does not start P 2 (neither direct nor indirect). Therefore, the instruction (3) use B is displaced. For this, (R.3.4) a virtual machine and the corresponding process intermediate representation should define the scopes of objects carefully.
The separation between local and global objects has less attention in previous
research. The determination of local and global objects is simple in structured
processes as it can be done like for traditional programming languages, e.g.,
by data flow analyses [
The terms of local and global objects belong to a single control flow in processes and belong not to their spatial position. In general, (R.5) sub and partial processes of a process should be able to be executed on different physical machines. That belongs to the fact, that business processes are almost implemented by the use of SOA and that they work beyond company borders. As result, (R.5.1) a virtual machine has to abstract from the underlying physical network. For this reason, our considerations have a secure business network and standardized processes in mind as, otherwise, we have to know all details about processes which is commonly not the case. The difficulty is to identify communication partners in networks and to guarantee the correct usage of state-based services. 4
The requirements mentioned before are implemented as a conception in the
following. For this, Figure 4 shows the overall structure of our proposed virtual
machine. Concluding from requirements (R.1) and (R.3), the machine owns a
process loader which loads a process and recognize the PIR part. We recommend to
use a PIR in a tree representation as such a representation has many advantages
[
As argued in previous work [
The process interpreter gets the PIR and creates a new process frame. The structure of such a process frame illustrates Fig. 5. Each frame defines the state of each (sub) process and hence stores all necessary execution information (R.3.1): A process object stack, a process extract, an in-/output, a process position pointer, and a process stack. The process stack (illustrated as arc in the figure) contains all process frames of started sub processes. Once a sub process starts,
the virtual machine creates a process frame for it. and pushs the frame on the process stack on the calling process. If the work of the sub process is done, its frame can be popped from the process stack. The “super” process can continue its work not until its process stack is empty (as, otherwise, it has to wait for the results of its sub processes). Although other implementations are possible, this stack-based approach reflects all hierarchic dependencies between different processes in a simple way. For example, Java uses a stack for its hierarchy of method invocations.
The process extract shows a subgraph of a tree representation (from the PIR) of the process that should be executed (R.3.1). That tree representation is generated by the compiler with the help of the PST (R.4). Each node of this tree has its own functionality (branch, parallelism, task, etc.) (R.1.1) - (R.2.2). Through link edges in the tree, sequences are implicit and the tree can be traversed easily. Furthermore, that fact guarantees a simple reference safety, since global objects can be derived by a backward traverse from the current executed node to
G0
IF link PAR T
T
IF
T
the root of the tree (R.3.4). The current executed node is marked by the process position pointer as the machine has to know which process’s nodes are currently executed. The execution semantics of a node depends on its functionality. For example, if the current node produces parallelism, for each of its child nodes, the virtual machine creates a process frame, passes the process object stack, determines the subtree as process extract, and pushes the frame on the current process’s process stack. After each sub process is finished, the process frames are popped from the process stack and the link node is executed afterwards. If an execution produces objects, they are pushed on the process object stack and they are locatable via this stack (R.3.3). That stack contains all objects, which the (sub) process can access (R.3.2),(R.3.4). Objects, which are stored over process borders, are stored within a permanent object storage (data base). Only processes, which have the permission, can access those objects.
If the execution arrives at an instruction for the reception or sending of a message and event, respectively, (R.2.1) the virtual machine uses the in-/output mechanism that handles the communication — regardless whether it talks locally or via a network (R.5),(R.5.1). For this, each virtual machine can provide its processes by a RESTful web service, i.e., it automatically creates an unique uniform resource identifier (URI) for each process. Another process may then contact that URI via a network and gets an URI for the resource which points to the corresponding started instance of the process. Now, it is simply possible to communicate with a state-based process via a network. However, for this, it has to know its communication partners before. 5
In this paper, we have extracted the need for a complete and consistent system for the development, analysis, and execution of processes in business process management. For this, we have focused on the conception of a virtual machine for the execution of processes. Besides the conception, we derived requirements for such a virtual machine.
In future work, these proposals have to be implemented and have to be compared to and extended for its application on business process management. Additionally, some parts of the machine (e.g., an efficient intermediate representation of a process) are in our focus of research.