FROM PROCESS TO SOFTWARE SYSTEMS’ SERVICES

Using a Layered Model to Connect Technical and Process-related Views

Christian Prpitsch

Institute for Computer Science and Business Information Systems

University of Duisburg–Essen, Germany

Keywords:

Abstraction, layer, process support, workﬂow, reusable subprocess, collaboration, e-learning.

Abstract:

A layered model is a solution to the problem of two disjunct points of view on the same problem. One group

has a technical background but does not know much processes. The other group’s members have a process

perspective. This contribution introduces a meta–model consisting of three layers. The outer ones represent

the disjunct points of view. The inner one contains elements of both other layers and combines them. It also

contains a system–independent scripting language to automatically conﬁgure software systems.

1 INTRODUCTION

The administration of collaborative courses in a learn-

ing environment is a collection of complex and re-

peated tasks. A collaborative course is in this contri-

bution a course where learners build groups and do

some exercises. Administration is done by the lec-

turer and technican, called acotrs, in terms of watch-

ing and moderating the learning process and taking

care of software systems. We answer the question

what language or meta–model should be used for sup-

porting both lecturer and technicans.

The example scenario is derived from e–learning

but the presented model can be transfered to many

other use cases. Therefore one has to interchange ac-

tors and the workﬂow itself. We evaluated the model

by using it in a scenario of cooperative writing. It is

well known to most scientists

Users not being familiar with complex informa-

tion systems often have difﬁculties to make decisions

about the usage of software. They usually do not have

enough competencies and experience in the evalua-

tion of systems requirements. System administrators

in general belong to a group of staff not being familiar

with complex workﬂows in different business cases.

So they need a model to exchange requirements and

opportunities.

This contribution starts with a short overview

about existing meta–models on both sides. Then

we outline a scenario of a collaborative course in e–

learning. With this scenario we try to model both the

perspective of a workﬂow as seen by the lecturer and

the perspective of software systems and services as

seen by the technicans with the shown approaches.

This is either not possible or does not meet the needs.

After that we present our approach of connecting both

perspectives by deﬁning an additional layer of ab-

straction. In the last section we shortly describe the

improvements introduced by our approach.

2 RELATED WORK

This section summarises some selected approaches of

modeling the perspectives business process and soft-

ware systems as described in other research projects

on this matter. We selected them by relevance on their

speciﬁc area. A business process is related to a busi-

ness case with deﬁned start and termination. A work-

ﬂow is deﬁned as the technical support of a business

process. The workﬂow contains subprocesses doing

small subtasks (Mueller, 2005, 8). In this contribu-

tion we use the term workﬂow to express the model

of a complete business case and subprocess for sub-

tasks. A workﬂow is independent of concrete soft-

ware systems but uses services for describing them.

It can be used in different environments by assigning

different software systems. Subprocesses are treated

as patterns and can be reused in many workﬂows.

When we compared many different workﬂows in

the course of the study there were several common

patterns concerning parts of the process. Some of

these patterns belong to cooperative writing as de-

298

Prpitsch C. (2008).

FROM PROCESS TO SOFTWARE SYSTEMS’ SERVICES - Using a Layered Model to Connect Technical and Process-related Views.

In Proceedings of the Tenth International Conference on Enterprise Information Systems - ISAS, pages 298-304

DOI: 10.5220/0001703202980304

 SciTePress

scribed by (Lowry et al., 2004). They show several

patterns how collaborative work can take place in the

task of writing a text. Controlling of writing tasks is

explained in (Posner and Baecker, 1992).

The ﬁrst approach is the Uniﬁed Activity Manage-

ment (UAM) by (Harrison et al., 2005) and (Cozzi

et al., 2006). It is based on an artefact named ac-

tivity which brings semantics and structure to a given

problem and consists of metadata and assignments.

The activity is a layer of abstraction in the workﬂow.

It is visible and editable by every user. So the user

is aware of the activity and the usage of an activity

management system. They include references on re-

sources and users / people. Every user inerts a role

