Role-based Multi-purpose Workﬂow Engine

Architecture

Sebastian Richly, Sebastian Goetz, Uwe Assmann and Sandro Schmidt

Software Engineering Group, Dresden University of Technology, 01062 Dresden, Germany

Abstract. The workﬂow management systems domain today is completely frag-

mented. For each purpose various solutions with different specializations exist.

Even for standardized process languages, many different extensions and engines

exist. If new requirements, domains or standards emerge, the engines have to be

adopted. In this paper, we want to show how a workﬂow engine can be designed

to support different workﬂow languages and different domains - an extensible

multi-purpose workﬂow engine. Our approach for this kind of engine is based on

a workﬂow net engine that allows us to support most of the existing workﬂow

languages. To support different tasks of different speciﬁcations, we integrated

object roles in our engine. This extension of the object-oriented paradigm allows

ﬂexible runtime adaptations and extensions. Thus, we are able to add new domain

speciﬁc functions to our engine at runtime, even if the original process language

does not support them.

1 Introduction

A workﬂow process is the executable representation of a business process in a work-

ﬂow management system. A workﬂow management system does not only execute these

processes. Most systems support modeling, monitoring, integration of external applica-

tions, organization structures and administration, too. Workﬂow management systems

operate on workﬂow speciﬁcations. They all deﬁne a set of activities (also called tasks)

and their order of execution. Over the years, a completely fragmented workﬂow lan-

guage ecosystem has been developed. After the introduction of SOAP Web services, the

number increased further and started a new wave of research. BPEL, BPMN, ebXML

BPSS, WS-CDL are prominent representatives of these languages; XPDL, jPDL or

YAWL are examples for classic process languages from the pre-SOA era. The corre-

sponding workﬂow engines, which all differ in their speciﬁc description, deployment

and conﬁguration, are incompatible, although the language is standardized.

Another deﬁcit of today’s workﬂow engines is their missing runtime ﬂexibility. For

example, if a Web service invocation fails, current engines search for another adequate

service or initiate the predeﬁned exception handling. It is not possible to bypass the

call to an Enterprise Java Bean because this runtime adaptation is not feasible in the

engines architecture. Now, many specialized and inﬂexible workﬂow engines exist, but

there is no workﬂow management system that can be used in a ﬂexible way and for

different workﬂow languages. Exception handling techniques react only, we intent to

Richly S., Goetz S., Assmann U. and Schmidt S.

Role-based Multi-purposeWorkﬂow Engine Architecture.

DOI: 10.5220/0003011300450054

In Proceedings of the International Joint Workshop on Technologies for Context-Aware Business Process Management, Advanced Enterprise Architecture and Repositories and Recent

Trends in SOA Based Information Systems (ICEIS 2010), page

ISBN: 978-989-8425-09-6

build a proactive solution. Hence, we present a workﬂow engine design with its focus

on extensibility and runtime adaptation. The approach is based on two main techniques:

Workﬂow Net [1] / Petri Net: As pointed out in [2], the implementation of a work-

ﬂow engine with workﬂow nets has several advantages compared to Directed Acyclic

Graphs: (a) the formal semantics despite the graphical nature, (b) the state-based struc-

ture, and (c) the availability of analysis techniques (check deadlock, liveness, fairness).

Role-Oriented Programming (ROP)[3]: This approach of modeling and program-

ming systems is an extension to the classic object-oriented paradigm. The term role (or

object role) is not related and can not be compared to the classic role term in workﬂow

systems - also called Role-Based Access Control model (RBAC). In a role universe

core types (these are the classical objects) and a set of role types exist. A core object

can play a role instance, this means core type and role type are linked by the can-play-a

relationship. For example, a Person can play a Father and a Customer role. Players are

able to start and stop playing roles at runtime. Notably, roles change the behavior of

core objects (like aspects in aspect oriented programming) and are able to store data,

which is only applicable for the role and not for the core.

By combining these two essential techniques, we build a multi-purpose workﬂow

engine with ﬁve essential characteristics:

1. Support of all petri-net-compatible process languages.

