Mobile Service Platforms Cluster

White Paper

Service Lifecycle Management

Date delivered: April 20th, 2008

Editor
Pierre-Guillaume Raverdy (INRIA, PLASTIC)

Contributors
Marco Autili (Univerity of l’Aquilla, PLASTIC)
Antonia Bertolino (CNR-Pisatel, PLASTIC)
Christophe Cordier (FTRD, SPICE)
Bhushan, Bharat (FOKUS, SPICE)
Isabel Ordás (TID, OPUCE)
Carlos Baladrón (Universidad de Valladolid, OPUCE)
Joe Gorman (Sintef, MIDAS)
Erik Klintskog (Appear Networks, MIDAS)
Alisa Devlic (Appear Networks, MIDAS)

Version: <1.0>

1
Alterations

Version Type of change Author(s)

1.0 Initial Public Release P. -G. Raverdy

Document Review

Date Version Reviewer Comment

Abstract

The ability to effectively manage the different steps of the service lifecycle is fundamental to
the success of mobile service platforms. Indeed, while service lifecycle has been traditionally
viewed as largely isolated steps, the need to take into account the changing mobile environ-
ment and the distribution of resources and service components is leading to stronger inter-
twining. This white paper presents the work on service lifecycle management carried out
within projects of the Mobile Services Platform cluster. Specifically, the problems of service
creation, monitoring, validation, deployment, discovery and composition in B3G networks are
addressed. While these projects have investigated the same research domains, the varia-
tions in the targeted application domains or in the underlying infrastructure have lead to dif-
ferent approaches and solutions.
This white paper was produced as a result of work in the Mobile Service Platforms (MSP)
cluster of IST FP6 projects. The MSP cluster is part of the Sixth Framework Program of Eu-
ropean research activities IST (Information Society Technologies). The cluster covers all
work providing elements of platforms, which facilitate the development and deployment of
mobile services. The cluster provides a forum to facilitate knowledge sharing on all aspects
of B3G service platform technologies. The problem space includes: hiding the heterogene-
ous service execution platforms, managing the personal communication sphere (devices,
groups, networks), creating autonomous systems, context/knowledge management, auto-
matic service composition, end-user/3rd party service development environments, service
roaming etc.

2
Contributing projects

Project name Short description

MIDAS MIDAS aims to produce an overall architecture and middleware
building blocks providing solutions to technical issues that must
(Middleware Platform
be addressed in developing mobile services. It specifically ad-
for Developing and
dresses mobile service provision in situations where the network
Deploying Advanced may need to be set up at short notice, or for limited duration, and
Mobile Services) where communications infrastructure may be unavailable for
some users, necessitating the need for use of ad-hoc communi-
cations. The middleware includes modules for establishing con-
nectivity using heterogeneous networks, distributed data sharing
in unreliable networks, generating synthesised context data, and
context-based routing of messages.
OPUCE OPUCE is an FP6 Integrated Project aimed at developing a com-
plete platform for the dynamic user-centric creation, deployment
(Open Platform for
and execution of services including information technologies and
User-centric service
communication features. The goal of the OPUCE platform is to
Creation and Execu-
put the end-user in the centre of the whole lifecycle of a service,
tion)
to let them become at the same time the creator, the manager
and the consumer of services.
PLASTIC PLASTIC (Providing Lightweight and Adaptable Service Technol-
ogy for Pervasive Information and Communication) revisits ser-
(Providing Light-
vice-oriented computing for the B3G network, in particular assist-
weight and Adaptable
ing the development of services targeted at mobile devices. Spe-
Service Technology
cifically, the PLASTIC platform provides a development environ-
for Pervasive Informa-
ment leveraging model-driven engineering for the thorough devel-
tion and Communica-
opment of SLA- and resource-aware services, a middleware lev-
tion)
eraging multi-radio devices and multi-network environments for
applications and services run on mobile devices, and a validation
framework enabling off-line and on-line validation of networked
services.
SPICE SPICE is an IST-FP6 Integrated Project addressing the problem
of designing, developing and putting into operation efficient and
(Service Platform for
innovative mobile Service creation/execution Platforms for net-
Innovative Communi-
works beyond 3G. SPICE investigates novel platform features
cation Environment)
such as distributed communication sphere management, intelli-
gent service enablers, service roaming, adaptive content delivery
and multi-domain access control.

3
Contents

1 Introduction .................................................................................................................... 7
2 Service Model and Creation Tools.................................................................................. 9
2.1 Related Work .......................................................................................................... 9
2.1.1 Service Oriented Architecture........................................................................... 9
2.1.2 Component vs Service Orientation ................................................................... 9
2.2 PLASTIC Conceptual Model for Adaptive Services ................................................10
2.2.1 Combining services and components..............................................................11
2.2.2 Extending the SeCSE conceptual model .........................................................12
2.3 SPICE Component Model and Toolchains .............................................................12
2.4 User-centric Services in OPUCE ............................................................................13
3 Service Validation..........................................................................................................17
3.1 Related Work .........................................................................................................17
3.1.1 Testing of networked systems .........................................................................18
3.1.2 Web Services Testing .....................................................................................19
3.1.3 Runtime Monitoring .........................................................................................20
3.1.4 QoS Validation of Networked Services............................................................20
3.2 Validation in PLASTIC............................................................................................21
4 Service Deployment ......................................................................................................23
4.1 Related Work .........................................................................................................23
4.1.1 Bundle deployment in OSGi ............................................................................23
4.1.2 SmartFrog and CDDLM...................................................................................24
4.2 Context-aware service deployment in MIDAS.........................................................25
4.3 Service deployment in OPUCE ..............................................................................26
5 Service Discovery..........................................................................................................28
5.1 Related Work .........................................................................................................28
5.2 New challenges for service discovery.....................................................................29
5.2.1 Multi-protocols SD...........................................................................................29
5.2.2 Context-aware SD...........................................................................................30
5.2.3 Semantic SD ...................................................................................................30
5.2.4 Multi-networks SD ...........................................................................................30
5.2.5 Security and privacy........................................................................................31
5.2.6 Mobility............................................................................................................31
5.3 Service Discovery in PLASTIC ...............................................................................31
5.4 Discovering, publishing and sharing services in OPUCE ........................................32
6 Dynamic Service Composition.......................................................................................33

4
 6.1 Related Work .........................................................................................................33
6.1.1 Web service conversation ...............................................................................33
6.1.2 Web service choreography..............................................................................34
6.1.3 Web service orchestration...............................................................................34
6.2 New Challenges for Service composition in B3G environments .............................35
6.2.1 Dynamic service composition ..........................................................................35
6.2.2 Reconfigurable service composition ................................................................35
6.3 Service broker architecture in SPICE .....................................................................36
6.4 The Service Composition Model in OPUCE ...........................................................37
7 Conclusion ....................................................................................................................39
8 References....................................................................................................................40

5
List of Figures
Figure 1: Design-time and run-time aspects of service lifecycle............................................. 7
Figure 2: Service lifecycle in MobiLife.................................................................................... 7
Figure 3: PLASTIC two-layers approach ..............................................................................11
Figure 4: OPUCE architecture ..............................................................................................14
Figure 5: OPUCE faceted approach to service description ...................................................15
Figure 6: MIDAS middleware components............................................................................26
Figure 7: Service provisioning and deployment in OPUCE ...................................................27

6
1 Introduction
The ability to effectively manage the lifecycle of services is fundamental to achieving success
within mobile service platforms. Service lifecycle [1][2] can be abstracted as a succession of
operations which can be grouped into design-time aspects and run-time aspects (see Figure
1).

Figure 1: Design-time and run-time aspects of service lifecycle

Design-time aspects include service modeling, development and packaging while run-time
aspects include, among others, the deployment, discovery and execution of these services
(See Figure 2). While service lifecycle has been traditionally viewed as largely isolated steps,
the need to take into account the changing mobile environment and the distribution of re-
sources and service components is leading to stronger intertwining. This white paper pre-
sents the work on service lifecycle management carried out within projects of the Mobile Ser-
vices Platform cluster. While these projects have investigated the same research domains,
the variations in the targeted application domains or in the underlying infrastructure have
lead to different approaches and solutions.

Figure 2: Service lifecycle in MobiLife

In this paper, we describe work undertaken in different IST projects of the MSP cluster cover-
ing service lifecycle management at both design-time and at run-time. In particular, we focus
in Chapter 2 on the various service models adopted by various projects and the creation
tools they provide. A common evolution of these projects compared to traditional service
models is to emphasize the modeling of non-functional properties in their models. We then
describe in Chapter 3 how service models may be used to support design-time and run-time
service validation. In particular, we describe how service modeling can be used to automati-
7
cally generate monitors and test suite for service validation. Chapters 4 and 5 focus respec-
tively on service deployment and service discovery. While projects targeting telecom-oriented
B3G networks (i.e., infrastructure-based) build on top of well-proven solutions for scalability
and security, projects targeting highly dynamic networks (e.g., pervasive environments, sen-
sor networks, MANETs) need to provide innovative solutions to deal with the heterogeneity
and dynamics of their environment (e.g., service mobility). In Chapter 6, we describe support
for service composition, which is a major research topic in most MSP projects. Finally, we
conclude in Chapter 7.

8
2 Service Model and Creation Tools

2.1 Related Work

Generally speaking, Software Architectures (SA) are meant to abstractly model the overall
structure of a system in terms of communicating subsystem. In a component-based setting,
this general definition of SA can be rephrased by substituting the word subsystem with set of
software components interacting through communication channels. In a service-oriented vi-
sion, the communicating subsystem is composed of services that interact in a more loosely-
coupled fashion. We now discuss the properties of service and component based architec-
tures and their associated service model.

2.1.1 Service Oriented Architecture

Service Oriented Architectures (SOA) are meant to abstractly model the overall structure of
service-centric software systems in terms of communicating services. SOA is a loosely-
coupled model whose most significant aspect is that it separates the service implementation
and the service provider from its contractual description. In this way, it separates the “what”
from the “how”. The service description is given in neutral manner, independently from any
platform and implementation detail. Service consumers view a service simply as an endpoint
that supports a particular request format or contract. Service consumers do not need to know
how the service will act for satisfying their requests; they expect only that it will.
Due to the rapid evolution of software service technologies, the development of service-
based software applications can lay nowadays on a solid support and is adopted in ever
wider application domains. Applications are built as assemblies of existing services, and ever
more mature tools for discovering (over the web) and adapting services are being developed.
A classic example of a proto-SOA system that has been around for a while is CORBA, which
defines similar concepts to SOA. SOA is different from it in the roles played by “interfaces'”
(description). In fact, SOA relies on a more flexible and neutral language for describing inter-
faces. Web Services (WS) represent a concrete instantiation of SOA. Web Services are
components that can be integrated into more complex distributed applications by means of
some Web-based/XML-based open standards (e.g. WSDL, UDDI, HTTP, SOAP, etc.). Web
services are not the only way to implement SOA. Message-Oriented Middleware systems,
such as the IBM MQ Series, represent an alternative.

2.1.2 Component vs Service Orientation

Starting from an assembly-oriented view of software engineering, Component Based Soft-
ware Engineering (CBSE) promotes the construction of a software application as a composi-
tion of reusable building blocks called components.
In a component-based approach, assemblers build applications by wiring ports of connectors
and “ready to use” components. In other words, integration is carried out at assembling time.
As a direct consequence, composition is structural in nature and the component should pro-
vide the external structure of its instances (such as provided and required functional inter-
faces). Preconditions, post-conditions, and a behavioral specification of the interaction with
its environment may be also required to allow assemblers to connect and eventually adapt
the various component instances. Hierarchical structural composition is achieved when the
external view of a component is itself implemented by a composition.
Sharing the same idea of component orientation, software applications in service orientation
are assembled from reusable building blocks, but in this case the blocks are represented by
services. Each service has a description of provided functionalities that can be contractually

9
defined as a mix of syntax, semantics and behavior specifications. The basis for assembling
services is only service descriptions. In this way, as opposed to component orientation, ser-
vice integration may be carried out either prior or at run time. In such a context, it is clear that
service orientation concentrates on how the services are described in order to support dy-
namic discovery and possibly run-time integration.
Service orientation promotes the idea that different service providers may supply a service.
In fact whenever other providers comply with the contract imposed by the service description
they can be interchanged. In this way a requester is not coupled with a particular provider.
Another fundamental characteristic of service orientation is that services exhibit dynamic
availability, since they can be added or removed from the service registry at any time. Con-
sequently, running applications must be capable of releasing departing services or of incor-
porating newly arriving services. Table 1 summarizes in a point-to-point view the previous
discussion about service orientation and component orientation.

Service Orientation Component Orientation

Emphasis on software service descrip- Emphasis on component external-view.
tions.
Natural separation from description and No evident separation between compo-
implementation. nent external-view and implementation.
Only service description is available dur- Component physically available during
ing assembly. assembly.
Integration is made prior or during execu- Integration at assembly-time.
tion.
Better support for run-time discovery and No native support for run-time discovery
substitution. and difficult substitution.
Native dynamic availability. No native dynamic availability.
Abstract composition. Structural composition.

Table 1 – Main aspects of Service Orientation and Component Orientation.

2.2 PLASTIC Conceptual Model for Adaptive Services

