Whitepaper 4 Lifecyclemgmnt Plastic Final

8/8/2019 Whitepaper 4 Lifecyclemgmnt Plastic Final

1/46

1

Mobile Service Platforms Cluster

White Paper

Service Lifecycle Management

Date delivered:April 20th, 2008

EditorPierre-Guillaume Raverdy (INRIA, PLASTIC)

ContributorsMarco Autili (Univerity of lAquilla, PLASTIC)

Antonia Bertolino (CNR-Pisatel, PLASTIC)

Christophe Cordier (FTRD, SPICE)

Bhushan, Bharat (FOKUS, SPICE)Isabel Ords (TID, OPUCE)

Carlos Baladrn (Universidad de Valladolid, OPUCE)

Joe Gorman (Sintef, MIDAS)

Erik Klintskog (Appear Networks, MIDAS)Alisa Devlic (Appear Networks, MIDAS)

Version:


2/46

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 tothe success of mobile service platforms. Indeed, while service lifecycle has been traditionallyviewed 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 outwithin projects of the Mobile Services Platform cluster. Specifically, the problems of servicecreation, monitoring, validation, deployment, discovery and composition in B3G networks areaddressed. 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 allwork providing elements of platforms, which facilitate the development and deployment ofmobile services. The cluster provides a forum to facilitate knowledge sharing on all aspectsof 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/46

3

Contributing projects

Project name Short description

MIDAS

(Middleware Platformfor Developing and

Deploying AdvancedMobile Services)

MIDAS aims to produce an overall architecture and middleware

building blocks providing solutions to technical issues that mustbe addressed in developing mobile services. It specifically ad-dresses mobile service provision in situations where the networkmay need to be set up at short notice, or for limited duration, andwhere communications infrastructure may be unavailable forsome users, necessitating the need for use of ad-hoc communi-cations. The middleware includes modules for establishing con-nectivity using heterogeneous networks, distributed data sharingin unreliable networks, generating synthesised context data, andcontext-based routing of messages.

OPUCE

(Open Platform forUser-centric serviceCreation and Execu-tion)

OPUCE is an FP6 Integrated Project aimed at developing a com-

plete platform for the dynamic user-centric creation, deploymentand execution of services including information technologies andcommunication features. The goal of the OPUCE platform is toput the end-user in the centre of the whole lifecycle of a service,to let them become at the same time the creator, the managerand the consumer of services.

PLASTIC