2. Mix of concepts of different process languages.

3. Dynamic extension of new task types. (e.g. invoke geospacial web service)

4. Runtime ﬂexibility of the task conﬁgurations and the execution semantics.

5. Customizable description language.

This paper is structured as follows. In the subsequent section, we describe role-

oriented programming. In Section 3, we present our workﬂow model, and illustrate

the architecture and functionality of the role based workﬂow engine and explain its

implementation in Section 4. Section 5 takes a look at the current state of multi-purpose

workﬂow engines and other related work.

2 Role-oriented Programming

Designing such a ﬂexible workﬂow engine is not easy with object-oriented techniques.

For example, to support new types of tasks, two main possibilities are available. Multi-

ple inheritance is one of them, but is a rather static approach, because instances cannot

change their type dynamically. Delegation is the second possibility, but delegation does

not support type safety. Thus, we had to look for another opportunity and chose role-

oriented programming [3].

Imagine the following scenario: In a workﬂow engine there is a task which should exe-

cute something. This could be a WebService-Call, GeoWebService-Call and EJB-Call.

In object-oriented programming (OOP), at least four classes are necessary to model the

scenario in Figure 1. The task can only be an instance of one of these three specializa-

tions at runtime. A Task either can be an instance of WebService-Call or, for example,

of EJB-Call. There is no inheritance-based solution for this problem. The only way to

Fig. 1. Roles Example.

express this scenario is to use delegation, thereby losing type safety and the conceptual

unity of the core and its roles. This is, because only the type of the core object, but not

its role types are known when passing references to the player. A further feature of roles

is that objects are able to play multiple roles as it is shown in Figure 1. By introducing

the speciﬁc calls as roles having the Task as core, the Task can play all three roles at the

same time.

Another characteristic of role types is that they are founded. Founded types are

relative types that depend on a collaboration partner. The role WebSerivce-Call does

not only describe which service has to be invoked, but needs some kind of executor. For

example, a role instance of WebService-Call needs a core object of Task and the counter

role WebService-Invoker of Executor to collaborate at runtime. The WebService-Invoker

is responsible to invoke a single web service. It is the counter role of WebService-Call

and vice versa, meaning that they communicate with each other. At runtime, the engine

has to decide, which corresponding counter role to choose.

All these constraints are deﬁned conceptually. No currently available mature lan-

guage supports such constraints on the level of types. Hence, they are realized as ad-

ditional code inside of methods. The more complex the collaborations get, the harder

such implementations are to maintain. Section 3 presents a solution to this problem.

3 Role-based Workﬂow Engine

To build a general-purpose workﬂow engine, it is important to know the aspects that

have to be considered. The so-called ”aspects” of workﬂows give a guideline to the

main concepts encountered in workﬂow languages that should be supported by a multi-

purpose engine. These aspects describe the essential functionality for a workﬂow en-

gine/language. A good overview of the aspects is collected in [4] and the workﬂow

meta-model by the Workﬂow Management Coalition (WFMC).

Based on these aspects, we developed our role model. The role space is partitioned

by contexts, derived from the essential workﬂow aspects. Figure 2 shows the role and

object space on a high abstraction level. The square forms in the behavioural context

indicate core objects and the rounded forms in the contexts are symbols for roles. The

elements of the behavioural context can play the roles of the contexts which is shown

by the ”plus sign”.

3.1 Workﬂow Aspect Role Space

The core is represented by the behavioral context. This context contains the essential

object model of our base workﬂow net, which was introduced in [2].

Fig. 2. Basic Role Space.

The behavioral context represents the core context and thus contains the individuals

of the workﬂow system which can play roles. In all other aspects we expect changes,

hence they must be ﬂexible. We focused on the control ﬂow aspect because the roles

should only change the runtime behavior of several tasks, not the structure of the entire

process deﬁnition.

The roles need these individuals (see Figure 2): without them, they cannot be in-

stantiated. These are Transition, Edge, Token, Place and the Workﬂow Net itself. These

ﬁve individuals are static, that is, they cannot be removed from the engine at runtime in

