Chapter 11 SeCSE - Service Centric System ...

1 

Chapter 11   SeCSE ‐ Service Centric System Engineering: an overview  Massimiliano Di Penta, Leire Bastida, Alberto Sillitti, Luciano Baresi, Neil  Maiden, Matteo Melideo, Marcel Tilly, George Spanoudakis, Jesus  Gorroñogoitia Cruz, John Hutchinson, Gianluca Ripa   

1

Introduction 

  The service‐oriented paradigm is fostering a new breed of software system  development. Complex applications are seen as compositions of remote  services often owned by different organizations. This approach is one of  the pillars behind the NESSI vision of “the user, the individual, at the centre  of future developments for an inclusive knowledge‐based society for all”1, but  requires methods and tools for its full and seamless adoption.    The SeCSE project contributes to the definition of a sound service‐oriented  development discipline by means of some innovative solutions. Starting 

2 

from existing standards, research achievements, and stakeholders’  expectations, the project aims at:    1. Extending existing approaches to service specification to include  additional special‐purpose information, offering quality of service  (QoS), and dependability statements, and at supporting the use of  such specifications as for discovery and dynamic binding.   2. Developing linguistic mechanisms and methodological approaches  for the development of self‐adaptive service compositions where  non service‐based parts can be integrated seamlessly to create a  hybrid system. It also offers solutions for the validation, testing,  and run‐time monitoring of services and Service Centric Systems  (SCSs).   3. Verifying the SeCSE methods, tools and techniques against real‐ world problems and scenarios provided by the industrial partners.   

3 

This chapter provides a general overview of the main results of the project  based on the following motivating case study from the automotive and  telco domains:    A car maker wants to equip its top‐level models with an on‐board  device to allow drivers to interact with the remote services offered by  its portal. Among the other features, there is a service that allows  drivers to plan a trip according to their appointments. The service  uses a navigation system to get the geographical position of the car,  and automatically checks the driver’s agenda to understand if she/he  is on time for the scheduled appointments. If the driver is late, the  service automatically phones the secretary to change the schedule as  needed. Otherwise, all the appointments are confirmed. As soon as the  driver arrives at destination, the service provides the list of parking  lots close to the destination with some free spots.    The chapter is organized as follows. Section 2 sketches the SeCSE  development process. Section 3 introduces the different activities of the 

4 

methodology, while Section 4 describes the SeCSE integrated platform.  Section 5 surveys related approaches and Section 6 concludes the chapter.   

2

SeCSE Development Process  

  This section, starting from the scenario described in the previous section,  introduces the main elements of the SeCSE approach for conceiving  service‐centric applications. The concepts, artifacts, and activities are fully  defined in the SeCSE Conceptual Model (Colombo et al. 2005), while the  different steps of the process itself are presented in the SeCSE  Methodology.    The proposed scenario foresees the development of a composed service,  hereafter called DriveWorkAndPark, that fulfils the scenario described in  the previous section. We start with eliciting the requirements and, based  on these, discovering services that might, partially, address these  requirements. As a result of this phase the system integrator is provided  with:  

5 

  

A number of functional and non‐functional requirements: for  example, the fact that the call to the secretary has to pass through a  telecom network that depends on the preferences of the end users  (the driver), and the fact that the cost of the DriveWorkAndPark  service must be low and in any case not higher than 1,5 euros per  user session.  



A first set of potential services able to support parts of the  DriveWorkAndPark. In this specific case, these are services offering  parking places, supporting the execution of phone calls among third  parties and allowing users to access their agendas remotely. This set  of services is useful to check the feasibility of developing  DriveWorkAndPark. The system integrators in fact realizes that most  of the steps to be executed as part of DriveWorkAndPark can be  implemented by exploiting these services, and therefore as soon as  she/he move to the design phase, she/he can start understanding  how to integrate them. 

 

6 

As soon as the requirements are set, we can start the design phase to  define the workflow in charge of orchestrating the interactions with the  external services identified in the previous step (see Fig 11.1).    [Figure 11.1 Here]    The system integrator can also exploit Architecture‐based Service  Discovery to design composed services and discover that only a subset of  the parking services previously discovered share the same WSDL  interface. The integrator also discovers that no service for third party calls  is able to fulfill the interface foreseen by the workflow, where this service  is supposed to send an event to the workflow as soon as the phone call  between the service consumer and his/her secretary ends. Based on these  findings, the system integrator decides to develop some adapters for the  interactions with selected services, and to modify the structure of the  composition to comply with the interface of the actual third party call  service. In this phase, the system integrator can also negotiate some  Service Level Agreement (SLA) with the owner of some of the component 

7 

service in order to ensure that the requirement that has been set on the  cost of the service is actually fulfilled.     During design, the system integrator also identifies constraints on  modeled workflow. In the example, service DriveWorkAndPark only works  correctly if the agenda used by the service consumer is accessible via a  web service. When this does not apply, the service is not able to check the  conflicts and limits itself to providing information about the duration of  the trip and about the parking spots available at destination. After  finalizing the core part of the workflow, which is written in BPEL, the  system integrator focuses on the definition of monitoring and binding  constraints (in conjunction with runtime service discovery), which allow  the process to be configured with respect to usage context. As for service  DriveWorkAndPark, this means determining, for instance, the criteria for  selecting the telecommunication service for third party calls, and to be  able to react to faulty/unforeseen situations. When this happens, the faulty  service is added to a “black list” and it is not selected anymore (or until a  given timeout expires). 

8 

  As result of the design phase, the composed service (augmented BPEL  process) is ready for testing, deployment, publication, and execution. In  the testing phase the system integrator will check if the service fulfils the  functional and non‐functional requirements.    After deployment, a specification for the DriveWorkAndPark service is  defined and it is published in the SeCSE registry located at the car maker  site, and at this point the car maker can start integrating this service with  the on board device that is installed on its cars.     In the next section we describe in detail the main activities of the SeCSE  process.   

3

Main Activities 

  3.1  

Service Specification 

9 

Service specification refers here to the service’s capabilities as defined by  the service developer/provider. The provider describes and makes  available such services while the integrator/user can discover and use  them on the base of such a service specification. Different types of  specification are required to support specific SCS engineering processes.  The ability of a potential service consumer to exploit these processes,  therefore, is dependent upon appropriate service specifications that are  available.     There are a number of different specification mechanisms for advertising  services, such as UDDI, WSDL, and OWL‐S. Some focus on describing  different properties but there is much overlap, with many concentrating  on describing bindings and signatures. Motivated by the growing need for  service consumers to use semantics to distinguish between competing  services, the SeCSE approach is to provide support for the specification of  a range of service properties. Rather than inventing a new language, we  have developed a framework of partial specifications.   

10 

A SeCSE service specification is defined as a set of facets (Walkerdine  2007). Each facet describes one or more functional and non‐functional  service properties. Facets are essentially a way of packaging service  specifications, providing meta‐information that supports the management  and discovery of what information is available about a service. Within  SeCSE we have developed a number of facets that capture information  relating to a services general Description, Signature, Commercial  information (e.g. Service Level Agreement), QoS values, Test cases,  behavioral information, etc. Fig 11.2 shows a section of the QoS Facet  specification that was developed for the DriveWorkAndPark service.    [Figure 11.2 Here]    This service specification states an Availability > 96% for the service as a  whole, and a Mean Time to Complete for the parkRequest operation of