(Providing Light-weight and AdaptableService Technologyfor 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 forapplications and services run on mobile devices, and a validationframework enabling off-line and on-line validation of networkedservices.

SPICE

(Service Platform forInnovative Communi-cation Environment)

SPICE is an IST-FP6 Integrated Project addressing the problemof designing, developing and putting into operation efficient andinnovative mobile Service creation/execution Platforms for net-works beyond 3G. SPICE investigates novel platform featuressuch as distributed communication sphere management, intelli-gent service enablers, service roaming, adaptive content delivery

and multi-domain access control.


4/46

4

Contents

1 Introduction .................................................................................................................... 72 Service Model and Creation Tools.................................................................................. 9

2.1 Related Work .......................................................................................................... 92.1.1 Service Oriented Architecture........................................................................... 92.1.2 Component vs Service Orientation................................................................... 9

2.2 PLASTIC Conceptual Model for Adaptive Services ................................................102.2.1 Combining services and components..............................................................112.2.2 Extending the SeCSE conceptual model.........................................................12

2.3 SPICE Component Model and Toolchains .............................................................122.4 User-centric Services in OPUCE............................................................................13

3 Service Validation..........................................................................................................173.1 Related Work .........................................................................................................17

3.1.1 Testing of networked systems.........................................................................183.1.2 Web Services Testing .....................................................................................193.1.3 Runtime Monitoring .........................................................................................203.1.4 QoS Validation of Networked Services............................................................20

3.2 Validation in PLASTIC............................................................................................214 Service Deployment ......................................................................................................23

4.1 Related Work .........................................................................................................234.1.1 Bundle deployment in OSGi ............................................................................234.1.2 SmartFrog and CDDLM...................................................................................24

4.2 Context-aware service deployment in MIDAS.........................................................254.3 Service deployment in OPUCE ..............................................................................26

5 Service Discovery..........................................................................................................285.1 Related Work .........................................................................................................285.2 New challenges for service discovery.....................................................................29

5.2.1 Multi-protocols SD...........................................................................................295.2.2 Context-aware SD...........................................................................................305.2.3 Semantic SD...................................................................................................305.2.4 Multi-networks SD...........................................................................................305.2.5 Security and privacy........................................................................................315.2.6 Mobility............................................................................................................31

5.3 Service Discovery in PLASTIC ...............................................................................315.4 Discovering, publishing and sharing services in OPUCE........................................32

6 Dynamic Service Composition.......................................................................................33


5/46

5

6.1 Related Work .........................................................................................................336.1.1 Web service conversation ...............................................................................336.1.2 Web service choreography..............................................................................346.1.3 Web service orchestration...............................................................................34

6.2 New Challenges for Service composition in B3G environments .............................356.2.1 Dynamic service composition..........................................................................356.2.2 Reconfigurable service composition................................................................35

6.3 Service broker architecture in SPICE .....................................................................366.4 The Service Composition Model in OPUCE ...........................................................37

7 Conclusion ....................................................................................................................398 References....................................................................................................................40


6/46

6

List of Figures

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


7/46

7

1 Introduction

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

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

Design-time aspects include service modeling, development and packaging while run-timeaspects 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 havelead 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 focusin Chapter 2 on the various service models adopted by various projects and the creationtools they provide. A common evolution of these projects compared to traditional servicemodels is to emphasize the modeling of non-functional properties in their models. We thendescribe in Chapter 3 how service models may be used to support design-time and run-timeservice validation. In particular, we describe how service modeling can be used to automati-


8/46

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-orientedB3G networks (i.e., infrastructure-based) build on top of well-proven solutions for scalabilityand security, projects targeting highly dynamic networks (e.g., pervasive environments, sen-sor networks, MANETs) need to provide innovative solutions to deal with the heterogeneityand dynamics of their environment (e.g., service mobility). In Chapter 6, we describe supportfor service composition, which is a major research topic in most MSP projects. Finally, weconclude in Chapter 7.


9/46

9

2 Service Model and Creation Tools

2.1Related Work

Generally speaking, Software Architectures (SA) are meant to abstractly model the overallstructure 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 ofsoftware 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 ofservice-centric software systems in terms of communicating services. SOA is a loosely-

coupled model whose most significant aspect is that it separates the service implementationand the service provider from its contractual description. In this way, it separates the whatfrom the how. The service description is given in neutral manner, independently from anyplatform and implementation detail. Service consumers view a service simply as an endpointthat supports a particular request format or contract. Service consumers do not need to knowhow 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 everwider application domains. Applications are built as assemblies of existing services, and evermore 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 arecomponents that can be integrated into more complex distributed applications by means ofsome Web-based/XML-based open standards (e.g. WSDL, UDDI, HTTP, SOAP, etc.). Webservices are not the only way to implement SOA. Message-Oriented Middlewaresystems,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 connectorsand 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 withits environment may be also required to allow assemblers to connect and eventually adaptthe various component instances. Hierarchical structural composition is achieved when theexternal 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 byservices. Each service has a description of provided functionalities that can be contractually


10/46

10

defined as a mix of syntax, semantics and behavior specifications. The basis for assemblingservices 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 thatservice 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 descriptionthey 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 dynamicavailability, 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 previousdiscussion 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 andimplementation.

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

Only service description is available dur-ing assembly.

Component physically available duringassembly.

Integration is made prior or during execu-tion.

Integration at assembly-time.

Better support for run-time discovery andsubstitution.

No native support for run-time discoveryand difficult substitution.

Native dynamic availability. No native dynamic availability.

Abstract composition. Structural composition.

Table 1 Main aspects of Service Orientation and Component Orientation.

2.2PLASTIC Conceptual Model for Adaptive Services

The main role of the PLASTIC conceptual model is to build a common vocabulary on whichto base modeling and development tasks and is inspired by the SeCSE conceptual modelThe model has been conceived to be extensible since it can be easily adapted in order toaccommodate different needs coming from different service-oriented domain. The SeCSE

conceptual model was initially inspired by the Web Service Architecture (WSA) drafted by theW3C 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 toclarify 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 newconcepts 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 thisintegration comes from the adaptive nature of B3G applications and is one of the first attemptto explicitly specify the relationships between Service Oriented Architectures and Compo-nent-Based Software worlds.


11/46

11

2.2.1 Combining services and components

Services in PLASTIC are meant to be adaptable to the context whether related to the usersetting (e.g. type of device, user mobility) or the available network resources (e.g. networkbandwidth). The goal is to provide services that achieve the best tradeoff between the userneeds (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 contextwhere they run. Thus, we make the context characteristics emerging at the service level: aservice 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. servicereliability, latency time).

PLASTICs approach is somehow opposite to a typical layered architectural model, wheredifferences 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 asopposed to distributed system transparency.

In PLASTIC, applications in the B3G environment should always guarantee a certain level ofQoS to the consumer despite the heterogeneity and richness of the underlying networks. Atthe same time, the components implementing the services should have the capability toadapt to different contexts. QoSand adaptationare thus the main keywords for the PLASTICconceptual model. Figure 3 shows this two-layer vision of a software application:

The component layer represents the computing environment for networked servicesthat 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 bedeployed, updated, or removed on the fly without interrupting the operability of thedevice.Components developers bind to services by only using service descriptions. In other

words, components contractually implement service descriptions but the selection ofthe specific component to instantiate is deferred at run-time by taking into account theservice 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 implementingthem.

S4

S5S3 S7

S8

S9

S10

C2C1

C5

C4

C3 C6

C8

C9C7

ServiceLayer

ComponentLayer

Servicerequest

Service Composition

Component Assembling

ServiceConsumer

SoftwareDeveloper

Service Service Description

Component Component Description

Figure 3: PLASTIC two-layers approach


12/46

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 inorder to better meet the user requirements on the service. The context is a first classentity in the PLASTIC conceptual model since it influences the Service Level Agree-ment procedure, the composition of software services and the adaptation of softwarecomponents.

ContextDescription:This entity represents the information the PLASTIC platform isable to retrieve from the environment, suitably structured. In general this informationis partial since it is too heavy (and useless) to gather the complete information oncontext. 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 itcontains 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 andit is contained in the service request expressed by the consumer.

Location:Location is the identification of a context. It can be related both to physicaland logical context. This entity is useful to model mobility in PLASTIC platform. Thecontext is hence identified by a location contained in the context description. Each ofthe 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 bedeployed and executed. The information specified in this entity is used in the softwarecomponent 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 componentto a specific context. The specified rules make use of the component description inorder to suitably adapt the involved software component(s) to the available contextwhere the software service will run.

Service Level Agreement: This entity models the agreement reached between theservice 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.3SPICE Component Model and Toolchains

A hierarchical, abstract component model (largely influenced by the Fractal model [92]) hasbeen 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 identifiersand are associated with meta-information.


13/46

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 fullyspecified (endpoint, version, etc.). In complex cases, the composite component may becomposed 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 componentconnections are not fully known at design time. Abstract component networks are associatedwith adaptation rules that control how the components and component connections need tobe selected according to conditions of the environment.SPICE provides the Service Creation Environment (SCE) that supports the creation of basiccomponents, intelligent components, and value added services. The SCE provides graphicalservice development tools, as well as emulation of service enablers and testing environment.Two separate toolchains support the needs of the professional service developers and theneeds of the end users respectively.

The dedicated Development Studio for professional developers is being developedaround the high-level service description language SPATEL (SPICE Advanced Ser-

vice Description Language for Telecommunication Services). SPATEL allows using aModel-Driven Architecture (MDA) approach for transforming a service idea through aplatform independent representation to an executable service.

The special End User Studio allows the end-users to create service mashups fromexisting SPICE services, which are easily tailored to their needs. This means thatend-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 partyservice providers.

2.4User-centric Services in OPUCEUsers are putting pressure on telecom operators by increasingly requiring innovative andattractive services: They would like to have the advanced model they use on the Internetwhich allows users to define new contents and applications (mashups) using open servicesand 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 thoseservices autonomously. It also allows users to share these services within a community thatwill 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 ofWeb 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 servicesthat 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/46

14

(e.g., a positioning service, a messaging service or a map service). Furthermore, the creatormay 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 Environmentwith 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 users personal information,identity management and AAA issues.

A Subscription Managementmodule 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, whichmanages the execution of services and or-chestrates base services following the logic created by the users when composingthem.

A user-centric based service ecosystem requires major flexibility and dynamicity in managingservice lifecycle compared to current service management systems. In order to automate theprocess between the creation and the execution of the services, the OPUCE platform needsa common way to completely describe the services. The concept of service description hasalready been addressed in projects such as SPICE2 and SeCSE3. Some of the results of

2 http://www.ist-spice.org/


15/46

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 theSeCSE 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 thefaceted specification followed in OPUCE.

Therefore, in OPUCE, services are described using a service specification which contains allaspects 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 wehave considered three sets of facets:

Functional facets, which include service logic facets, service interface facets, servicesemantic information facet, etc.

Non-functional facets, which include service level agreement (SLA) facets, quality ofservice 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 andknowledge of service developers, they must ease the task of service creation as much aspossible: 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 asnatural language descriptions. The OPUCE platform also advocates that end-user servicecreators should be enabled to enjoy their new role of service creators using every device andaccess 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 featureeditor that supports a description language accepting a large numberof composition rules, rich graphical user interface (possibly with a large footprint), ad-vanced validation tools etc.

3 http://secse.eng.it/


16/46

16

The simplified editor with less demanding user interface, simpler description lan-guage, restricted set of available operations, more guided creation/customizationprocess, etc.

However, in order to support cross-editing, both tools share the same design principles andtake 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 specificservice resolution: the more advanced the editor the higher the resolution. But both work onthe same material, i.e. the service definition.


17/46

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 aseasing 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 totheir 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 ofservice-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 expectedor contractually agreed levels of quality, which are also part of the specifications in form ofsuitable annotations.Following the definition of terminology associated to validation, we survey in Section 3.1some topics related to the validation of B3G services, which altogether make the context forthe development of a B3G validation framework. We then detail how service validation is

carried out in PLASTIC.

3.1Related 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 involvefunctional 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 termsof the I/O sequences of events. In particular, it checks if the functionalities implemented bythe 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 testmeets its extra-functional constraints.

Off-line vs. On-line: Methods and tools for testing purposes can be classified into two maincategories: 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 itwill 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 otherhand, on-line approaches concern a set of techniques, methodologies and tools to monitorthe system after its deployment in one of its real working context. A possible scenario is thatwhile the end-users are using the service, data are being collected about the scenario underwhich 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 usagescenarios. Otherwise, the development organization performs on-line validation activities ona fully fielded service, perhaps during idle times.

Testing vs. Monitoring: Software testing is a broad term encompassing a wide spectrum ofactivities. The primary underlying common goal of these activities is to apply methodologiesand techniques designed to make sure that a software system does what it was designed todo and that it does not do anything unintended. However, the idea of pursuing such a goaljust by applying an exhaustive exploration of all possible configurations of the system and ofits environment is unrealistic. So, given a generic software system, testing activities focus onobserving 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. Crucialmonitoring steps are the elicitation of which data should be collected, how long the observing


18/46

18

windows are, what policies should be applied when a fault is detected, and so on. In someapproaches, the middleware is responsible for providing the facilities to disseminate the datacollected from the sources to the sinks that analyses the data. The two practices clearly havemany 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 systemis on-line.

3.1.1 Testing of networked systems

Distribution is one inherent characteristic of B3G applications, and MSPs thus need to copewith 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 arespecifically targeted at performance testing [14], [21]. However, these works address only theaccidental issues associated with distributed system testing, and do not address the morefundamental 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 testbedssuch as PlanetLabs [41] and Netbed/Emulab [49] that are appropriate for evaluating large-scale distributed applications. However, these systems do not provide explicit support fortesting but require some additional management and reporting software to do so. Anotherfocus for distributed application testing is the performance evaluation of systems based onarchitectural and design specifications. For example, the SoftArch/MTE system [22] enablesthe automatic generation of prototype distributed systems based on high-level architecturalobjectives 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- andsystem-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 atthe detection of concurrency faults, in particular execution sequences and schedules. Ingeneral, these techniques can be classified in two groups: those (e.g., ConTest tool [15]) thatsample over non-deterministic runs in the hope of exercising a reasonable percentage of thepossible synchronization events, and those (e.g., [10]) that attempt to create specific deter-

ministic runs.


19/46

19

A key aspect of B3G applications is the inherent mobility of terminals and devices on whichthe 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 theterminals could be moved and connected to, since we need to validate how the services caninteroperate in the various contexts, and also that the required QoS is provided. This mayincrease exponentially the difficulty of B3G application development and testing. There doesnot 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 runningon 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 possibleto 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, servicescomposing an application can change at run-time without informing all the other servicesintegrated in the application.

In [9] the authors identify f ive 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 ofthe service, in order to assess that the implementation of the services actually behaves asexpected. In the service oriented domain the specification of the behaviour could have beendefined by the developers themselves or even by some external bodies, as in the case ofchoreographies. 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 beused by the service under development is usually retrieved from the Net using some kind ofdiscovery service. In [17] the authors show how the specification of a choreography can beused 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 composedservices.

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 directoryand 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 isthat the service can be tested at the time it asks for registration. Main advantages of such anapproach is that tests are executed in a real execution environment providing more realisticresults. Moreover, following such an idea, only high quality certified services will be guaran-


20/46

20

teed to pass the registration. Industry-supported tools for the testing of Web services includeSOATest, Mindreef, and TestMaker.Finally WS-I is an industry organization chartered to facilitate WS interoperability. As a mainoutcome this organization released a specification, called the basic profile, composed of a listof 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 useof elements from such specifications. In particular such architecture is composed of a WS-Ianalyzer and a WS-I monitor, that applying the man-in-the-middle paradigm, intercepts all themessages 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 amongdifferent services, nevertheless it is not concerned with the functional and extra-functionalverification of a service implementation.

3.1.3 Runtime Monitoring

Monitoring is a runtime activity that collects data and transfers them to external functions forelaboration. 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 whatthey 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 acomposition or of individual services [38] [43], the planning of an execution [31], or (iv) thevalidating 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 apotential 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-orientedprogramming 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, allowto dynamically insert measurements points in the system and to execute the monitoring logictailored 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 aspredictive 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 implementationor prototype). The objective is carrying on some tests and comparing the observed QoScharacteristics with the expected ones.