in the context of the activity. The approach UAM is

designed to support a number of users while perform-

ing cooperative tasks. UAM is used as a tool to co-

ordinate and control a business process. There is an

evaluation of UAM in (Cozzi et al., 2006, 708) with

a case study of accomodation for new internees at a

scientiﬁc institution.

The standard for orchestration of web services

Web Service Business Process Execution Language

(BPEL) by OASIS (OASIS, 2007) deﬁnes a language

to orchestrate existing web services with connection

elements derived from process deﬁnition. XML is

used as meta–language. BPEL does not specify any

graphical representation. The Business Process Mod-

elling Notation (BPMN) (Object Management Group,

2007) by OMG is one language to solve this problem.

The metamodel consists of tasks, (sub–)processes and

control sequences arranged in so called swimlanes. In

BPEL there are abstract and concrete workﬂows spec-

iﬁed. A concrete workﬂow is ready to be executed by

a workﬂow processing engine. Any abstract workﬂow

uses the same syntax and semantics as a concrete one

but there is some information missing so that it can

not be executed. A good comparison is the object–

oriented pattern of abstract and concrete classes.

There is an extension to BPEL called BPEL for

People (BPEL4People) (Agrawal et al., 2007) by an

industrial consortium. It adds human beings into the

BPEL model. Users can be grouped to roles. They

carry out activities. This extension is ignored because

BPEL needs a central workﬂow engine and therefore

does not meet the requirements.

Abstract and concrete workﬂows are also men-

tioned by (Deelman et al., 2003). The goal of that

concept is to create workﬂows which are deﬁned in

terms of services instead of systems. The term “work-

ﬂow” means a complex process of performing data

intensive operations on grid environments. An ab-

stract workﬂow is not runnable within a workﬂow en-

gine. It has to be transfered into a concrete one by

replacing the services with concrete systems provid-

ing those services.

Modelling of business processes is done by the

usage of Event–Controlled Process Chains (EPCs)

as ﬁrst mentioned by (Keller et al., 1992). An EPC

consists of alternating events and business–functions

connected by control sequences. They are used in

an extended Version for describing business cases for

enterprise ressource planning systems. A business–

function is carried out by an anctor which can be a

human being or any technical system. There is an

approach to use EPCs as graphical representation of

BPEL by (Mendling and Ziemann, 2005).

3 SCENARIO

This section shows a shortened scenario from the con-

text of e–learning. It is used to get requirements on a

meta–model for modelling this kind of scenarios. The

author has some years of experience with the scenario

in virtual study course. The scenario is a course about

basic principles in programming. The students get a

simpliﬁed real–world problem and have to create a

runnable program. They are requested to build small

groups of 3 to 5 students having mixed qualiﬁcations.

The actors in the scenario are a lecturer, a tech-

nican per software system, and many students. On

the technical site there are one Learning Manage-

ment System (LMS) and one programming environ-

ment (PE). All the learning content is contained in the

LMS. While creating the course for the ﬁrst time, the

lecturer made a workﬂow of how collaboration will

take place, which people are involved, and where to

get the technical resources. This workﬂow is then

written on a piece of paper. Every term it is executed

by hand. The workﬂow is illustrated in ﬁgure 1.

Students have to form groups and tell the lecturer

by e–mail about that to manually create correspond-

ing usergroups in the LMS. The disadvantage of this

subtask is the media break while using e–mail (Whit-

taker and Sidner, 1996; Fisher et al., 2006). Every

group gets their own workspace in the LMS and PE

where only group members and lecturers are allowed

to step in. In the PE the lecturer has to order the cre-

ation of the workspace including all necessary soft-

ware by the administrator. Thereafter the PE is ready

to be accessed by the students. For equality reasons

all workspaces have to be identically prepared. After

the students have ﬁnished their exercise they submit

the solution by mail. The lecturer grades the submis-

sions and the scenario is terminated.

The lecturer had to decide what systems to use for

the course. There are requirements hidden in the non–

