Collaborative, Dynamic & Complex Systems

Modeling, Provision & Execution

Vasilios Andrikopoulos, Santiago G´omez S´aez, Dimka Karastoyanova and Andreas Weiß

Institute of Architecture of Application Systems, University of Stuttgart, Stuttgart, Germany

Keywords:

Collaborative, Dynamic & Complex Systems, Service Orchestration & Choreography, Pervasive Computing,

Service Networks, Context-awareness.

Abstract:

Service orientation has signiﬁcantly facilitated the development of complex distributed systems spanning mul-

tiple organizations. However, different application areas approach such systems in domain-speciﬁc ways, fo-

cusing only on particular aspects relevant for their application types. As a result, we observe a very fragmented

landscape of service-oriented systems, which does not enable collaboration across organizations. To address

this concern, in this work we introduce the notion of Collaborative, Dynamic and Complex (CDC) systems

and position them with respect to existing technologies. In addition, we present how CDC systems are mod-

eled and the steps to provision and execute them. Furthermore, we contribute an architecture and prototypical

implementation, which we evaluate by means of a case study in a Cloud-enabled context-aware pervasive

application.

1 INTRODUCTION

Complex software systems involving multiple, inde-

pendent partners/software components collaborating

in order to achieve one or more goals ﬁnd predomi-

nant application in the current IT landscape. Cases of

such systems from different domains are for instance

business applications targeting enactment of complex

business transactions and service networks, scientiﬁc

workﬂows providing one approach for scientiﬁc ex-

perimenting in eScience, and pervasive systems rep-

resenting one ﬂavor of ubiquitous computing. Based

on our research work towards building support sys-

tems for the development and execution of such appli-

cations in these domains, we conclude that while all

the above-mentioned application areas concentrate on

creating complex systems with very speciﬁc features

critical for the corresponding domain, there are re-

quirements valid across all domains. Our experience

also shows that synergies between these domains can

be exploited and potential beneﬁts realized through

reuse of research results and available software sys-

tems.

In this respect, in this work we investigate the

requirements towards software systems in the above

mentioned application areas with the purpose of iden-

tifying overlaps and differences. As we are going to

show, the overlaps are signiﬁcant and the differences

are mainly due to the special focus on critical aspects

in each domain, and not because the solutions are not

relevant in the other domains. Based on these ﬁnd-

ings we introduce the innovative notion of Collabo-

rative, Dynamic and Complex (CDC) systems aiming

to cover all identiﬁed requirements and allowing to

apply already existing technologies and software sys-

tems. CDC systems exhibit the aspects of modeling,

provision and execution.

The contributions of this work target enabling the

modeling, provision and execution of CDC systems

and can be summarized by:

• The synthesis of existing technologies and ap-

proaches from the service-oriented computing

paradigm and beyond, into a new, uniﬁed type of

Collaborative, Dynamic and Complex (CDC) sys-

tems.

• The speciﬁcation of the architecture for a frame-

work that supports the various aspects (modeling,

provision and execution) of CDC systems.

• The realization of this framework into a prototype

called CoDyCo, and its use for the evaluation of

our approach based on a case study.

The remaining paper is structured as follows. Sec-

tion 2 looks into different application areas that deal

with relevant for this work systems in order to high-

light their similarities and establish the minimum set

276

Andrikopoulos V., Goméz Sáez S., Karastoyanova D. and Weiß A..

Collaborative, Dynamic & Complex Systems - Modeling, Provision & Execution.

DOI: 10.5220/0004852402760286

In Proceedings of the 4th International Conference on Cloud Computing and Services Science (CLOSER-2014), pages 276-286

ISBN: 978-989-758-019-2

 2014 SCITEPRESS (Science and Technology Publications, Lda.)

of requirements for our work. Section 3 presents our

proposal for CDC systems and positions them with

respect to existing approaches. Section 4 introduces

the architecture of a CDC-supporting framework re-

quired for implementing CDC systems. Section 5 re-

ports on the overview and current state of CoDyCo.

Section 6 summarizes a case study we performed us-

ing CoDyCo for purposes of evaluation. Finally, Sec-

tion 7 presents related works, and Section 8 concludes

the paper.

2 MOTIVATION

In the following, we look into the areas of pervasive

systems, service networks and scientiﬁc workﬂows.

Our experience in research projects

shows, that de-

spite the differences, the available approaches from

these areas have many commonalities.

Pervasive Systems. Pervasive systems strive to-

wards enabling the paradigm of ubiquitous comput-

ing and have been a subject of interdisciplinary re-

search. Advances in pervasive systems have focused

on the aspect of context-awareness, i.e. taking into

account the context of physical and virtual entities,

which is in fact a view of the physical environment,

and the inﬂuence of the context on the applications the

entities are using or participating in (Baldauf et al.,

2007). A major requirement in these systems is the

ability to adapt their behavior with respect to the con-

text. Another major challenge is the optimization of

the distribution of applications based on context data

and resource consumption. The distribution of perva-

sive applications across multiple software system and

hardware devices require their integration and coor-

dination towards enabling a collaboration among par-

ticipating devices and systems. Due to the dynamic

characteristics of the environment of pervasive appli-

cations, with participants and devices appearing and

disappearing constantly, supporting context sharing,

adaptation, and scalability are particularly challeng-

ing. Since recently, Cloud Platforms in the scope

of the Internet of Things and Smart Systems initia-

tives have been investigated from the point of view

of enabling scalability, multi-tenancy and adaptabil-