The testing of extra-functional properties in general requires the development of expensiveand time consuming prototypes [34], on which representative benchmarks of the system inoperation can be run. Fortunately, much progress has been done in the direction of providingautomated support for the development of test environments. Specifically, computer-

readable specifications can be used in order to describe in detail both the software underevaluation and the expected environment. Today mechanisms acting as code-factories are


21/46

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 alarge room for the development of empirical approaches for the evaluation of a system withinthe 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. Themonitoring component is made up of two services: the first, the Measurement Service,measures parameters defined in the SLA, by probing client invocations or retrieving metricsfrom internal resources; the second, the Condition Evaluation Service, tests the measuredvalues 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 theexecution 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 otherEuropean 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 solutionswithout adequate specification and validation of QoS features, especially in heterogeneous

and networked services contexts.

3.2Validation 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 committingthe validation framework to one specific test methodology, but rather to conceive it as anopen 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 conductedduring development of the service, in a fake environment. On-line validation refers instead totesting software deployed in its real environment; in particular in the context of services, wehave distinguished between validating the service behaviour before it is made available forgeneral 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 QoSevaluation. 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 theQoS 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-functionalproperties too. The trend in SOA applications is that QoS agreed attributes and levels arespecified by means of appropriate annotations that augment the service specifications.

A second level of problems regards configuration and environment. Evaluating by means oftesting specified performance attributes (e.g., response time for a service), or dependabilityattributes (e.g., exposed reliability), involves many technical difficulties since such qualitiesdepend not only on the service under test, but also on the underlying support system and on