FROM PROCESS TO SOFTWARE SYSTEMS' SERVICE - Using a Layered Model to Connect Technical and

Process-related Views

299

students form

groups

create

user-groups

create

environment

create

workspace

exercises

submit

solution

per group

technican

students

technican

lecturer

Figure 1: Process with actors while doing the course.

formal workﬂow. The workﬂow itself is not able to

be executed automatically. The abstracted workﬂow

of the course “Introduction into Programming” shares

process patterns (Lowry et al., 2004) with any course

where students have to write a text in groups. In a

more complex scenario there are additional systems

to be integrated in the workﬂow (e.g. version control).

This is the simplest form of the workﬂow. To re-

duce manual interaction and make it more realistic,

we add some more process control. It is derived from

IMS Learning Design (LD) (IMS Global Learning

Consortium, 2003). There are special dates, when ex-

ercises have to be completed. After these dates there

are sample solutions put into a common workspace

to be viewed by everyone. The same pattern is to be

used if students are requested to bring their work to a

deﬁned state until a set date. This is a task in the PE,

where the LD–player is not available. In the scenario

of collaborative writing there are dates to synchronize

the work, as shown by (Lowry et al., 2004, 74ff).

We discovered in this scenario some weeknesses

concerning process management. First, the workﬂow

is not persisted in a formal way. Therefore, it is im-

possible to automatically execute it. It is not efﬁ-

cient to create it manually for supporting every sin-

gle course. The repeated tasks to support every group

is simple to execute but creates a lot of effort in sum

of all groups. A central controlling instance is to be

avoided because autonomy is left at the systems. The

following requirements are needed to make a solu-

tion:

• workﬂow is in a formal notation

• minimal effort to implement into existing soft-

ware

• no central controlling instance

• repeatable tasks must be supported

• reusable subprocesses to be used while modeling

• ﬂexible adding of reusable artefacts

• support of time–based actions

4 EVALUATION OF EXISTING

APPROACHES

In this section we will discuss the existing ap-

proaches. The evaluation is done by comparing the

meta–models from section 2.

All presented standards and approaches do not

provide a solution for modelling the scenario from

both technical and process–related perspective. The

connection between a technical model consisting of

software systems and their provided services and a

process–related one with actors and tasks is not avail-

able yet. In EPC there is an ability to map a process

on a BPEL–model as mentioned by (Mendling and

Ziemann, 2005). As mentioned in the scenario we

must not have one central application for controling

the workﬂow. If we would use BPEL we had to use a

so called workﬂow engine (OASIS, 2007). Therefore

these technologies to connect process and technical

perspective are not usable in our context because of

BPEL.

Both (Deelman et al., 2003) and BPEL (OASIS,

2007) use a term “abstract workﬂow” but in a differ-

ent manner so both are not compatible. We deﬁne an

abstract workﬂow the same as (Deelman et al., 2003).

The deﬁnition from BPEL is used for a partly con-

crete workﬂow.

The UAM approach addresses mainly endusers.

They have to work on the artefacts and therefore sys-

tems require changes which means additional effort

while implementing it. In the scenario from section 3

is no need to present artefacts to a user. In our experi-

ence there have often been difﬁculties while present-

ing too much new technology to a user. Therefore the

solution’s artefacts have to be invisible to some roles

like students.

Our additional requirement of time–based actions

cannot be modeled from both perspectives. The tech-

nical models use timers with very short duration (sec-

onds to hours) but usually do not give access to long–

ICEIS 2008 - International Conference on Enterprise Information Systems

300

run dates like three months or so. The process–

oriented ones provide timers “until a date” or “during

a period”. Both are incompatible.

5 SOLUTION BY ADDING

ABSTRACTION

Our solution sections the problem from section 3 into

layers as presented in ﬁgure 2. The idea is to use

two layers, each of them to be used by one group.

Groups are divided by tasks and competencies. Then

we introduce a third layer between them to be used

as a connection. The upper layer is used by a group