The main role of the PLASTIC conceptual model is to build a common vocabulary on which
to base modeling and development tasks and is inspired by the SeCSE conceptual model
The model has been conceived to be extensible since it can be easily adapted in order to
accommodate different needs coming from different service-oriented domain. The SeCSE
conceptual model was initially inspired by the Web Service Architecture (WSA) drafted by the
W3C to introduce a unified model in the domain of service-oriented applications. However,
the SeCSE model can be seen as complementary to the one of WSA since SeCSE tries to
clarify and detail the concept of service more than the WSA does for the concept of service.
The PLASTIC conceptual model extends the conceptual model of SeCSE by introducing new
concepts and relations. In particular it introduces the concepts of: context, location, adapta-
tion, resources available at the consumer side, service level agreement. In addition, it inte-
grates into the service model the concepts related to software components. The need of this
integration comes from the adaptive nature of B3G applications and is one of the first attempt
to explicitly specify the relationships between Service Oriented Architectures and Compo-
nent-Based Software worlds.

10
2.2.1 Combining services and components
Services in PLASTIC are meant to be adaptable to the context whether related to the user
setting (e.g. type of device, user mobility) or the available network resources (e.g. network
bandwidth). The goal is to provide services that achieve the best tradeoff between the user
needs (in terms of Quality of Service) and the current context characteristics (in terms of
available resources).
In order to achieve a high degree of adaptability, services must be aware of the context
where they run. Thus, we make the context characteristics emerging at the service level: a
service description will be not limited to its functional characteristics (i.e. signature and be-
haviour), but it will bring additional attributes that model its QoS characteristics (e.g. service
reliability, latency time).
PLASTIC’s approach is somehow opposite to a typical layered architectural model, where
differences in a lower layer (in terms of functional and non-functional characteristics) disap-
pear in at the upper layer. Instead, it stresses the importance of application-awareness as
opposed to distributed system transparency.
In PLASTIC, applications in the B3G environment should always guarantee a certain level of
QoS to the consumer despite the heterogeneity and richness of the underlying networks. At
the same time, the components implementing the services should have the capability to
adapt to different contexts. QoS and adaptation are thus the main keywords for the PLASTIC
conceptual model. Figure 3 shows this two-layer vision of a software application:
• The component layer represents the computing environment for networked services
that is able to manage the life cycle of the software components while delivering func-
tionalities for a device from anywhere in the network. Software components can be
deployed, updated, or removed on the fly without interrupting the operability of the
device.
Components developers bind to services by only using service descriptions. In other
words, components contractually implement service descriptions but the selection of
the specific component to instantiate is deferred at run-time by taking into account the
service requester needs and the environment/context of service access.
• The service layer manages two aspects: (i) the description of services and their com-
position, (ii) the mapping between services and set of components implementing
them.

Service Service Description

S8
Service
S4 Layer
S9
Service
S5
S3 Service Composition
request S7
S10

Service
Consumer

C7 C9
Software
C4 Developer
C2
C1
Component Assembling
C3 C6
C5 Component
C8 Layer

Component Component Description

Figure 3: PLASTIC two-layers approach

11
2.2.2 Extending the SeCSE conceptual model

The new entities introduced in the conceptual model of SeCSE by PLASTIC are as follows:
• Context: This entity represents the (physical/logical) context in which the service that
will run is executed. It is used by the PLASTIC platform to provide/adapt services in
order to better meet the user requirements on the service. The context is a first class
entity in the PLASTIC conceptual model since it influences the Service Level Agree-
ment procedure, the composition of software services and the adaptation of software
components.
• Context Description: This entity represents the information the PLASTIC platform is
able to retrieve from the environment, suitably structured. In general this information
is partial since it is too heavy (and useless) to gather the complete information on
context. It contains the descriptions of the available resources (logical and physical).
• Available Resources Specs: This entity is part of the context and it contains the de-
scription of the resources available at the service consumer side. In other words it
contains specifications about the device the service consumer uses in his service re-
quest. This piece of information about the context in which the service will run on and
it is contained in the service request expressed by the consumer.
• Location: Location is the identification of a context. It can be related both to physical
and logical context. This entity is useful to model mobility in PLASTIC platform. The
context is hence identified by a location contained in the context description. Each of
the component(s) implementing a service resides in a single location.
• Component Description: Component Description contains functional and non func-
tional specification of the software component it corresponds to. Among non func-
tional aspects the PLASTIC platform requires that QoS attributes of the component
are explicitly defined and that it contains the location where the component will be
deployed and executed. The information specified in this entity is used in the software
component assembling and in the component adaptation. Finally there is a strict rela-
tion between the description of the software service and the one of the software com-
ponent implementing the service.
• Adaptation Specs: This entity models the rules used to adapt a software component
to a specific context. The specified rules make use of the component description in
order to suitably adapt the involved software component(s) to the available context
where the software service will run.
• Service Level Agreement: This entity models the agreement reached between the
service consumer and the service provider. In practice, SLA is composed from multi-
ple different clauses and each clause addresses a particular service request require-
ment. It represents the contracts between them. Context, Service Request and Ser-
vice Description influences the procedure that finishes with the agreement.

2.3 SPICE Component Model and Toolchains

A hierarchical, abstract component model (largely influenced by the Fractal model [92]) has
been designed for the SPICE platform with the explicit goal of supporting automatic composi-
tion. This model defines two kinds of components: basic components that cannot be decom-
posed further and composite components that can be the composition of basic or other com-
posite components. The component input and output interfaces are labeled with identifiers
and are associated with meta-information.

12
Every service request served by the service platform is handled by a composite component.
In trivial case, the composite component consists of exactly one component that is fully
specified (endpoint, version, etc.). In complex cases, the composite component may be
composed of other composite components with a large nesting level. The components han-
dling a service request and their connections are referred to as service component network.
Furthermore, a component network is said to be abstract if its components or component
connections are not fully known at design time. Abstract component networks are associated
with adaptation rules that control how the components and component connections need to
be selected according to conditions of the environment.
SPICE provides the Service Creation Environment (SCE) that supports the creation of basic
components, intelligent components, and value added services. The SCE provides graphical
service development tools, as well as emulation of service enablers and testing environment.
Two separate toolchains support the needs of the professional service developers and the
needs of the end users respectively.

• The dedicated Development Studio for professional developers is being developed

around the high-level service description language SPATEL (SPICE Advanced Ser-
vice Description Language for Telecommunication Services). SPATEL allows using a
Model-Driven Architecture (MDA) approach for transforming a service idea through a
platform independent representation to an executable service.

• The special End User Studio allows the end-users to create service mashups from
existing SPICE services, which are easily tailored to their needs. This means that
end-users are not allowed to compose arbitrary mash-ups, but rather they have a se-
lection of templates that dictate how services can be combined and parameterized.
These templates are provided and maintained by the platform operator or third party
service providers.

2.4 User-centric Services in OPUCE

Users are putting pressure on telecom operators by increasingly requiring innovative and
attractive services: They would like to have the advanced model they use on the Internet
which allows users to define new contents and applications (mashups) using open services
and interfaces that could be quickly and easily built and deployed (e.g. Yahoo Pipes). User-
centric service creation in OPUCE refers to this process. It enables end-users (not necessar-
ily the very technically skilled) to create their own services and manage the lifecycle of those
services autonomously. It also allows users to share these services within a community that
will promote the most interesting ones at a minimum cost.
In order to support the aforementioned approach, it has become imperative for telcos to iden-
tify the operators' assets that can be provided only in the core network such as end-user lo-
cation and presence information, and then abstract and offer them through well defined inter-
faces. Users may use these resources to create new or personalized services. Service Ori-
ented Architecture (SOA) is the main approach to opening up network resources with initia-
tives such as ParlayX or Open Mobile Alliance (OMA) enablers, which converge in the use of
Web Services as the middleware allowing third parties to access and control network re-
sources. OPUCE1 aims to let users create, manage and use their own telecom-based ser-
vices in an Internet style. In OPUCE, services are envisioned as short-lived telecom services
that end-users will create by orchestrating simpler services called base services. Base ser-
vices are considered as functional units deployed by the operator or authorized third parties,
available at the OPUCE platform and offered to end users through Web Services interfaces

1
http://www.opuce.tid.es/
13
(e.g., a positioning service, a messaging service or a map service). Furthermore, the creator
may publish and share the service with other users.

Figure 4: OPUCE architecture

Figure 4 introduces a detailed diagram of the OPUCE architecture. Its main elements are:
• A Service Creation Environment with a set of tools to be used by people or third par-
ties to create services.
• A Context Awareness module to manage the adaptation and customization of ser-
vices to the users’ ambience conditions
• A User Information Management module to control the user’s personal information,
identity management and AAA issues.
• A Subscription Management module to keep control of the user subscriptions to ser-
vices
• A Service Lifecycle Manager module, which manages the lifecycle of all services,
created within the OPUCE platform.
• A Service Execution Environment, which manages the execution of services and or-
chestrates base services following the logic created by the users when composing
them.
A user-centric based service ecosystem requires major flexibility and dynamicity in managing
service lifecycle compared to current service management systems. In order to automate the
process between the creation and the execution of the services, the OPUCE platform needs
a common way to completely describe the services. The concept of service description has
already been addressed in projects such as SPICE2 and SeCSE3. Some of the results of

2
http://www.ist-spice.org/
14
these projects have been considered in OPUCE to create a service specification model com-
pletely. More precisely, the faceted approach of the service description defined by the
SeCSE project has been extended to support the user-centric features of OPUCE services,
including the user-driven lifecycle management of user-centric services. Figure 5 depicts the
faceted specification followed in OPUCE.
Therefore, in OPUCE, services are described using a service specification which contains all
aspects of a service. Each aspect, called a facet, is further described in a separate XML-
based specification. With a view to all the functionalities available in the OPUCE platform we
have considered three sets of facets:
• Functional facets, which include service logic facets, service interface facets, service
semantic information facet, etc.
• Non-functional facets, which include service level agreement (SLA) facets, quality of
service facets, etc.
• Management facets, which include service lifecycle schedule and deployment facets.

Figure 5: OPUCE faceted approach to service description

As the OPUCE service creation tools also target end-users that lack the relevant skills and
knowledge of service developers, they must ease the task of service creation as much as
possible: suitable techniques to achieve this goal are user friendly graphical interfaces, wiz-
ards, composition helpers, guided editing etc., but others could also be leveraged, such as
natural language descriptions. The OPUCE platform also advocates that end-user service
creators should be enabled to enjoy their new role of service creators using every device and
access at hand, namely PCs, mobile phones, PDAs etc. This extended range of target de-
vices imposes a requirement both on the SCE and on the resulting service definitions.
To that end, OPUCE will deliver two different service creation environments:
• The full feature editor that supports a description language accepting a large number
of composition rules, rich graphical user interface (possibly with a large footprint), ad-
vanced validation tools etc.

3
http://secse.eng.it/
15
 • The simplified editor with less demanding user interface, simpler description lan-
guage, restricted set of available operations, more guided creation/customization
process, etc.
However, in order to support cross-editing, both tools share the same design principles and
take a consistent approach to the underlying service platform, linking with a centralized ser-
vice repository in the background. In fact, both editors show OPUCE services with specific
“service resolution”: the more advanced the editor the higher the resolution. But both work on
the same material, i.e. the service definition.

16
3 Service Validation
As outlined in the introduction, enabling the development and deployment of mobile adapt-
able robust services for Beyond 3G (B3G) networks faces numerous challenges such as
easing the deployment of services on a wide range of infrastructures or taking care that us-
ers of the services always experience the best Quality of Service (QoS) possible according to
their specific situation. Because of the emphasis on the QoS and on the dependability of ser-
vice behaviour, the validation of B3G applications must consider in equal measure both func-
tional and extra-functional properties, i.e., not only we need to check that the behaviour of
service-oriented applications complies with the expected logical sequence of events as de-
fined in the service functional specifications, but also that the services abide to the expected
or contractually agreed levels of quality, which are also part of the specifications in form of
suitable annotations.
Following the definition of terminology associated to validation, we survey in Section 3.1
some topics related to the validation of B3G services, which altogether make the context for
the development of a B3G validation framework. We then detail how service validation is
carried out in PLASTIC.

3.1 Related Work

As the literature is wide and many of the terms we use are overloaded, it is useful to infor-
mally introduce the meaning we assume for the main terms adopted throughout.
Functional Validation vs. QoS validation: As the requirements on B3G services involve
functional and extra-functional properties, both functional and QoS validation should be ad-
dressed. Functional testing relies on validating the observed behaviour of a system in terms
of the I/O sequences of events. In particular, it checks if the functionalities implemented by
the systems conform to those described in the functional specification. On the other hand,
QoS validation concerns the activities that focus on checking whether the system under test
meets its extra-functional constraints.
Off-line vs. On-line: Methods and tools for testing purposes can be classified into two main
categories: off-line and on-line. Off-line validation activities are performed while no user
("paying customer") is using the service. Hence, off-line validation of a system implies that it
will be tested in one or more artificially evolving environments that simulate possible real in-
teracting situations. In this case the system is still undergoing development or, in a wider-
ranging view, it is already completed but not available for use (deployed) yet. On the other
hand, on-line approaches concern a set of techniques, methodologies and tools to monitor
the system after its deployment in one of its real working context. A possible scenario is that
while the end-users are using the service, data are being collected about the scenario under
which the service is being used and this data is sent back to the development organization,
which then determines (i.e., validates) whether the service behavior is correct (i.e., the "test"
passes) or incorrect (i.e., the "test" fails). Hence, the "test cases" consist of actual usage
scenarios. Otherwise, the development organization performs on-line validation activities on
a fully fielded service, perhaps during idle times.
Testing vs. Monitoring: Software testing is a broad term encompassing a wide spectrum of
activities. The primary underlying common goal of these activities is to apply methodologies
and techniques designed to make sure that a software system does what it was designed to
do and that it does not do anything unintended. However, the idea of pursuing such a goal
just by applying an exhaustive exploration of all possible configurations of the system and of
its environment is unrealistic. So, given a generic software system, testing activities focus on
observing a sample of its execution. Monitoring is a runtime activity whose objective is to
collect data about a phenomenon and analyze them with respect to certain criteria. Crucial
monitoring steps are the elicitation of which data should be collected, how long the observing