22/46

22

the network. Therefore, the tough challenge here is how to validate the provided QoS of anapplication, keeping the aspects that pertain strictly to the observed system separate fromthe aspects which depend on the underlying platform. The service developer can interveneon 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 realusage. The monitoring process however consumes valuable resources. Therefore, careshould be put in devising lightweight approaches that do not heavily impact performance. Infact, one of the problems that need to be solved is how to keep the overhead introduced bydata collection and analysis to a minimum. This can be achieved by an intelligent sampling ofthe introduced probes and by dynamically adjusting the monitoring intensity based on somesuitable policy.

Context-awareness and adaptation are key aspects of PLASTIC applications, meaning thatapplications can react to context changes, both anticipated and unanticipated, and adaptthemselves 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 parametersand 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 thevalidation of QoS properties, as actual quality can be measured. However, a failure is onlydetected 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/46

23

4 Service Deployment

An important milestone in the lifecycle of a service is deployment. Deployment in generalrefers to the process whereby a software system is made available to be referenced by othersoftware. 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 viewof the tester, in particular, publication is the step which makes the difference on whether theservice 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 asdefined by the service creator, and then the actual code deployment and management of theservice execution.

For resource provisioning and management, high-level service specifications shouldbe translated to low-level resource requirements. The relevant resources should then