contrast to roles that are able to reﬁne these individuals. Considering the workﬂow ap-

plication domain, a transition expression is often represented by a task execution. Tran-

sitions are atomic operations that, when ﬁred, consume tokens from the input places

and put tokens into the output place, which stores the token until the next transition can

be ﬁred. The tokens can be typed through the roles of the informational context.

The informational context is responsible for the data itself and the dataﬂow. All

default entities in the context are roles, which are associated with each other. The base

role interface is the datacontainer, which can refer to multiple data roles. The data

construct is designed using the classic composite design pattern. Using the recursion of

Var, structured data types can be constructed, which is necessary for BPEL or other Web

service composition languages. The other basic roles are constant, a variable value and

a data reference.The number of default implementations in these two contexts is much

higher than in the other contexts because they represent the most common part of all

workﬂow deﬁnitions.

The other contexts are not modeled in such detail and need to be reﬁned to sup-

port the different languages. The functional context describes data for the execution of

different functions in the workﬂow engine. There are only two role interfaces: function

and condition. A function could be an invocation of a Web service. The available Web

services are described in the operational context. It contains only one interface: the op-

eration. The derived service and bundle are only sample implementations to support

BPEL and JPDL.

Fig. 3. From JPDL to role space.

The organizational context describes the structure of an organization and a general

resource. This could be a human or a computer resource. Thus, we support user tasks

and automated tasks by assigning the corresponding roles to the core identities.

In addition to the classic contexts, we added two components. The ﬁrst one is the

manager. This component monitors and controles all the core-role playing and checks

all role model constraints. Because the role space should be extended at runtime, the

manager is designed as an extensible component. Other managers can register them-

selves with the central manager and they will be invoked during validation. This enables

to add new role constraints if new roles are added to the role space.

Figure 3 shows a simple JPDL process deﬁnition which had been transformed to

our role space. It shows a process to check a credit card number. The process consists

of a single transition and a token. The transition transports the token to the end. Thus,

it knows the token and can access the data it transports. The transition itself plays the

function CheckCreditCard which is associated to a Java class call. Both have access to

the DataContainter (DC) CreditCard through CheckCreditCard.

The second component is the executor, which interprets the workﬂow net and serves

as execution environment for the roles. Functions of basic roles can only be executed

in conjunction with the assigned counter roles. For that purpose, the executor provides

the counter roles for the basic roles. For example the executor provides the WebSerivce-

Invoker role for the base role WebSerivce-Call. The ”call role” serves the conﬁguration

data which is interpreted by the ”invoker role”. This scenario is shown in Figure 1. But

someone has to know, which is the correct counter role. Accordingly the role-counter

role mapping is primarily instantiated at execution time and not at design time. Thus,

the manager helps the executor allocates the referenced roles. The correct role map-

ping is expressed as simple key-value pair role = counterrole. This knowledge base

is integrated in the manager and can be extended at runtime. In Figure 3 the role associ-

ation between function CheckCreditCard and DataContainer CreditCard is created by

the executor using the basic role interfaces. The concrete communication depends on

the implementation of the roles.

Fig. 4. Example Role Space for One Transition and One Token.

3.2 Dynamic Extension

The main advantage of using roles in this context is the dynamic extensibility of the

workﬂow engine. In contrast to classic inheritance-based extensibility - provided by

decorator, composite and other design patterns - roles can be attached or detached at

runtime, with a component type. Using this characteristic, we build up a dynamic ex-

tensible workﬂow engine.

The basic roles and role interfaces are provided by the engine itself. Every extension

can use or inherit them, except if they violate the role constraints. New roles can be

added by registering a new role bundle to the engine during runtime. The role bundle

has to provide two essential components: The role registry of the bundle, where all

roles are listed and a role manager extension. The registry is used by the role runtime

to instantiate the roles. The manager extension will be automatically registered with the

central manager. This is necessary to provide a safe role space in the entire engine.

A role bundle can be detached at runtime. If so, the roles are no longer available for

all designed and running processes. But this can lead to an invalid state of the complete