with competencies in formal description of business

processes. In the above scenario this is the lecturer.

The lowest layer is to be used by technicans with

high competencies in administrating software sys-

tems. They are also able to describe services provided

by their systems. We use the middle layer to create a

connection between both layers. Figure 3 shows the

process by using our model. It starts with the initial

creation and terminates when the course is ready to be

used by a class. The next paragraphs will explain the

three layers and their connections.

system class

software

system

workﬂow

moodle

progr.

env.

LMS library

library

system

Figure 2: Layers of abstraction with some items.

The layer of software systems represents any sys-

tems or applications provided for use in the later

mentioned workﬂow. Usually a system is imple-

mented as a web accessible application but we also

assume standalone applications and systems without

user–interface belonging to this. Any application has

to provide services. The deﬁnition of web services

(SOAP by W3C) explains a service as a machine–to–

machine service without any direct user–interaction.

To have a complete description of all provided ser-

vices we have to add the deﬁnition of user–interfaces

as well. While web services are to be deﬁned by

WSDL the users’ services are to be deﬁned by a more

task–related notation in normal language. To get the

available services of one special system it has to im-

plement a service called explain which provides all

needed metadata about the system.

The goal of deﬁning web services by the Web

Services Deﬁnition Language (WSDL) is to enable

inter–system–operability. In order to achieve the in-

teroperability of system classes one has to deﬁne a

set of services to be provided by every system of a

class. There are also projects dealing with this: The

MISTEL project (Bopp et al., 2006), the JAVA Con-

tent Repository API Standard (Nuescheler and Pie-

gaze, 2006) and the IMS Resource List Interoperabil-

ity (IMS Global Learning Consortium, 2004). These

projects describe some systems, abstract from their

special implementation by the deﬁnition of services

and interchangable formats.

We deﬁne a system class by its provided ser-

vices. Every class has to implement a service set

containing mandatory and optional services. Differ-

ent system classes do not need to have disjunct ser-

vice sets. There are some groups of services as pre-

deﬁned classes, e. g. LMS, PE and Document repos-

itory. Their users’ services are well known, so we do

not mention them again. The metadata provided by

the explain–service refers to system classes and tells

about optional services. One software system can be-

long to several system classes if it fulﬁlls their service

sets. System classes have to be deﬁned from the per-

spective of a user and not of a technican. Therefore

the grouping of services is done along with the deﬁni-

tion of tasks one could do with the system class (e. g.

authoring) or that could be done by the system class

itself (e. g. versioning).

The most abstract layer is the workﬂow consisting

of subtasks and control sequences (e.g., conditions,

sequences, break points). Substasks consist of ser-

vices provided by system classes. So it is matched on

one or more system classes. The creator of a work-

ﬂow is in general a user not being familiar with tech-

nical details. It is sufﬁcient to describe a real–world

workﬂow in terms of services and control sequences.

They need competencies in describing a subtask in

terms of services and control sequences. They can

use predeﬁned subtasks as well. Their task is to make

use of their competencies and experiences in creating

and rating workﬂows in their ﬁeld of practice. Then a

technican can decide what member of a system class

to use while performing this workﬂow. The shortened

process from creation of any process until its usage is

shown in ﬁgure 3.

FROM PROCESS TO SOFTWARE SYSTEMS' SERVICE - Using a Layered Model to Connect Technical and

Process-related Views

301

There is no “workﬂow engine” (see BPEL) or any-

thing alike necessary to execute the workﬂows. They

are created, transformed and distributed by a stand–

alone or shared application. Then the workﬂow is ex-

ecuted peripheral by every system. It is intended by

our approach to step in systems as less as possible to

keep the implementation simple. Any permissions are

left under control of the system itself. Therefore we

decided not to use a central workﬂow engine. Now we

will explain how the workﬂow is put into the systems.

The disadvantage of implementing a special en-

vironment for every single usergroup is addressed by

the automation of workﬂow–implementation. There-

fore the formal description of the workﬂow and deci-

