Matthias Winkler
SAP Research CEC Dresden, SAP AG, Dresden, Germany
Alexander Schill
Chair for Computer Networks, TU Dresden, Dresden, Germany
Service dependency, Business service, Service composition, Service monitoring, SLA negotiation.
Business services are a valuable asset to be traded on internet service marketplaces. While they are offered via
the internet their execution often involves manual steps. The provisioning of services is regulated by service
level agreements (SLA). The composition of business services enables the creation of innovative business
processes which can be offered as services again. Selling these service compositions brings along challenges
for handling two important tasks, namely the monitoring of SLA violations and SLA renegotiation. Both tasks
are challenging because they affect not only a single service but multiple stakeholders of the composition. In
this paper we discuss the problem of dependencies between services in compositions based on a scenario from
the logistics domain. Dependencies between services are problematic because they lead to situations where
the SLA violation of one service affects the provisioning of other services. Similarly, the renegotiation of the
SLA of one service has effects on the SLAs of other services. We present a conceptual architecture and an
approach towards a solution for handling service dependencies.
The project was funded by means of the German Federal Ministry of Economy and Technology under the
promotional reference “01MQ07012”. The authors take the responsibility for the contents.
Within the TEXO project (Pressebuero, 2008) the
foundations for making business services tradable on
service marketplaces are established. Business ser-
vices are any kind of business activity offered by a
service provider to create value for a consumer. They
are offered via the internet but may be provided in-
volving manual tasks executed by humans or ma-
chines. The provisioning and consumption of ser-
vices is regulated by service level agreements (SLA).
Monitoring SLAs during service provisioning is im-
portant to ensure efficient provisioning of the service
and to build up trust between the stakeholders, i.e. the
providers of atomic services, the providers of com-
posite services, and the service consumers (Winkler
et al., 2008). In order to better distinguish the com-
posite service from its contained services, we call the
services, which are the building blocks of a composi-
tion, atomic services, knowing that they may be com-
posite services themselves.
When atomic services are composed to service
compositions dependencies regarding their execution
may exist. Problems during the execution of one
atomic service may hinder the execution of other ser-
vices. Problems are detected as service level objec-
tive (SLO) violations. SLOs are the single measur-
able elements of an SLA. In cases where services are
affected by problems, the service composition may be
adapted (e.g. exchange services, renegotiate SLA).
Also, there are situations where one stakeholder of
the composite service wants to renegotiate its SLA
and thus affects the other SLAs of the composition.
Although these dependencies have an impact on the
execution of the composition, they are currently nei-
ther directly described nor managed. Information re-
garding dependencies is indirectly available, though,
in the different SLAs negotiated between the compos-
ite service provider, the atomic service providers, and
the consumers of the composition as well as in the
underlying process of the composite service.
Based on a use-case from the logistics domain
(section 2), we will discuss the problem of service de-
pendencies in service compositions (section 3), out-
line our envisioned solution and present the results of
first steps towards this solution (section 4). Finally,
Winkler M. and Schill A. (2009).
In Proceedings of the International Conference on e-Business, pages 79-84
DOI: 10.5220/0002188600790084
we discuss related work (section 5).
Logistics services (e.g. transport and storage of
goods) are an example of business services. In our
scenario (see Fig. 1) the 4PL (fourth party logistics
provider) ”Global Transport” acts as organizer of a
logistics process offered as composite service ”Trans-
port DD-HH”. The process is created from three ser-
vices offered by different providers. The service is
bought by “Heal Pharma”, which needs to ship phar-
maceutical goods from Dresden to Hamburg. Ser-
vice “Truck DD“ offered by provider ”DD Logistics”
is responsible for picking up the goods at the “Heal
Pharma” factory in Dresden and delivering them to
the train station. There the goods are received by
provider ”Railway Services” and shipped to Hamburg
via service “Train Shipping DD-HH”. Finally, “HH
Logistics” delivers the goods to the customer of ”Heal
Pharma” via service“Truck HH”. During the provi-
sioning of this composite service the 4PL manages
the underlying process.
Transport DD-HH
Heal Pharma
Train Shipping
Heal Pharma
Figure 1: Simple Logistics Process.
When services are composed to service compositions,
they are implicitly collaborating to achieve a business
goal. We consider collaboration of services as im-
plicit because the atomic service providers may not
be aware of the full process and the different services
involved. Only the 4PL has all the information.
In our use case dependencies occur regarding the
time of transport and the amount of goods. These as-
pects are regulated by SLAs. The 4PL needs to assure
that the SLAs negotiated with the different providers
enable the smooth execution of the process. Problems
during the execution of one atomic service or the rene-
gotiation of its SLA may affect other atomic services
of the composition as well as the composition as a
whole. We will now analyse different types of depen-
dencies and illustrate them in our logistics use-case.
3.1 Types of Dependencies
We classify dependencies with respect to their oc-
currence either between atomic services or between
atomic services and the composite service. We call
dependencies, which occur between atomic services
of a service composition, horizontal dependencies,
because they affect services on the same hierarchi-
cal level of composition. In cases where horizontal
dependencies are managed properly they might not
show to the consumers of the composition. However,
this is not always possible. In such cases the effects
of the problem will be propagated through the whole
composition and thus affect it. Problems would then
be visible to the consumers of the composition. Hor-
izontal dependencies can be further classified into di-
rect and indirect dependencies. Direct dependencies
occur between two interacting atomic services. Indi-
rect dependencies occur between services which do
not directly interact with each other, but where a tran-
sitive relationship exists via an intermediate service.
Problems of an atomic service may affect the over-
all composition. We call these dependencies, which
occur across a hierarchical level of composition, verti-
cal dependencies. If vertical dependencies exist, SLO
violations of atomic services as well as their renegoti-
ation affect the SLA negotiated with the customer. In
many cases horizontal and vertical dependencies oc-
cur at the same time. Fig. 2 illustrates the presented
types of dependencies.
Vertical dependency
Horizontal dependency (direct)
Shipping DD-HH
Horizontal dependency (indirect)
Figure 2: SLAs and Dependencies in a Composite Service.
3.2 Dependencies in a Logistics Process
We will now illustrate the different types of dependen-
cies based on two SLO violation examples of our lo-
gistics use case: the delayed delivery of goods and the
delivery of a false quantity of goods. Late delivery:
The service ”Train Shipping DD-HH” follows a fixed
ICE-B 2009 - International Conference on E-business
schedule which sets the departure time of the train
to 6pm each day. In order for the transshipping of
goods from truck to train to be completed by that time,
goods need to be delivered to ”Train Shipping DD-
HH” by 4pm. When the train has reached Hamburg
the next morning, the goods need to be picked up by
the ”Truck HH” service between 6am and 8am. Vio-
lations of such time constraints may lead to problems
for multiple stakeholders of the process. If ”Truck
DD” cannot deliver the goods on time, the 4PL needs
to inform not only ”Railway Services” as the provider
of “Train Shipping DD-HH” but also ”HH Logistics”,
the provider of “Truck HH”, since there will not be
any goods to be picked up the next day. While the
dependency between ”Truck DD” and ”Train Ship-
ping DD-HH” is quite obvious (direct horizontal de-
pendency), the dependency between ”Truck HH” and
”Truck DD” is not. This is an indirect horizontal de-
pendency which can only be derived by analysing the
underlying process of the composite service. It may
also be necessary for ”Global Transport” to renegoti-
ate the SLA with “Heal Pharma”. Here we find a ver-
tical dependency between ”Truck DD” and ”Trans-
port DD-HH”.
False quantity of goods: ”Heal Pharma” con-
tracted ”Global Transport” to transport 10 pallets of
pharmaceutical goods. In case that an error occurs
during the loading or unloading of the goods, parts of
the cargo might get lost. Let us assume that the error
occurred during the loading of the truck at the ware-
house of ”Heal Pharma”. The problem will be rec-
ognized during the unloading procedure at the train
station and is propagated to ”Global Transport” as a
violation of the respective SLO by ”Truck DD”. Now
all contracts with the other services (”Train Shipping
DD-HH” and ”Truck HH”) need to be adapted in such
a way that the transport of goods should be carried out
for 9 pallets only. These are examples for horizontal
dependencies. There is also a vertical dependency to
the composite service due to the fact that it also cannot
be completed successfully any more. Thus, the con-
tract with ”Heal Pharma” will be violated or needs to
be renegotiated.
It might not always be necessary to adapt a pro-
cess once problems occur. The SLA might state that
deliveries need to be on time in 95 percent of all trans-
ports. Nevertheless it is important for many logistics
providers to avoid unnecessary costs. Such costs may
occur, for example, when ”Global Transport” does not
inform ”HH Logistics” about the fact that the goods
do not need to be transported any more. Providing
stakeholders with the right information or renegotiat-
ing SLA are possible ways for avoiding unnecessary
In many cases service dependencies cannot be
avoided but need to be actively managed by the com-
posite service provider. In this section we present an
approach which will support this work.
Our solution approach is based on an architecture
for service modeling and description, SLA (re-)nego-
tiation, and service monitoring. It is extended by
functionality for service dependency analysis in ser-
vice compositions based on SLAs and the business
process and a central model for capturing service de-
pendencies. This dependency model is created dur-
ing dependency analysis at the time of the creation
of the service composition and evaluated at runtime
upon the occurrence of SLO violations or a request
for SLA renegotiation.
In this chapter we present our conceptual architec-
ture, explain our approach to the formal modeling of
service descriptions and SLAs, and present first steps
towards a dependency model.
4.1 Conceptual Architecture
The proposed architecture, which is shown in Fig.
3 (in FMC notation
), consists of the service design
time tools (ISE Development Environment), a mar-
ketplace for trading services (Service Management
Platform - SMP), and a runtime environment (Trad-
able Services Runtime - TSR). It is based on joint
work together with our partners within the TEXO
The ISE Development Environment (Cardoso
et al., 2008) supports the modeling and description of
services based on the Universal Service Description
Language (USDL) (Cardoso et al., 2009) and the cre-
ation of service compositions. The analysis of service
dependencies and the creation of a dependency model
takes place as part of the development process. This
will be explained in more detail later. Following the
successful development of a service, it is deployed to
a TSR and registered at the SMP.
The SMP enables service providers to register
their services and thus make them available to inter-
ested consumers (creators of compositions as well as
end users). Besides functionality such as service reg-
istration and billing for service usage, SLA negotia-
tion is supported via the SLA Manager component.
We implemented SLA negotiation based on the WS-
Agreement specification (Andrieux et al., 2007). SLA
Fundamental Modeling Concepts website:
Platform (SMP)
ISE Development
Service Composition
SLA (Re-)
Model Store
SLO Violation Event
Monitoring Data
Model Store
Model Store
Dependency Model
Dependency Model
Figure 3: Conceptual Architecture.
templates are offered and can be requested from in-
terested consumers, who will then modify the tem-
plate according to their specific needs. The resulting
agreement proposal document will then be returned
to the SLA Manager and forwarded to the service
provider, who may decide to either accept or reject
the agreement. The final SLA will then be stored by
the SLA Manager from where it will be available for
the provider as well as the consumer for monitoring
The TSR provides support for executing and mon-
itoring services. To determine SLO violations, the
service monitoring component accesses SLA infor-
mation and compares negotiated SLO with monitor-
ing data. Upon the detection of SLO violations the
dependencies on other services are evaluated by the
Dependency Effects Evaluation component.
4.2 Modeling Services and Service Level
USDL forms the base for the formal description of
operational, technical, and business attributes of ser-
vices. It covers attributes which are common for most
services independent of their nature (rather technical
or more business oriented), including provider infor-
mation, terms of use and pricing. At the same time
USDL does not cover attributes which are specific
to any application domain of a service. Thus, we
have extended USDL with a language called Logis-
tics4USDL to express special attributes of the logis-
tics domain such as delivery time and transport ca-
pacity, to only mention a few. The following listing
presents a simplified version of a USDL service de-
scription enriched with Logistics4USDL elements.
service {
serviceName Train Shipping DD-HH
description Goods transport via train
business {
providerName Railway Services
providerAddress Traubestr. 17, Dresden
log4usdl:pickUpAddress Seestr. 1, Dresden
log4usdl:deliveryAddress Im Tal 3, Hamburg
log4usdl:pickupTime 2009-02-10T16:00:00Z
log4usdl:deliveryTime 2009-02-10T16:00:00Z
log4usdl:transportCapacity 10 pallets
reliability 95%
This formal service description provides the base
for formalizing contracts (SLA) (Cardoso et al.,
2009). SLA templates are created from the service
description as part of the service engineering process
and made available at the SLA Manager component
for SLA negotiation. These templates are based on
the WS-Agreement specification and are augmented
with service information using the USDL and Logis-
tics4USDL notations.
Based on the SLA information dependencies be-
tween different services are analysed and formalized
in a dependency model. The analysis of dependen-
cies requires a formal description of SLAs in order
to be able to relate service aspects of different ser-
vices with each other. This formal base is provided by
USDL and Logistics4USDL. A simplified version of
an agreement including USDL and Logistics4USDL
terms is presented in the following listing.
agreement {
Name Train Shipping DD-HH SLA
ServiceDescriptionTerm {
ServiceName Train Shipping DD-HH
usdl:description Goods transport via train
usdl:providerName Railway Services
usdl:providerAddress Traubestr. 17, Dresden
ServiceProperties {
VariableSet {
Variable {
Name deliveryTime
Metric xsd:dateDuration
Variable {
Name transportCapacity
Metric log4usdl:pallet
GuaranteeTerm {
ICE-B 2009 - International Conference on E-business
Name BasicService_GUARANTEE
monitored true
ServiceScope Train Shipping DD-HH
ServiceLevelObjective {
SLOName deliveryTime
ServiceLevel 2009-02-10T16:00:00Z
ServiceLevelObjective {
SLOName transportCapacity
ServiceLevel 10
4.3 The Dependency Model
We are currently developing a model for representing
the dependencies between services in service com-
positions. In (Bodenstaff et al., 2008), (Ludwig and
Franczyk, 2008), and (Zhou et al., 2008) three ap-
proaches to expressing dependencies are presented.
While they form a good base for our work, they have
some shortcomings. While the first two approaches
are only concerned with vertical dependencies, the
third one is not concerned with dependencies on the
base of SLAs. Please see the related work section for
more details. Thus, they need to be extended to fit the
needs of business services from the logistics domain.
Runtime (TSR)
Design Time
Violation Event
SLO Violation
Figure 4: Dependency Analysis and Dependency Effects
The dependency model will be created at design
time containing information about the SLAs which
were negotiated with the service consumer and the
different service providers, as well as the horizontal
and vertical dependencies between different SLOs of
all involved SLAs.
The creation of the dependency model will take
place in two steps. During the process of creating
the service composition, SLAs are negotiated with the
single service providers. The formal description of
SLOs based on USDL and Logistics4USDL will be
used as a base for determining the dependencies. The
created process determines the relationships among
services and thus helps analysing the dependencies.
The dependency model will be updated once an SLA
has been negotiated with a consumer of the composite
We currently envision an automatic approach to
dependency analysis and model creation based on the
formal process and SLA description. This process is
shown in Fig. 4. Further work is necessary to deter-
mine whether additional manual modeling effort will
be necessary.
Dependency effects evaluation is triggered by
SLO violations detected during service monitoring
or renegotiation requests. The Service Dependency
Monitoring component uses the dependency model
for evaluating horizontal and vertical dependencies
and provides information on affected services (see
Fig. 4). Finally the handling of detected issues is
Most approaches to SLA monitoring (Flehmig et al.,
2006; Ameller and Franch, 2008) are concerned with
the evaluation of single contracts between a service
provider and a consumer. This is not sufficient in the
context of composite services since they have hori-
zontal and vertical dependencies between the differ-
ent services which need to be considered. Thus, we
build on the different approaches and extend them
with the functionality for managing service depen-
The approach presented in (Bodenstaff et al.,
2008) monitors vertical service dependencies. A
model for formalizing SLA dependencies is de-
scribed. It covers the aspects of response time and
cost. This approach helps to determine to what extend
different services are responsible for SLO violations
of a composite service. Problems occurring between
single services are not covered. Thus, the approach
is too limited for the comprehensive management of
dependencies between services in compositions.
The COSMA approach (Ludwig and Franczyk,
2008) supports the management of SLAs in service
compositions where the SLOs negotiated for the com-
posite service depend on the respective SLOs negoti-
ated for the atomic services of the process. In a cen-
tral document called COSMAdoc the vertical depen-
dencies for different QoS parameters as well as price
information are expressed using aggregation formu-
las. Horizontal dependencies between the different
services are not handled.
In (Zhou et al., 2008) the authors discuss con-
trol and data dependencies in business processes in
the light of sequencing constraints. They present an
approach for deriving a dependency model from se-
mantically annotated business activities by evaluat-
ing their pre-conditions, effects, and parameters. It is
destined to support the handling of sequencing con-
straints at runtime. No work has been done with re-
gard to analysing SLAs, representing dependencies
between different SLOs or for the determination of
SLO violation and renegotiation effects.
Related to our work is also the functionality pro-
vided by Business Activity Monitoring (SAP, 2006)
approaches. Their goal is to monitor business ac-
tivities (e.g. sales process) spanning across organi-
zational boundaries. Events from different sources
are collected and correlated in order to determine
problems such as conflicting quantities of line items
between an order and received goods. This pro-
vides business people with information about prob-
lems within processes only after they have occurred.
It enables them to quickly react and potentially solve
the problem. It does not enable the prediction of ef-
fects of the problem on other parts of the business pro-
In this paper we have presented the problem of hori-
zontal and vertical dependencies between services in
compositions and argued for a need to manage them.
We have illustrated these dependencies based on two
examples from the logistics domain.
We also presented our solution approach to depen-
dency management in form of a conceptual architec-
ture. It supports the development of composite ser-
vices, trading of services on a marketplace, and ser-
vice provisioning via a service runtime platform. The
management of dependencies consists of two main
steps: the analysis of dependencies and creation of
a dependency model at design time, and the depen-
dency effects evaluation at runtime based on the de-
pendency model. Components for analysing and eval-
uating service dependencies were integrated into the
conceptual architecture as important building blocks.
As first steps towards the analysis of service de-
pendencies we presented how logistics services can
be formally described based on the Universal Service
Description Language and the Logistics4USDL ser-
vice description extension. This description provides
the base for formalizing SLAs which are then anal-
ysed for dependencies between services.
We outlined our envisioned dependency model, as
well as steps and artefacts needed to create this model
at design time and evaluate it at runtime. While large
parts of the conceptual architecture have already been
implemented as part of the TEXO project, the devel-
opment of the dependency model, as well as the de-
pendency analysis and evaluation components is on-
going work.
Ameller, D. and Franch, X. (2008). Service level agreement
monitor (salmon). In ICCBSS ’08: Proceedings of the
Seventh International Conference on Composition-
Based Software Systems (ICCBSS 2008), pages 224–
227, Washington, DC, USA. IEEE Computer Society.
Andrieux, A., Czajkowski, K., Dan, A., Keahey, K., Lud-
wig, H., Nakata, T., Pruyne, J., Rofrano, J., Tuecke,
S., and Xu, M. (2007). Web services agreement speci-
fication (ws-agreement). Technical report, Open Grid
Bodenstaff, L., Wombacher, A., Reichert, M., and Jaeger,
M. C. (2008). Monitoring dependencies for slas: The
mode4sla approach. In IEEE SCC (1). IEEE Com-
puter Society.
Cardoso, J., Voigt, K., and Winkler, M. (2008). Service
engineering for the internet of services. To appear
in Enterprise Information Systems, Lecture Notes in
Business Information Processing (LNBIP).
Cardoso, J., Winkler, M., and Voigt, K. (2009). A service
description language for the internet of services. Pro-
ceedings of ISSS 2009.
Flehmig, M., Troeger, P., and Saar, A. (2006). Design and
integration of sla monitoring and negotiation capabil-
ities. Adaptive Services Grid Deliverable D5.II-7.
Ludwig, A. and Franczyk, B. (2008). Cosma an approach
for managing slas in composite services. In Bouguet-
taya, A., Krueger, I., and Margaria, T., editors, ICSOC
2008, number 5364 in LNCS, page 626632. Springer-
Verlag Berlin Heidelberg.
Pressebuero, T. (2008). Texo - Business Webs
im Internet der Dienste. http://theseus-
programm .de/scenarios/de/texo.
SAP (2006). Business activity monitoring. White paper,
Winkler, M., Cardoso, J., and Scheithauer, G. (2008). Chal-
lenges of business service monitoring in the internet of
services. In Proceedings of iiWAS2008. Linz, Austria.
Zhou, Z., Bhiri, S., and Hauswirth, M. (2008). Control
and data dependencies in business processes based
on semantic business activities. In Proceedings of ii-
WAS2008. Linz, Austria.
ICE-B 2009 - International Conference on E-business