engine. Thus, before the roles can be detached, every running process has to ﬁnish. This

can be done through canceling or simply by waiting for the regular ending. Canceling

is not an adequate procedure in productive systems. Hence, the solution is to delete

the registration of the role bundle, but to let it stay active and connected until all related

processes have come to an end. The advantage of this approach is that no new processes

can be started if they use the unknow roles. The validator checks the registry at every

request and returns an invalid-message to the executor if a constraint is violated or if a

role is not available any longer. In such a case, the executor will not start the execution.

3.3 Dynamic Flexibility

Figure 4 shows a modiﬁed sample conﬁguration of Figure 3. The transition Invoke Ser-

vice itself plays the function CheckCreditCard which is now associated to two opera-

tional roles: WebService and JavaClass. This means that the function can be executed by

both operational roles. Both have access to the DataContainter(DC) CreditCard through

the function CheckCreditCard. The executor and manager can decide at runtime, which

counter role they use for this function. If one call fails the executor can then call the

other one in the exception handling strategy. Our dynamic role-based engine also al-

lows us to adapt the designed processes at runtime. If we look at the example transition

in Figure 4, the transition has one function and two available operations to invoke,

namely a WebService and a JavaClass, which is located on the engines server. Both

can be invoked with the variables of the data container from the token. If the engine

supports both roles, it can choose which one of them to invoke. This can happen with a

random function or in accordance to quality-of-service parameters. For example, if the

engine recognizes that the Web service answers very slowly to requests, it can use the

Java class implementation. If the process gets transferred to another engine with only

one of the two possible roles, the executor can only invoke the one activated on the sys-

tem. Thereby, activities in the process can be designed in a more ﬂexible way. Instead

of compensation handling, if the Web service is not available or if the response time is

bad, we can model variants at design time and avoid compensation handling.

This type of ”ﬂexibility by conﬁguration” is the basic kind of adaptation. [5] presents

an approach establishing ﬂexibility/adaptation using workﬂow inheritance. This ap-

proach can be realized through our role based engine but in our approach it is ﬂexible at

runtime. An approach with inheritance is just too static. In our simple example it would

be possible to design a Task which implements both types- WebService and JavaClass

- but if a third invocation method is added we have to redesign the application. The role

approach enables a dynamic type system, which is more ﬂexible in adaptive systems.

3.4 Support of other Workﬂow Languages

As we stated in the last sections, a role-based workﬂow engine is very ﬂexible at runtime

and even during the execution of processes. But we can use these features to support

and import different workﬂow languages, too. To import several workﬂow languages in

our engine, we designed a two-step procedure. The ﬁrst step is to map the control ﬂow

structures to the workﬂow net object structure. The second step is to map resources and

the activity description.

Building on the workﬂow nets, we designed our generic importer that contains sev-

eral interface methods to be implemented by the concrete importer for each language.

These interface methods represent the two-step import. First, we import the control

ﬂow; second, if we have mapped the control ﬂow to the behavioral context, all the ac-

tivity and resource conﬁgurations have to be mapped. The mapping has to be provided

by the importer, too. The conﬁguration data has to be transferred to the roles. To ensure

the smooth import, every importer has to provide a list of required roles for a complete

mapping. If a role is not provided by the engine, it can be installed immediately (see

3.2 and 3.3).

3.5 Mix of Domain Concepts and Domain-speciﬁc Workﬂow Engine

Aside from importing different processes from different domains, another advantage

of a role-based workﬂow engine appears. The different roles, deployed in the engine,

represent different domains, such as Open Geospatial Web Service roles running side

by side with SOAP or EJB roles. If a common BPEL process has been imported to

the engine, it is no longer restrained by the BPEL corset. The process is now open for

different domains, which are provided by the roles in the engine. For example, we can

add EJB-RMI calls to a former invoke. With this mashup of different domain concepts,

we can design unique process deﬁnitions.

Fig. 5. a) Architecture and b) JavaClass Role deﬁnition.

On the basis of the presented new features of a role-based workﬂow engine, com-