17
windows are, what policies should be applied when a fault is detected, and so on. In some
approaches, the middleware is responsible for providing the facilities to disseminate the data
collected from the sources to the sinks that analyses the data. The two practices clearly have
many commonalities in terms of overall goals and problems. In this sense, is possible to con-
sider the monitoring as one of the specific testing activities that are applied when the system
is on-line.

3.1.1 Testing of networked systems

Distribution is one inherent characteristic of B3G applications, and MSPs thus need to cope
with issues surrounding the testing of networked services. Ghosh and Mathur [20] list a num-
ber of differentiating factors between distributed and non-distributed software that are repre-
sentative of those mentioned by other authors:
• distributed systems have a larger scale;
• monitoring and control are more difficult;
• heterogeneity, non-determinism, concurrency, scalability and performance, and par-
tial failure (fault tolerance) contribute complexity.
Of these, tool support for monitoring and controlling distributed tests has received consider-
able attention. Some tools support primarily functional testing [18], [19], [26], [25]; others are
specifically targeted at performance testing [14], [21]. However, these works address only the
accidental issues associated with distributed system testing, and do not address the more
fundamental questions having to do with what and how best to test a networked service.
Gosh and Mathur [20] presented an adequacy criterion targeted at covering CORBA compo-
nent interfaces. Krishnamurthy and Sivilotti [30] presented a method for specifying and test-
ing progress properties of CORBA components, while Williams and Probert applied tech-
niques of pair-wise interaction testing to component-based systems [50], [51]. By its nature,
work targeting distributed component systems is restricted to a limited level of distribution,
since much of the complexity of developing these systems is handled by the container infra-
structure.
One focus for the testing of distributed applications has been the development of testbeds
such as PlanetLabs [41] and Netbed/Emulab [49] that are appropriate for evaluating large-
scale distributed applications. However, these systems do not provide explicit support for
testing but require some additional management and reporting software to do so. Another
focus for distributed application testing is the performance evaluation of systems based on
architectural and design specifications. For example, the SoftArch/MTE system [22] enables
the automatic generation of prototype distributed systems based on high-level architectural
objectives which are deployed on a dedicated testbed.
In the testing of a complex system, unit testing is intended to verify the most basic program
units in isolation before more complicated and comprehensive tests at the integration- and
system-level are conducted. Unfortunately, some modules simply cannot be tested in com-
plete isolation since they depend heavily on other modules for a portion of their functionality.
In mock object testing [40], stub classes are created that allow the tester to control the be-
haviour of a dependency so that all expected behaviour of the low-level module can be mim-
icked.
A wide spectrum of validation techniques for concurrent systems (e.g., [10], [15], [35]) aim at
the detection of concurrency faults, in particular execution sequences and schedules. In
general, these techniques can be classified in two groups: those (e.g., ConTest tool [15]) that
sample over non-deterministic runs in the hope of exercising a reasonable percentage of the
possible synchronization events, and those (e.g., [10]) that attempt to create specific deter-
ministic runs.

18
A key aspect of B3G applications is the inherent mobility of terminals and devices on which
the Software Under Test runs. As B3G networks incorporate different wireless technologies,
software running on mobile terminals must be possibly tested in all the networks to which the
terminals could be moved and connected to, since we need to validate how the services can
interoperate in the various contexts, and also that the required QoS is provided. This may
increase exponentially the difficulty of B3G application development and testing. There does
not exist much work in the literature about how the testing for such aspect can be tackled.
One author who has addressed specifically this concern and proposed an innovative ap-
proach is Ichiro Satoh [45]. Satoh identified four approaches for testing applications running
on mobile terminals and presented a further innovative solution, called the Flying Emulator,
in which the physical mobility is emulated by means of mobile agents.

3.1.2 Web Services Testing

The resemblance of the WS domain to the Component-based (CB) domain makes it possible
to reuse some of the results and approaches proposed in testing CB systems. However, test-
ing WS is somehow more challenging as a service application results from the integration of
several services, generally controlled and owned by different organizations. Thus, services
composing an application can change at run-time without informing all the other services
integrated in the application.
In [9] the authors identify five main actors concerned with testing of services:
1. Developer: an organization that implements the service;
2. Provider: an organization that deploys the service and makes it accessible to possible
users;
3. Integrator: an organization that provides services integrating (i.e., orchestrating)
services provided by other parties;
4. Third-party: an organization that certifies the quality of a service in different contexts;
5. User: an organization that is interested in using a service.
As stated above, off-line testing is carried on by the developer, or possibly by the provider of
the service, in order to assess that the implementation of the services actually behaves as
expected. In the service oriented domain the specification of the behaviour could have been
defined by the developers themselves or even by some external bodies, as in the case of
choreographies. In the latter case the developer has to retrieve the specification of the ser-
vice s/he wants to implement from the Net. Also the specification of the services that will be
used by the service under development is usually retrieved from the Net using some kind of
discovery service. In [17] the authors show how the specification of a choreography can be
used to test a service implementation by automatically deriving test cases from a specifica-
tion, given as a Symbolic Transition System, while another notation is used in [6]. An inter-
esting approach to the off-line unit testing of orchestration description, defined using BPEL, is
described in [33]. In the paper the authors provide a testing architecture that permits to rec-
reate an environment useful for testing the BPEL process. In particular the BPEL4WS ser-
vice interacts with a set of Test Processes (TPs) simulating the behaviour of the composed
services.
Other approaches have been proposed with a focus on the use of orchestration and/or cho-
reographies in order to check the possible emergence of failures before run-time [18]
The above list of five actors concerned with testing of services does not include the directory
and discovery services. Nevertheless some test approaches in the literature suggest to aug-
ment the discovery and directory service with testing functionality. The very general idea is
that the service can be tested at the time it asks for registration. Main advantages of such an
approach is that tests are executed in a real execution environment providing more realistic
results. Moreover, following such an idea, only “high quality” certified services will be guaran-

19
teed to pass the registration. Industry-supported tools for the testing of Web services include
SOATest, Mindreef, and TestMaker.
Finally WS-I is an industry organization chartered to facilitate WS interoperability. As a main
outcome this organization released a specification, called the basic profile, composed of a list
of rules that refine and put constraints on the combined use of specifications such as WSDL,
UDDI, SOAP. At the same time a testing architecture has been developed to check the use
of elements from such specifications. In particular such architecture is composed of a WS-I
analyzer and a WS-I monitor, that applying the man-in-the-middle paradigm, intercepts all the
messages exchanged by services, and pass them to the analyzer that checks the confor-
mance to the profile. This approach is certainly relevant to assure interoperability among
different services, nevertheless it is not concerned with the functional and extra-functional
verification of a service implementation.

3.1.3 Runtime Monitoring

Monitoring is a runtime activity that collects data and transfers them to external functions for
elaboration. The definition of data to collect and the functions to apply are given separately,
possibly dynamically. The systems we survey here are first characterized in terms of what
they intend to monitor and then on the basis of their logical architectures.
Monitoring frameworks may enable either (i) dynamic Web service compositions [7] [8] [16]
described as BPEL, (ii) the verification of requirements such as behavioral properties of a
composition or of individual services [38] [43], the planning of an execution [31], or (iv) the
validating of the behaviour of a service against their predefined interaction constraints [32].
Industry-supported frameworks for runtime monitoring include Cremona [36], Colombo [13],
GlassFish [23] and Tivoli Composite Application Manager [27].
Many of these architectures have a monitoring component, e.g. a proxy, which represents a
potential bottleneck. Moreover, some of them require the modification of the workflow proc-
ess, which could be error-prone and cumbersome. An alternative architecture for integrating
monitoring, property checking, and possible reactions may be based on an aspect-oriented
programming approach [12]. Also in [48], a selection mechanism for web services is pro-
posed that allows dynamic switching between services, based on business driven require-
ments that can change over time. AOP techniques, in the form of monitoring aspects, allow
to dynamically insert measurements points in the system and to execute the monitoring logic
tailored for a desired property.

3.1.4 QoS Validation of Networked Services

The term Quality of Service (QoS) refers to the extra-functional requirements, such as la-
tency, availability, workload, etc, associated with the service specification. In recent years,
great efforts have been spent in deriving methodologies for the elicitation of extra-functional
requirements, in defining expressive annotation methods, and in the development of meth-
odologies for early performance analysis of software systems and are generally referred as
predictive techniques and empirical techniques [24], Predictive techniques is that perform-
ance cannot be retrofitted, and must thus be designed into software since the beginning [47].
On the contrary, empirical techniques are applied to running software (final implementation
or prototype). The objective is carrying on some tests and comparing the observed QoS
characteristics with the expected ones.
The testing of extra-functional properties in general requires the development of expensive
and time consuming prototypes [34], on which representative benchmarks of the system in
operation can be run. Fortunately, much progress has been done in the direction of providing
automated support for the development of test environments. Specifically, computer-
readable specifications can be used in order to describe in detail both the software under
evaluation and the expected environment. Today mechanisms acting as code-factories are

20
often available. Such tools can automatically generate a running prototype from a given spe-
cification. In our view, when these technologies can be assumed to be applied, there is a
large room for the development of empirical approaches for the evaluation of a system within
the context where it will be used.
Keller and Ludwig [29] present the Web Service Level Agreement (WSLA) framework to de-
fine and monitor SLAs, focusing on QoS properties such as performance and costs. The
monitoring component is made up of two services: the first, the Measurement Service,
measures parameters defined in the SLA, by probing client invocations or retrieving metrics
from internal resources; the second, the Condition Evaluation Service, tests the measured
values against the thresholds defined in the SLA and, in case of a violation, triggers correc-
tive management actions. An automated and distributed SLA monitoring engine is also pro-
posed in [44]. The monitor acquires data from instrumented processes and by analyzing the
execution of activities and messages passing. Collected data are then stored in a high per-
formance database and a data warehouse, to allow the verification of SLAs. Several other
European research projects (ASG [5], SeCSE [46] COMET [11] INFRAWEBS [28], MADAM
[37], MUSIC [39]) also recognize that it is certainly no longer possible to propose solutions
without adequate specification and validation of QoS features, especially in heterogeneous
and networked services contexts.

3.2 Validation in PLASTIC

PLASTIC validation aims at the following:
• To develop a testing methodology for mobile, adaptable component-based services.
• To develop methodologies, both analytical and empirical, for assessing QoS of mo-
bile, adaptable component-based services.
• To develop a test framework to be incorporated into the PLASTIC platform.
The general approach taken in PLASTIC towards these objectives is that of not committing
the validation framework to one specific test methodology, but rather to conceive it as an
open environment that can include differing methods and tools. The validation of B3G appli-
cations in PLASTIC is organized into three subsequent stages: off-line testing, on-line pre-
publication, and on-line pre-usage. Off-line testing refers to validation activities conducted
during development of the service, in a fake environment. On-line validation refers instead to
testing software deployed in its real environment; in particular in the context of services, we
have distinguished between validating the service behaviour before it is made available for
general public invocation, or after, in which case the validation is a synonymous with monitor-
ing.
In PLASTIC the QoS specifications are first-class citizens of the application model, as de-
tailed in [42] and hence the successful provision of services is indivisible from the achieve-
ment of the contractually agreed levels of QoS. Therefore, in validating service adequacy, a
key objective is to verify that the delivered QoS conforms to the specified agreement. Func-
tional testing techniques must therefore be enhanced with appropriate approaches for QoS
evaluation. This task involves two different levels of problems.
At the test planning level, we need to understand which test cases should be selected, whe-
reby each test case also includes the configuration of quality parameters. Hence also the
QoS properties to be validated need to be suitably specified, so that we can extend the deri-
vation of test cases, e.g. by use of model-based approaches, to account for extra-functional
properties too. The trend in SOA applications is that QoS agreed attributes and levels are
specified by means of appropriate annotations that augment the service specifications.
A second level of problems regards configuration and environment. Evaluating by means of
testing specified performance attributes (e.g., response time for a service), or dependability
attributes (e.g., exposed reliability), involves many technical difficulties since such qualities
depend not only on the service under test, but also on the underlying support system and on
21
the network. Therefore, the tough challenge here is how to validate the provided QoS of an
application, keeping the aspects that pertain strictly to the observed system separate from
the aspects which depend on the underlying platform. The service developer can intervene
on the former, but not on the latter, which nonetheless should be accounted for.
The challenge for off-line testing is to provide a testbed in which the underlying platform and
network can be simulated in a realistic way. In on-line testing, instead, provided that monitor-
ing probes are inserted in the right places, point-to-point attributes can be measured in real
usage. The monitoring process however consumes valuable resources. Therefore, care
should be put in devising lightweight approaches that do not heavily impact performance. In
fact, one of the problems that need to be solved is how to keep the overhead introduced by
data collection and analysis to a minimum. This can be achieved by an intelligent sampling of
the introduced probes and by dynamically adjusting the monitoring intensity based on some
suitable policy.
Context-awareness and adaptation are key aspects of PLASTIC applications, meaning that
applications can react to context changes, both anticipated and unanticipated, and adapt
themselves so as to continue to provide services with the guaranteed levels of QoS. Validat-
ing such adaptive applications off-line is clearly unaffordable, as environment parameters
and application adaptations are too complex to predict. By testing on-line instead, it is how-
ever possible to detect all potential malfunctions. This becomes particularly relevant to the
validation of QoS properties, as actual quality can be measured. However, a failure is only
detected after it manifests itself, meaning that it may only serve for future usages of the ser-
vice. A second drawback is that the monitoring infrastructure may degrade performance.
Hence appropriate policies for monitoring the dynamic adaptation of services must be de-
vised.

