Peter Tr
oger, Harald Meyer
Hasso-Plattner-Institute at University of Potsdam, Prof.-Dr.-Helmert-Str. 2-3, 14482 Potsdam, Germany
Ingo Melzer, Marcus Flehmig
DaimlerChrysler Research & Technology, P.O. Box 2360, 89013 Ulm, Germany
Adaptive Services Grid, ASG, Service-Oriented Architectures, Service-Oriented Computing, Stateful Ser-
vices, Web Service Resource Framework, WSRF, Web Services, J2EE.
While tools for service-oriented architectures promise a seamless combination of stateless basic services to
new applications, reality looks different. Real-world services are wrapping stateful behavior using application-
specific concepts, the monitoring is only available through vendor-specific interfaces, and service installations
are bound to particular execution hosts.
We present the ASG Services Infrastructure (SI) architecture as our practical solution to these real-world
service integration issues. Our framework is based on established Web service standards and supports the
dynamic hosting and monitoring of heterogeneous and stateful service implementations.
Nowadays, real world service landscapes consist of
heterogeneous services and legacy systems. Higher-
level service functionality, like the automated and
adaptive creation of service compositions, abstracts
from these realities and assumes an idealized homo-
geneus Web service landscape. These approaches and
tools expect the integration and monitoring of existing
heterogeneous services in a unified manner, regard-
less of their technical varieties or proprietary state
semantics. Services need to be observable accord-
ing to their resource usage, performance metrics and
service-specific quality characteristics.
The European research project Adaptive Services
Grid (ASG) works on an open development plat-
form for the automated and adaptive creation of com-
plex service workflows, based on semantic service de-
scriptions. In the context of this paper, we give an
overview about our Services Infrastructure (SI) archi-
tecture, which was defined, implemented and oper-
ated as part of ASG during the last 18 months. SI pro-
vides a uniform and standards-based access to state-
ful service instances on dynamically allocated execu-
tion resources. This includes functionalities for de-
ployment, instantiation, invocation, and monitoring
of internal or proxy services. Our current SI imple-
mentation is based on a combination of commercial-
of-the-shelf (COTS) middleware products with estab-
lished standards from both the Web and the grid ser-
vice community. It acts as foundation for semantic
service composition in the ASG project, but works
also in other service-driven research projects as unifi-
cation layer for atomic services.
The ASG project, an integrated project of 21 Euro-
pean partners from seven countries, develops an archi-
tecture and reference implementation for automated
and adaptive discovery, creation, composition, and
enactment of services. ASG automatically creates
service compositions, based on an user-provided se-
mantic goal definition and requested quality parame-
ters (i.e. response time, costs). It discovers all nec-
essary services based on the semantic specification of
their functionality, and combines them to a dynami-
cally enactable service composition. More details are
available in according publications (Harald Meyer
and Mathias Weske, 2006) and the web
Tröger P., Meyer H., Melzer I. and Flehmig M. (2007).
In Proceedings of the Third International Conference on Web Information Systems and Technologies - Internet Technology, pages 434-438
DOI: 10.5220/0001286904340438
From the viewpoint of the service workflow com-
ponent in ASG, all service-related functionality such
as SLA negotiation, SLA monitoring and service in-
vocation are seen as implementation-independent fea-
tures. The representation of the service composition
in WS-BPEL demands a unified SOAP access to in-
tegrated or newly created services, regardless of pos-
sible stateful behavior, interface semantics or imple-
mentation technology issues. ASG therefore intro-
duced an abstraction layer between the external ser-
vice landscape and the Adaptive Process Management
component the Services Infrastructure component.
2.1 Web Services In Reality
The initial motivation for a ’unification’ layer in ASG
arose from the project analysis of real-world candi-
date Web services for use case scenarios. Even though
many Web services meanwhile rely on WS-I compli-
ant interfaces, there are still interoperability problems
in the daily work with them. Prominent examples
are PayPal (proprietary SOAP header for credentials),
Directi (enforced proprietary client library), Google
(non WS-I compliant RPC-encoded SOAP) or Ama-
zon (proprietary access / session key).
Demands for a language-specific client library are
mostly reasoned by non-standardized SOAP header
extensions for special purposes, such as session
handling or authentication. Complex types in the
WSDL structures can prevent the consumption of the
Web service interface in particular programming lan-
guages. We also experienced several bugs and miss-
ing features in frameworks like Apache Axis, JBoss
Axis, IBM WebSphere, or Sun WSDP in case of com-
plex WSDL descriptions, which are wrapped by these
Web services are usually assumed to process in-
coming messages regardless of earlier calls, other ac-
tivities in the system or the time of message arrival.
This is commonly named as ”stateless” service behav-
ior. In contrast, existing real-world services (whether
SOAP-based or not) often assume a functional un-
derstanding of server-side state on the client side.
Server and client form a joint session in their inter-
action, where the servers response depends not only
on the input arguments, but also on the current ses-
sion state. One example is mandatory security au-
thentication, which results in some proprietary user
session handling such as with today’s payment Web
services. Another example is cart management in
shopping services. In general, we found proprietary
implementations of session identification in the oper-
ational interface, in additional SOAP-body data (be-
ing the wrong spot for this kind of meta-data), or in
transport-protocol dependent methods such as HTTP
cookies. The service consumer then has the burden of
performing session-related activities, which are spe-
cific for each particular kind of service.
While this solution might be feasible for static
client applications, dynamic service composition fa-
cilities such as ASG are not able to perform special-
ized state operations for each service. Service compo-
sition facilities instead demand a unified and interop-
erable way of interacting with all atomic services, re-
gardless of their technical varieties or stateful interac-
tion patterns. In addition, with the introduction of ser-
vice contracting and monitoring capabilities, clients
need to have an understanding of the ’contract partner
instance’ on the other side.
Based on this analysis, we propose the idea of a
dynamic service hosting environment with an unified
stateful service interface.
Our Service Infrastructure (SI) stack is a thin and
scalable abstraction layer upon real-world service en-
vironments. We focused on the usage of existing and
approved middleware products and standards, in or-
der to keep the possibility of later reuse in industrial
3.1 Service Instance Concept
Our approach extends the idea of stateless Web ser-
vices with the concept of service instances on the in-
frastructure interface layer. Client applications (such
as the workflow engine in ASG) are enforced to per-
form an explicit service instantiation through a fac-
tory operation. The resulting endpoint reference doc-
ument describes all relevant data to perform a partic-
ular call to a logical service instance.
A logical service instance represents a stateful en-
tity to the client, but does not necessary need to be
realized by only one physical service instance on a
particular execution host in the infrastructure. This
slightly extends the idea of standard Web service
frameworks, where services are referenced by an end-
point URI for a particular service instance on a partic-
ular machine. Instead, all clients communicate with
an coordination layer (see Figure 1) that routes SOAP
requests (specifically the SOAP body) to a matching
execution host.
In our model, a logical service instance has query-
able state and monitoring properties and a lifetime
model. Client applications such as the workflow en-
gine are now enabled to consider stateful service state
data in the service workflow decisions, since all ac-
cording query operations become automatically part
of the particular service interface.
Figure 1: Service Infrastructure Architecture.
In order to realize the free mapping of virtual to
physical service instances, the physical service im-
plementations need to externalize their own state with
the help of the surrounding infrastructure. For each
logical service instance, the data storage of the in-
frastructure manages an own state data representa-
tion. The physical service instance on an execution
host accesses the state storage with a specific client
library, which passes the according logical instance
ID from the request SOAP header transparently to the
data layer. Therefore, every physical service instance
automatically uses the matching state data of the logi-
cal instance it serves the request for. The request pro-
cessing now can implement advanced mechanism like
voting or load balancing for logical service instances.
Scalability is achieved by using multiple coordination
layer instances, where the factory operation balances
instantiation requests between them.
In order to keep the consistency of the state data
in case of multiple requests, it must be possible for
a physical service implementation to demand serial-
ization of incoming requests for the same logical ser-
vice instance. Otherwise, it could happen that differ-
ent physical instances concurrently access and mod-
ify the state data for the same logical service instance
in an illegal way. In our framework, we provide this
configuration option as part of the service deployment
The classical scenario of purely stateless service
implementations can be seen as special case of this
idea, where the implementation does not store any
state information in the infrastructure. However, since
we also relate monitoring information to logical ser-
vice instances, it is still necessary to have the explicit
instance creation step with the factory operation.
A service instance concept automatically leads to
the need for lifetime management. Logical service
instances must be destroyed at some point in time,
either implicitly or explicitly. Another aspect is the
handling of fault situations, where the status of the
stateful instance must be well-known to the client for
an appropriate reaction.
With a classical stateless execution model, the
profiling of multiple service operation calls over a
time period cannot distinguish if a measured behav-
ior arises from the service implementation itself, from
some delay in the setup procedures, or from the exe-
cution environment it runs on.
With the logical instance approach, the client
(such as the dynamic service profiling and negotiation
components in ASG) can now differentiate between
behavioral aspects observed for a service instance on
a particular resource, the logical service instance in
general, or the service implementation. In order to
classify profiling results reasoned by some change in
the resource binding, our monitoring data model sup-
ports the abstract identification of the resource which
served the current / last request.
As another aspect, the service instance factory ap-
proach allows the easy integration of service negoti-
ation capabilities, which are researched by different
partners in the ASG project. With the concept of ex-
plicit service instantiation, each client negotiates ser-
vice aspects with their own logical service instance.
Due to the fact that in our concept each operation call
anyway must refer to its service instance, the negoti-
ated behavioral aspects are referenced automatically
by each service call and remain on the server side.
3.2 Service Properties Concept
A unified provisioning of state and monitoring data
enables service composition facilities, like in the ASG
architecture, to integrate all information seamlessly
in their dynamic decision procedures during work-
flow enactment. One example for these service prop-
erties are resource-bounded monitoring values, such
as response time, throughput or jitter. Even though
many toolkits, information models and analysis envi-
ronments already provide such data in different ways,
there is still some conceptional flaw in the binding
of monitoring properties to service interactions. By
using the concept of service instance properties, it is
now possible to relate monitoring data directly to a
logical service instance endpoint.
Beside resource-related information, a service
property can also provide implementation-specific
WEBIST 2007 - International Conference on Web Information Systems and Technologies
properties such as state information, or quality-related
information for dynamic SLA negotiation facilities.
The validity scope of the property declares another
categorization scheme. A service property can be
valid either in the service call scope, service instance
scope, or service implementation scope.
Properties from the service call scope are only
valid during and / or after a service operation call, un-
til the next service operation call happens
Properties from the service instance scope are
valid during the whole lifetime of a logical service in-
stance. They usually represent average values of call
scope values, as well as average values for continu-
ous resource-driven measurements. Implementations
can provide cross-operation information, like details
about the interconnection to a wrapped external ser-
Properties from the service implementation scope
are valid as long as the service implementation re-
mains deployed in the SI stack. This allows service
implementations to persist and offer relevant informa-
tion across different service instantiations. This in-
cludes configuration data, which is passed during the
deployment process.
Our unified ASG information model for monitor-
ing data relates such resource, service and state infor-
mation in one type system. It is derived from exist-
ing standards in this area, like the DMTF Common
Information Model (CIM) or the OASIS Web Ser-
vice Quality Model (WSQM). The model relies on a
combination of approved standards with standardized
metrics from the JVM and application server monitor-
ing interfaces. Details of this information model are
out-of-scope for this paper.
3.3 Dynamic Service Placement
Many existing service infrastructures rely on some
entry router hardware to provide load balancing and
fail-over capabilities. With such an approach, the
number of service containers offering the requested
service limits the available throughput rate for a ser-
vice type.
Reasoned by the fact that higher layers in ASG
only work with the virtual representation of service
instances, physical execution host crashes and over-
load situations need to be transparently handled by
the SI layer. During normal operations, the coordina-
We assume here that service operation calls for one
physical instance are happening in a serialized manner. This
is reasonable since reentrant service implementations usu-
ally also perform an internal synchronization of parallel
calls, in order to protect their access to underlying data
tion layer forwards an incoming request to one of the
matching physical service instances. This physical in-
stance is ensured to have enough resources available,
in order to fulfill the demanded performance goal.
In case of a node failure, static instance bindings
must be re-established on another empty execution
node. In case of a non-contracted service binding, the
load of the failed node is evenly distributed to the re-
maining execution resources, until no more machines
with this service type are available. A scheduling al-
gorithm in the coordination layer, based on the work
from (A. Karve and T. Kimbrel and G. Pacifici and M.
Spreitzer and M. Steinder and M. Sviridenko and A.
Tantawi, 2006), manages the placement with respect
to the current request load and earlier placement de-
cisions. It relies on a specific placement Web service,
which supports the upload and installation of the ser-
vice binary. For each supported service implementa-
tion format (currently J2EE, servlet, and .NET), the SI
provides an implementation of the same remote place-
ment interface.
Since the factory service gives the coordination
layer endpoint information to the client, it is possi-
ble to operate multiple coordination layer instances in
parallel. It is also possible to operate multiple factory
instances, in combination with some low-level bal-
ancing mechanism (such as round-robin DNS). Only
the central state and data storage needs to have a
unique view on the available data. Our current imple-
mentation relies on reliable standard database tech-
nology here, so that in sum we are able to provide a
crash-fault tolerant hosting infrastructure.
Facing the problem of unified state representation
with Web services, two major standards are available:
The Web Service Resource Framework (WSRF) (Tim
Banks, 2005) and the WS-Context (Mark Little and
Eric Newcomer and Greg Pavlik, 2006) specification.
Both specifications support the standardized represen-
tation of stateful entities in a Web service interface,
and meanwhile both are approved OASIS specifica-
Since ASG manages cross-service state anyway
in the composition engine, our SI framework con-
centrates on state issues of single service instances,
where standardized state querying and lifecycle man-
agement becomes a major issue. With respect to this
problem domain, we identified the WSRF as optimal
The family of WSRF specifications is supported
by companies such as IBM and Microsoft, the Globus
Alliance, HP, Fujitsu and CA. In our SI architecture,
these standards form the coordination layer interface
available for client applications.
The coordination layer is implemented as one
J2EE application, containing multiple servlets for the
different functional parts. The WSRF interfaces are
realized as JAX-RPC handlers, based on the Apache
WSRF implementation. The underlying service exe-
cution hosts can be different middleware technologies
(such as J2EE, .NET or OSGI).
So far, our prototype integrates JBoss 4, IBM
WebSphere 6, Apache Geronimo 1.0 and .NET instal-
lations on heterogeneous distributed machines in the
testbed. All SI parts where developed with the JBoss
4.0 application server.
We presented a short overview of the ASG Services
Infrastructure, which tries to fulfill the ’SOA promise’
of seamless legacy integration and on-demand re-
source usage. Based on practical demands from the
ASG project, we implemented the consistent repre-
sentation of service state, lifecycle and monitoring
data for higher layers. Our approach is based on the
WSRF Web service specifications and standard mid-
dleware products. The framework can act as integra-
tion platform for existing stateful legacy services, as
well as hosting platform for newly created service im-
Our future research efforts will concentrate on
service-level agreement (SLA) fulfillment strategies,
based on resource partitioning technologies and ba-
sic concepts from service capacity planning research
(Daniel A. Menasce and Virgilio A.F. Almeida,
2002). We started to extend the dynamic service in-
stallation capabilities with the usage of grid comput-
ing resources, based on standardized Grid API’s and
environments. In addition, we are observing exist-
ing solutions for migration of stateful entities in both
J2EE and .NET (Andreas Rasche and Andreas Polze,
2003), in order to relax the demand of state external-
ization in the service implementations.
A. Karve and T. Kimbrel and G. Pacifici and M. Spreitzer
and M. Steinder and M. Sviridenko and A. Tantawi
(2006). Dynamic placement for clustered web appli-
cations. In WWW ’06: Proceedings of the 15th inter-
national conference on World Wide Web, pages 595–
604, New York, NY, USA. ACM Press.
Andreas Rasche and Andreas Polze (2003). Configura-
tion and Dynamic Reconfiguration of Component-
based Applications with Microsoft .NET. In Interna-
tional Symposium on Object-oriented Real-time dis-
tributed Computing (ISORC), pages 164–171, Hako-
date, Japan.
Daniel A. Menasce and Virgilio A.F. Almeida (2002). Ca-
pacity Planning for Web Services: Metrics, Models,
and Methods. Prentice Hall.
Harald Meyer and Mathias Weske (2006). Automated Ser-
vice Composition using Heuristic Search. In Proceed-
ings of the Fourth International Conference on Busi-
ness Process Management.
Mark Little and Eric Newcomer and Greg Pavlik
(2006). Web Services Context Specification 1.0 (WS-
Tim Banks (2005). Web Services Resource Frame-
work (WSRF) - Primer, Committee Draft 01.
WEBIST 2007 - International Conference on Web Information Systems and Technologies