Implementing Dynamic Management for Mediated Service Interactions
Xiaoqiang Qiao, Wei Chen, Jun Wei
Technology Center of Software Engineering, Institute of Software,
Chinese Academy of Sciences, Beijing, China
{qxq; wchen; wj}@otcaix.iscas.ac.cn
Abstract—Considering the inherent heterogeneous, auto-
nomous and dynamic nature of Web services, mismatches
usually exist between service signatures and behaviors, and
mediation is a common approach for service interactions.
Current techniques focus on mismatch analysis and automatic
synthesis of mediators at development time, but they do not
consider the effect that dynamic changes of services bring
about for mediators at runtime. Since Web services are
continuously evolving, mediators should be equipped with the
dynamic adaptation and re-configuration capabilities to avoid
being the bottleneck of the adaptability of service interactions.
To address this challenge we propose a dynamic management
approach for mediated service interactions. In this paper,
migration strategies and correctness criteria suitable for the
mediator are provided to realize dynamic adjustment of
mediators at runtime, which ensures the agility and adapta-
bility of service interactions based on the mediation mechanism.
Keywords- Web services; service interaction; service
mediation; dynamic management
I. INTRODUCTION
In service-oriented computing [1], loosely coupled and
reusable services are used as basic building blocks, whereby
different organizations will be able to integrate their services
to achieve the business goal or offer value-added services.
Ideally, interactive services could be integrated correctly and
interact seamlessly. In real-life, however, Web services are
developed by different organizations and it is impossible to
predict all potential interactive possibilities at development
time. Hence there will be certain mismatches that make inter-
active services incompatible [2]. Such mismatches occur not
only at the signature level (the set of messages exchanged by
services) but also at the behavioral level (the allowed
message exchange sequences supported by services) [3].
For incompatible service interactions, developing me-
diators is a feasible technique to reconcile mismatches and
make services compatible [2]. Mediators could address mis-
matches without changing service implementations, which is
considered as a labor-saving approach and effectively im-
proves the reusability of services. An interaction conducted
by a mediator is called a mediated service interaction [4].
Some existing methods analyze the possible mismatch
patterns between service interfaces and business protocols to
develop mediators semi-automatically [3], [5]. Several other
approaches make further efforts on automated mediator
generation and mismatch identification [6], [7], [8]. However,
these works only focus on mismatch analysis and mediator
generation at development time. Considering the dynamic
nature of service computing environments, services can
evolve typically due to changes in operations and in business
protocols. How to dynamically migrate service interaction
instances that have already begun execution is a challenging
issue, especially for long running business applications.
From a business continuity perspective, in most cases, we
cannot abort all service instances and restart the interaction
from the beginning.
For the evolution of mediated service interactions, as the
mediator is the core of the service interaction system and any
change will induce modification of the mediator, the key is
to provide dynamic adaptation techniques for the mediator.
Evolution management and instance migration of the
mediator have some similarities to workflow [9], [10], [11]
and service protocol evolution [12], [13]. Most of the
existing methods provide primitive change operations and
corresponding compliance criteria to solve the problem.
However, these methods are not acceptable for mediator
evolution. On the one hand, commonly the mediator is
automatically synthesized, so it is difficult to distinguish the
types of modification primitives after the mediator evolution.
On the other hand, the compliance criteria require that the
execution trace could be replayed on the new protocol,
which is too restrictive for the mediator migration.
Receive (m
1
, m
2
)
W
Send (m
3
)
W
Receive (m
1
)
W
'
Send (m
3
)
W
Receive (m
2
)
W
(a) old mediator protocol
(b) new mediator protocol
Figure 1. Figure 1. An example of mediator evolution
For example, the mediator protocol has the changes as
depicted in Fig. 1. Suppose there is an instance and its
activity t
2
is activated. As both the forward and backward
paths have been changed, the instance could not be migrated
according to the existing compliance criteria. But through
further analysis, we could find the required messages of the
changed activity t'
1
and the inserted activity t
3
could be
supported by the executed activity t
1
. Therefore, the active
instance could continue to interact correctly without runtime
errors. In most cases, the main activities in the mediator
transfer and transform messages as shown in the above
example, thus existing compliance criteria are not applicable
for the mediator instance. Therefore, we should find an
2012 IEEE Ninth International Conference on Services Computing
978-0-7695-4753-4/12 $26.00 © 2012 IEEE
DOI 10.1109/SCC.2012.28
226
2012 IEEE Ninth International Conference on Services Computing
978-0-7695-4753-4/12 $26.00 © 2012 IEEE
DOI 10.1109/SCC.2012.28
234