22
4 Service Deployment
An important milestone in the lifecycle of a service is deployment. Deployment in general
refers to the process whereby a software system is made available to be referenced by other
software. This process in turn may involve several steps. Deployment can be further subdi-
vided into three different steps: installation, admission and publication. From the point of view
of the tester, in particular, publication is the step which makes the difference on whether the
service is visible to users or not.
Deploying any complex, distributed service presents many challenges related to service con-
figuration and management. The deployment of the various components (i.e., code and re-
sources) forming a service require first the provisioning and management of the resources as
defined by the service creator, and then the actual code deployment and management of the
service execution.
• For resource provisioning and management, high-level service specifications should
be translated to low-level resource requirements. The relevant resources should then
be discovered within the targeted deployment domain. Some of these resources may
need to be reserved either for long-term utilization, or to allow for exclusive access.
• For its deployment, service code should then be downloaded to every host (with po-
tentially storage, recompilation, and installation/registration). The relevant hosting
service (i.e., application server) on the target hosts, as well as the service to execute,
should then be configured properly before the service can be executed.
• Once started, the reserved resources should be monitored to guarantee the correct
execution of the service. The service itself should also be managed through monitor-
ing and adaptation operations.

4.1 Related Work

While the OSGi platform (Section 4.1.1) is the most prominent service deployment technol-
ogy, Web services deployment (Section 4.1.2) has also been studied, primarily for wired,
infrastructure-based network such as Grids [52][53] or overlay networks [54].

4.1.1 Bundle deployment in OSGi

The Open Services Gateway Initiative (OSGi) defines an open specification for the coordi-
nated development, deployment and management of services in networked environments.
More specifically, the OSGI specification addresses lifecycle management, inter-service de-
pendencies, data management, device management, client access, resource management,
and security. While the OSGi framework was initially targeted at home environments (e.g., in
a set-top-box or home gateway), it is being extended to other domains (mobile, automotive).
OSCAR4, the IBM Service Management Framework5 and Siemens VDO6 are different im-
plementations of the OSGi™ Service Platform specification.
OSGi's central unit for services is called a bundle. A bundle corresponds to a delivery and
deployment unit (JAR file) that contains the code, resources (i.e., images, libraries, etc.), and
a manifest file (bundle description). In particular, the manifest of the bundle contains informa-
tion about the dependencies of the bundle, as well as a description of the libraries and ser-
vices that this bundle may provide to others.

4
http://oscar.objectweb.org
5
http://www.bm.com/software/wireless/wsdd
6
http://siemensvdo.com
23
OSGi thus provides mechanisms to support the deployment of a bundle (installation, re-
moval, update, (de-) activation), while the bundle is itself responsible for the dynamic/run-
time management of services dependences. During execution, services exhibit dynamic
availability as they are introduced or removed from the execution environment as a conse-
quence of bundle deployment activities. Dynamic availability of services requires an applica-
tion to be capable of dynamic assembly (i.e., publication of the bundle's services, connection
between bundles and requested services, idle state while waiting for unavailable services)
and dynamic adaptation (monitoring of existing services through notifications by the service
registry, application reconfiguration involving new bindings or the release of services).
Two types of dependencies are managed in OSGi:
• Deployment dependencies: classes within a bundle may require some code that is
not contained in the bundle. In such case, the bundle must declare explicitly (in the
manifest file) that this code should be imported from another bundle. Bundles can al-
so explicitly export certain Java packages in order to satisfy import requirements from
other bundles. A bundle installed in the platform can be activated once its deployment
dependencies have been satisfied.
• Service dependencies: service management at run time includes service publica-
tion, discovery, binding and adaptation with respect to changes due to dynamic avail-
ability (arrival or departure) of services that are being used by a bundle during execu-
tion. Service dependency management is key to building applications, as they are not
guaranteed, or managed, by the OSGi framework. Service dependencies can be de-
clared in the manifest file.
OSGi announced a Mobile Specification as part of the Release 4 of the OSGi Service Plat-
form Specification that aims at supporting the management of the platform and associated
services for mobile devices (Personal Java 1.2 and Java CDC 1.0). However, OSGi on mo-
bile devices cannot be fully implemented on top of the Java CLDC (which is the environment
used in mobile handsets) as it lacks support for the reflection API and for user-defined class
loaders. Indeed, CLDC profiles only support the execution of pre-verified code components
(i.e., MIDlets) that have already their own life cycle management. These restrictions are re-
quired in cellular environments for security reasons.

4.1.2 SmartFrog and CDDLM

SmartFrog7 is a framework to configure and automatically activate complex, distributed appli-
cations in a flexible and extensible manner. The problems addressed by SmartFrog, which
are common to service deployment frameworks, include
• The lack of a standard method to capture service configurations, with multiple defini-
tions (semantic) for values, various mechanisms to access information, and different
notations (XML, ini files, SQL, ...),
• The lack of a validation method for the configuration as a whole due to various lifecy-
cles for different type of applications, and the lack of facility to compose systems from
sub-systems,
• The lack of separation of concerns, with code related to application functionality being
mixed together with configuration/monitoring/management code, and rigid location
and binding preventing adaptation to dynamic contexts,
• The lack of discovery, monitoring, and automation services.
To address these issues, SmartFrog describes services as collections of components (e.g.,
software, data: storage, cpu) and provides a framework to activate services by realizing ser-

7
http://www.smartfrog.org/
24
vice descriptions. Smartforg components collaborate to achieve some goal for which they
must be appropriately organized. The framework must therefore be able to correctly initialize
components (i.e., the appropriate attributes and required components must be properly de-
fined) and to enable the discovery and exchange of state information between components.
The framework elements are:
• A language that allows rich system descriptions. SmartFrog uses attribute-value pairs
in a structured containment hierarchy. Properties are declarative and support in-
stance-inheritance to allow templates to be extended. Flexible linking between attrib-
utes and values is supported and value resolution can be delayed to deployment
time. Finally, descriptions can be a composition of smaller descriptions.
• An engine distributed and executed on all the nodes that automates application de-
ployment, activation, management and shutdown. Each engine that receives a
SmartFrog description loads the required components with the appropriate configura-
tion parameters. The engine also orchestrates the whole system by managing com-
ponents through their complete lifecycles.
• A component model with a simple lifecycle that allows all components to be controlled
by the engine. The engine is composed of a core set of components (lifecycle), with
additional components providing discovery, reliability building blocks, JMX support, …
Much of the experience on description, deployment and management gained with the design
and development of the SmartFrog platform was reused in the design of CDDLM by the
CDDLM-WG which is part of the Global Grid Forum8 (GGF) Scheduling and Resource Man-
agement Project This WG addresses how to describe configuration of services; deploy them
on the Grid; and manage their deployment lifecycle (instantiate, initiate, start, stop). The
CDDLM WG provides specifications for (i) the CDDLM Configuration Description Language
(CDL) which is an XML-based language for declarative description of system configuration,
(ii) the CDDLM Component Model that outlines the requirements for creating a deployment
object responsible for the lifecycle of a deployed resource. Each deployment object is de-
fined using the CDL language and mapped to its implementation, and (iii) the deployment
API is the WSRF-based SOAP API for deploying applications to one or more target com-
puters.

4.2 Context-aware service deployment in MIDAS

The goal of the IST MIDAS is to make it feasible to develop and to rapidly deploy services on
heterogeneous network infrastructures, possibly ad-hoc networks, which involve a large
number of users. In order to achieve the goal, the MIDAS middleware consists of the follow-
ing components (see Figure 6):
• Connectivity Component (CRT): the main responsibility of the Connectivity Compo-
nent are initializing and maintaining connections between individual nodes. Different
types of communications technologies are combined in order to maintain overall net-
work connectivity.
• Data Space Component (MDS): This component implements the MIDAS Data Space
(MDS) concept. Its purpose is to provide applications running on multiple nodes, at
different locations, with a mechanism to share information by inserting data in and re-
trieving data from a virtual shared data space. To application programmers, the
shared data space looks like a standard relational database.

8
http://www.ggf.org/
25
 • Context Engine Component (CTX): This component implements the MIDAS Context
Space. The purpose of the Context Engine Component is to provide middleware sup-
port for context information.
• Common Functions (CFN): This component is essentially an “open” component: the
idea is that it will provide functionality that is identified as being useful for applications
implementing mobile services – but is not specific to any one mobile service, and is
not covered in any of the other middleware components. The examples of CFN can
be device management, connectivity management, etc.
• Deployment Component (DPL): It is necessary that the appropriate software is in-
stalled and configured on the appropriate devices. MIDAS provides an overall model
for this, as well as support in the middleware to help use network connections for ser-
vice deployment. It is the deployment component which provides such support.

Figure 6: MIDAS middleware components

Provided that the MIDAS middleware is installed the context aware application deployment
can be split into different phases including device detection, service discovery, download,
installation, execution and discard. Components of the MIDAS middleware perform these
different tasks, and incorporate each other in such a way that yields maximum performance
to the middleware.
The deployment component (DPL) will use both the Data Space component (MDS) and the
Context Space component (CTX) to achieve its task. After the system administrator finishes
preparing an application bundle, the bundle will be serialized into binary stream and stored in
the application repository managed by MDS. As MDS has a distributed nature, the availability
of this application will be propagated to every user node. As the part of installation process,
the administrator will define a condition for the application to be launched when the condition
is fulfilled. DPL on the user node will register the condition defined by the administrator to the
CTX. When context condition event occurs, DPL will retrieve the bundle from repository and
launch the application.

4.3 Service deployment in OPUCE

As stated earlier, the goal of the OPUCE platform is to put the end user in the centre of the
whole lifecycle of a service, to let them become at the same time the creator, the manager
and the consumer of services. User created services impose new requirements to the tele-
com platforms, because they must be able to cope with a huge set of dynamically generated
services, each one orchestrating a subset of telecom-oriented Base Services. Thus, effective
lifecycle management has to take place:

26
• To allow users to decide when and how long their services must be available, i.e. the
lifecycle schedule.
• To be able to automatically perform the provisioning of Base Services and platform ele-
ments, and to register and publish new services in order to be available to end users.
• To avoid interference of services that act on the same set of control flow (e.g. SIP mes-
sages) or detect such feature interaction in advance to define rules to cope with it.
• To provide scalable execution architectures in a heterogeneous environment allowing the
orchestration of enablers residing on different platforms. This scalability should also avoid
execution hot spots in case specific services become successful.
In OPUCE, the Service Lifecycle Manager allows service creators to take control of some
aspects of the deployment [55]. As such, there is no need for any human intervention from
the operator either when triggering the service deployment process or during the deployment
itself as the service description contains all data necessary to deploy the service.
As part of the deployment process, service provisioning in OPUCE is carried out automati-
cally using the service description to specify the provisioning details for each service. Three
provisioning tasks have been identified, each one impacting different elements of the plat-
form.
o Component Provisioning, which considers the provisioning tasks to be done in those
Base Services that the service creator has combined, such as reservation of re-
sources or configuration of permissions.
o Platform Provisioning, which considers the provisioning tasks to be carried out in the
OPUCE platform components such as updating service repository or, in the future,
the billing systems.
o User Provisioning, which considers the provisioning tasks to be performed on the us-
er side at subscription time, such as installing a dedicated application in the user’s
mobile device or accepting a certain SLA before using the service.
Figure 7 depicts the service description structure for this facet and the relationship of each
type of provisioning with the corresponding OPUCE architecture module.

Figure 7: Service provisioning and deployment in OPUCE

27
5 Service Discovery
B3G networking aims to enable users to access information and computational resources
anytime and anywhere, where mobile users carry around tiny personal devices that integrate
seamlessly in the existing infrastructure in both managed and ad hoc modes. Integrating the
available hardware and software resources at any given time and place is highly complex, as
such environment is highly dynamic and open. Dynamic service discovery is thus especially
critical due to the fact that B3G services and potential software clients (assuming the role of
service requester) are designed, developed and deployed independently.
Over the years, many academic and industry-supported Service Discovery Protocols (SDPs)
have been proposed, which are described in Section 5.1. Although key features of SDPs are
now well understood and go along with well-proven protocol implementations, a number of
challenging issues remain, as outlined in Section 5.2. We then briefly describe in Section 5.3
some solutions proposed by IST projects to address some of these issues.

5.1 Related Work

Discovery protocols enable components of a network to discover each other, express oppor-
tunities for collaboration, and compose themselves into larger collections that cooperate to
meet an application need. SDPs can be classified [66] [77] as:
• Pull-based protocols where clients send requests directly to service providers or to a
third-party repository in order to get a list of services compatible with the request at-
tributes.
The pull-based approach can be further divided into two sub-categories: centralized
discovery protocols where one or a few repositories store the descriptions of the
available services in the network and distributed discovery protocols where clients
rely on the broadcast capability of the underlying network to send their discovery re-
quests to service providers.
• Push-based protocols where service providers provide their service descriptions to all
clients that locally maintain a list of networked services.
In centralized pull-based discovery protocols, one or a few repositories store the descriptions
of the available services in the network. Registrations and requests may be either sent to one
or all repositories. In the former case, and if multiple repositories exist, they cooperate in or-
der to distribute the service registrations or to route the client requests to the relevant reposi-
tory. Repositories are kept up to date by requiring explicit sign-off or by removing entries pe-
riodically. CORBA's Trading Object Service and Naming Service, UDDI and Jini implement
the centralized approach. In many of these protocols, the location or the repository is as-
sumed to be well-known (e.g., UDDI), while in some other protocols, clients and service pro-
viders broadcast a specific request on the network to localize the repository (e.g., Jini). Other
methods like hash-based location exist where a hash function is used to transform a given
service description into a numerical value. This value that can be computed independently by
the provider and the requester is then associated with the address of a device in a network.
This device acts as a middleman, storing the real location of the service and answering the
clients' requests. Examples of systems implementing hash-based discovery protocols include
Freenet [59], Tapestry [70], or Chord [68]. The main drawbacks of the hash-based approach
originate from the hashing function. As it needs to map values randomly all across the net-
work, two services descriptions semantically close may not be stored on physically close
devices.
In an Internet setting, the centralized approach raises scalability and reliability issues. Rely-
ing on cooperative repositories to replicate the information is a common technique to address
these issues. In the case of Mobile Ad Hoc Networks (MANETs), the main drawbacks of the