be discovered within the targeted deployment domain. Some of these resources mayneed 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 hostingservice (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 correctexecution of the service. The service itself should also be managed through monitor-ing and adaptation operations.

4.1Related 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 anddeployment unit (JAR file) that contains the code, resources (i.e., images, libraries, etc.), anda 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.org5

http://www.bm.com/software/wireless/wsdd6 http://siemensvdo.com


24/46

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 dynamicavailability 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, connectionbetween bundles and requested services, idle state while waiting for unavailable services)and dynamic adaptation (monitoring of existing services through notifications by the serviceregistry, 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 isnot contained in the bundle. In such case, the bundle must declare explicitly (in themanifest 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 fromother bundles. A bundle installed in the platform can be activated once its deploymentdependencies 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 notguaranteed, 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 associatedservices 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 environmentused 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, whichare 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 differentnotations (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 fromsub-systems,

The lack of separation of concerns, with code related to application functionality beingmixed together with configuration/monitoring/management code, and rigid locationand 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/46

25

vice descriptions. Smartforg components collaborate to achieve some goal for which theymust be appropriately organized. The framework must therefore be able to correctly initializecomponents (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 pairsin 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 deploymenttime. 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 aSmartFrog 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), withadditional components providing discovery, reliability building blocks, JMX support,

Much of the experience on description, deployment and management gained with the designand development of the SmartFrog platform was reused in the design of CDDLM by theCDDLM-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 themon the Grid; and manage their deployment lifecycle (instantiate, initiate, start, stop). TheCDDLM 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 deploymentobject 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 deploymentAPI is the WSRF-based SOAP API for deploying applications to one or more target com-puters.

4.2Context-aware service deployment in MIDAS

The goal of the IST MIDAS is to make it feasible to develop and to rapidly deploy services onheterogeneous network infrastructures, possibly ad-hoc networks, which involve a largenumber 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. Differenttypes 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, atdifferent locations, with a mechanism to share information by inserting data in and re-trieving data from a virtual shared data space. To application programmers, theshared data space looks like a standard relational database.

8 http://www.ggf.org/


26/46

26

Context Engine Component (CTX): This component implements the MIDAS ContextSpace. 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: theidea 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 isnot covered in any of the other middleware components. The examples of CFN canbe 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 modelfor 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 deploymentcan be split into different phases including device detection, service discovery, download,installation, execution and discard. Components of the MIDAS middleware perform thesedifferent tasks, and incorporate each other in such a way that yields maximum performanceto the middleware.

The deployment component (DPL) will use both the Data Space component (MDS) and theContext Space component (CTX) to achieve its task. After the system administrator finishespreparing an application bundle, the bundle will be serialized into binary stream and stored inthe application repository managed by MDS. As MDS has a distributed nature, the availabilityof 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 conditionis fulfilled. DPL on the user node will register the condition defined by the administrator to theCTX. When context condition event occurs, DPL will retrieve the bundle from repository andlaunch the application.

4.3Service deployment in OPUCE

As stated earlier, the goal of the OPUCE platform is to put the end user in the centre of thewhole lifecycle of a service, to let them become at the same time the creator, the managerand 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 generatedservices, each one orchestrating a subset of telecom-oriented Base Services. Thus, effective

lifecycle management has to take place:


27/46

27

To allow users to decide when and how long their services must be available, i.e. thelifecycle 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 theorchestration of enablers residing on different platforms. This scalability should also avoidexecution hot spots in case specific services become successful.

In OPUCE, the Service Lifecycle Manager allows service creators to take control of someaspects of the deployment [55]. As such, there is no need for any human intervention fromthe operator either when triggering the service deployment process or during the deploymentitself 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 thoseBase 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 theOPUCE 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 users

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 eachtype of provisioning with the corresponding OPUCE architecture module.

Figure 7: Service provisioning and deployment in OPUCE


28/46

28

5 Service Discovery

B3G networking aims to enable users to access information and computational resourcesanytime and anywhere, where mobile users carry around tiny personal devices that integrateseamlessly in the existing infrastructure in both managed and ad hoc modes. Integrating theavailable hardware and software resources at any given time and place is highly complex, assuch environment is highly dynamic and open. Dynamic service discovery is thus especiallycritical due to the fact that B3G services and potential software clients (assuming the role ofservice 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 arenow well understood and go along with well-proven protocol implementations, a number ofchallenging issues remain, as outlined in Section 5.2. We then briefly describe in Section 5.3some solutions proposed by IST projects to address some of these issues.

5.1Related WorkDiscovery protocols enable components of a network to discover each other, express oppor-tunities for collaboration, and compose themselves into larger collections that cooperate tomeet an application need. SDPs can be classified [66] [77] as:

Pull-based protocols where clients send requests directly to service providers or to athird-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: centralizeddiscovery protocols where one or a few repositories store the descriptions of theavailable services in the network and distributed discovery protocols where clientsrely 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 descriptionsof the available services in the network. Registrations and requests may be either sent to oneor 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 implementthe 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). Othermethods like hash-based location exist where a hash function is used to transform a givenservice description into a numerical value. This value that can be computed independently bythe 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 theclients' requests. Examples of systems implementing hash-based discovery protocols includeFreenet [59], Tapestry [70], or Chord [68]. The main drawbacks of the hash-based approachoriginate 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 closedevices.

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 addressthese issues. In the case of Mobile Ad Hoc Networks (MANETs), the main drawbacks of the


29/46

29

centralized approach is that, as one device has to host the repository, service providers andclients need to dynamically discover its location and have to trust it. Furthermore, networkpartitioning/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 factflood the network to reach potential service providers. The flooding algorithm will however tryto limit/prevent the duplication of queries. When receiving such request, service providers willcompare the request with the service descriptions stored locally to decide if they can satisfythe 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], therequired support of multicast/broadcast communication by the underlying network, and thelimited range of the multicast/broadcast messages.

In the push-based approach, each device maintains a local repository of services found onthe network. A service provider pushes the service advertisements to the network, typically

by periodic unicast or multicast. As a result, each devices local registry will gradually collectservice advertisements of service providers. When a client submits a service query to thelocal registry, the local registry looks up the service advertisement entries for both the localand 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 broadcastinterval. If set too short, the network will be flooded with unnecessary advertisements. If settoo 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 centralizedand distributed modes of interaction (SLP, WS-Discovery).

5.2New challenges for service discovery

Although several protocols are now well-established for simple service discovery in specificenvironments, 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 witheach other as they employ incompatible formats and protocols for service descriptions ordiscovery requests, and also use incompatible data types or communication models. In anycase, the diverse environment constraints and the de-facto standard status of some of theexisting protocols make it unlikely for a new and unique SDP to emerge. Several projectshave thus investigated interoperability solutions [78] [61] [64], as requiring clients and serviceproviders to support multiple SDPs is not realistic. SDP interoperability is typically achievedusing 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 withthe number of supported protocols. Furthermore, the interoperability layer may be locatedclose to the network layer [79], and efficiently and transparently translate network messagesbetween 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/46

30

5.2.2 Context-aware SD

A major trend to handle the richness and heterogeneity of B3G environments is to rely oncontext 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 networkedservices 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 propertiesmay be achieved through the evaluation of context rules [82] or the maximization of a utilityfunction [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 clientsand service providers use the same terminology to identify the same contextual information.Such assumption is not realistic in B3G environments as, there, networked components aredesigned, 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 tothe 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 inparticular for semantic Web services such as OWL-S or SAWSDL. The SAWSDL annotatesWeb 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 asto annotate the communication aspects between services. Other efforts [85][86][87] startedto take care of some of the ambiguity in service descriptions arising from the openness ofB3G environments. EASY [88] provides efficient semantic service discovery, a key require-ment for the resource-limited devices found in pervasive environments, by encoding ontologyconcepts off-line and adequately classifying service descriptions in the repository based onthese encoded concepts.

5.2.4 Multi-networks SD

Network heterogeneity leads to many independent networks being available to users at alocation, which can be loosely interconnected with todays multi-radio mobile devices. Inno-vative solutions are then required for the efficient inter-network dissemination, filtering andselection of discovery requests and announcements [74]. Several projects have investigatedpeering (gateways) or application-level (P2P) routing combined with intelligent filtering toprovide efficient and scalable multi-networks service discovery. The mSLP [71] protocol im-

proves SLP efficiency and scalability by introducing mesh enhancements for the peering ofregistries as well as preference filters. INS/Twine [57] proposes a scalable P2P architecturewhere 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 hierarchicaland peer-to-peer architecture. MUSDAC [74] dynamically composes nearby networksthrough specific components providing application-level routing on multi-radio devices, whichenables 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 ofinformation to exchange and process.


31/46

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 contextualinformation [75], Many mechanisms have been proposed to secure the disclosure of serviceinformation, 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 orpersonal 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 tofavors interaction between nodes that will remain in network reach of each other for the dura-tion of the session [76].

5.3Service 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. PLASTICSD solution additionally deals with seamless mobility and scalability issues, and introducesenhanced service description and matching.

In a nutshell, a (logically) centralized manager, the Discovery Manager, coordinates servicediscovery 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-Discoveryand 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 PLASTICspecific format for interopera

Whitepaper 4 Lifecyclemgmnt Plastic Final

Documents

Transcript of Whitepaper 4 Lifecyclemgmnt Plastic Final