ity (Distefano et al., 2012). Later in this paper, we

present a detailed description of a pervasive context-

aware application for booking a taxi nearest to the lo-

cation of a user based on the information provided by

For example SimTech http://www.simtech.uni-

stuttgart.de/, S-Cube http://www.s-cube-network.eu/,

4CaaSt http://www.4caast.eu/, ALLOW Ensembles http://

www.allow-ensembles.eu/.

mobile devices available to the taxi drivers. We also

use the taxi application for purposes of evaluation as

a case study.

Service Networks. Service Networks (SNs)

(Caswell et al., 2008) are considered a specialized

view on business processes, which focus on assisting

business experts to evaluate the value of participating

in a collaborative business activity. SNs are mod-

eled as a network of business services exchanging

offerings; basically, the composite perceived value

of the exchanged offerings with the other services

determines the value of participating in the network

to one participant. Typical examples of SNs are

supply chains; the taxi application described later can

also be viewed as an SN. There is a signiﬁcant gap

between the meta-models used by business experts

when designing the SNs, and the technological

realization that needs to be bridged by means of

software engineering techniques like model-driven

development and code generation, whereas both

top-down and bottom-up approaches are required.

In addition, service networks are inherently collabo-

rative activities and therefore imply efforts towards

integration of applications across organizations.

A SOA-based realization of service networks, as

well as a meta-model and graphical notation are pre-

sented in (Danylevych et al., 2010) and (Bitsaki et al.,

2008). The interoperability of service implementa-

tions in an SN have been addressed by means of

Web services and the high-level meta-model has been

mapped on choreographies of composite service (i.e.

organization-speciﬁc business processes). Addition-

ally, choreographies take over the role of coordinat-

ing the services in a network, which addresses an-

other important requirement. Changes in the per-

ceived value of a network to a participant may initiate

changes in the individual partners or in the network as

a whole, which have to be propagated to their techno-

logical realization. We therefore identify the need for

adaptation of service networks; some preliminary at-

tempts to support only some types of service networks

adaptation (Wagner et al., 2012) are already available.

Monitoring the value of an SN for a participant is not

directly measurable, but can only be derived based

on monitoring data provided by the execution envi-

ronment for choreographies, orchestrations and ser-

vices. Approaches based on business activity moni-

toring, like (Guinea et al., 2011) and (Wetzstein et al.,

2012) are only ﬁrst steps towards the necessary tech-

nological support.

Scientiﬁc Workﬂows. Scientiﬁc workﬂows enable

the modeling and execution of scientiﬁc experiments

Collaborative,Dynamic&ComplexSystems-Modeling,Provision&Execution

277

and are part of the technology landscape in eScience

(Sonntag and Karastoyanova,2010). A major require-

ment in this ﬁeld is ﬁrst and foremost the user friend-

liness of the approach, so that scientists do not face a

high learning burden when using the experiment mod-

eling tools. The division between the way scientists

model an experiment and the meta-models used in the

supporting IT systems is signiﬁcant and there are dif-

ferent approaches towards eliminating it (Sonntag and

Karastoyanova, 2010). Both top-down and bottom-

up approaches are required to enable the use of ex-

isting software and the development of experiments

from scratch. The distributed nature of complex sci-

entiﬁc experiments requires integration and composi-

tion of scientiﬁc computing software, which presents

an additional challenge due to the lack of clearly de-

ﬁned software engineering principles for building sci-

entiﬁc applications, including scientiﬁc workﬂows.

Reusability is hampered by the heterogeneous land-

scape of applications and integration is of high com-

plexity, because of the large number of available

techniques for composition. Since scientiﬁc discov-

ery is based on exploring physical phenomena, huge

amounts of data are collected via numerous types of

mobile devices and sensors (e.g. simulations of the

distribution of CO

in the soil, weather forecasts, bi-

ological system simulations, simulations of manufac-

turing systems, etc.), and need to be processed. Com-

putations in scientiﬁc workﬂows are time-consuming

and also distributed, and most often they do not ex-

hibit characteristics of pervasive applications. Adap-

tation during the modeling and execution of scien-

tiﬁc workﬂows is a must, as evidenced by existing

work (Sonntag and Karastoyanova, 2010), (Sonntag

and Karastoyanova, 2012).

Despite the different focus of the application sys-

tems described above, they all exhibit overlapping

characteristics that can be leveraged in a uniﬁed man-

ner across the various areas. The following section

presents our proposal toward this goal.

3 CDC SYSTEMS

We deﬁne Collaborative, Dynamic and Complex

(CDC) systems as distributed systems enabling col-

laboration among participants across different orga-

nizations. Participants of CDC systems are services,

representing software systems of different granularity,

virtual and physical devices, and individuals. CDC

participants join and leave the system at will in order

to fulﬁll their individual goals. CDC systems are ca-

pable of adapting with respect to different triggers in

the system and/or in their environment. CDC systems

consist potentially of a large amount of participants

dealing with large amounts of data as part of multiple

interactions between them, following one or more co-

ordination protocols. CDC systems have three funda-

mental aspects: Modeling, Provision and Execution.

With respect to modeling, we use choreographies

to deﬁne the high-level, domain-speciﬁc models of

CDC systems. Choreographies describe the inter-

action protocol of the involved participants and the

participant roles’ deﬁnitions. In SOA environments,

individual participant roles are implemented by ser-

vice orchestrations exposed as services, whereas their

service interfaces are compliant with the participant

role deﬁnitions modeled in the choreography. The

services composed by the orchestrations are either