28
centralized approach is that, as one device has to host the repository, service providers and
clients need to dynamically discover its location and have to trust it. Furthermore, network
partitioning/merging and device mobility may force costly updates.
In distributed pull-based discovery protocols, service providers store locally their descrip-
tions, which are therefore not distributed to the other nodes on the network. Clients send
their requests using the broadcast/forward functionality provided by the network, and in fact
flood the network to reach potential service providers. The flooding algorithm will however try
to limit/prevent the duplication of queries. When receiving such request, service providers will
compare the request with the service descriptions stored locally to decide if they can satisfy
the request. Typical representatives of this approach are the Simple Service Discovery Pro-
tocol (SSDP) [69], and JXTA-Search [62].
The main drawbacks of the distributed approach are the network-flooding problem [67], the
required support of multicast/broadcast communication by the underlying network, and the
limited range of the multicast/broadcast messages.
In the push-based approach, each device maintains a local repository of services found on
the network. A service provider pushes the service advertisements to the network, typically
by periodic unicast or multicast. As a result, each device’s local registry will gradually collect
service advertisements of service providers. When a client submits a service query to the
local registry, the local registry looks up the service advertisement entries for both the local
and non-local services in order to find the qualified service.
The main issues with the push-based model are related to the reachability of the services
(similarly to the distributed pull-based discovery protocols), and the setting of the broadcast
interval. If set too short, the network will be flooded with unnecessary advertisements. If set
too long, clients will not get an accurate listing of the available services.
Leading SDPs use a pull-based approach (Jini, SSDP), often supporting both the centralized
and distributed modes of interaction (SLP, WS-Discovery).

5.2 New challenges for service discovery

Although several protocols are now well-established for simple service discovery in specific
environments, a number of challenges remain for providing a comprehensive service discov-
ery solution for B3G environments due to (i) hardware and software heterogeneity, (ii) inher-
ent mobility of clients and service providers, (iii) dynamic composition of distributed services,
and (iv) the need of taking into account the context and profile of users.

5.2.1 Multi-protocols SD
Middleware heterogeneity raises interoperability issues between the different SDPs (e.g.,
SLP, SSDP, UDDI) active in the environment. Existing SDPs do not directly interoperate with
each other as they employ incompatible formats and protocols for service descriptions or
discovery requests, and also use incompatible data types or communication models. In any
case, the diverse environment constraints and the de-facto standard status of some of the
existing protocols make it unlikely for a new and unique SDP to emerge. Several projects
have thus investigated interoperability solutions [78] [61] [64], as requiring clients and service
providers to support multiple SDPs is not realistic. SDP interoperability is typically achieved
using intermediate representations of service discovery paradigms (e.g., service description,
discovery request) [79] instead of direct mappings [64], as the latter does not scale well with
the number of supported protocols. Furthermore, the interoperability layer may be located
close to the network layer [79], and efficiently and transparently translate network messages
between protocols, or may provide an explicit interface [74] to clients or services so as to
extend existing protocols with advanced features such as context management.

29
5.2.2 Context-aware SD
A major trend to handle the richness and heterogeneity of B3G environments is to rely on
context information for inferring mobile users’ needs and autonomously locate the most ap-
propriate services [65]. Context-aware SDPs aims to provide users with the best networked
services based on their preferences, needs and runtime conditions [60][63][80][58], some-
times focusing on location-awareness [72] or QoS [81]. The evaluation of context properties
may be achieved through the evaluation of context rules [82] or the maximization of a utility
function [81], but commonly relies on strict syntactic matching between the information pro-
vided by the client and by the service. Context-aware SDPs therefore assume that all clients
and service providers use the same terminology to identify the same contextual information.
Such assumption is not realistic in B3G environments as, there, networked components are
designed, developed and deployed independently.

5.2.3 Semantic SD
The matching of service requests and service advertisements is classically based on assess-
ing the syntactic conformance of functional and non-functional properties. However, an
agreement on a common syntactic standard is hardly achievable in open environments.
Thus, higher-level abstractions, independent of the low-level syntactic realizations specific to
the technologies in use, should be employed for denoting service and context semantics [73].
A number of approaches for semantic service specification [83] have been proposed, and in
particular for semantic Web services such as OWL-S or SAWSDL. The SAWSDL annotates
Web services with semantics, by attaching references to concepts from ontologies (e.g.,
OWL) to WSDL input, output and fault messages, as well as to operations. METEOR-S [84]
uses DAML+OIL ontologies (precursor to OWL) to add semantics to WSDL and UDDI so as
to annotate the communication aspects between services. Other efforts [85][86][87] started
to take care of some of the ambiguity in service descriptions arising from the openness of
B3G environments. EASY [88] provides efficient semantic service discovery, a key require-
ment for the resource-limited devices found in pervasive environments, by encoding ontology
concepts off-line and adequately classifying service descriptions in the repository based on
these encoded concepts.

5.2.4 Multi-networks SD
Network heterogeneity leads to many independent networks being available to users at a
location, which can be loosely interconnected with today’s multi-radio mobile devices. Inno-
vative solutions are then required for the efficient inter-network dissemination, filtering and
selection of discovery requests and announcements [74]. Several projects have investigated
peering (gateways) or application-level (P2P) routing combined with intelligent filtering to
provide efficient and scalable multi-networks service discovery. The mSLP [71] protocol im-
proves SLP efficiency and scalability by introducing mesh enhancements for the peering of
registries as well as preference filters. INS/Twine [57] proposes a scalable P2P architecture
where resolvers (i.e., directory services) collaborate as peers to distribute resource informa-
tion and to resolve queries. GloServ [56] is an ontology-based global service discovery archi-
tecture that operates in wide area as well as local area networks using a hybrid hierarchical
and peer-to-peer architecture. MUSDAC [74] dynamically composes nearby networks
through specific components providing application-level routing on multi-radio devices, which
enables the dissemination of discovery requests in the environment. The key issue for multi-
networks discovery is to accurately report the dynamic changes in the network without jeop-
ardizing processing and network resources due to the potentially considerable amount of
information to exchange and process.

30
5.2.5 Security and privacy
Securing the exchange of service descriptions and discovery requests is crucial in open envi-
ronments, especially when such information is laced with service- or user-related contextual
information [75], Many mechanisms have been proposed to secure the disclosure of service
information, focusing either on encryption and access rights [89] or the need to balance dis-
closure and privacy [75]. Indeed, service discovery is critical to the privacy of clients and ser-
vice providers, in particular when service descriptions or requests are laced with context or
personal information that may be correlated to gain detail knowledge of a person.

5.2.6 Mobility
Client and service mobility has rarely been investigated in the context of service discovery,
as supporting mobility (nomadic or seamless) is primarily seen as an issue for service access
(i.e., maintaining connectivity). Mobility pattern has however been investigated as a way to
favors interaction between nodes that will remain in network reach of each other for the dura-
tion of the session [76].

5.3 Service Discovery in PLASTIC

PLASTIC SD solution builds upon that of the MUSDAC [74] middleware that introduced con-
text-aware multi-protocol, multi-network service discovery. However, the PLASTIC SD solu-
tion relies on a generic B3G overlay network for disseminating discovery requests. PLASTIC
SD solution additionally deals with seamless mobility and scalability issues, and introduces
enhanced service description and matching.
In a nutshell, a (logically) centralized manager, the Discovery Manager, coordinates service
discovery within a network. This manager interacts with local PLASTIC applications to regis-
ter and locate services using a proprietary discovery protocol derived from the WS-Discovery
and UDDI SD protocols. Additionally, legacy clients and services are supported through
SDP-specific plugins, with legacy discovery requests and service descriptions being trans-
lated to the PLASTIC–specific format for interoperability. The discovery manager relies on a
B3G SOAP overlay to communicate with other nearby managers and disseminate discovery
requests. Clients use the same B3G SOAP overlay to interact with services located in distant
networks.
PLASTIC introduces an enriched description format for services, which is to be used by both
clients (for service location) and service providers (for service advertisement). This hierarchi-
cal service description format actually combines a number of distinct documents specifying
different facets of the service. This format specifically decomposes into (i) a Functional profile
and grounding similar to WSDL, (ii) a BPEL-based process model that specify the service’s
conversations, (iii) the B3G grounding of host, that identifies the networks and IP address at
which the service’s host is network-reachable (i.e., for multi-radio devices), (iv) a description
of the mobility behavior of the service, focused on the physical mobility of hosts, (v) a Con-
text model, and (vi) a QoS profile more specifically building upon Service Level Specification.
PLASTIC service discovery is a central element in the management of (clients and services)
mobility. Indeed, it serves both relocating a given service, and locating a valid substitute for a
service. In PLASTIC, mobility (e.g., following a vertical or horizontal handover) is managed
by the middleware based on application profiles.

31
5.4 Discovering, publishing and sharing services in
OPUCE
The OPUCE platform contains a Service Advertiser (SA) subsystem [90][91] that enables
notification of services to users via multiple channels. It also allows sharing of services be-
tween various levels of system participants – from operators to end-users.
Whenever a service is created, it becomes necessary to advertise it to users of the platform
in order to let them know about the newly created item. The SA offers automatic and intelli-
gent correlation of user interests and service description to determine the individuals poten-
tially interested in that kind of service, resulting in a fine-targeted system.
When sharing, a user is able to specifically notify other users (typically his/her friends) about
interesting services.
The result of both processes is a notification, i.e. a message which is sent to a set of target
users. Context-awareness techniques are employed for low-intrusive sending. Each user is
able to select a set of preferences specifying how to receive these messages. For example,
a user can select to receive notifications via instant messaging if his/her presence status is
online, via SMS if presence status is offline and location is at home, and via email otherwise.
In any case, anti-spam tools inside the Service Advertiser module avoid message flooding.
The user is able to select the entities he/she trusts or distrusts in order to avoid or block, re-
spectively, notifications from their side.
In order to facilitate the advertising process the composer specifies at creation time a set of
defining keywords for the service. Additionally, every OPUCE user aware of the service can
access the notification capabilities of the SA, selecting further target users from their contact
list to notify them about it, enabling viral marketing inside the community.

32
6 Dynamic Service Composition
In this section, we concentrate on the support for composition in the B3G networking envi-
ronment and in particular WS composition. We also address the issue of reconfigurable dy-
namic service composition so as to overcome failures resulting from the occurrence of dis-
connection with services with which connectivity cannot be restored despite the rich B3G
networking environment.

6.1 Related Work

Service composition allows for the creation of applications (possibly exposed as services) out
of networked services. Such a facility is beneficial towards enabling distributed applications
across organizations, and much effort has been done in this area both in academia and in
industry. This has produced a number of languages, methods, tools and runtime environ-
ments towards effectively enabling the development of composite services.
Basically, when developing a composite service, developers should answer several ques-
tions: Which service can be integrated? What is the interaction protocol that should be im-
plemented? How to express the control flow of the composite service? Three complementary
aspects of composability in the Web services architecture have been identified for giving an-
swers to the above questions:
• Conversations address the first issue by defining the flow of interactions that an
individual Web service supports.
• Choreography gives an answer to the second question by specifying the interac-
tion protocol for a specific business process involving several Web services.
• Orchestration addresses the third issue by providing means for specifying the
composition process.

6.1.1 Web service conversation

In WS-A, the WSDL document associated with a Web service gives the messaging pattern of
each operation of the service. However, to correctly use a Web service and get the expected
result, a service consumer needs to know, in addition, the order in which it should call the
operations offered by the Web service. This is specifically provided by the service conversa-
tions, where a conversation specifies the XML documents being exchanged, and the allowed
sequencing of these document exchanges. Conversations enable thus defining a higher level
of interaction protocol by expressing ordering dependencies between operations, in a way
similar to path expressions introduced for the synchronization of concurrent processes [96].
A conversation is considered as an extension of the abstract interface of a Web service,
complementing its WSDL definition.
Various conversation languages for Web services have been introduced in the literature,
which may be coupled or not with the specification of Web services composition. Solutions
may be distinguished according to whether the conversation is expressed from the point of
view of an external observer, or if it is given from the point of view of an individual service.
The first approach enables in particular to link conversations supported by different Web ser-
vices for expressing multi-party conversations, as in the language introduced in CS-WS [97].
However, this approach limits the expressiveness of a service interface by introducing a tight
coupling between conversations of different Web services. The second approach, which is
adopted by most of the proposed conversation languages, enables the definition of the con-
versation independently of any specific interaction protocol, complementing directly the
WSDL definition. Languages proposed for describing conversations of Web services from an
individual Web service perspective include DML [98], WSCL [99], the framework introduced