sions what systems to use are needed. A formal and

reusable deﬁnition of how to set up the requested en-

vironment is needed. Then an engine is able to create

the complete environment or even parts of it. In the

scenario from section 2 we use the ability for creating

parts of the environment. The usergroups are known

to the workﬂow–engine so it can automatically create

the environment.

The technology to be used for this scripting is at

the time not ﬁnally deﬁned. We actually use a for-

mat similar to XSLT to deﬁne the workﬂow indepen-

dent from systems. This ﬁle is called workﬂow ﬁle.

It contains also the conﬁguration parts needed to cre-

ate environments (see scenario). This conﬁguration is

very simple because it is a goal to be independent of

software systems and just depend on system classes.

One of the commands is create workspace along with

some arguments. The second part is an XML–ﬁle

containing actual data like usergroups and systems’

metadata we named data ﬁle.

The technical process of instantiating a workﬂow

is as follows: The workﬂow ﬁle “is applied” on the

data ﬁle. The result is a script composed of the work-

ﬂow with actual conﬁguration details inside, as e. g.

systems and usergroups. There are some parts named

conﬁg in this ﬁle. They are pushed to the systems

named inside. A system receives this command–

script and either executes it directly or transforms it

before. The system can apply an XSLT–ﬁle on it and

gets a system–speciﬁc script because the script is still

in XML. The format of this speciﬁc script has no im-

pact on the other systems involved in the workﬂow.

Changes can occur while operating software sys-

tems. Our model only needs few maintenance as ex-

pleined in the following. Adding a system requires

to classify it into a system class. Then the system is

ready to be used. When deleting a system it has to be

deleted in all system classes, too. Replacement of a

system requires the update of its name and metadata

in all system classes. Update of a system can require

the same procedure. When a system disappears all its

occurences in workﬂows can be found automatically.

deﬁnes

process

names

services

maps both

writes speciﬁc

items (groups,..)

creates scripts

per system

starts course

technican

lecturer

deﬁnes

software systems

deﬁnes

system classes

lecturer

technican

Figure 3: Deﬁning a process in our model.

The communication between systems is done via

web services SOAP. Such an architecture is called a

service–oriented architecture as deﬁned by (Conrad

et al., 2006). The decision is based on platform inde-

pendency of this kind of middleware. The second rea-

son is the usage of HTTP as a transport protocol. Both

the user–interface (in most cases a web GUI) and the

machine interaction can be carried by the same pro-

tocol. As mentioned in the former paragraph we use

XML to exchange information so it is consequent to

transport them by a technology based on XML itself.

Some services are globally deﬁned. The most im-

portant service is the explain–service, as mentioned

above. Each two systems have to agree on the exact

speciﬁcation of the content they interchange. In case

of documents this would be the metadata set. There is

a suitable solution of systems communication deﬁned

by the project MISTEL in (Bopp et al., 2006).

6 DISCUSSION OF THE

APPROACH

The transformation is under supervision of the user

who has to make decisions. None the less users are

ICEIS 2008 - International Conference on Enterprise Information Systems

302

provided with proposals of suitable options. The dif-

ferent concept of abstract workﬂows from BPEL is

used by our approach to provide the ability for partly

creation of an executable workﬂow. We use the same

deﬁnition of abstract as (Deelman et al., 2003). A

newly created workﬂow is abstract by deﬁnition. It is

transformed into a runnable workﬂow by users with

assistance of the workﬂow management application.

In this task we use the deﬁnition from BPEL to store

partly deﬁned workﬂows.

Our approach is focused on supporting the role

lecturer. Technicans also use the approach to support

lecturers by caring about their systems. In our expe-

rience it is favourably to present details only to staff

really needing them, especially technical facts. In the

scenario from section 2 the artefacts are transparent

to users of the role student. The automatic conﬁgu-

ration of many instances of the same software system

is daily work to many system administrators. They

often use self–created scripts or management–tools to

improve their work. With usage of our approach those

scripts are deﬁned in a system–independent language.