available in the software landscape of the participat-

ing organizations, or are discoverable in global ser-

vice registries. Utilizing these SOA-based approaches

provides a ﬂexible way of composing applications in

complex systems and facilitates application integra-

tion. To enable context-awareness, choreographies

and orchestrations, as well as involved services, have

to incorporate in their models context information and

deﬁne its use and reaction to potential changes. Since

context information may be part of correlation data of

orchestrations belonging to an enacted choreography,

a mapping between context and correlation mecha-

nisms has to be in place.

Performance indicators, like KPIs, utility, value,

etc. are an inseparable part of the CDC system mod-

els. On the one hand, they are used to deﬁne the in-

dicators according to which users will measure and

evaluate whether they achieve their goals in a collab-

oration. On the other hand, this is the information

needed to derive the data to be monitored during the

execution of the CDC system. Therefore choreogra-

phies, orchestrations and services models have to con-

tain elements deﬁning the necessary monitoring in-

formation. In order to enable the dynamic features of

CDC systems, constructs accommodating adaptation

mechanisms in the choreographies and orchestrations

have to be incorporated. Available approaches from

the ﬁelds of workﬂow adaptation, ﬂexible scientiﬁc

workﬂows and pervasive dynamic ﬂows, e.g. (Wet-

zstein et al., 2012) or (Sonntag and Karastoyanova,

2010) can be applied individually or in combination.

Change propagation across all levels of the CDC sys-

tems and thus adaptation of choreographies can be

identiﬁed as a major research challenge.

As identiﬁed in Section 2, two types of approach

in modeling are required: top-down and bottom-

up. Top-down CDC system modeling entails starting

the development of the system with a choreography

representing a realization of a high-level (domain-

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

278

speciﬁc model), like a SN, scientiﬁc workﬂow, or per-

vasive application. Techniques required to map the

choreography into orchestrations and services, like

code generation and transformations, are available

from software engineering and various existing SOA-

enabling systems. The bottom-up approach involves

deriving a meaningful choreography model based on

existing orchestrations and/or services. In this case,

deriving fault handling, monitoring and adaptation in-

formation is based on the corresponding capabilities

of the involved services and correctness of the derived

choreography.

The provisioning aspect of CDC systems entails

the provision of the choreography,which also requires

the deployment of orchestrations onto execution en-

gines, their provisioning as services, populating the

system with the corresponding context and correla-

tion data, and conﬁguring the monitoring infrastruc-

ture with the requirements from the CDC model.

Mechanisms in service composition systems and sci-

entiﬁc workﬂows for the provisioning of orchestra-

tions and services are already available. Solutions

for mapping monitoring requirements to monitoring

probes are available in pervasive systems and service-

based applications. The provision of a choreography

results into adaptive and context-aware orchestrations

available as a service. The choreography can be initi-

ated multiple times for multiple interactions and can

be started by any of the participating orchestrations or

services, if they are allowed to do so by the choreogra-

phy deﬁnition. Any underlying infrastructure should

therefore enable sharing of resources across different

CDC systems while correlating interactions to tenants

and their users.

Running a choreography is therefore realized as a

distributed execution of the collaboration among par-

ticipating orchestrations and services. Since context-

awareness is inherent to the CDC system model, the

execution environment has to be able to support this

property. Adaptation mechanisms, predeﬁned in the

system model (like abstract activities, binding strate-

gies for services, reactions to context change, etc.)

and such that are orthogonal to the model (like man-

ual adaptation, forced termination, substituting a ser-

vice endpoint, etc.) need to be realized by the exe-

cution environment. Furthermore, the execution envi-

ronment of CDC systems must scale with their num-

ber of participants and their interactions, as well as the

volumes of data exchanged. Monitoring information

is necessary in order to enable such scaling.

Adaptation

Manager

Execution

Engine

Choreography

Editor

Orchestration

Editor

Transformer

Deployment

Manager

Monitor

Tenant

Manager

Context

Modeling

Provision

Execution

ESB

Figure 1: CDC-supporting framework — Architectural

view.

4 CDC FRAMEWORK

ARCHITECTURE

Figure 1 provides an overview of our proposal for a

framework supporting the modeling, provision and

execution of CDC systems. Starting from the mod-

eling aspect, a Choreography Editor is required to

create, visualize and manage the choreography mod-

els of the CDC systems. A Transformer component

can then either generate orchestration templates that

the CDC participants are meant to implement (in the

top-down approach in the previous section), or derive

possible choreographies from existing orchestrations

(in the bottom-up approach). In either case, an Or-

chestration Editor (not necessarily but preferably in

the same environment as the Choreography Editor)

should be available for orchestration visualization and

manipulation. The transformer components also re-

quires as input the service descriptions of the used or-

chestrations in the bottom-up approach or generates

(abstract) service descriptions for derived orchestra-

tions. Moving to the provisioning aspect, the Deploy-

ment Manager allows the assignment of the neces-

sary for operation computational resources to the or-

chestrations involved in the modeled choreographies.

Beyond physically deploying the necessary artifacts

on an Execution Engine, this additionally entails the

creation of all service endpoints necessary for access-

ing the orchestration logic by the system participants.

The Deployment Manager also handles the informa-

tion needed for late and dynamic binding to concrete

service endpoints and provides it to the ESB during

the execution of orchestrations.

In principle, multiple organizational domains may

be using the same instantiation of this framework for

different CDC systems. It is therefore necessary to

Collaborative,Dynamic&ComplexSystems-Modeling,Provision&Execution