33
in [100], the service model description of OWL-S [101], the conversation specification pre-
sented in [102], WSCI [103] and the service specification language introduced in [104]. Con-
versations of Web services that are expressed in the above languages are generally repre-
sented using state transition diagrams. In particular, WSCL uses the UML activity diagram for
modeling conversations where activities represent the operations that may be called, and
transitions the execution of operations.
In general, providing machine-readable specifications of conversations in the service inter-
face is beneficial from the standpoint of dependability for at least two reasons. First, conver-
sations may be used to check the correctness of interactions engaged by a service con-
sumer, prior or during execution. A second benefit of describing conversations in service
interfaces is that they may be used to automate the implementation of service compositions
[105], e.g., by providing tools for the automated generation of correct code skeletons.

6.1.2 Web service choreography

A choreography describes the message exchange rules among multiple interacting parties.
Concretely, it is achieved by linking sent and received messages of different parties and
specifying a control flow among related message exchanges. While conversations are used
to describe all supported interactions of a Web service, a choreography gives the interaction
protocol for a specific composite task (workflow) involving several Web services and service
requesters. A choreography can be instantiated by assigning concrete Web services to the
different roles defined. Existing languages for specifying choreographies include WS-CDL
from the W3C choreography working group [106], which specifies interaction protocols by
defining a global control flow among interacting parties using explicit control structures. The
model presented in [107] defines choreographies (referred to as conversations by the au-
thors) using Mealy machines [108]. In addition, the conversation languages, CS-WS [97] and
WSCI [103] introduced in the previous section, enable defining choreographies by linking
conversations of different Web services.

6.1.3 Web service orchestration

The term orchestration refers to a (logically centralized) executable workflow process, which
interacts with external Web services. Orchestration can thus be used to specify a composite
Web service. It specifies the control flow of the composition, from the point of view of the
composite service. In particular, it can be used to implement different roles of a choreogra-
phy, contrary to choreography that describes the interactions of all parties involved in the
composition. Orchestration also distinguishes from conversation and choreography by the
fact that it specifies the internal mechanisms of a Web service, and thus need not to be pub-
licly available or shared between interacting parties. However, the specification can be used
to derive the conversations supported by the composite Web service and to verify its com-
patibility with a choreography.
Several models for specifying orchestrations, based on existing solutions for the coordination
of distributed activities, have been proposed. State-charts are used to specify composite
Web services in the Self-Serv environment, where composed services are coordinated by
peer-to-peer interactions [109][110][111]. Another approach is to model the composition
based on Petri nets [113]. BPEL [112] is the most popular orchestration language and for-
malization of BPEL processes has indeed been the subject of many publications
[114][115][116]. Automated composition of Web services is also considered (e.g., [110]), and
is further attractive for B3G environments as discussed in the next section.

34
6.2 New Challenges for Service composition in B3G envi-
ronments
For mobile service platforms, the dynamic realization of user tasks may conveniently trans-
late into the dynamic composition of services, which however raises a number of issues such
as: overcoming the syntactic heterogeneity of service descriptions during the dynamic com-
position process, and reconfiguring composite services to face the mobility of nodes.

6.2.1 Dynamic service composition

Dynamic realization of user tasks out of networked resources is one of the major challenges
in pervasive computing environments [117]. A user task is a software application available on
the user's device, which is abstractly described in terms of the integration/composition of
functionalities to be found in the networked environment. A number of research efforts have
been conducted such as Aura [118] and Gaia [119] that provide solutions to the dynamic
realization of user tasks in pervasive computing environments. However, both approaches
assume framework-dependent XML-based descriptions for services and tasks. In other
words, both approaches assume that services and tasks of the pervasive computing envi-
ronment are aware of the semantic underlying the XML descriptions employed. Thus, these
solutions commonly assume that the networked services have been developed to integrate in
terms of service interfaces and perform syntactic matching of these interfaces, which restricts
the ability to fully exploit the diversity of the heterogeneous B3G environment.
Ontology-based semantic Web technologies, and in particular semantic Web services, allow
supporting semantic descriptions for services and tasks, and to perform a more thorough
matching. Semantic Web services are based on the definition of an ontology for service de-
scription together with that of domain-specific ontologies, so that the behavior of services can
be unambiguously advertised over the network. OWL-S, which is one such Web service on-
tology, describes what a service does (in the service profile) and how to interact with the ser-
vice (in the process model), which in turns provide the basis of Web services composition.
Furthermore, OWL-S descriptions are based on ontologies enabling common and non-
ambiguous understanding of service behavior, which is necessary to leverage the openness
and heterogeneity of B3G environments.
In Task Computing [120], services are described as semantic Web services using OWL-S.
Each user carries a composition tool that discovers on the fly available services in the user's
vicinity and suggests to the user all the possible compositions of these services based on
their semantic inputs/outputs. While this approach validates the relevance of semantic Web
technologies in pervasive computing environments, it presents some drawbacks. For in-
stance, suggesting to the user all the possible compositions of networked services requires
that the user selects the right composition among the suggested ones, which can be incon-
venient for mobile users in pervasive computing environments. Support for the automated
and transparent dynamic composition of networked services has given rise to various solu-
tions. In particular, conversation-based service composition has led to a number of ap-
proaches in recent years, e.g., [121][122][123][105]. Solutions based on semantic Web ser-
vices technology are further quite well suited to open networked environments like the ones
enabled by B3G networks.

6.2.2 Reconfigurable service composition

In B3G environments, an orchestration may loose connectivity with some component ser-
vice(s) due to e.g., mobility of service hosts. Reconfigurable service composition aims to
guarantee the continuity of composite services despite connectivity loss, including maintain-
ing consistency of composite and component/composed services. Relevant solutions to con-
nectivity loss were introduced in the nomadic computing domain, e.g., [124], but generally
assume that a service consumer is connected to some given remote server providing re-
35
quired services with intermittent connectivity. It is thus assumed that the consumer will even-
tually reconnect to the same server or some replica of the server. The objective is then to
enable users to use their mobile devices even during periods of low or non-connectivity. In
B3G however, service instances making up the environment do not have any a priori knowl-
edge of each other before their dynamic composition. Bindings between services are ad hoc
and temporary. Thus, after a disconnection, a service consumer is unlikely to reconnect to
the same service provider or even a replica of it. It will rather connect to another provider.
Nevertheless, disconnection is a common event in nomadic computing systems, which
makes the experience gained from the nomadic system solutions useful.
Fault tolerance techniques also propose relevant solutions to deal with process failure at
runtime. These techniques are essentially based on checkpointing and rollback. Checkpoint-
ing is the operation of periodically saving intermediate states of a process on a stable stor-
age while rollback recovery shifts the distributed system from an inconsistent state back to a
consistent one. In general, fault tolerance techniques are not specific to mobile or to station-
ary systems. They are based on monitoring interactions among constituent services to re-
store distributed system consistency despite constituent failure. However, as for nomadic
solutions, fault tolerance techniques are not applicable as is to pervasive computing systems,
providing uncoordinated checkpointing protocols that respects service autonomy.

6.3 Service broker architecture in SPICE

As detailed in Section 2.3, SPICE defined a hierarchical, abstract component model with the
explicit goal of supporting automatic composition. Indeed, an important requirement for
SPICE is that component networks must adapt to conditions of the environment. Thus, the
SPICE platform provides context-aware, dynamic service composition by adapting and com-
bining components within the Service Composition Environment (SCE). The broker is the
functional unit in SPICE that intercepts the incoming request and creates and adapts the
service component network for the request. This broker can be thought of as a gatekeeper
for composable services, which dynamically calculates the bindings for the interaction upon
receiving request such services. When connecting components, the broker considers:
• Functional and semantic annotations exposed by components,
• Security requirements, particularly those that describe, how end user services are
exposed toward end users,
• Context information obtained from the Knowledge Management Framework (KMF).
• Contract information exposed by components that control which components can be
connected.
• Service Level Agreements (SLA) that may be considered as a special kind of con-
straint. SLA constraints on services may change dynamically depending on the re-
sources the services have.
The broker issues semantic search requests toward the Discovery Facility (DF), which are
augmented with the relevant context information, and checks with the Subscription Manager
(SM) that the user must have access to the selected services. In the SPICE platform, meta-
data is envisaged not only to support interoperability at the interface level, but also to provide
a semantic foundation that allows for system entities to be able to reason over the service
capabilities that a single SPICE component provides. Semantic metadata available to the
broker includes: service creator information, semantically annotated functional descriptions,
and non-functional properties (Policies, Quality Ratings, etc). The semantic metadata of a
SPICE component can take several forms. OWL-S Profile provides a semantic description,
which is separated from the invocation interface description, WSDL. Alternatively, SAWSDL
[95] embeds the semantic information into the invocation interface.

36
As there are many ways to compose services, the broker must support multiple composition
algorithms [94]. Indeed, the composition method field is still quite diverse and comes with a
number of trade-offs with regards to consistency of the composed service network, the speed
of the service network calculation and the flexibility or “intelligence” of the service network
calculation when the system is exposed to conditions unforeseen at design time. Each com-
position mechanism supported by the broker is expected to use the same component model.
The usage of the elements of the component model and the way of describing the composi-
tion, however, may be very different depending on the composition mechanism. Four com-
position methods have already been specified for the broker. These are the single dynamic
component composition (when the selection of a single component depends on a KMF con-
text element), the static BPEL (support for legacy BPEL scripts) OWL-S composition and the
semantically annotated BPEL composition. The composite service refers to the composition
method indirectly, e.g. if the composite service uses semantically annotated BPEL then the
broker will invoke the composition method for semantically annotated BPEL. The composi-
tion methods are modeled as services and the broker maintains association tables between
the composition mechanism and the composition service
The output of the broker is a service component network that can be executed directly. The
service component network contains the exact services (endpoints, etc.) and their connec-
tions. The service platform specification supports two execution methods.
• Execution by a dedicated execution engine. In this case the execution engine re-
ceives the service component network and acts as a central distribution point that
sends requests to components and receives responses. This is also called star-based
execution pattern [93].
• Direct component-component communication without execution engines. In this case
the components are connected to each other and there is no router among them. This
is also called mesh-based execution pattern [93].
While the dedicated execution engine option’s enables off-the-self software components like
BPEL execution engines to be reused, the direct component-component implementation op-
tion offers more stability, performance and security. The favoured implementation option is
the direct component-component one.
The broker composes service component network based on the composition descriptor. Two
sorts of composed service networks exist:
• Statically composed service component networks that remain the same independ-
ently of conditions in the environment. These networks can be composed once, for
every user as their composition is not related to any conditions in the environment,
including the user that accesses the composite service.
• Dynamically composed service component networks are composed based on envi-
ronmental conditions that include context variables associated to the user, like user
location, user preferences, etc. Therefore these service component networks belong
to users and a separate version of the service network is calculated and temporarily
cached for each user.
Finally, the lifetime of the service component network within SPICE may be per-request, per-
session, or per-application.

6.4 The Service Composition Model in OPUCE

The OPUCE project defines a Service Composition Model that seamlessly integrates IT and
Telco resources. The main feature of this model is the event-driven approach which defines
the execution of complex, high level services in a way that the end-user feels natural: users
are exposed to a user-friendly way of dealing with resources (e.g. “place a call”, “line is
busy”, “drop the call”, “read RSS feed” etc.). To support such approach, the OPUCE Service
37
Composition Model requires that the interaction with the resources happens in terms of events
and actions, and the fundamental composition rules for building complex services are event-
triggered patterns. The main advantage of this paradigm is that the description of the service
logic is simple and straightforward, because it is close to natural language [124].
The resource available to the user to create OPUCE Services is a complete set of building
blocks called Base Services. Base Services are functional units available on a service plat-
form, wrapping a single capability, belonging to either Telco world or the IT world
Each Base Service is identified by a unique name inside the platform, and is specified by
three sets:
• Properties: variables, each property consists of a name (unique inside the base service)
and a value; each base service instance (BSI) will manage its own properties, keeping
track of their values and updating them. The values of the properties of a BSI represent
its state.
• Actions: operations that a BSI can perform when requested. The behavior of an action
can depend on the value of the properties associated with the instance. After the invoca-
tion of an action, the Base Service Instance can fire one or more events.
• Events: events are the mean a BSI can use to proactively communicate that something
has happened (a change of state, the arrival of a message, etc.). Each event is charac-
terized by an event name, which is unique inside the base service. A Base Service In-
stance can fire events after one of its actions has been invoked. The events fired by a
Base Service Instance can trigger the invocation of an action on a (possibly different)
Base Service Instance.
The OPUCE platform provides a graphical Service Creation Environment (SCE) to allow end-
users to create service compositions. An OPUCE Service Composition is defined by a set of
Base Service Instances, a set of connections between the events and the actions of the
Base Service Instances, and by an Initial Event.

38
7 Conclusion
In this white paper, we presented the work on service lifecycle management carried out with-
in projects of the Mobile Services Platform cluster. Specifically, the problems of service crea-
tion, monitoring, validation, deployment, discovery and composition in B3G networks were
addressed.
While the projects within the MSP cluster have investigated the same research domains, the
variations in the targeted application domains or in the underlying infrastructure have lead to
different approaches and solutions. In particular, while most projects investigate the deploy-
ment of services within an infrastructure-based B3G network, with mobile terminals as mainly
service clients (e.g., SPICE, OPUCE), other projects consider highly dynamic environments
with limited infrastructure support and where services hosted on mobile devices play an im-
portant role (e.g., MIDAS, PLASTIC).
Most projects emphasize the role of service modeling and the need to model both functional
and extra-functional service properties (e.g., SLA, context). An emerging approach for ser-
vice creation is also to support user service creation as in OPUCE.
It becomes apparent that service lifecycle in B3G networks, and in particular run-time as-
pects, cannot be considered as a succession of independent steps. Indeed, the boundaries
between the run-time operations (deployment, discovery, access and composition) tend to
disappear when considering distributed services due to user or service mobility, the dynamic
distribution of the resources, and the underlying need to adapt to changes in the context in
order to deliver the required service to the user.
However, dynamic service deployment of services has not been as investigated as other
topics in current MSP projects, and may require new solutions to properly integrate with ser-
vice discovery and composition.

