Towards Composition as a Service – A Quality of
Service Driven Approach
Florian Rosenberg, Philipp Leitner, Anton Michlmayr, Predrag Celikovic, Schahram Dustdar
Distributed Systems Group, Technical University Vienna
Argentinierstrasse 8/184-1, 1040 Vienna, Austria
{florian, leitner, anton, celikovic, dustdar}@infosys.tuwien.ac.at
Abstract— Software as a Service (SaaS) and the possibility to
compose Web services provisioned over the Internet are impor-
tant assets for a service-oriented architecture (SOA). However, the
complexity and time for developing and provisioning a composite
service is very high and it is generally an error-prone task. In this
paper we address these issues by describing a semi-automated
“Composition as a Service” (CAAS) approach combined with a
domain-specific language called VCL (Vienna Composition Lan-
guage). The proposed approach facilitates rapid development and
provisioning of composite services by specifying what to compose
in a constraint-hierarchy based way using VCL. Invoking the
composition service triggers the composition process and upon
success the newly composed service is immediately deployed
and available. This solution requires no client-side composition
infrastructure because it is transparently encapsulated in the
CAAS infrastructure.
I. INTRODUCTION
Over the last years, the Software as a Service (SaaS)
concept has gained momentum as a means to offer software as
well-defined services over the Internet. Implementing SaaS is
typically achieved by leveraging service-oriented architecture
(SOA) design principles such as loose coupling and self-
describing service interfaces. Web services as one technology
for implementing SOAs can help to achieve this vision by
providing standards such as WSDL [1] as service description
language and SOAP [2] as transport protocol.
One of the main benefits of implementing a well-shaped
SOA is the ability to compose new functionality out of
existing services into so-called “composite services”, thus
significantly increasing reuseability of existing services. This
process itself is called composition [3] or orchestration and
needs a composition engine to enact a composed service (or
application)
1
.
Typically, two major issues have to be addressed before
adopting service compositions: Firstly, which composition
approach should be used allowing an adequate description of
functional and non-functional aspects of a composed service?
These include functional aspects such as the services to be
used, non-functional aspects such as Quality of Service (QoS)
concerns as well as the specification of the control and/or data
flow (depending on the composition language). Secondly, how
are these composed services deployed and provisioned to allow
other software artifacts to invoke them?
1
We use the terms composite service, composite application and composi-
tion interchangeably in this paper.
Currently, several approaches to engineer composite appli-
cations exist. The vast majority of developers use a purely
static approach to build a composition by manually selecting
available services and specifying the control flow to define
the composition logic. Static compositions can be built for
example by using WS-BPEL [4] or the Microsoft Windows
Workflow Foundation [5]. The static nature of a composition
poses a real problem, for example, when services need to
be dynamically selected or exchanged from a pool of sim-
ilar services based on changing Quality of Service (QoS)
attributes such as response time, throughput or availability.
So-called dynamic service adaptation mechanisms for static
approaches have been introduced to overcome this problem
and increase availability and fault-tolerance of Web service
compositions [6], [7].
In terms of service deployment and provisioning, a service
composition infrastructure is required to enable the deploy-
ment of composite services and atomic services (if not hosted
otherwise). Currently, most deployment aspects include a
number of (often ’hand-crafted’) tasks leading to a successful
deployment. This process is usually very cumbersome and
error-prone. Especially for small and medium sized enterprises
(or even individuals) the required infrastructure to host com-
posite services is often not available or simply too expensive
in terms of acquisition cost and maintenance.
In this paper we address these two aforementioned issues by
adding the CAAS approach to our VRESCO SOA runtime [8],
[9], [10], [11], [12] and enable the specification of composite
applications with VCL. VRESCO itself provides a uniform
programming model and SOA runtime that addresses issues
such as service publishing, querying, versioning and service
mediation based on a uniform service metadata model. A
detailed description of all the VRESCO aspects is out of scope
of this paper, we refer the interested reader to our previous
work.
The contributions of this paper can be summarized as
follows: Firstly, we put forward a textual domain-specific
language (DSL) named VCL (Vienna Composition Language)
that was developed solely for the purpose of specifying service
compositions. The novelty of VCL is the ability to specify
constraints describing functional and non-functional aspects
of a composition using a constraint hierarchy-based approach.
Quality of service (QoS) is a first-class entity of the DSL
enabling a QoS-aware composition.
IEEE International Conference on Data Engineering
1084-4627/09 $25.00 © 2009 IEEE
DOI 10.1109/ICDE.2009.153
1733
IEEE International Conference on Data Engineering
1084-4627/09 $25.00 © 2009 IEEE
DOI 10.1109/ICDE.2009.153
1733
IEEE International Conference on Data Engineering
1084-4627/09 $25.00 © 2009 IEEE
DOI 10.1109/ICDE.2009.153
1733
Authorized licensed use limited to: Universitatsbibliothek der TU Wien. Downloaded on September 29, 2009 at 07:40 from IEEE Xplore. Restrictions apply.
Secondly, we bridge the gap between composite service
specification and provisioning by enabling “Composition as
a Service” (CaaS). To this end, we leverage VRESCO as an
infrastructure (including metadata for the services stored in a
service registry) to enhance it with a composition environment
to receive and process composition requests (written in VCL).
During runtime, a composition request is transformed into a
constraint optimization problem to find an optimal selection
of services that match the user’s constraints. However, in this
paper we focus on the end-to-end system rather than on the
QoS-aware optimization algorithms.
This paper is organized as follows: Section II presents some
of the related work. Section III and IV describe the approach
and rationale behind CAAS and VCL. Some implementation
aspects are highlighted in Section V. Section VI discusses
some of the issues and limitations related to this work and
Section VII concludes this work and highlights some future
work.
II. RELATED WORK
Applying DSLs for composing service-oriented systems is a
relatively new idea, whereas DSLs have been successfully ap-
plied in other areas (also within the SOA domain). Oberortner
et al. [13] discuss the use of DSLs for SOAs in general, with
a special focus on model-driven development and process-
driven SOAs [14]. The authors differentiate between DSLs
for domain experts (high-level DSLs) and DSLs for technical
experts (low-level DSL). According to their classification, VCL
can neither be explicitly classified as high-level DSL nor as
low-level DSL because it abstracts from low-level semantic
and syntactic issues (such as constructs in WS-BPEL or
any other composition language) but requires some technical
understanding about the domain of “service composition” to
be practically usable.
In [15], the author describes the WebDSL approach, a
domain-specific language for dynamic Web applications. It
allows the specification of domain models, presentation logic,
page flows and access control [16]. Similar to our approach,
WebDSL abstracts from the complexity of the underlying
execution languages and runtimes (JSF, Hibernate and Seam
in their approach). Besides abstracting from the underlying
runtime, in our approach we additionally introduce an opti-
mization layer in between the language specification and the
generation of the executable composition to optimize the local
and global QoS constraints that have been specified by the
user.
JOpera [17], developed at the ETH Z
¨
urich, provides a visual
composition language that focuses on an interactive environ-
ment allowing users to visually specify, design and test their
compositions. Their approach does not focus on pure SOAP-
based services, it also handles arbitrary Java or Enterprise
JavaBeans and RESTful services. In contrast to their approach,
we go into a different direction by providing a semi-automated
approach using a textual DSL that gives developers a simple
language to rapidly developing and deploying a composition
without requiring any composition infrastructure.
In terms of QoS-aware optimization of compositions, Zeng
et al. [18] provided some of the fundamentals in the Web
service community. They use the well-known Integer Program-
ming (IP) technique to find an optimized composition in terms
of QoS that satisfies all the global and local QoS constraints.
This is based on the assumption that for each abstract service
in a composite service a pool of candidate services exists. The
main challenge is the encoding of various QoS constraints
and the aggregation of QoS values in the workflow according
to the execution path in a composite service. Their approach
can be seen complementary to our work, however, our overall
approach is not focused on one specific formalism for QoS-
aware optimization. VCL itself allows the specification of
given QoS requirements, either locally on given services as
well as globally. Our work is also capable of integrating
different optimization algorithms, such as approaches based
on stochastic models [19], [20].
In [21], the authors discuss an approach for interleaving
planning and execution of service compositions by means
of a special language called XSRL (XML Service Request
Language). It enables users to specify goals and constraints
for a (pre-compiled) composite service where the services are
dynamically bound in the composition, e.g., by using UDDI
(Universal Description Discovery and Integration). Their ap-
proach is based on AI planning and constraint satisfaction
techniques to fulfill a service request. In contrast, we focus
on providing a language and runtime to create and deploy
a composite service that has various constraints in terms of
functionality and QoS. Once a composite service is deployed
our approach is still able to re-bind to another service once the
QoS changes since the initial deployment of the composition.
III. COMPOSITION APPROACH
The Composition as a Service (CaaS) approach is based
on the idea of reducing the complexity involved when devel-
oping a composite application, e.g., such as with WS-BPEL.
Typically, the composition process can be divided into service
discovery, composite service specification, deployment, testing
and runtime monitoring (assuming that the requirements of the
composite service in terms of its functionality have already
been defined). The CaaS approach in combination with the
VRESCO SOA runtime mainly encompasses all these steps
(except testing) in a holistic approach. Service discovery is not
done by querying public registries but VRESCO provides a
mechanism to publish services in its own registry and associate
them with expressive metadata which can later be queried by
a powerful query language.
A. CaaS Overview
An overview of the CAAS approach is depicted in Figure 1.
From an end-user perspective the developer (on the client-side)
specifies the composition in VCL and uses the client library
to invoke the composition service at the VRESCO runtime.
The client library provides a convenient way to access the
VRESCO core services (such as publishing, metadata, query-
ing, etc). Additionally, the client library compiles the VCL
173417341734
Authorized licensed use limited to: Universitatsbibliothek der TU Wien. Downloaded on September 29, 2009 at 07:40 from IEEE Xplore. Restrictions apply.
VRESCo Runtime Environment
Registry
Database
Metadata
Service
Publishing
Service
Notification
Service
ORM
Layer
QoS
Monitor
Composition
Service
VRESCo
Core
Client
Library
VCL
Specification
Infrastructure Level
Feature
Resolution
Constraint
Resolution & QoS
Optimization
Generation of
Executable
Composition
Client Side
d
Deployment of the
Composite
Service
e
c
a
Querying
Service
SOAP
Structured
Composition
Generation
b
Fig. 1. Architectural Overview of Composition as a Service with VCL
specification and checks for static errors to avoid contacting
the composition service using invalid input. Once a statically
correct VCL specification is sent to the VRESCO runtime,
the five steps (a) to (e) in the grey box on the left side
have to be executed to successfully deploy and provision a
composite service. Step (a) comprises the resolution of features
(service operations are denoted as features in our model – see
below) that are required for the composition. Resolving all
features implies a translation of the feature requirements into
a query that is offered by the VRESCO querying service.
In step (b) a data flow analysis of the VCL specification
is performed to determine dependencies among the service
and to generate a fully structured composition [22]. Once all
features and data dependencies have been resolved, step (c)
is activated where all the constraints in the VCL specification
have to be satisfied and the QoS optimization problem defined
by the QoS constraints has to be resolved. A non-satisfiable
constraint leads to an error and will send a notification back to
the user to allow changes, e.g., by relaxing some constraints.
Assuming all constraints are satisfied, the actual generation
of the executable composite service happens in step (d). Step
(e) finalizes the process by deploying the generated composite
service and sending the newly deployed service endpoint back
to the user. Additionally, the new service is registered in the
VRESCO registry using the publishing service.
B. Service Model
Before going into the details of VCL, we need to introduce
the foundations of our service model as it is essential for
VCL. The user needs to be able to define what should be
composed and the composition engine needs be able to retrieve
metadata about the services to match its capabilities with the
user’s requirements. In our approach, we define a service by
its functional and non-functional characteristics [11].
1) Functional Characteristics: The functionality of a ser-
vice is described by the VRESCO metadata model, an ab-
stract, feature-driven model for defining what functionality
is offered by a service. In Figure 2, we have depicted our
basic metadata model for modeling services, their categories,
features, pre- and postconditions. In this model we have to
abstract from the technical service implementation to achieve
a common understanding what a service does and what it
expects and provides. In a typical SOA environment, there
may be multiple services that facilitate the same business goal,
therefore, we also need a way to group services according
to their functionality. In the following, we use italic font
to represent model elements and typewriter to indicate
instances of a model element.
Category
Feature
Concept
Precondition
Postcondition
Predicate
Argument
Data Concept
isSubCategory
1..*
1
1
1
1
1
*
0..1
1
1
*
0..1
derivedFrom
consistsOf
0..1
*
Fig. 2. VRESCo Metadata Model
173517351735
Authorized licensed use limited to: Universitatsbibliothek der TU Wien. Downloaded on September 29, 2009 at 07:40 from IEEE Xplore. Restrictions apply.
The main building blocks of the VRESCO metadata model
are Concepts. A Concept is the definition of an entity in the
domain model (e.g., a generalized model element Person
and a special variant of it called Customer). We distinguish
between three different types of Concepts:
• Features represent activities in the domain that per-
form a concrete action, e.g., Calculate Loan,
Create Customer.
• Data Concepts represent concrete entities in the domain
(e.g., customers, addresses or bills) which are defined
using other Data Concepts (e.g., the concept Customer
might consist of Customer Id, Customer Name, and
Address) and/or atomic elements such as strings or
numbers.
• Predicates represent domain-specific statements that ei-
ther return true or false. Each Predicate can have a
number of Arguments that express their inputs. For exam-
ple, a (state) predicate for a Feature Create Customer
could be Customer Not Exists, expressing that a
customer must not exist before invoking that feature.
Concepts have a well-defined meaning specific to a certain
domain. Concepts may be derived from other concepts; that is
specifically interesting for Data Concepts, e.g., it is possible to
define the concept Premium Customer which is a special
variant of the more general concept Customer.
Each Feature is associated with one Cate-
gory expressing the purpose of a service (e.g.,
Customer Relationship Management). Each
category can have additional subcategories to allow a more
fine-grained differentiation. Each Feature has a Precondition
and a Postcondition expressing logical statements that have
to hold before and after the execution of a Feature. Both
types of conditions are composed of multiple Predicates,
each having a number of (optional) Arguments that refer
to a Concept in the domain model (indirectly through a
Data Concept). A Predicate can be used to express data
flow or observable state related information that may be
necessary when composing a service. For example, a Feature
called Create
Customer could have a precondition
Customer Not Registered(Customer) expressing
that a customer must not be registered before invoking it.
In general, predicates can be specified by the developer
to explicitly define flow and state behavior, however, they
are not required or enforced by the service implementation
upon execution time. This kind of metadata only provides
knowledge which is required later, when performing semi-
automated or fully automated service composition, where
such pre- and postconditions are a required means to guide
the composition process for stateful services.
The VRESCO client library provides an API to define the
aforementioned metadata programmatically. When concrete
service instances are published, the mapping between a feature
and a concrete service operation can be defined. Additionally,
the input and output concepts of a feature can be mapped
to the input and output of the concrete service instances.
Having multiple services which implement the same feature
enables a dynamic binding and dynamic interface mediation
between similar services [23]. This powerful concept enables
a transparent handling of service invocations based on features
and is foundational for the approach described in this paper.
2) Non-functional Characteristics: Besides the functional
characteristics, a set of QoS attributes is associated with
every service. QoS is a useful measure to distinguish well
performing from bad performing services. In general, one
has to distinguish between deterministic and non-deterministic
QoS. The former encompasses values which are known when a
service is invoked whereas the latter are unknown at invocation
time, therefore, they have to be gathered through runtime
observation. In [24], we have described an approach for
measuring QoS attributes from a client side perspective that we
use within the VRESCO environment (see the QoS Monitor
in Figure 1).
Attribute Formula Unit
Response Time q
rt
(n) =
1
n
n
X
i=0
q
rt
i
msec
Latency q
la
(n) =
1
n
n
X
i=0
q
la
i
msec
Availability q
av
(t
0
, t
1
, t
d
) = 1 −
t
d
t
1
−t
0
percent
Accuracy q
ac
(r
f
, r
t
) = 1 −
r
f
r
t
percent
Throughput q
tp
(t
0
, t
1
, r) = 1 −
r
t
1
−t
0
invocation/sec
Price n/a per invocation
Reliable Messaging n/a {true, false}
Security n/a {None,X.509,. . . }
TABLE I
AVAILABLE QOS ATTRIBUTES
All QoS attributes considered in our approach are shown in
Table I. For each attribute we list a distinct name, a formula
how the attribute is calculated in case of non-deterministic
attributes or “n/a” if it is deterministic (such as price, reliable
messaging and security). The response time q
rt
(n) is the dura-
tion that a service request needs on the wire plus the execution
time of service at the service provider. It is calculated as
the average value of n individual measuring points q
rt
i
. The
latency q
la
(n) is the time a request needs on the wire and the
average is calculated the same way as the response time. The
availability q
av
(t
0
, t
1
, t
d
) is the probability a service is up and
running and producing correct results; (t
0
, t
1
are timestamps,
t
d
is the time the service was down). The accuracy q
ac
(r
f
, r
t
)
is the probability of a service to produce correct results where
r
f
denotes the number of failed request and r
t
denotes the
total number of requests. The throughput q
tp
(t
0
, t
1
, r) is the
maximum number of requests a service can process within
a certain time period (denote as t
1
− t
0
), and r is the total
number of requests during that time.
QoS attributes are automatically available within the
173617361736
Authorized licensed use limited to: Universitatsbibliothek der TU Wien. Downloaded on September 29, 2009 at 07:40 from IEEE Xplore. Restrictions apply.
VRESCO runtime and are monitored using our approach
from [24]. The observed values are automatically associated
with the corresponding service operations in the VRESCO
registry and can be queried using the querying service (see
Figure 1).
IV. VIENNA COMPOSITION LANGUAGE
The main goal of VCL is to provide an intuitive and simple
DSL for the purpose of composition within the VRESCO
environment. It enables to capture what a composition should
do and what QoS is required from a global perspective and
also what QoS is required from individual services in the
composition (local perspective). Additionally, constraints on
individual services can be imposed, such as on inputs and
outputs of each service, preconditions or postconditions that
have to be fulfilled. A main concept in VCL is the fact that we
group QoS constraints into constraint hierarchies to address
the problem that not all QoS attributes can always be fully
satisfied and not necessarily have to be. Consider an example,
where a user specifies two global constraints on a composition
expressing that the response time should be ≤ 5000msec and
the availability should be ≥ 0.95. Unfortunately, the composi-
tion system cannot fulfill the availability constraint because its
actual value is 0.935, thus, the composition process fails due to
a violating QoS constraint. By using constraint hierarchies one
can add a strength to QoS attributes to express its importance
in a hierarchical way. Traditional constraint-based approaches
usually fail when a constraint is violated and no solution exists
that fulfills all constraints. Such systems of constraints are
called over-constrained systems. Constraint hierarchies [25]
have been proposed to solve such system by associating a
strength or preference value with each constraint expressing
its importance in the constrain resolution. In VCL we use
four different hierarchy values per default: {required,
strong, medium, weak} can be specified for each QoS
global or local QoS constraint and will be respected by the
composition algorithm.
The service model presented in Section III is an integral
part for the overall CaaS approach, as VCL has to rely on a
strong runtime support that is able to generate an executable
composite service from that abstract description specified in
VCL. The core elements of a VCL specification are visualized
in Figure 3 and described in detail in the subsequent sections.
A VCL specification of a composite service CS is a tuple
CS =< F D, F C, GC, BP S > with the following elements:
F D represents the feature definitions that specify which
features will be composed. Each feature has an associated
category and an invocation type defining whether a feature has
to be invoked synchronously (type sync) or asynchronously
(type async). The definition of features and categories fol-
lows the notation we introduced in Section III. Due to the fact
that categories can have multiple subcategories (as denoted
in Figure 2), the specification of categories allows a wildcard
character
*
to refer to a specific category within the category
tree without specifying the whole path in the category tree.
composition Sample1
Business Protocol Specifciation
invoke name1 { /* data assignments here */
invoke name2
join name1, name2
check (condition) {
invoke name3
}
invoke name4
return { status = "job done" }
Constraints
Feature Definition
feature name1, *.Category1, sync
feature name2, *.Category2, sync
feature name3, *.Category3, sync
feature name4, *.Category4, async
constraint global {
input = { }
output = { }
qos = { }
precond = {}
postcond = {}
}
Global Constraints
constraint name1 {
input = { /* constraints defined here */ }
output = { }
qos = { }
precond = { }
postcond = { }
}
Feature Constraints
Fig. 3. VCL General Schema
F C represents a set of (optional) feature constraints that
can constrain the input, output, QoS, precondition and post-
condition of each feature. The input and output constraints
restrict the data which is required as an input or output of
a feature. Preconditions and postconditions can be used to
express assertions that need to be valid before or after the
execution of a feature, respectively. QoS constraints can be
associated with a strength to express its preference (“required”
strength is the default).
GC represents the global constraints for the overall compo-
sition. Similar to feature constraints, global constraints can be
used to restrict input, output, QoS and specify preconditions
and postcondition for the resulting composite service CS.
The semantics of input and output is used to define input
and the output data of CS. In other words they define the
input and output of the composed service interface. Again,
QoS constraints can be associated with a strength value.
BP S represents an abstract business protocol specification
that defines what service should be invoked and can also
specify simple conditional execution or loops. The business
protocol specification does not have to specify a complete
composition, as it has to be done in WS-BPEL. Many aspects,
such as determining the execution order, are done automati-
173717371737
Authorized licensed use limited to: Universitatsbibliothek der TU Wien. Downloaded on September 29, 2009 at 07:40 from IEEE Xplore. Restrictions apply.