279

offer multi-tenancy capabilities out of the box for all

components in the provision and execution aspect of

the framework. A Tenant Manager is responsible for

this role, and implements administration and manage-

ment capabilities for existing and new tenants (or-

ganizational domains) and their users (individuals or

sub-systems in the same domain). The Tenant Man-

ager is also meant to implement access control to both

choreography and orchestration models, and to the

computational resources corresponding to them dur-

ing the execution of CDC systems, as assigned to

them by the Deployment Manager. Only authorized

parties should be allowed, for example, to participate

in a given choreography. Furthermore, any collected

contextual information relevant for tenants and users

in terms of a representation of their environment, e.g.

their physical location or the quality of observed data,

is stored and accessed through the Tenant Manager.

While the Deployment and Tenant Managers play

prominent roles in the provision aspect of CDC sys-

tems, they are also heavily involved during CDC sys-

tem execution, since both of them need to interact

with the actual Execution Engine that runs the orches-

trations deﬁned during modeling. Furthermore, the

Execution Engine has to provide fault handling capa-

bilities, both for pre-deﬁned fault and compensation

handlers in the orchestration models, and for failures

during execution like service failures and unavailabil-

ity of other components in the framework (e.g. access

to the Deployment Manager).

The Adaptation Manager is responsible for trig-

gering and managing the adaptivity features of CDC

systems by providing mechanisms for different types

of adaptations across the levels of the systems. It im-

plements and/or coordinates the actions necessary to

enable the adaptation constructs from the CDC sys-

tem model and the ones implemented only on the level

of the execution environment. The Adaptation Man-

ager collaborates also with the Deployment Manager

when necessary, e.g. for re-binding service endpoints,

and with the Execution Engine, e.g. for injecting a

new activity and control connectors into an existing

orchestration or deploying a new orchestration in case

a choreography has been changed. The Adaptation

Manager acts on information provided by the Monitor

component which monitors and analyses the behav-

ior and performance of the executed orchestrations,

of the enacted choreographies, and also of the execu-

tion components in the framework. The Monitor must

be conﬁgurable based on the monitoring information

required for the CDC system and is responsible for

providing to the users of choreographies and orches-

trations personalized views of the relevant monitoring

information on their devices.

Leveraging the SOA paradigm, all components in

the framework relevant to execution should be pro-

vided as services and communicate through an En-

terprise Service Bus (ESB) solution to facilitate their

integration. Furthermore, each component should be

designed and implemented allowing for both types

of scalability: horizontal (modify number of avail-

able instances as required) and vertical (adjustment

of available computational resources for each compo-

nent) (Vaquero et al., 2011).

5 IMPLEMENTATION

In this section we present CoDyCo, a realization ap-

proach of the CDC-supporting framework presented

in the previous section. As shown in Fig. 2, two sep-

arate environments are distinguished in the CoDyCo

architecture: a Modeling and Monitoring Toolset, and

a Runtime Environment.

Starting from the Modeling and Monitoring

Toolset, CDC choreographies are speciﬁed in the

BPEL4Chor language using our BPEL4Chor De-

signer. BPEL4Chor was ﬁrst introduced by (Decker

et al., 2008) as an extension of the WS-BPEL

language (OASIS, 2007) and stemming from the

business transactions ﬁeld. However, BPEL4Chor

choreographies are by deﬁnition not executable and

therefore the transformation of BPEL4Chor deﬁ-

nitions to WS-BPEL process (orchestration) skele-

tons (Reimann, 2007) is supported in CoDyCo by

a BPEL4Chor Transformer (Fig. 2). Based on the

choreography topology, the participants’ grounding

deﬁnitions, i.e. their WSDL interfaces, and their mes-

sage links, this transformation generates the exe-

cutable BPEL orchestrations for each participant in

the choreography. The skeletons only model the in-

teractions between partners so that together they can

enact the choreography. Manual reﬁnements can be

performed on the created orchestrations, using our

Mayﬂower BPEL Designer (Sonntag et al., 2012) de-

veloped in the context of the SimTech project

as an

Eclipse-based BPEL designer. These reﬁnements al-

low deﬁning speciﬁc process logic for each partici-

pant, for example by reusing predeﬁned process frag-

ments from a process fragment library, as demon-

strated in (Sonntag et al., 2012) and (Schumm et al.,

2010). Both choreography deﬁnition and transforma-

tion functionalities are wrapped as an Eclipse Graph-

ical Editor, and provide a palette with the graphical

elements of the choreography language (Weiß et al.,

2013). Only the top-down modeling approach (see

The SimTech project: http://www.simtech.

uni-stuttgart.de

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

280

Modeling and Monitoring Toolset

Runtime Environment

Context

Management

System

Mayflower BPEL

Engine

BPEL4Chor

Designer

BPEL4Chor

Transformer

Management

Dashboard

ESB

Tenant

Manager

Adaptation

Manager

Execution Engine

Mayflower

BPEL Designer

Figure 2: The CoDyCo System: Overview and Current State.

Section 3) is currently supported by the Modeling

and Monitoring Toolset; supporting the bottom-upap-

proach is part of our future work. For more informa-

tion on the status of the tools the interested reader is

referred to (Weiß et al., 2013).

The deployment and instantiation of the BPEL

processes generated by the Modeling and Monitor-

ing Toolset is done on our Mayﬂower BPEL En-

gine. This engine is an extended version of the open-

source Apache ODE Engine. It provides an inter-

face for event publishing and conﬁgurable ﬁltering