The initial effort to create an environment imple-

menting our approach depends on the systems which

have to be integrated. Some licenses of commercial

systems prohibit the necessary extensions so they can

not be used. One working solution is the creation

of proxy systems transforming SOAP calls into the

systems internal format. A web service stack based

on HTTP is available to nearly all programming lan-

guages, especially the widely used JAVA, PHP and

Microsoft .NET.

We improved the scenario from section 3 by cre-

ating a model in terms of the abstraction model from

section 5. The ﬁrst improvement takes place before

the course starts. The lecturer creates a model of

the workﬂow and passes it to technicans in order to

check system classes and available software systems

for existance. This model can be reused partly or in

whole by other lecturers who use a similar workﬂow.

They just have to change few artefacts or control se-

quences. Conﬁgurations for systems are derived from

the model. They are passed to the systems and a

course is ready to start.

After the ﬁrst step of the course is completed there

are usergroups. The lecturer receives them from the

LMS in an XML format. This ﬁle is merged with

the model to get speciﬁc conﬁguration–commands.

These commands are passed to the intended systems

via their conﬁguration web service. This is the main

improvement if the workﬂow would be used with only

one course. Before a decision is made about using

our approach or not it has to be calculated if the ef-

fort to create the scenario is less than the saved time

while creating environments for every single user-

group. The step of submission can be done automati-

cally by setting a timer. When it expires there is no

more work on the exercise possible, all results are

packaged and sent to the lecturer.

The effort on doing repeated tasks decreased. Stu-

dents did not notice the improvement but had a proﬁt

by faster creation of their groups with equal environ-

ments. As mentioned at the beginning of section 2

it is possible to transfer this scenario on collaborative

writing. Patterns identiﬁed by (Lowry et al., 2004)

are to be predeﬁned and can be reused in any future

workﬂow.

7 CONCLUSIONS

This contribution shows a solution as model a busi-

ness process on a high level and attach technical de-

tails expressed as system classes. We deﬁned an inter-

face between the process–oriented meta–model used

by people creating or describing business processes

and the technical description of software systems.

While decomposing complex business processes into

smaller subprocesses we create reusable artefacts. As

supporting several processes we get many predeﬁned

artefacts so the chance on having something nearly

ready to use rises.

Future research will be looking for even more ab-

straction from technical details. The goal is to allow

ad hoc networks (or grids) not being installed in just

the one organisation but using services and content

from many systems. In the future the question should

be what to combine to reach a goal and not what to

create. Within the context of service–oriented archi-

tecture and service–component–oriented architecture

we think we can add some beneﬁt.

ACKNOWLEDGEMENTS

This work is funded by the Deutsche Forschungs-

gemeinschaft (DFG), section Scientiﬁc Libraries,

see www.dfg.de and the MISTEL project’s website

www.systemkonvergenz.de.

REFERENCES

Agrawal, A., Amend, M., Das, M., Ford, M., Keller,

C., Kloppmann, M., Koenig, D., Leymann, F.,

Mueller, R., Pfau, G., Ploesser, K., Rangaswamy,

R., Rickayzen, A., Rowley, M., Schmidt, P., Trick-

ovic, I., Yiu, A., and Zeller, M. (2007). Ws–bpel

FROM PROCESS TO SOFTWARE SYSTEMS' SERVICE - Using a Layered Model to Connect Technical and

Process-related Views

303

extension for people. Speciﬁcation Vers. 1.0, online:

http://download.boulder.ibm.com/ibmdl/

pub/software/dw/specs/ws-bpel4people/

BPEL4People_v1.pdf.

Bopp, T., Hampel, T., Hinn, R., Pawlowski, J., and Prpitsch,

C. (2006). Mistel – an approach to access multiple

resources. In Manolopoulos, Y., Filipe, J., Constan-

topoulos, P., and Cordeiro, J., editors, Proceedings of

the 8th International Conference on Enterprise Infor-

mation Systems – ICEIS 2006, pages 319 – 322, Pa-