39
8 References
[1] Q. Wall, Understanding the Service Lifecycle within a SOA, 2006.
http://dev2dev.bea.com/pub/a/2006/11/soa-service-lifecycle-run.html
[2] V. Räisänen, W. Kellerer, P. Hölttä, O. Karasti, S. Heikkinen, ”Service Management Evolu-
tion”, IST Mobile and Wireless Communications Summit, 2005, Dresden, Germany.
[3] R. Alur, C. Courcoubetis, and D. Dill. Model checking in dense real-time. Information and
Computation, 104(1):2–34, 1993.
[4] R. Alur and D. Dill. A theory of Timed Automata. Theoretical Computer Science, 126(2):183–
235, 1994.
[5] ASG - Adaptive Services Grid. European Commission Project. Information Society Technol-
th
ogy. Funded under 6 Framework Programme. http://asg-platform.org/
[6] M. Baldoni, C. Baroglio, A. Martelli, V. Patti, C. Sciafanell “Verifying the Conformance of Web
Services to Global Interaction Protocols: A First Step” in Proceedings of Web Services and
Formal Methods, LNCS 3670, pp. 257-271.
[7] L. Baresi, C. Ghezzi and S. Guinea. Smart Monitors for Composed Services. In Proceedings
of the 2nd International Conference on Service Oriented Computing, 2004.
[8] L. Baresi and S. Guinea. Towards Dynamic Monitoring of WS-BPEL Processes. Proceedings
of ICSOC05, 3rd International Conference On Service Oriented Computing. 2005.
[9] G.Canfora, M. Di Penta. Testing Services and Service-Centric Systems: Challenges and Op-
portunities. In IT Professional March-April 2006 pp.10-18
[10] R. H. Carver and K.-C. Tai, Replay and Testing for Concurrent Programs, IEEE Software,
Vol.8 (2), Mar. 1991, 66-74.
[11] COMET - Converged Messaging Technology. European Commission Project. Information
th
Society Technology. Funded under 6 Framework Programme. https://www.comet-
consortium.org/
[12] C. Courbis and A. Finkelstein. Towards aspect weaving applications, Proceedings of Interna-
tional Conference on Software Engineering, St. Louis, 2005.
[13] F. Curbera, M. J. Duftler, R. Khalaf, W. A. Nagy, N. Mukhi, and S. Weerawaran. Colombo:
lightweight middleware for service-oriented computing. IBM Syst. J., 44(4):799-820, 2005.
[14] G. Denaro, A. Polini, and W. Emmerich, Early performance testing of distributed software
applications, Proceedings of the fourth international workshop on Software and performance,
2004, pp. 94–103.
[15] O. Edelstein, E. Farchi, Y. Nir, G. Ratsaby and Shmuel Ur, Multithreaded Java program test
generation, IBM Systems Journal, Vol. 41 (1), 2002, 111-125.
[16] O. Ezenwoye and S. Masoud Sadjadi. Enabling robustness in existing BPEL processes. In
Proceedings of the 8th International Conference on Enterprise Information Systems, Paphos,
May 2006.
[17] L. Frantzen, J. Tretmans and R. d. Vries. Towards Model-Based Testing of Web Services. In
Andrea Polini, editor. Proceedings of International Workshop on Web Services - Modeling and
Testing (WS-MaTe2006), pages 67-82, 2006.
[18] X. Fu, T. Bultan, and J. Su. Analysis of interacting BPEL web services. In Proc. of WWW2004,
May, 17-22 2004. New York, New York, USA, pp. 621-630.
[19] S. Ghosh, N. Bawa, S. Goel, and Y. Raghu Reddy, Validating run-time interactions in distrib-
uted java applications, ICECCS ’02: Proceedings of the Eighth International Conference on
Engineering of Complex Computer Systems (Washington, DC, USA), 2002, p. 7.
[20] S. Ghosh and A. Mathur, Issues in testing distributed component-based systems, Proceedings
of the First International ICSE Workshop Testing Distributed Component-based Systems, May
1999.

40
[21] J. Goguen, J. Thatcher, and E. Wagner. An initial algebra approach to the specification, cor-
rectness and implementation of abstract data types. In Current Trends in Programming Meth-
odology, volume IV: Data Structuring, pages 80-149. Prentice-Hall. 1978
[22] J. Grundy, Y. Cai, and A. Liu, Softarch/mte: Generating distributed system test-beds from
high-level software architecture descriptions, Automated Software Eng. 12 (2005), no. 1, 5–
39.
[23] H. Hrasna. Glassfish community building an open source JavaEE5 application server, 2006.
[24] C.E. Hrischuk, J.A. Rolia, and C.M. Woodside. Automatic Generation of a Software Perform-
ance Model Using an Object- Oriented Prototype. In Patrick W. Dowd and Erol Gelenbe, edi-
tors, Proc. of the 3rd International Workshop on Modeling, Analysis, and Simulation On Com-
puter and Telecommunication Systems (MASCOTS 1995), pages 399–409. IEEE Computer
Society, 1995.
[25] A. Hubbard, C. M. Woodside, and C. Schramm, DECALS: distributed experiment control and
logging system, Proceedings of the 1995 conference of the Centre for Advanced Studies on
Collaborative research, 1995, p. 32.
[26] D. Hughes, P. Greenwood, and G. Coulson, A framework for testing distributed systems, P2P
’04: Proceedings of the Fourth International Conference on Peer-to-Peer Computing (P2P’04)
(Washington, DC, USA), 2004, pp. 262–263.
[27] IBM. Tivoli: Composite Application Manager for SOA, 2006.
[28] INFRAWEBS. European Commission Project. Information Society Technology. Funded under
th
6 Framework Programme. https://www.comet-consortium.org/
[29] A. Keller and H. Ludwig. Defining and Monitoring Service-Level Agreements for Dynamic e-
Business. In Proceedings of the 16th Conference on Systems Administration, 2002.
[30] P. Krishnamurthy and P. A. G. Sivilotti, The specification and testing of quantified progress
properties in distributed systems, Proceedings of the 23rd international conference on Soft-
ware engineering, 2001, pp. 201–210.
[31] A. Lazovik, M. Aiello, and M. Papazoglou. Associating assertions with business processes and
monitoring their execution. Proceedings of the 2nd International Conference on Service Ori-
ented Computing, pages 94-104. ACM, 2004.
[32] Z. Li, Y. Jin and J. Han. A Runtime Monitoring and Validation Framework for Web Service
Interactions. In Proceedings of the 2006 Australian Software Engineering Conference, 2006.
[33] Z. Li, W. Sun, Z. B. Jiang, X. Zhang. BPEL4WS Unit Testing: Framework and Implementation.
In Proc. of ICWS'05, Orlando, Florida, July 11-15 2005, pp. 103-110.
[34] Y. Liu and I. Gorton. Accuracy of Performance Prediction for EJB Applications: A Statistical
Analysis. In Proc. Of Software Engineering and Middleware (SEM 2004), volume LNCS 3437,
pages 185–198. Springer, 2004
[35] B. Long, D. Hoffman and P. Strooper, Tool Support for Testing Concurrent Java Components,
IEEE Transactions on Software Engineering, Vol. 29 (6), Jun 2003, 555-566.
[36] H. Ludwig, A. Dan, and R. Kearney. Cremona: An architecture and library for creation and
monitoring of WS-Agreements. In Proc. of Service-Oriented Computing - ICSOC 2004, Sec-
ond International Conference, pages 65–74. ACM, 2004.
[37] MADAM - Mobility and Adaptation Enabling Middleware. European Commission Project. In-
th
formation Society Technology. Funded under 6 Framework Programme. http://www.ist-
madam.org
[38] K. Mahbub and G. Spanoudakis. A framework for requirements monitoring of service-based
systems. Proceedings of the 2nd International Conference on Service Oriented Computing,
pages 84-93. ACM, 2004.
[39] MUSIC - Self-Adapting Applications for Mobile Users in Ubiquitous Computing Environments.
th
European Commission Project. Information Society Technology. Funded under 6 Framework
Programme. ftp://ftp.cordis.europa.eu/pub/ist/docs/directorate_d/st-ds/music-project-
story_en.pdf
41
[40] T. Mackinnon, S. Freeman, and P. Craig, Endo-testing: Unit testing with mock objects, Pro-
ceedings of eXtreme Programming Conference 2000 (XP2000), May 2000.
[41] L. Peterson, T. Anderson, D. Culler, and T. Roscoe, A blueprint for introducing disruptive
technology into the internet, ACM SIGCOMM Computer Communication Review 33 (2003),
no. 1, 59–64.
[42] PLASTIC IST STREP Project. Deliverable D2.1: SLA language and analysis techniques for
adaptable and resource-aware components.
[43] W. Robinson. Monitoring web service requirements. In Proceeding of the International Confer-
ence on Requirements Engineering, 2003.
[44] A. Sahai, V. Machiraju, M. Sayal, A. P. Moorsel and F. Casati. Automated SLA Monitoring for
Web Services. In Proceedings of the 13th IFIP/IEEE international Workshop on Distributed
Systems: Operations and Management: Management Technologies for E-Commerce and E-
Business Applications, LNCS 2506, 2002.
[45] I. Satoh. Software Testing for Wireless Mobile Computing. IEEE Wireless Communications,
Oct. 2004, pp. 58-64.
[46] SeCSE - Service Centric System Engineering. European Commission Project. Information
th
Society Technology. Funded under 6 Framework Programme. http://secse.eng.it
[47] C.U. Smith and L. Williams. Performance Solutions: A practical Guide To Creating Respon-
sive, Scalable Software. Addison–Wesley, 2001.
[48] B. Verheecke, M. A. Cibrán and V. Jonckers. Aspect-Oriented Programming for Dynamic Web
Service Monitoring and Selection. In Proceedings of European Conference on Web Services
2004, LNCS 3250, September 2004.
[49] B. White et al. An Integrated Experimental Environment for Distributed Systems and Net-
works. Proceedings of the Fifth Symposium on Operating Systems Design and Implementa-
tion, Boston, Massachusetts, December 2002, pp. 255-270.
[50] A. W. Williams and R. L. Probert, A practical strategy for testing pair-wise coverage of network
interfaces, Proceedings of the The Seventh International Symposium on Software Reliability
Engineering (ISSRE ’96), 1996, p. 246.
[51] A. W. Williams and R. L. Probert, A measure for component interaction test coverage, Pro-
ceedings of the ACS/IEEE International Conference on Computer Systems and Applications,
2001, p. 304.
[52] G. von Laszewski, I. Foster, J. Gawor, W. Smith, S. Tuecke. CoG Kits: A Bridge between
Commodity Distributed Computing and High-Performance Grids. ACM Java Grande 2000
Conference. June 2000.
[53] IBM. The Era of Grid Computing: Enabling New Possibilities For Your Business. http://www-
1.ibm.com/grid/pdf/business exec grid.pdf. January 2003.
[54] Oscar Ardaiz Villanueva and Joe Touch. "Web Service Deployment and Management Using
the X-Bone" Spanish Symposium on Distributed Computing (SEID 2000), September 2000,
Ourense, Spain.
[55] Yelmo, Juan C., Rubén Trapero, José M. del Álamo, Juergen Sienel, Marc Drewniok, Isabel
Ordás and Kathleen McCallum. 2007. User-Driven Service Lifecycle Management - Adopting
Internet Paradigms in Telecom Services. Paper presented at Service-Oriented Computing -
ICSOC 2007 Fifth International Conference Proceedings, September 16-18, in Vienna, Aus-
tria.
[56] K. Arabshian and H. Schulzrinne. “Gloserv: Global service discovery architecture”. In First Intl.
Conference on Mobile and Ubiquitous Systems: Networking and Services (Mobiquitous), Au-
gust. 2004.
[57] M. Balazinska, H. Balakrishnan, and D. Karger, “INS/Twine: A scalable peer-to-peer architec-
ture for intentional resource discovery,” First International Conference on Pervasive Comput-
ing, Zurich, Switzerland, August 2002.