pletely new application areas can be covered with one single engine design. These ap-

plication areas are divided in two parts: language- and architectural-speciﬁc areas. First

of all, the role-based engine can be adopted to many software and hardware architec-

tures. It is possible to create different variants. For example, in embedded systems, only

a basic set of roles is available because of the limited hardware; the same engine can

also be conﬁgured for a full-ﬂedged engine for high-end servers.

But if we can easily conﬁgure an engine for special hardware architectures only

by conﬁguring the role space for a use case, we can also specify our own domain-

speciﬁc workﬂow language. As described in the previous section, with a role space,

we can mix several domain concepts within one engine. The mix can be ﬁxed and

described in a special domain-speciﬁc workﬂow language. A company can now build a

special adapted language and is no longer restricted to a language that does not ﬁt the

companies requirements.

4 Implementation

We realized our role-based workﬂow engine in the Open Service Process Platform [6,

7]. This engine is developed at TU Dresden as an OSGi application.

The role-based engine is a step towards a novel kind of workﬂow engine, which af-

fects all three stated requirements. The base for all implementations is the OSGi frame-

work. In this component framework, we can deﬁne so-called bundles, which are often

called plug-ins, too. The OSGi framework is responsible for the runtime and lifecycle

of each bundle. One central concept is the extension point. These points are slots in

a bundle where other bundles can hook in to extend the original implementation. We

used this concept to deﬁne extension points for our importer, the manager extensions

and the workﬂow contexts themselves. One special feature of OSGi is the dynamic

bundle integration at runtime, which allows for the dynamic extension and adaptation

at runtime (see 3.2 and 3.3). Figure 5 a) shows the OSGi container including our bun-

dles. The OSGi runtime contains Object Teams for the role support. The base workﬂow

engine contains a workﬂow net walker (execution of the workﬂow net description), the

manager and executor including all roles. Additionally users can add new role bun-

dles containing the role description, executor role and a validator. But OSGi does not

support roles as ﬁrst-order programming paradigm. Thus, we had to integrate another

framework that supports roles. We decided to use Object Teams (short OT) [8] for this

purpose. OT is realized as an extension to the Java language that does not need a mod-

iﬁed Java Virtual Machine and introduces two new elements - Teams and Roles which

you can see in Figure 5 b). Teams are modeled like classes and they are denoted by the

additional keyword team. In our implementation, every workﬂow aspect is described as

a team with all the roles we showed in 3.1. The workﬂow net engine is implemented

in an extra OSGi bundle and is designed following the work in [2] and represents the

core context. The different contexts are represented by teams, which contain the roles.

In Figure 5 b) you can see the operational team containing one role - the JavaClassHan-

dler. The JavaClassHandler can be played by a transition. This role only contains a

description of the JavaClass (and Java methods) to call, but can not be executed alone.

The executor has a corresponding counter role to execute this description (in this case

just using the Java reﬂection API). With the described mechanisms, it is possible to

build a role-based workﬂow engine. First, we implemented a basic importer and roles

for BPEL. Then, we also built an importer for JPDL and implemented the JavaClass

role to show the ﬂexibility of our approach but the approach is not limited to these two

languages.

5 Related Work

The subject of interoperability between workﬂow languages has been discussed in dif-

ferent ways. The Workﬂow Management Coalition [9], a standardization organization

for the workﬂow domain, has deﬁned several interfaces for workﬂow systems as well

as one for the import and export of workﬂow deﬁnitions. They use a common workﬂow

model for the exchange, like XMI for UML models. This common model is the well

known XPDL.

The extensible routing language - XRL - also bases on XML with a DTD. In sev-

eral papers [10, 11] the authors present the basic functions (comparable to BPEL) and

several transformations to workﬂow nets. Processes are executed by a workﬂow net

engine. New elements can be added through changing the DTD. In contrast to our ap-

proach the changes can only be done at design time and the engine does not support

runtime ﬂexibility through different conﬁgurations.

Runtime adaptation is also possible with some aspect oriented approaches like

AO4BPEL[12]. These approaches allow to weave in new tasks or to replace designed