and a BPEL event model

(Khalaf et al., 2007), which

have been specialized for the purposes of monitor-

ing and triggering dynamic adaptation of process in-

stances(Sonntag et al., 2012). Functionalities pro-

vided by the Mayﬂower BPEL Engine address the

requirements of the CDC execution environment in

terms of orchestration execution, storing of histori-

cal information, failure and compensation handling,

and in combination with the Adaptation Manager also

enable some dynamic adaptation patterns. For in-

stance, dynamic adaptation of process instances trig-

gered by humans are supported in CoDyCo through

the Modeling and Monitoring Toolset. More specif-

ically, the Mayﬂower BPEL Designer interacts with

the Mayﬂower BPEL Engine and the Adaptation

Manager and so allow the users to view the status of

process instances and trigger their adaptation. Based

on this users can adapt the process instance by chang-

ing its graphical representation.

The adaptation operations that can be performed

on a process instance in our current implementation

are, e.g. re-execution or forced iteration of activ-

ities (Sonntag and Karastoyanova, 2012), insertion

ODE PGF: http://www.iaas.uni-stuttgart.de/forschung/

projects/ODE-PGF/

and deletion of process elements, or their substitu-

tion. The changes made on the viewed process in-

stance are then propagated to the Adaptation Man-

ager Component, which is responsible for performing

the actual adaptation on the concrete process instance

in the engine. This is also made possible by auxil-

iary functions in the Mayﬂower BPEL Designer, mir-

rored in the Mayﬂower BPEL Engine, like enabling

user subscriptions to monitoring events published by

the engine, and hence retrieval of real-time informa-

tion about a concrete process instance, and built-in ac-

tions per process instance like stop, suspend, resume,

etc. (Sonntag et al., 2012). Automatic adaptation of

running process instances, like injection of process

fragments is currently not supported by the Adapta-

tion Manager in CoDyCo

Communication between participants collaborat-

ing in the scope of a speciﬁc choreography instance,

and between the different components comprising the

runtime environment is established through the multi-

tenant open source ESB solution ESB

(Strauch

et al., 2012a), (Strauch et al., 2012b). ESB

enhances an existing ESB Solution, Apache Ser-

viceMix

with multi-tenant awareness both at the ad-

ministration and management, and messaging levels.

Management and administration functionalities im-

plemented by a Tenant Manager enable the dynamic

deployment and conﬁguration of service endpoints

with tenant- and user-speciﬁc information, while

tenant-aware messaging capabilities isolate tenants’

messages routed to the service endpoints (Strauch

et al., 2012b). As tenants represent organizational

units, e.g. Taxi Company A, which has N taxi drivers,

Note that this is possible only manually, as described

above.

Apache ServiceMix: http://servicemix.apache.org/

Collaborative,Dynamic&ComplexSystems-Modeling,Provision&Execution

281

and M potential taxi customers, their communication

in the scope of a choreography is supported in the

ESB

through tenant-aware service endpoints. At

the moment we are working on the integration of our

execution engine with the ESB

as a JBI Service

Engine, to enable multi-tenancy support for orches-

trations and choreographies, too.

The Management Dashboard is the component in

the Modeling and Monitoring Toolset responsible for

providing analyzed and personalized monitoring in-

formation to users and tenants about the execution

state of choreographiesand orchestrations. Our proto-

type visualizes the execution status of orchestrations,

the data they produce and consume, and the adapta-

tions that have been performed (Sonntag et al., 2012).

This is possible due to the interaction of the Manage-

ment Dashboard with the Mayﬂower BPEL Engine

via its event publishing interface, as described above.

Our approaches for monitoring choreographies (Wag-

ner et al., 2012) and KPIs (Wetzstein et al., 2012) are

not yet integrated into CoDyCo.

The Context Management System stores the sys-

tem context (i.e. a set of context properties of all ac-

tive tenants) and constantly synchronizes its current

conﬁguration with the tenant speciﬁc applications by

retrieving context data from each of the tenant users

created in the system, e.g. from a location provider

embedded system in a speciﬁc taxi cab. Context infor-

mation is used in the execution of choreographies by

the corresponding orchestrations through Context In-

tegration Processes (CIPs) (Wieland et al., 2007) and

may trigger their adaptation. Context-aware adapta-

tions will be handled by a collaboration of the Adap-

tation Manager, the Mayﬂower Engine, the Context

Management System (CMS), and the Tenant Manager

and is part of our future work on the implementation.

The modeling tool is currently also missing features

supportingmodeling of context in the choreographies.

6 CASE STUDY

In the scope of project 4CaaSt

, the Taxi Scenario use

case has been deﬁned, where a service provider of-

fers a taxi management software as a service to dif-

ferent taxi companies, i.e. tenants. Taxi company

customers, who are the users of the tenant, submit

their taxi transportation requests to the company they

are registered with. The taxi company uses the taxi

management software to contact nearby taxi drivers.

Once one of the contacted taxi drivers has conﬁrmed

the transportation request, the taxi management soft-

The 4CaaSt project: http://www.4caast.eu

ware sends a transport notiﬁcation containing the es-

timated arrival time to the customer. As discussed in

Section 2, the Taxi Scenario constitutes a pervasive

context-aware application and therefore, in the scope

of this work, an ideal candidate for the evaluation of

our proposal.

Figure 3 shows the processes the Taxi Scenario

application realizes. The simpliﬁed BPMN diagram

has three lanes depicting the three participants of the

application choreography: Customer, Taxi Company,