42
[58] G. Chen, and D. Kotz, “Solar: An Open Platform for Context-aware Mobile Applications”, In
st
Proc. of the 1 Int'l Conference on Pervasive Computing (Pervasive 2002), Switzerland, June
2002.
[59] Ian Clarke, Oskar Sandberg, Brandon Wiley, Theodore W. Hong; Freenet: A Distributed Ano-
nymous Information Storage and Retrieval System; Lecture Notes in Computer Science 2000
[60] Christos Doulkeridis, Efstratios Valavanis, Michalis Vazirgiannis. "Towards a Context-Aware
Service Directory", 4th VLDB Workshop on Technologies for E-Services (TES'03), September
8, 2003, Berlin, Germany, held in conjunction with the 29th International Conference on Very
Large Data Bases (VLDB 2003), Lecture Notes in Computer Science, Vol. 2819, pages 54-65,
Springer-Verlag, 2003.
[61] P. Grace et al, "ReMMoC: A Reflective Middleware to Support Mobile Client Interoperability".
In Proceedings of International Symposium on Distributed Objects and Applications, 2003.
[62] S. Wharehouse. "JXTA Search: Distributed Search for Distributed Networks"; Sun Microsys-
tems Whitepaper (http://search.jxta.org/JXTAsearch.pdf)
[63] Friederike Klan, "Context-aware service discovery, selection and usage" 18th GI-Workshop on
the Foundations of Databases, Wittenberg, Saxony-Anhalt, June 2006
[64] T. Koponen et al, "Service Discovery: A Service Broker Approach" In Proceedings of the 37th
Annual Hawaii International Conference on System Sciences (HICSS), 2004.
[65] C. Lee and S. Helal, “Context Attributes: An Approach to Enable Context-awareness for Ser-
vice Discovery”, In Proc. of the 2003 Symposium on Applications and the Internet (SAINT’03),
Orlando, USA, January 2003.
[66] M. Maheswaran, "Data Dissemination Approaches for Performance Discovery in Grid Com-
puting Systems", In Proceedings of 15th International Parallel and Distributed Processing
Symposium, 2001.
[67] S.Y. Ni et al, “The Broadcast Storm Problem in a Mobile Ad Hoc Network”, In Proceedings of
th
the ACM/IEEE 5 International Conference on Mobile Computing and Networking(MobiCom),
1999.
[68] Ion Stoica, Robert Morris, David Karger, M. Frans Kaashoek, Hari Balakrishnan, Chord: A
Scalable Peer-to-Peer Lookup Service for Internet Applications; Proceedings of ACM SIG-
COMM 2001
[69] Simple Service Discovery Protocol - Internet Draft -(http://www.upnp.org/)
[70] Ben Y. Zhao, Ling Huang, Jeremy Stribling, Sean C. Rhea, Anthony D. Joseph, John D. Kubi-
atowicz; Tapestry: A Resilient Global-scale Overlay for Service Deployment; IEEE Journal on
Selected Areas in Communications 2003
[71] Weibin Zhao and Henning Schulzrinne, "Enhancing Service Location Protocol for Efficiency,
Scalability and Advanced Discovery", in Journal of Systems and Software, Vol. 75(1-2), pp.
193-204, February 2005.
[72] F. Zhu, M. Mutka, and L. Ni, "Splendor: A Secure, Private, and Location-aware Service Dis-
covery Protocol Supporting Mobile Services", In Proc. of the 1st IEEE Int'l Conference on Per-
vasive Computing and Communications (PerCom’03), Fort Worth, Texas, USA, March 2003.
[73] S. Ben Mokhtar, A. Kaul, N. Georgantas, and V. Issarny. “Efficient semantic service discovery
in pervasive computing environments”. In Proceedings of ACM/IFIP/USENIX 7th International
Middleware Conference (Middleware’06), 2006.
[74] P.-G. Raverdy, V. Issarny, R. Chibout, A. de La Chapelle. “A Multi-Protocol Approach to Ser-
vice Discovery and Access in Pervasive Environments”. In Proceedings of MOBIQUITOUS -
The 3rd Annual International Conference on Mobile and Ubiquitous Systems: Networks and
Services. July 2006, San Jose, CA, USA.
[75] F. Zhu, M. Mutka, and L. Ni. “PrudentExposure: A Private and User-centric Service Discovery
Protocol”. In PERCOM ’04: Proceedings of the Second IEEE International Conference on Per-
vasive Computing and Communications (PerCom’04), 2004.

43
[76] J. Liu, V. Issarny. Signal Strength based Service Discovery (S3D) in Mobile Ad Hoc Networks.
In Proceedings of the 16th Annual IEEE International Symposium on Personal Indoor and
Mobile Radio Communications (PIMRC). September 2005.
[77] F. Zhu, M. Mutka, and L. Ni, "Service Discovery in Pervasive Computing Environments," IEEE
Pervasive Computing, vol. 4, No. 4, pp. 81-90, 2005.
[78] J. Nakazawa, W. Keith Edwards, Umakishore Ramachandran, and Hideyuki Tokuda, ”A Bridg-
ing Framework for Universal Interoperability in Pervasive Systems”, The 26th International
Conference on Distributed Computing Systems (IEEE ICDCS 2006), Lisboa, Portugal, July
2006
[79] Y-D Bromberg and V Issarny. "INDISS: Interoperable Discovery System for Networked Ser-
vices". In Proceedings of ACM/IFIP/USENIX 6th International Middleware Conference (Mid-
dleware). 2005.
[80] G. Lee, P. Faratin, S. Bauer, and J, Wroclawski, “A User-Guided Cognitive Agent for Network
nd
Service Selection in Pervasive Computing Environments”, In Proc. of the 2 IEEE Int'l Con-
ference on Pervasive Computing and Communications (PerCom’04), Orlando, USA, March
2004.
[81] L. Capra, S. Zachariadis, and C. Mascolo, "Q-CAD: QoS and Context Aware Discovery
Framework for Mobile Systems", In Proc. of Int'l Conference on Pervasive Services (ICPS'05),
Greece, July 2005.
[82] P-G Raverdy, O. Riva, A. de La Chapelle, R. Chibout, V. Issarny. “Efficient Context-aware
Service Discovery in Multi-Protocol Pervasive Environments”. In Proceedings of the 7th Inter-
national Conference on Mobile Data Management (MDM'06). May 2006, Nara, Japan.
[83] The DAML Services Coalition. “Bringing semantics to web services: The owl-s approach”. In
Proceedings of the First International Workshop on Semantic Web Services and Web Process
Composition (SWSWPC’04), 2004.
[84] A. A. Patil, S. A. Oundhakar, A. P. Sheth, and K. Verma. “Meteor-s web service annotation
framework”. In Proceedings of the 13th conference on World Wide Web, 2004.
[85] K. Sycara, M. Paolucci, A. Ankolekar, and N. Srinivasan. “Automated discovery, interaction
and composition of semantic web services”. Web Semantics: Science, Services and Agents
on the World Wide Web, 2003.
[86] D. Trastour, C. Bartolini, and J. Gonzalez-Castillo. “A semantic web approach to service de-
scription for matchmaking of services”. In Proceedings of the first Semantic Web Working
Symposium, (SWWS), 2001.
[87] N. Srinivasan, M. Paolucci, and K. Sycara. “Adding owl-s to uddi, implementation and
throughput”. In Proceedings of the Workshop on Semantic Web Service and Web Process
Composition, 2004.
[88] S. Ben Mokhtar, D. Preuveneers, N. Georgantas, V. Issarny, Y. Berbers. EASY: Efficient Se-
mAntic Service DiscoverY in Pervasive Computing Environments with QoS and Context Sup-
port. In Journal of System and Software, 2007. To Appear.
[89] S. E. Czerwinski, B. Y. Zhao, T. D. Hodes, A. D. Joseph, and R. H. Katz. “An Architecture for
a Secure Service Discovery Service”. In MobiCom ’99: Proceedings of the 5th annual
ACM/IEEE international conference on Mobile computing and networking, 1999.
[90] OPUCE project. 2007. Deliverable D2.3_1: Description of OPUCE platform elements.
[91] Baladrón, Carlos, Javier Aguiar, Belén Carro, Jürgen Sienel, Rubén Trapero, Juan Carlos
Yelmo, José María del Álamo, Jian Yu and Paolo Falcarin. 2007. Service Discovery Suite for
User-Centric Service Creation. Paper presented at Service Oriented Computing: a Look at the
Inside Proceedings (SOC@Inside '07), September 17, in Vienna, Austria.
[92] E. BRUNETON, T. COUPAYE AND J. STEFANI, Recursive and dynamic software composi-
tion with sharing, In Proceedings of the 7th ECOOP InternationalWorkshop on Component-
Oriented Programming (WCOP’02), Malaga (Spain), June 2002.

44
[93] D. Chakraborty, A. Joshi, T. Finin and Y. Yesha, Service Composition for Mobile Environ-
ments, Journal on Mobile Networks and Applications (MONET), 10, 435–451, 2005
[94] S. Dustdar and W. Schreiner, A survey on web services composition, Int. J. Web and Grid
Services, Vol. 1, No. 1, 2005.
[95] Semantic Annotations for WSDL and XML Schema, W3C Working Draft 10 April 2007,
http://www.w3.org/TR/sawsdl/
[96] R. H. Campbell, A. N. Habermann, The specification of process synchronization by path ex-
pressions. In Proceedings of International Symposium on Operating Systems Principles. 1974.
[97] J. E. Hanson, P. Nandi, D. Levine. Conversation-enabled Web Services for Agents and e-
business. In Proceedings of the International Conference on Internet Computing (IC-02).
2002.
[98] R. Tolksdorf. A Dependency Markup Language for Web Services. In Web Databases and
Web Services. LNCS 2593. 2003.
[99] W3C. Web Services Conversation Language (WSCL), Version 1.0, The World Wide Web
Consortium. 2002. W3C Note. http://www.w3.org/TR/wscl10/.
[100] B. Benatallah, F. Casati, F. Toumani. Web Service Conversation Modeling. IEEE Internet
Computing. 2004.
[101] W3C. The OWL Services Coalition at the World Wide Web Consortium. OWLS: Semantic
Markup for Web Service, http://www.daml.org/services/owl-s/
[102] X. Yi, K.J. Kochut. Process composition of Web services with complex conversation protocols:
a colored Petri nets based approach. In Proceedings of Advanced Simulation Technology
Conference (DASD2004). 2004.
[103] W3C, Web Service Choreography Interface (WSCI) 1.0. W3C Note.
http://www.w3.org/TR/wsci/.
[104] R. Jimenez-Peris, M. Patino-Martinez, S. Woodman, S. Shrivastava, D. Palmer, S. Wheater,
B. Kemme, G. Alonso. Service Specification Language. Deliverable of ADAPT IST project IST-
2001-37126. 2003.
[105] S. Ben Mokhtar, N. Georgantas, V. Issarny. COCOA: COnversation-based Service COmposi-
tion in PervAsive Computing Environments. In Proceedings of the IEEE International Confer-
ence on Pervasive Services (ICPS'06). June 2006.
[106] W3C, Web Services Choreography Description Language Version 1.0. W3C Working Draft.
http://www.w3.org/TR/ws-cdl-10/.
[107] T. Bultan, X. Fu, R. Hull, J. Su. Conversation Specification: A New Approach to Design and
Analysis of E-Service Composition. In Proceedings of the 12th International World Wide Web
Conference. 2003.
[108] G. H. Mealy. A Method for Synthesizing Sequential Circuits. Bell System Tech. J. 34. 1955.
[109] B. Benatallah, M. Dumas, Q. Z. Sheng. Facilitating the rapid development and scalable or-
chestration of composite web services. Distrib. Parallel Databases, 17(1). Kluwer Academic
Publishers. 2005.
[110] S. Narayanan, S. McIlraith. Simulation, Verification and Automated Composition of Web Ser-
vices. In Proceedings of the WWW'02 Conference. 2002.
[111] R. Hamadi, B. Benatallah. A Petri net-based model for web service composition. In Proceed-
ings of the Fourteenth Australasian database conference on Database technologies. 2003.
[112] BEA Systems, IBM, Microsoft, SAP AG and Siebel Systems. Business Process Execution
Language for Web Services. http://www.ibm.com/developerworks/library/specification/ws-
bpel/.
[113] W. Reisig, G. Rozenberg. Lectures on Petri Nets I: Basic Models. LNCS 1491. 1998.
[114] R. Farahbod, U. Glasser, M. Vajihollahi. Specification and Validation of the Business Process
Execution Language for Web Services. ASM 2004. LNCS 3052. 2004.

45
[115] H. Foster, S. Uchitel, J. Magee, J. Kramer, Compatibility Verification for Web Service Chore-
ography. In Proceedings of the IEEE International Conference on Web Services (ICWS'04).
2004.
[116] X. Fu, T. Bultan, J. Su. Analysis of interacting BPEL web services. In Proceedings of the 13th
international conference on World Wide Web. 2004.
[117] N. Georgantas, P. Inverardi, V. Issarny. Software Platforms. In E. Aarts, J. Encarnacao (edi-
tors), True Visions: Tales on the Realization of Ambient Intelligence. Springer Verlag. 2006.
[118] J.P. Sousa, D. Garlan. Aura: An architectural framework for user mobility in ubiquitous com-
puting environments. In proceedings of WICSA’02. 2002.
[119] Manuel Roman, Christopher K. Hess, Renato Cerqueira, Anand Ranganathan, Roy H. Camp-
bell, and Klara Nahrstedt. Gaia: A middleware infrastructure to enable active spaces. IEEE
Pervasive Computing, 1(4):74--83, October-December 2002.
[120] R. Masuoka, B. Parsia, Y. Labrou. Task computing – The semantic Web meets pervasive
computing. In Proceedings of ISWC’03. 2003
[121] A. Bernstein, M. Klein. Towards high precision service retrieval. In Proceedings of ISWC.
LNCS 2342. 2002.
[122] R. A. K. Verma, J. Miller, W. Milnor Dynamic Web service composition in Meteor-S. Technical
report, LSDIS lab, CSD, UGA, 2004.
[123] S. Majithia, D. W. Walker, W. A. Gray. A framework for automated service composition in ser-
vice-oriented architecture. In Proceedings of the 1st European Semantic Web Symposium.
2004.
[124] A. Joseph, A. deLespinasse, J. Tauber, D. Gifford, F. Kaashoek. Rover: a toolkit for mobile
information access. In ACM SIGOPS SOSP ’95. 1995.
[125] J. Caetano et al "Introducing the user to the service creation world: concepts for user centric
service creation, personalization and notification" In: Proceedings of the User centricity-state
of the art Workshop, 16th IST Mobile and Wireless Communications Summit, 1-5July 2007,
Budapest, Hungary

46