behavior, but these approaches are limited to speciﬁc languages and engines and do not

allow to produce customizable workﬂow deﬁnitions.

Other approaches can be found in different areas. In [13], the authors present a portal

supporting the interoperation between different workﬂow languages in the grid domain.

They use an XSLT converter, which translates between the workﬂow languages.

6 Conclusions

In this paper, we presented an approach for a new type of workﬂow engines. Based on

the powerful combination of workﬂow nets and role-based programming, we showed

an architecture for more ﬂexible and integrative workﬂow engines. We do not intro-

duce a new workﬂow language or a new interoperability model, but we present a sim-

ple workﬂow net model enhanced with a basic role model that can be easily extended

at runtime. Through this combination, we are able to support unique features: (1) Dy-

namic extension by new constructs or task deﬁnitions, (2) runtime adaptation of the role

conﬁgurations and the execution semantic, (3) support for many workﬂow languages,

and (4) the mix of concepts of different domains.

We implemented our approach in the Open Service Process Platform using OSGi

and Object Teams. In our future work we try not only to adopt the runtime behavior of

the worklfow but also on non-functional aspects such as security which where not in

the focus of the paper. In a future work we will extend our workﬂow engine to support

workﬂow nets, which overcome some disadvantages of pure workﬂow nets.

References

1. Van Der Aalst, W.M.P.: Veriﬁcation of workﬂow nets. In: ICATPN ’97: Proceedings of

the 18th International Conference on Application and Theory of Petri Nets, London, UK,

Springer-Verlag (1997) 407–426

2. Pellegrini, S., Giacomini, F.: Design of a petri net-based workﬂow engine. In: GPC-

WORKSHOPS ’08: Proceedings of the 2008 The 3rd International Conference on Grid and

Pervasive Computing - Workshops, IEEE Computer Society (2008) 81–86

3. Steimann, F.: On the representation of roles in object-oriented and conceptual modelling.

Data Knowl. Eng. (2000) 83–106

4. Jablonski, S.: Mobile: A modular workﬂow model and architecture. In: in Proceedings of

the 4th International Working Conference on Dynamic Modelling and Information Systems.

(1994)

5. Van der Aalst, W.M.P., Jablonski, S.: Dealing with workﬂow change: identiﬁcation of issues

and solutions. International Journal of Computer Systems Science and Engineering (2000)

267–276

6. Richly, S., Habich, D., Ruempel, A., Buecke, W., Preissler, S.: Open service process platform

2.0. In: Proceedings of the 2008 IEEE International Conference on Services Computing

(SCC 2008, 8-11 Jul, Hawaii, USA). (2008)

7. Richly, S., Buecke, W., Assmann, U.: A bdi-based reﬂective infrastructure for dynamic

workﬂows. Enterprise Distributed Object Computing Workshops, International Conference

on (2008) 112–119

8. Herrmann, S.: Object teams: Improving modularity for crosscutting collaborations. In:

NetObjectDays. (2002) 248–264

9. Hollingsworth, D.: Workﬂow management coalition speciﬁcation: the workﬂow reference

model. Technical report, WfMC speciﬁcation (1994)

10. Van der Aalst, W.M.P., Kumar, A.: Xml - based schema deﬁnition for support of interorga-

nizational workﬂow. Information Systems Research (2003) 23–46

11. Verbeek, H.M.W., Van Der Aalst, W.M.P., Kumar, A.: Xrl/woﬂan: Veriﬁcation and extensi-

bility of an xml/petri-net-based language for inter-organizational workﬂows. Inf. Technol.

and Management (2004) 65–110

12. Charﬁ, A., Mezini, M.: Aspect-oriented web service composition with ao4bpel. In Zhang,

L.J., ed.: ECOWS, Springer (2004) 168–182

13. Huang, L., Akram, A., Allan, R., Walker, D.W., Rana, O.F., Huang, Y.: A workﬂow por-

tal supporting multi-language interoperation and optimization: Research articles. Concurr.

Comput. : Pract. Exper. (2007) 1583–1595