phos / CY. INSTICC, INSTICC.

Conrad, S., Hasselbring, W., Koschel, A., and Tritsch, R.

(2006). Enterprise Application Integration. Spektrum,

Heidelberg / DE.

Cozzi, A., Farrell, S., Lau, T., Smith, B. A., Drews, C.,

Lin, J., Stachel, B., and Moran, T. P. (2006). Activity

management as a web service. IBM Systems Journal,

45(4):695 – 712.

Deelman, E., Blythe, J., Gil, Y., Kesselman, C., Mehta, G.,

Vahi, K., Blackburn, K., Lazzarini, A., Arbree, A.,

Cavanaugh, R., and Koranda, S. (2003). Mapping

abstract complex workﬂows onto grid environments.

Journal of Grid Computing, 1(1):25 – 39.

Fisher, D., Brush, A. J., Gleave, E., and Smith, M. A.

(2006). Revisiting whittaker & sidner’s ”email over-

load” ten years later. In CSCW ’06: Proceedings of the

2006 20th anniversary conference on Computer sup-

ported cooperative work, pages 309 – 312, New York

/ USA. ACM Press.

Harrison, B. L., Cozzi, A., and Moran, T. P. (2005). Roles

and relationships for uniﬁed activity management.

In Proceedings of the 2005 international ACM SIG-

GROUP conference on Supporting group work, pages

236 – 245.

IMS Global Learning Consortium (2003). Ims learn-

ing design information model. Speziﬁkation, IMS

Global Learning Consortium Inc., online: http://

www.imsglobal.org/learningdesign. Ver. 1.0.

IMS Global Learning Consortium (2004). Ims resource

list interoperability information model. Speziﬁka-

tion, IMS Global Learning Consortium Inc., online:

www.imsglobal.org/rli. Ver. 1.0.

Keller, G., Nuettgens, M., and Scheer, A.-W. (1992).

Semantische prozessmodellierung auf der grundlage

ereignisgesteuerter prozessketten. Veroeffentlichun-

gen des Instituts fuer Wirtschaftsinformatik, Univer-

sity Saarbruecken / DE, 89:1 – 31.

Lowry, P. B., Curtis, A., and Lowry, M. R. (2004). Building

a taxonomy and nomenclature of collaborative writ-

ing to improve interdisciplinary research and practice.

Journal of Business Communication, 41:66 – 99.

Mendling, J. and Ziemann, J. (2005). Transformation of

bpel processes to epcs. In Nuettgens, M. and Rump,

F., editors, Proceedings of EPK 2005, pages 41 – 53,

Hamburg / DE. CEUR Workshop Proceedings Vol.

167.

Mueller, J. (2005). Workﬂow–based Integration. Springer,

Berlin / DE.

Nuescheler, D. and Piegaze, P. (2006). Content repository

api for java technology speciﬁcation - java speciﬁca-

tion request 170. Technical report, JSR 170 Group.

OASIS (2007). Web services business process ex-

ecution language. Standard 2.0, OASIS, on-

line: http://docs.oasis-open.org/wsbpel/2.

0/OS/wsbpel-v2.0-OS.pdf.

Object Management Group (2007). Business process

modeling notation speciﬁcation. Speciﬁcation v

1.2 draft, Object Management Group (OMG), on-

line: http://www.omg.org/cgi-bin/apps/doc?

dtc/07-06-03.pdf.

Posner, I. R. and Baecker, R. M. (1992). How people

write together. In Proceedings of the 25th Hawaii

International Conference on System Sciences, vol-

ume 4, pages 127 – 138. online: http://www.kmdi.

toronto.edu/rmb/papers/D26.pdf.

Whittaker, S. and Sidner, C. (1996). Email overload — ex-

ploring personal information management of email. In

Proceedings of the ACM Conference on Human Fac-

tors in Computer Systems (CHI), pages 276 – 283.

ACM, ACM Press.

ICEIS 2008 - International Conference on Enterprise Information Systems

304