and Taxi Service Provider. If a Customer wishes to

book a Taxi, he sends an initial request to the Taxi

Company call center (usually through a Web GUI),

which forwards it to the Taxi Service Provider. The

Taxi Service Provider process determines the nearby

available taxis and the contact information of the taxi

drivers using CIPs (Wieland et al., 2007) (not shown

here for brevity). Subsequently, the transport request

is sent to each available taxi driver, and their re-

sponses are collected for a speciﬁed duration. The

gathered transport informationis sent back to the Cus-

tomer. Implementing the Taxi Scenario required the

manual design of all involved processes as orches-

trations for each participant and their interactions, as

well as the implementation of most services involved

in them (except from those that already existed, e.g.

a context provisioning framework exposed as a ser-

vice (Knappmeyer et al., 2010)).

For the evaluation of our approach we started with

the BPMN diagram in Fig. 3 which we translated into

BPEL4Chor. Figure 4 shows the processes depicted

in Fig. 3 as participants in our BPEL4Chor Designer.

The rectangular shapes in the editor view in Fig. 4

stand for the choreography participants, whereas the

message links and their directions are depicted by la-

beled arrows. The set of taxi drivers are represented

by the Taxi Transmitters participant, standing for the

devices carried by the drivers. Inside each partic-

ipant, the control ﬂow regarding its communication

behavior such as receive or send activities is visible.

The resulting choreography model was then trans-

formed into a series of BPEL4Chor artifacts by the

BPEL4Chor Designer: a participant topology speci-

fying the involved participants in the choreography,

the participant types, and the message links between

participants.

The BPEL4Chor artifacts are used by the

BPEL4Chor Transformer to generate Abstract BPEL

processes and WSDL ﬁles. These WSDL ﬁles con-

tain the technical information about the interfaces be-

tween the participants, i.e. the port types, operations,

messages, and partner links. Each previously mod-

eled participant was transformed into exactly one Ab-

stract BPEL process. Basic executable completion of

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

282

Taxi Service

Provider

Call Center

Taxi Driver

Customer

Initiate Taxi

Request

Forward Taxi

Request

Get Taxi

Request

Get

Available

Nearby Taxis

Get Taxi

Driver Contact

Information

Send

Transport

Request

Send

Transport

Information

Get

Available

Nearby Taxis

Get

Transport

Information

Send

Transportation

Figure 3: The BPMN process diagram of the Taxi Application.

Figure 4: Excerpt of the Taxi Application choreography modeled with the Chor Designer.

the Abstract BPEL processes, i.e. their transformation

into executable ones, is supported by the BPEL4Chor

Designer, as well as the manual reﬁnement of the pro-

cess logic in each participant that is not part of the

choreography. The resulting (executable) processes

were then deployed and executed successfully in our

Mayﬂower BPEL Engine. Through this process we

have also identiﬁed a number of technical issues with

the current implementation of the BPEL4Chor De-

signer and Transformer (Weiß et al., 2013). For exam-

ple, not all BPEL activities are currently supported,

and the generated WSDL ﬁles need manual deﬁnition

of the involved message types. We are already work-

ing on addressing these deﬁciencies.

7 RELATED WORK

As discussed in (Barker et al., 2009), the interac-

tion between participants in a choreography can be

modeled following the interaction, or interconnection

modeling approaches. The former approach models

atomic interactions between participants through in-

teraction activities, while the latter interconnects the

communication activities of each participant of the

choreography. The WS-CDL

language standard

supports the interaction approach. Using the WS-

CDL language as the basis, the Savara

project aims

to provide tooling support for a top-down choreog-

raphy modeling approach. Interconnection model-

ing approaches are supported in the CHOReOS In-

WS-CDL:http://www.w3.org/TR/ws-cdl-10/

http://www.jboss.org/savara

Collaborative,Dynamic&ComplexSystems-Modeling,Provision&Execution

283

tegrated Development and Runtime Environment

in the Open Knowledge European project

, and in

BPEL4Chor (Decker et al., 2007). The CHOReOS

environment supports the choreography speciﬁcation

using BPMN 2.0 collaborations (CHOReOS Consor-

tium, 2011), and encompasses choreography adapta-

tion based on service availability and QoS assurance.

The Open Knowledge framework employs a mul-

tiagent protocol to control the interactions between

participants in the choreography. Therefore, partic-

ipants must be speciﬁed and deployed prior to the

choreography enactment, and adaptation based on

context modiﬁcations is not considered. As dis-

cussed in the previous sections, BPEL4Chor wraps

the choreography speciﬁcation in a layer atop of WS-

BPEL which contains the choreography control ﬂow,

its participants description and message links be-

tween them, and the mapping support to their concrete

communication descriptions (WSDL). BPEL4Chor

does not support the explicit speciﬁcation of rules

for context-aware adaptation purposes, but decouples

the choreography speciﬁcation from communication

speciﬁc details, enabling extensibility for dynamic

context-aware choreography adaptation.

Context-aware systems have been widely stud-

ied in the scope of Ubiquitous Computing. In (Bal-

dauf et al., 2007) a set of context-aware systems are

presented, and a comparison focusing on the archi-

tectural principles of context-aware middleware and

framework to ease the development of context-aware

applications is provided. The CoWSAMI middleware

infrastructure utilizes Web services for managing lo-

cation context in open ambient intelligence environ-

ments (Athanasopoulos et al., 2008). The utilization

of an ESB as the centralpiece for communicationsup-

port in context-aware systems is discussed in (Chanda

et al., 2011), where a Context-aware ESB (CA-ESB)

