service lifecycle management - semantic scholar · sents the work on service lifecycle management...

1

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>

2

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.

3

Contributing projects

Project name Short description

MIDAS

(Middleware Platform for Developing and

Deploying Advanced Mobile Services)

MIDAS aims to produce an overall architecture and middleware building blocks providing solutions to technical issues that must be addressed in developing mobile services. It specifically ad-dresses mobile service provision in situations where the network may need to be set up at short notice, or for limited duration, and 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

(Open Platform for User-centric service Creation and Execu-tion)

OPUCE is an FP6 Integrated Project aimed at developing a com-plete platform for the dynamic user-centric creation, deployment and execution of services including information technologies and communication features. 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.

PLASTIC

(Providing Light-weight and Adaptable Service Technology for Pervasive Informa-tion and Communica-tion)

PLASTIC (Providing Lightweight and Adaptable Service Technol-ogy for Pervasive Information and Communication) revisits ser-vice-oriented computing for the B3G network, in particular assist-ing the development of services targeted at mobile devices. Spe-cifically, the PLASTIC platform provides a development environ-ment leveraging model-driven engineering for the thorough devel-opment of SLA- and resource-aware services, a middleware lev-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

(Service Platform for Innovative Communi-cation Environment)

SPICE is an IST-FP6 Integrated Project addressing the problem of designing, developing and putting into operation efficient and innovative mobile Service creation/execution Platforms for net-works beyond 3G. SPICE investigates novel platform features such as distributed communication sphere management, intelli-gent service enablers, service roaming, adaptive content delivery and multi-domain access control.

4

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

5

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

6

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

7

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-

8

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.

9

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

10

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-tions.

Emphasis on component external-view.

Natural separation from description and implementation.

No evident separation between compo-nent external-view and implementation.

Only service description is available dur-ing assembly.

Component physically available during assembly.

Integration is made prior or during execu-tion.

Integration at assembly-time.

Better support for run-time discovery and substitution.

No native support for run-time discovery 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.

11

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.

S4

S5S3 S7

S8

S9

S10

C2 C1

C5

C4

C3 C6

C8

C9C7

Service Layer

Component Layer

Service request

Service Composition

Component Assembling

Service Consumer

Software Developer

Service Service Description

Component Component Description

Figure 3: PLASTIC two-layers approach

12

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.

13

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/

14

(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/

15

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/

16

• 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.

17

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

18

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.

19

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-

20

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

21

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

22

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.

23

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

24

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/

25

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/

26

• 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:

27

• 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

28

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

29

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.

30

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.

31

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.

32

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.

33

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

34

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.

35

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-

36

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.

37

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

38

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.

39

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.

40

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-ogy. Funded under 6th 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 Society Technology. Funded under 6th 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.

41

[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 6th 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-formation Society Technology. Funded under 6th 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. European Commission Project. Information Society Technology. Funded under 6th Framework Programme. ftp://ftp.cordis.europa.eu/pub/ist/docs/directorate_d/st-ds/music-project-story_en.pdf

42

[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 Society Technology. Funded under 6th 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.

43

[58] G. Chen, and D. Kotz, “Solar: An Open Platform for Context-aware Mobile Applications”, In Proc. of the 1st 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 the ACM/IEEE 5th 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.

44

[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 Service Selection in Pervasive Computing Environments”, In Proc. of the 2nd 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.

45

[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.

46

[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

service lifecycle management - semantic scholar · sents the work on service lifecycle management...

Documents