DYNAMIC PROVISIONING AND MONITORING OF STATEFUL

SERVICES

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

Keywords:

Adaptive Services Grid, ASG, Service-Oriented Architectures, Service-Oriented Computing, Stateful Ser-

vices, Web Service Resource Framework, WSRF, Web Services, J2EE.

Abstract:

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-

speciﬁc concepts, the monitoring is only available through vendor-speciﬁc 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.

1 INTRODUCTION

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 uniﬁed 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-speciﬁc 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 workﬂows, 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 deﬁned, 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 uniﬁ-

cation layer for atomic services.

2 ASG FRAMEWORK BASICS

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 deﬁnition and requested quality parame-

ters (i.e. response time, costs). It discovers all nec-

essary services based on the semantic speciﬁcation 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

http://www.asg-platform.org/

434

Tröger P., Meyer H., Melzer I. and Flehmig M. (2007).

DYNAMIC PROVISIONING AND MONITORING OF STATEFUL SERVICES.

In Proceedings of the Third International Conference on Web Information Systems and Technologies - Internet Technology, pages 434-438

DOI: 10.5220/0001286904340438

 SciTePress

From the viewpoint of the service workﬂow 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 uniﬁed 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 ’uniﬁcation’ 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-speciﬁc 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

libraries.

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 identiﬁcation 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-

ciﬁc 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 uniﬁed 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 uniﬁed

stateful service interface.

3 THE ASG SERVICES

INFRASTRUCTURE

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

environments.

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 workﬂow 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 (speciﬁcally 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

DYNAMIC PROVISIONING AND MONITORING OF STATEFUL SERVICES

435

model. Client applications such as the workﬂow en-

gine are now enabled to consider stateful service state

data in the service workﬂow 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 speciﬁc 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

conﬁguration option as part of the service deployment

descriptor.

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

proﬁling 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 proﬁling 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 proﬁling results reasoned by some change in

the resource binding, our monitoring data model sup-

ports the abstract identiﬁcation 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 uniﬁed 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-

ﬂow 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 ﬂaw 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-speciﬁc

WEBIST 2007 - International Conference on Web Information Systems and Technologies

436

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-

vice.

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 conﬁguration data, which is passed during the

deployment process.

Our uniﬁed 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

sources.

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 fulﬁll 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. Paciﬁci 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 speciﬁc 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.

4 IMPLEMENTATION DETAILS

Facing the problem of uniﬁed 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) speciﬁcation.

Both speciﬁcations support the standardized represen-

tation of stateful entities in a Web service interface,

and meanwhile both are approved OASIS speciﬁca-

tions.

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 identiﬁed the WSRF as optimal

approach.

The family of WSRF speciﬁcations is supported

by companies such as IBM and Microsoft, the Globus

DYNAMIC PROVISIONING AND MONITORING OF STATEFUL SERVICES

437

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.

5 CONCLUSION

We presented a short overview of the ASG Services

Infrastructure, which tries to fulﬁll 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 speciﬁcations 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-

plementations.

Our future research efforts will concentrate on

service-level agreement (SLA) fulﬁllment 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.

REFERENCES

A. Karve and T. Kimbrel and G. Paciﬁci 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). Conﬁgura-

tion and Dynamic Reconﬁguration 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 Speciﬁcation 1.0 (WS-

Context).

Tim Banks (2005). Web Services Resource Frame-

work (WSRF) - Primer, Committee Draft 01.

http://docs.oasis-open.org/wsrf/.

WEBIST 2007 - International Conference on Web Information Systems and Technologies

438