is proposed to discover and orchestrate services based

on the users’ location and available services in spe-

ciﬁc regions.

Concerning different context views in pervasive

environments, in (Abdulrazak et al., 2010) micro and

macro context-awareness modeling approaches are

presented. The former describes the users’ surround-

ings and aims to provide access to local context data,

while the latter aggregates local context data to pro-

vide a global perspective of different spaces. Self-

conﬁguration operations in micro context-awareness

models involve coordination of peers in a decen-

tralized manner, making choreographies suitable for

modeling the coordination between peers. Further-

more, in (Roy et al., 2008) high system availability

EU Project CHOReOS: http://www.choreos.eu/

Open Knowledge: http://www.openk.org/

is achieved by decentralizing the coordination of enti-

ties collaborating in context construction and decision

making activities in open intelligence spaces ensures.

Context-aware workﬂows as an approach for eas-

ing the development of context-awareapplications are

presented in (Wieland et al., 2007). Thus, they pro-

pose Context4BPEL, a WS-BPEL

extension for ex-

plicitly modeling the inﬂuence of context on work-

ﬂows. However, WS-BPEL supports orchestration of

services within a business process, while choreogra-

phy modeling approaches demand a further seman-

tic support for specifying process interactions from a

global view. Further research on workﬂow ﬂexibility

has been conducted by integrating support of human

interactions during the execution of scientiﬁc work-

ﬂows in (Karastoyanova et al., 2012). This approach

triggers human interactions for non-automated activi-

ties via a framework supporting a multi-protocolcom-

munication between a scientiﬁc workﬂow manage-

ment system and pluggable communication devices.

All these approaches are focusing on only one partic-

ular aspect of CDC systems.

8 CONCLUSIONS AND FUTURE

WORK

Our investigation into different application areas

like pervasive systems, service networks and scien-

tiﬁc workﬂow systems that have been inﬂuenced by

service-orientation illustrated a series of overlapping

characteristics that have not been leveraged so far. To-

ward this purpose, in this work we introduced the no-

tion of Collaborative, Dynamic and Complex (CDC)

Systems as dynamic distributed systems that allow

participants from different organizations to collabo-

rate to fulﬁll their goals. We discussed three fun-

damental aspects of CDC systems: modeling, pro-

vision and execution, and presented the architecture

of a framework that supports these aspects. We then

showed the current status of the prototypical imple-

mentation of CoDyCo, a system that realizes this

framework. A case study on a context-aware perva-

sive application was then presented for purposes of

evaluating our proposal.

Currently, we are working on improving the state

of the CoDyCo prototype by addressing the deﬁcien-

cies identiﬁed during the case study. Future work is

aimed at ﬁnalizing the different aspects of our pro-

posal. Concerning modeling and provision CDC sys-

tems, the bottom-up modeling approach has to be

realized, as well as enabling context-awareness in

WS-BPEL 2.0: http://docs.oasis-open.org/wsbpel/2.0/

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

284

choreographies and orchestrations for both type of ap-

proaches. This also entails the realization of the con-

text management system. In addition, multi-tenancy

awareness has to be enabled for choreographies and

orchestrations, and reﬂected in the Execution Engine.

The Management Dashboard has to be integrated with

approaches to monitoring KPIs and business transac-

tions which is a step towards enabling the monitor-

ing of choreographies. In terms of adaptation, avail-

able approaches context-aware adaptation and auto-

matic adaptation of orchestration has to be integrated

in CoDyCo. Finally, the scalability features of the

CoDyCo components have to be investigated further

in the scope of our Cloud computing research.

ACKNOWLEDGEMENTS

This work is funded by the projects FP7 EU-FET

600792 ALLOW Ensembles and the German DFG

within the Cluster of Excellence (EXC310) in Sim-

ulation Technology.

REFERENCES

Abdulrazak, B., Roy, P., Gouin-Vallerand, C., Giroux, S.,

and Belala, Y. (2010). Macro and micro context-

awareness for autonomic pervasive computing. In

Proceedings of iiWAS’2010, pages 427–434. ACM.

Athanasopoulos, D., Zarras, A. V., Issarny, V., Pitoura, E.,

and Vassiliadis, P. (2008). Cowsami: Interface-aware

context gathering in ambient intelligence environ-

ments. Pervasive and Mobile Computing, 4(3):360–

389.

Baldauf, M., Dustdar, S., and Rosenberg, F. (2007). A sur-

vey on context-aware systems. International Journal

of Ad Hoc and Ubiquitous Computing, 2(4):263–277.

Barker, A., Walton, C. D., and Robertson, D. (2009). Chore-

ographing web services. IEEE Transactions on Ser-

vices Computing, 2(2):152–166.

Bitsaki, M., Danylevych, O., van den Heuvel, W.-J.,

Koutras, G., Leymann, F., Mancioppi, M., Nikolaou,

C., and Papazoglou, M. (2008). An Architecture for

Managing the Lifecycle of Business Goals for Part-

ners in a Service Network. In Proceedings of Service-

Wave’08, Lecture Notes in Computer Science, pages

196–207. Springer Berlin Heidelberg.

Caswell, N. S., Nikolaou, C., Sairamesh, J., Bitsaki, M.,

Koutras, G. D., and Iacovidis, G. (2008). Estimating

value in service systems: A case study of a repair ser-

vice system. IBM Systems Journal, 47(1):87–100.

Chanda, J., Sengupta, S., Kanjilal, A., and Bhattacharya, S.

(2011). CA-ESB: Context Aware Enterprise Service

Bus. International Journal of Computer Applications,

30(3):1–8.

CHOReOS Consortium (2011). CHOReOS Dynamic De-

velopment Model Deﬁnition (D2.1).

Danylevych, O., Karastoyanova, D., and Leymann, F.

(2010). Service Networks Modelling: An SOA &

BPM Standpoint. J.UCS, 16(13):1668–1693.

Decker, G., Kopp, O., Leymann, F., Pﬁtzner, K., and Weske,

M. (2008). Modeling Service Choreographies Using

BPMN and BPEL4Chor. In Proceedings of CAiSE’08,

pages 79–93. Springer.

Decker, G., Kopp, O., Leymann, F., and Weske, M. (2007).

BPEL4Chor: Extending BPEL for Modeling Chore-

ographies. In Proceedings of ICWS’07, pages 296–

303. IEEE Computer Society.

Distefano, S., Merlino, G., and Puliaﬁto, A. (2012). En-

abling the cloud of things. In Proceedings of IMIS’12,

pages 858–863.

Guinea, S., Kecskemeti, G., Marconi, A., and Wetzstein, B.

(2011). Multi-layered monitoring and adaptation. In

Proceedings of ICSOC’11, pages 359–373. Springer.

Karastoyanova, D., Dentsas, D., Schumm, D., Sonntag, M.,

Sun, L., and Vukojevic, K. (2012). Service-based Inte-

gration of Human Users in Workﬂow-driven Scientiﬁc

Experiments. In Proceedings of eScience’12, pages 1–

8. IEEE Computer Society Press.

Khalaf, R., Karastoyanova, D., and Leymann, F. (2007).

Pluggable framework for enabling the execution of ex-

tended bpel behavior. In Proceedings of WESOA’07,

pages 376–387. Springer.

Knappmeyer, M., Kiani, S. L., Fr`a, C., Moltchanov, B., and

Baker, N. (2010). ContextML: a light-weight context

representation and context management schema. In

Proceedings of ISWPC’10, pages 367–372. IEEE.

OASIS (2007). Web services business process execution

language version 2.0.

Reimann, P. (2007). Generating BPEL Processes from a

BPEL4Chor Description. Studienarbeit 2100, Uni-

versit¨at Stuttgart, Institut f¨ur Architektur von Anwen-

dungssystemen.

Roy, P., Abdulrazak, B., and Belala, Y. (2008). Approach-

ing context-awareness for open intelligent space. In

Proceedings of MoMM’08, pages 422–426. ACM.

Schumm, D., Karastoyanova, D., Leymann, F., and Strauch,

S. (2010). Fragmento: Advanced Process Fragment

Library. In Proceedings of ISD’10, pages 659–670.

Springer.

Sonntag, M., Hahn, M., and Karastoyanova, D. (2012).

Mayﬂower - Explorative Modeling of Scientiﬁc

Workﬂows with BPEL. In Proceedings of BPM’12,

pages 1–5. CEUR Workshop Proceedings.

Sonntag, M. and Karastoyanova, D. (2010). Next Gener-

ation Interactive Scientiﬁc Experimenting Based On

The Workﬂow Technology. In Proceedings of MS’10.

ACTA Press.

Sonntag, M. and Karastoyanova, D. (2012). Ad hoc Itera-

tion and Re-execution of Activities in Workﬂows. In-

ternational Journal On Advances in Software, 5(1 &

2):91–109.

Strauch, S., Andrikopoulos, V., Leymann, F., and Muh-

ler, D. (2012a). ESB

: Enabling Multi-Tenancy in

Enterprise Service Buses. In Proceedings of Cloud-

Com’12, pages 456–463. IEEE Computer Society.

Strauch, S., Andrikopoulos, V., S´aez, S. G., Leymann, F.,

and Muhler, D. (2012b). Enabling Tenant-Aware Ad-

Collaborative,Dynamic&ComplexSystems-Modeling,Provision&Execution

285

ministration and Management for JBI Environments.

In Proceedings of SOCA’12, pages 206–213. IEEE

Computer Society.

Vaquero, L., Rodero-Merino, L., and Buyya, R. (2011). Dy-

namically scaling applications in the cloud. ACM SIG-

COMM Computer Communication Review, 41(1):45–

52.

Wagner, S., Fehling, C., Karastoyanova, D., and Schumm,

D. (2012). State Propagation-based Monitoring of

Business Transactions. In Proceedings of SOCA’12,

pages 1–8. IEEE.

Weiß A., Andrikopoulos, V., G´omez S´aez, S., Karastoy-

anova, D., and Vukojevic-Haupt, K. (2013). Model-

ing Choreographies using the BPEL4Chor Designer:

an Evaluation Based on Case Studies. Technical Re-

port 2013/03, IAAS, University of Stuttgart.

Wetzstein, B., Zengin, A., Kazhamiakin, R., Marconi, A.,

Pistore, M., Karastoyanova, D., and Leymann, F.

(2012). Preventing KPI Violations in Business Pro-

cesses based on Decision Tree Learning and Proactive

Runtime Adaptation. Journal of Systems Integration,

3(1):3–18.

Wieland, M., Kopp, O., Nicklas, D., and Leymann, F.

(2007). Towards context-aware workﬂows. In Pro-

ceedings of CAiSE07, pages 11–15. Springer.

All links were last followed on January 29, 2014.

CLOSER2014-4thInternationalConferenceonCloudComputingandServicesScience

286