A Methodology for Dynamic Service Composition

Leire Bastida European Software Institute, Parque Tecnologico #204, 48170 Zamudio, Bizkaia, Spain

leire.bastida@esi.es

Abstract

Much work has been done in the area of Service-

centric Software Engineering and Service oriented Architectures (SOA). However, comprehensive guidance on how to compose dynamic and context-aware services in order to be able to self-adapt and self-configure at run-time is rarely given. This paper provides such guidance in the form of an ISO/IEC 24744-based methodology, which includes the work that is expected to be performed (by people and by machines), the products to be involved, and the agents that participate. By using this methodology, Service-centric Software Engineering approaches can come closer to delivering tangible results. 1. Introduction

The service oriented paradigm [1] is based on the assumption that services can be composed in order to obtain new, synthetic services by assembling existing ones. Sometimes, composite services are designed in a pre-determined manner, which results in rigid systems that are reliable but hard to reconfigure. This is often called static composition. As an alternative, dynamic composition [2] defines the specification that composite services must have, leaving the choice of the specific component services to the run time. The process of determining which specific services are used to realise a given specification is called binding.

Dynamic composition is especially useful when the behaviour of the services to be bound must depend on information taken from the execution context where the composite service is running. Variable information coming from the context is formalised and captured as variability points, which draws from the techniques often used in Product Line Software Engineering (PLE) [3].

In order to develop software systems that are based on services that are dynamically composed, a methodology is necessary. Without a methodology that

addresses the specific issues of dynamic composition, the inherent complexity of this area would we overlooked. This paper presents a methodology specifically designed to cater for Service-centric Systems that exhibit a high amount of dynamism, and which takes into account context information and variability. We have chosen the ISO/IEC 24744 [4] standard metamodel as a language in which to express the methodology.

This paper is structured as follows: Section 2 describes the methodology, listing the processes, work products and producers that comprise it. Section 3 introduces a case study describing how this methodology is used in a real-world scenario. In Section 4 the most relevant initiatives are compared with respect our approach. Section 5 presents some conclusions and future work. 2. Methodology Description

The purpose of the methodology presented here is not to define yet another novel software development methodology. Instead, this composition methodology highlights the important features and practices in the context of dynamic service compositions, leveraging on existing software methodologies and extend them incorporating the service composition specific activities.

The methodology is described using the ISO/IEC 24744 standard metamodel [4]. Consequently, the methodology is described as a collection of kinds of processes, work products and producers. Each process kind is described by a name, a purpose, and a collection of task kinds. Each task kind, in turn, is described by a name, a purpose and description, the actions it performs on the different kinds of work products (such as create, read or modify), and the agents (i.e. kinds of roles or tools) that are responsible for its performance. Separately, each work product kind is described by a name and a description. Finally, each producer kind is also described by a name and a

Seventh International Conference on Composition-Based Software Systems

0-7695-3091-5/08 $25.00 © 2008 IEEEDOI 10.1109/ICCBSS.2008.11

33

description. The rationale of this approach is further discussed in [5]. A detailed list of processes, work products, roles and other methodology elements can be found in [6].

2.1. Processes

This section describes the dynamic service composition methodology from the process viewpoint, focussing on what kinds of processes and tasks are expected to be performed when using the methodology.

The following figure shows the sequence of execution of these proposed processes.

Composition Realisation

Functional Specification

Design-Time Service Composition

Validation & Verification

Variation Point Management

Architectural Specification

Composition Realisation

Functional Specification

Design-Time Service Composition

Validation & Verification

Variation Point Management

Architectural Specification

Figure 1 - Processes of the Composition Methodology

We consider the Requirements Engineering as a

traditional and autonomous discipline so we have not included this process in the methodology; although it provides the requirements as an input to the methodology.

A service is usually made of a specification that defines its functionality, plus an appropriate implementation. So, in this paper, we refer to the service specification as abstract service, and to the service implementation as concrete service (see Figure 2).

SpecificationAbstract Service

SERVICE

ImplementationConcrete Service

SpecificationAbstract Service

SERVICE

ImplementationConcrete Service

Figure 2 – Structure of a Service

Architectural Specification Purpose: This process defines and maintains domain-wide or organisation-wide architecture models and assets with their correspondent benefit and drawbacks. This expertise is important to select and maintain a set of architectures that may be used in new projects to facilitate the architectural work and encourage reliability, flexibility and performance of the solutions.

In this process, architecture alternatives are also identified and assessed to fulfil system requirements. • Analyse feasibility of different architectural

options and patterns Purpose and description: Having at hand a set of strategic architectural options and patterns extracted from previous experiences, the next task is to identify the pros and cons of each alternative. This task is called feasibility analysis of the proposed architectural options and patterns, and it is carried out for each of the proposed alternatives. To enable an informed decision making, the analysis of the different patterns is performed in a quantitative manner. In this step one should also look at the identified architectural patterns to support the composition and describe the best moment to use each one. This information will be helpful to select appropriate patterns and architecture models depending on the problem to solve. Actions: Reads System Requirements and Enterprise Model Database; Creates Architectural Options and Patterns. Agents: Analyst (recommended), Architect (mandatory).

• Define architectural policies Purpose and description: Once proposed architectural options and patterns have been identified and analysed with respect to their benefits or disadvantages, this task defines a set of principles policies and architectural alternatives that will constraint the decision related to the architecture, design, implementation and deployment of the solution. Actions: Reads System Requirements and Architectural Options and Patterns; Creates Architectural Policies. Agents: Analyst (recommended), Architect (mandatory).

Functional Specification Purpose: This process defines how to specify what kind of sub-functionalities will be needed to cover the final functionality of the composition. These functionalities will be part of the composition and their specifications will be used to find those implementations which fulfil the requirements. All the specifications together will guarantee that the composition will meet the original requirements. This process defines the optimal abstract service descriptions aligned to the solution requirements and fulfils the needs of a strategic direction for architecture. • Identify abstract service description

Purpose and description: Taking into account both functional and non functional requirements, identify and describe what kind of sub-functionalities should

34

offer the composition in order to fulfil those requirements and provide the final functionality and Quality of Service (QoS) needed. These descriptions represent, in an abstract way, the services which will be part of the composition. Actions: Reads System Requirements; Creates Functional Specification Model. Agents: Analyst (mandatory), Business Process Modeller (recommended).

• Complete abstract service descriptions Purpose and description: To provide a complete description of each abstract service to be part of the composition. This task defines information related to the abstract service such as the purpose, a brief description, non functional requirements to be fulfilled and other desirable requirements (i.e. possible implementations or existing concrete services available in the market). Actions: Reads System Requirements; Modifies Functional Specification Model. Agents: Analyst (mandatory), Business Process Modeller (recommended).

• Decide upon service provisioning strategy Purpose and description: To provide guidelines on how the abstract services should be realised, considering whether to consume third-party services, building services in-house or wrapping legacy systems. Actions: Reads Architectural Policies; Modifies Functional Specification Model. Agents: Analyst (mandatory), Architect (recommended).

• Indicate possible service realisation candidates Purpose and description: Depending in previous experiences or organization policies, for each of abstract service, indicate which existing implementations map with those abstract descriptions identified in the previous tasks. Actions: Reads Architectural Policies and Architectural Options and Patterns; Modifies Functional Specification Model; Creates Requirements-Based Discovered Services Specification. Agents: Analyst (mandatory), Architect (recommended), Requirements-Based Service Discovery Tool (recommended).

Design-Time Service Composition Purpose: This process defines, at design time, an appropriate composition of the different sub-functionalities identified as abstract service description fulfilling both functional and non-functional requirements of the solution. It also analyses the best architecture for the composition workflow.

• Select the best architecture Purpose and description: To choose, between all the architecture options and patterns defined in the organisation, the architecture that matches better with the needs and requirements of the composition, from the business strategic point of view. The composition workflow will be designed using this architecture as the basis to define the skeleton of the composition. Actions Reads Architectural Policies and Architectural Options and Patterns; Creates Composition Specification Model. Agents: Architect (recommended), Business Process Modeller (mandatory).

• Define abstract composition workflow Purpose and description: To describe the workflow of the composition that performs the final goal by combining the defined abstract services. These sub-functionalities collaborate and cooperate in a basic workflow in order to fulfil the initial requirements of the composition. Actions: Reads Functional Specification Model; Modifies Composition Specification Model. Agents: Business Process Modeller (mandatory).

• Describe non-functional requirements Purpose and description: To complete the description of the composition workflow, with issues related to the managements of error handling, security or transactions. Actions: Reads System Requirements; Modifies Composition Specification Model. Agents: Business Process Modeller (mandatory).

Variation Point Management Purpose: At run-time, some parts of the composition might change. For this reason, the purpose of this process is to identify at design time which parts of the composition might change and define a set of requirements to perform this variability and maintain the coherence with the composition goal at run-time. • Analyse variation points of composition

Purpose and description: The whole composition must be analysed in order to get which parts of the workflow might change at run-time and identify those parts as variation points. The points to place variations depend on the architecture selected, the requirements and the abstract services descriptions identified previously. Actions: Reads System Requirements, Functional Specification Model and Composition Specification Model; Creates Variation Points Specification Model. Agents: Architect (optional), Business Process Modeller (mandatory).

35

• Describe variant requirements Purpose and description: For each variation point, define the associated variants or alternatives and also the criteria to be fulfilled in order to guarantee that the new composition is coherent and compatible with the initial requirements and goal. This will set the requirements to change the composition depending on the context or the circumstances. Actions: Reads Functional Specification Model and Composition Specification Model; Modifies Variation Points Specification Model. Agents: Business Process Modeller (mandatory).

Composition Realisation Purpose: In this process, candidate concrete services are selected as possible implementations to abstract service descriptions. These concrete services that can be discovered or developed depending on the existing services in the market and the system requirements, are mapped to the abstract service descriptions of composition. The goal is to obtain the final composition that fulfils the functionality and QoS expected from the solution during its execution. • Discover concrete services

Purpose and description: Having as inputs the abstract service descriptions and the composition requirements, search new candidate concrete services to fulfil all those functional and non functional requirements (defined operations, parameters and behaviour),. Actions: Reads System Requirements and Composition Specification Model; Creates Architecture-Time Discovered Services Specification. Agents: Architecture-Time Service Discovery Tool (mandatory), Business Process Modeller (mandatory).

• Set candidate concrete services Purpose and description: To choose, between all discovered concrete services, those which match better with the abstract services that define the composition and discard those which do not meet the composition requirements; and create a ranking of alternative concrete services for each specification. It is possible that the discovery mechanisms also provide a rating to indicate in which level those concrete services match with abstract descriptions. This would be very helpful to obtain the ranking and choose the best concrete services between the different candidates. It is important to be aware with limitations due to the usage of some services: it is possible that some requirements are not fulfilled fully. Actions: Reads Architecture-Time Discovered Services Specification, Functional Specification

Model and Composition Specification Model; Creates Composition Realisation Model. Agents: Business Process Modeller (mandatory).

• Update service composition specification (optional) Purpose and description: In case any concrete service is found to fulfil some abstract service description of the composition, there are two options: to develop an implementation in order to cover that sub-functionality; or to split that sub-functionality in smaller functionalities. The second option implies updating the composition specification model and searching new candidate concrete services. Actions: Reads Architecture-Time Discovered Services Specification, Functional Specification Model and Composition Realisation Model; Modifies Composition Specification Model. Agents: Business Process Modeller (mandatory).

• Map concrete services to abstract services Purpose and description: After defining the list of possible candidate concrete services, it is necessary to choose a concrete service from the associated list and define operations and parameters for interactions in more detail. It is possible to maintain that list of candidate concrete services associated to the specification in order to be used at run-time; for example, if the selected concrete service is not available, the engine could use the list to get and invoke another concrete service. Actions: Modifies Composition Realisation Model. Agents: Business Process Modeller (mandatory).

• Variation Point Realisation (optional) Purpose and description: This task defines the actions to be performed for each variant associated to the variation point identified previously. These actions could be to discover at run-time candidate concrete services or, using the list of candidate concrete services, to indicate which concrete services have to be bound to the composition and how they are going to fulfil requirements of the variation point. Actions: Reads Composition Specification Model and Variation Points Specification Model; Modifies Composition Realisation Model. Agents: Business Process Modeller (mandatory).

• Establish final QoS Purpose and description: As the concrete services’ QoS has been evaluated based on requirements before integrating those concrete services in the composition, this task is in charge of setting the final level of QoS and security that the overall composition can guarantee. To perform this task, the QoS level indicated for each concrete service

36

specification must be used to compute the final QoS that will be evaluated to verify that it fulfils the requirements of the composition. Actions: Reads Composition Specification Model; Modifies Composition Realisation Model. Agents: Business Process Modeller (mandatory).

• Generate final executable composition model Purpose and description: To create the executable composition model in order to do the composition ready to be executed by an execution engine. To perform this task, the final interfaces between services as well as transactions and security parameters should be determined. Actions: Reads Functional Specification Model, Composition Specification Model, and Composition Realisation Model; Creates Executable Composition Model. Agents: Business Process Modeller (mandatory), Programmer (mandatory).

• Generate final executable variable composition model (optional) Purpose and description: In case of having identified and specified some variability in the composition, it is required to create the executable variable composition model that will be associated to the composition model. The execution engine will use this variable composition model to manage the dynamicity of the composition at run-time. Actions: Reads Composition Realisation Model; Modifies Executable Composition Model; Creates Executable Variable Model. Agents: Business Process Modeller (mandatory), Programmer (mandatory).

Validation and Verification Purpose: This process assures that composition meets the required functionality and QoS. • Iterate workflow

Purpose and description: The composition workflow must be iterated to detect possible deadlocks in the composition. Actions: Modifies Executable Script, Service Deployment Architecture, Variable Execution Script and Variable Service Deployment Architecture. Agents: Business Process Modeller (optional), Programmer (recommended), Tester (mandatory).

• Check service integration Purpose and description: To perform integration testing (check the integrity of data in the communication between the different services of the composition) and conformance testing (check that all the services use valid standards for an optimum interoperability).

Actions: Modifies Executable Script, Service Deployment Architecture, Variable Execution Script and Variable Service Deployment Architecture. Agents: Business Process Modeller (optional), Programmer (recommended), Tester (mandatory).

• Check composition stability Purpose and description: To perform load testing (simulate the access of multiple users to each service, to check the response to high loading peaks and to find possible bottlenecks) and stability testing (check whether a service crashes by introducing malformed data as input. e.g. very long strings to check for buffer overflows). Actions: Modifies Executable Composition Model; Executable Variable Model and Composition Realisation Model. Agents: Business Process Modeller (optional), Programmer (recommended), Tester (mandatory).

• Perform system testing Purpose and description: To check that the same inputs always produce the same outputs. There can be a predefined test script linked to each service to make testing easier. Actions: Modifies Executable Composition Model; Executable Variable Model and Composition Realisation Model. Agents: Business Process Modeller (optional), Programmer (recommended), Tester (mandatory).

2.2. Work Products

This section describes the dynamic service

composition methodology from the product viewpoint, focusing on what kinds of work products are expected to be created and used when using the methodology. • Architectural Options and Patterns: List of patterns

and possible architectures available to use as a basis to define the skeleton of the service composition. It may include information about all the patterns like description, how and when to use them, feasibility analysis (including measures obtained from assessments), examples and so on.

• Architectural Policies: Defines a set of principles, goals, constraints and maxims that guide choices related to architecture, design, realisation and deployment. It includes best choices for the composition to develop as well as architecture evolution guides, so the composition can adapt to context changes.

• Architecture-Time (AT) Discovered Services Specification: List of available services, composed of the specification and the implementation, discovered when the composition design is being developed and using the abstract service descriptions as search criteria.

37

• Composition Specification Model: A model that describes how the composition will be done. The Composition Specification Model specifies the behaviour of a system, how the functionalities are choreographed or orchestrated, the composition workflow and also issues related to, transactions or security aspects. It is an abstract representation of the composition.

• Composition Realisation Model: A model that specifies how services interact to fulfil all the requirements. It contains information about the concrete services bound to the abstract services involved in the composition, as well as how those services cover the final composition functionality. It also includes the QoS level offered by the composition. This model could also include information about the actions associated to the different variation points of the composition specified in the Variation Point Specification Model.

• Enterprise Model Database: A database or repository that collects the expertise of the organisation in domain-wide or organisation-wide architecture models and assets with their correspondent benefit and drawbacks. This repository is very useful for future projects to facilitate the architectural work and encourage reliability, flexibility and performance of the solutions. This work product is of external origin, meaning no task kind in the methodology creates it. Although the existence of this Enterprise Model Database will provide a significant benefit for the development of service composition, it is an optional work product that depends on the organisation.

• Executable Composition Model: An executable model or script written in a concrete implementation language for composition (e.g. WS-BPEL [7]) that includes all issues designed in the Composition Specification Model.

• Executable Variable Model: An executable model or script written in a concrete executable format, for example Event-Condition-Action (ECA) rules, that defines all the variation points identified in the composition. These rules allow to the execution engine to introduce dynamicity in the composition execution.

• Functional Specification Model: A model that describes the different sub-.functionalities of the composition specifying as abstract services. Each abstract service includes the purpose, the description, non functional requirements and other desirable requirements and issues.

• Requirements-Based (RB) Discovered Services Specification: List of available services, composed of the specification and the implementation,

previously discovered using as criteria a set of requirements or suggestions defined by the customer.

• System Requirements: Enumeration of all functionality expected from the system at different levels of definition, interactions with end users, entities of the system, interfaces with other systems and non-functional requirements. It may include also information about the business model and possible scenarios to cover by the system to be developed. This work product is of external origin, meaning no task kind in the methodology creates it. It is supposed to be supplied to the organisation from the outside.

• Variation Points Specification Model: A model that identifies and describes the variation points and the associated variants identified in the composition.

2.3. Producers

This section describes the dynamic service

composition methodology from the people viewpoint, focusing on what kinds of producers are expected to take part in the usage of the methodology.

Some producers represent roles that people may play, whereas others represent tools that provide important inputs required by some processes of the methodology. • Analyst: This role is mainly involved in the

processes related to the requirements of the customers. It is mainly involved at the beginning of the development, because it gathers and analyzes the requirements which the composition has to fulfil.

• Architect: This role is involved in the development of architectural patterns and models, and is the responsible of starting the design of the architecture of the system, with its services descriptions and their interfaces. It is also the adequate role to select the architectural patterns to use for the composition.

• Architecture-Time (AT) Service Discovery Tool: This tool allows discovering at design time available services using as search criteria a specification.

• Business Process Modeller: This role is involved in the design of the workflow and all the issues around it like security, transactions or exception handling. It is also the role in charge of selecting the services that better fulfil the requirements and calculating the QoS that the service can guarantee.

• Programmer: This role is involved in the implementation of the business process, obtaining services needed to be part of the composition and developing the final script to can be executed by an execution engine.

38

• Requirement-Based (RB) Service Discovery Tool: This tool allows discovering at design time available services using as search criteria a specification or specific requirements defined in the composition.

• Tester: This role is involved in the processes where testing and validation are performed.

3. Case Study

This section illustrates the applicability of the composition methodology in a real scenario where a group of actors take advantage of some advanced automotive-telecommunication services. This case study has been extracted from the scenarios [8] defined by the industrial partners (Centro Ricerche Fiat, Telecom Italia Lab, Telefónica I+D, Daimler Chrysler, Atos Origin) in the context of the SeCSE project [9], and describes a short story in which both the automotive and telecommunication aspects are mixed together with the objective to build powerful services. 3.1. Scenario Description

XService team is a company in charge of developing and maintaining advanced services for car drivers that can be subscribed and used by means of a special onboard device included in some brand cars. After analyzing the market, there is a potential exploitable opportunity on professional staff, such as delivery staff or company managers, who need to plan and manage their trips and appointments in an easy way. So, XService team plans to develop a new in-car service that allows the car owners to remotely manage their trips, guaranteeing that new trips will not overlap already existing appointments and if such overlap happens this could be resolved with a call to a car owner’s choice number in order to try to arrange a new appointment. This new service is called XTrip.

As a first task to develop the new functionality called XTrip, the XService business analyst models the system requirements identifying and describing use cases, actors, relationships and non-functional. The description of the XTrip is the following one: first, the XTrip service calculates the route between two places indicated by the user or between the current car position (given by the GPS system) and the destination address indicated by the user. With this information and using an external Geographical Information System (GIS), the XTrip service estimates the route and time needed to arrive to the destination. If there are different alternatives, XTrip considers the fastest alternative as the best one. Then, the XTrip service has to consult the user agenda. The user must indicate the time when the trip is planned to begin so that the XTrip

service is able to determine if there are conflicts with existing appointments. In the case that there are one or various routes without conflicts, the XTrip service includes the trip/s in the user agenda, showing that the driver will be busy during the trip time. If there is an overlap and there is no alternative to solve it, XTrip calls a phone number pre-defined by the user to solve the problem. XService team supposes that the user is able to postpone or cancel an appointment. The selection of the service to perform this call depends on the telecom provider that offers the best rate to connect the two endpoints and also the best performance.

After this analysis, the XService team uses the composition methodology to develop the XTrip service from scratch, adding dynamicity to the workflow through the design and implementation of variation points.

3.2. Application of Composition Methodology

With the help of a good system requirements analysis and all the previous expertise of the organization about complete projects, the XService system engineers (Architectural Specification process) define the architectural policies and identify the best architectures that fit into the composition. Several patterns that fit well with the requirements are usable, so after a deeper analysis the XService team decides that, probably, the best one would be the so called “hub and spoke” approach.

To define the Functional Specification, the XService team identifies three main abstract services from the system requirements. The first one calculates the route between two places, the second one is in charge of managing the agenda and the third one performs a phone call. These abstract services are called ‘Calculate Route’, ‘Manage Agenda’ and ‘Perform Phone Call’, respectively. There abstract services are explained in detail in the Functional Specification Model.

The organisation’s service provisioning strategy will be to consume services provided by third parties, but in some cases, XService team will have to build and develop all the needed functionalities.

After this, the XService team starts the process of Design-Time Service Composition where the workflow of the composition is defined and refined and non functional issues like transactions, security and error handling are also described. All this information is described in the Composition Specification Model which specifies the behaviour of the composition.

While describing the workflow of the composition (see Figure 3), XService team realise that the phone call can be made by more than one service, as each

39

telephone company provides a service that make the phone calls cheaper if the destination phone number belongs to the same company, so they decide that a variation point should be described to always select the cheaper alternative (Variation Point Management process).

Trip time calculationTrip time

calculation

Check ScheduleCheck Schedule

Conflicts ?Conflicts ?

Set appointment

Set appointment

Perform phone call

Perform phone call

NO YES

Trip time calculationTrip time

calculation

Check ScheduleCheck Schedule

Conflicts ?Conflicts ?

Set appointment

Set appointment

Perform phone call

Perform phone call

NO YES

Trip time calculationTrip time

calculation

Check ScheduleCheck Schedule

Conflicts ?Conflicts ?

Set appointment

Set appointment

Perform phone call

Perform phone call

NO YES

Trip time calculationCalculate

route

Check ScheduleManage Agenda

Conflicts ?Conflicts ?

Perform phone call

Perform phone call

NO YES

Trip time calculationTrip time

calculation

Check ScheduleCheck Schedule

Conflicts ?Conflicts ?

Set appointment

Set appointment

Perform phone call

Perform phone call

NO YES

Trip time calculationTrip time

calculation

Check ScheduleCheck Schedule

Conflicts ?Conflicts ?

Set appointment

Set appointment

Perform phone call

Perform phone call

NO YES

Trip time calculationTrip time

calculation

Check ScheduleCheck Schedule

Conflicts ?Conflicts ?

Set appointment

Set appointment

Perform phone call

Perform phone call

NO YES

Trip time calculationCalculate

route

Check ScheduleManage Agenda

Conflicts ?Conflicts ?

Perform phone call

Perform phone call

NO YES

Figure 3 – Abstract view of the XTrip composed service

In this point, the XService engineers realise that

they need a service to calculate the route between two places, another service to control the agenda, and another one to perform phone calls. So they use some discovery mechanisms to look for services that would fulfil the abstract service descriptions, obtaining the list of candidate concrete services to be used. With those candidate service descriptions in hand, XService team selects the concrete services that best match the composition necessities, being the XNavigation (to calculate the route), and XAgenda (to control the agenda) from the associated list and define operations and parameters for interactions in more detail.

As the phone call abstract service has been identified as a variation point, it is necessary to define the associated actions.

By default, the phone call abstract service will be bound to kTPCC service, which offers the best rate to perform calls to Italian endpoints. However, if the target number is prefixed with an international dial code, then the composition dynamically selects and binds to the most suitable telecom provider call service. The Figure 4 shows this composition realization.

Trip time calculationTrip time

calculation

Check ScheduleCheck Schedule

Conflicts ?Conflicts ?

Set Set Perform phone call

Perform phone call

NO YES

Trip time calculation

XNavigation

Check ScheduleXAgenda

Conflicts ?Conflicts ?

Perform phone callVariation

Point

NO YES

<rule name="Perform Phone Call Rule"><scope>

<activity>Perform Phone Call

</activity> </scope><event>

<name>variabilityEvent</name> </event><condition>

!(variabilityEvent.getInputVariableValue("Company").equals("A"))

</condition><action description="dynamically select

and bind to a new telecom service depending on the company">…

</action></rule>

Rule

Trip time calculationTrip time

calculation

Check ScheduleCheck Schedule

Conflicts ?Conflicts ?

Set Set Perform phone call

Perform phone call

NO YES

Trip time calculation

XNavigation

Check ScheduleXAgenda

Conflicts ?Conflicts ?

Perform phone callVariation

Point

NO YES

<rule name="Perform Phone Call Rule"><scope>

<activity>Perform Phone Call

</activity> </scope><event>

<name>variabilityEvent</name> </event><condition>

!(variabilityEvent.getInputVariableValue("Company").equals("A"))

</condition><action description="dynamically select

and bind to a new telecom service depending on the company">…

</action></rule>

Rule

Figure 4 – Realization of the XTrip composed service

The final information about all the services

involved in the composition as well as how they cover the functionality required and possible alternatives are described in the Composition Realisation Model.

Once the design is finished, the composition is translated into an executable model. At last, an intensive Validation and Verification process is performed to assure the functionality and QoS of the composition.

4. Related Work

Service composition is a very active area of

research and development. In this section, we focus on research initiatives that are closely related to our work. Examples are eFlow [10], Meteor-S [11], Self-Serv [12, 13] and MAIS [14].

In eFlow a service integrator describes a composite service as a process schema that composes other basic or composite services, but it requires a proprietary composition language to specify that process model.

Meteor-S is a proposal to create a framework for semi-automated configuration of Web processes by enabling the dynamic selection of services and supporting reconfiguration in case of service invocation errors. However, Meteor-S requires attaching a semantic description to each candidate service, while our approach does not require a complete description for services; it can work with a lightweight description that contains, at least, the service location.

In Self-Serv, services are declaratively composed and the resulting composite services are executed in a peer-to-peer and dynamic environment. This initiative exploits the concept of service community in order to

40

address the run-time reconfiguration of the composition process. The same approach is adopted in MAIS initiative, in which the concept is called abstract service.

However, while both Self-Serv and MAIS depend on pre-defined attributes to reconfigure the process, our approach also enables the user inputs through the usage of variability rules.

Our approach aims to offer a solution to define dynamic and context-aware service compositions. The application of the PLE approach to define the variability of dynamic compositions enables the development of context-aware (i.e. the composition can use contextual information of the execution environment), self-configuring and self-optimizing compositions (i.e. when a service does not behave as expected, it can be replaced by other service).

Summarizing, our approach aims to offer a solution to define dynamic and context-aware service compositions. The application of the PLE approach to define the variability of dynamic compositions enables the development of context-aware (i.e. the composition can use contextual information of the execution environment), self-configuring and self-optimizing compositions (i.e. when a service does not behave as expected, it can be replaced by other service).

5. Conclusions and Future Work

In this paper we have described a methodology specifically designed for Service-centric Systems that expressly supports dynamic service composition and context information in the form of variability points. The methodology has been described using the ISO/IEC 24744 standard metamodel, which results in a highly modular specification of kinds of processes, tasks, work products, roles and the interactions among them. Because of this, alterations or extensions to the methodology are considered to be relatively easy. For example, adding a new task kind or changing the way in which a task kind acts upon a particular work product kind should be straightforward.

As part of future work, the methodology will be “fragmented out” according to the structure given by the underlying metamodel (i.e. ISO/IEC 24744) and integrated into a repository (such as [15]) so that its method components can be mixed and matched with components from others sources.

We have also evaluated the methodology in the automotive and telecommunications domain with excellent results. Some recommendations have been obtained to improve the overall approach. For example, we have learned that having a tool set to support the

application of the methodology would add great value. Also, the ability to change variability options at run-time has also been suggested. These issues will be approached in the future.

More future work to be done in the research of dynamic service compositions includes the definition and implementation of the re-planning approach, allowing a composition to change parts or one service with a small sub-composition of services to obtain the same functionality.

Another open research line is the development of the approach for on-the-fly compositions, which would allow a system to create simple service compositions automatically as user needs request them.

6. Acknowledgements

This work is being carried out in the context of the

SeCSE (Service Centric Systems Engineering) Project [9], which aims to support the cost-effective development and use of dependable services and service-centric application. We thank all SeCSE partners for their helpful suggestions and proposals in order to improve our work.

7. References [1] Papazoglou M.P., Traverso P., Dustdar S., Leymann F., Krämer B.J.: Service-Oriented Computing Roadmap, Proceedings in Service Oriented Computing (SOC), (April 2006). [2] Yang J. and Papazoglou M.P.: Service Components for Managing the Life-Cycle of Service Compositions, Information Systems, vol. 28, no. 1, (2004). [3] Butler J.: Applying Product Line Techniques to SOA, CBDI Journal, (February 2006). [4] ISO/IEC 24744. Software Engineering - Metamodel for Development Methodologies (2007) [5] Henderson-Sellers, B. and Gonzalez-Perez, C. The Rationale of Powertype-Based Metamodelling. In Second Asia-Pacific Conference on Conceptual Modelling. (30 January - 4 February 2005). Australian Computer Science Communications vol. 7, n. 6, pp 7-16. [6] SeCSE: Report on methodological approach to designing service compositions v2, (2006). [7] OASIS: Web Services Business Process Execution Language (WS-BPEL) v2.0, OASIS Standard, (January 2007). [8] SeCSE: Mixed scenario for demonstration deliverable (2006). [9] SeCSE, (2004-2008) Service Centric System Engineering: http://secse.eng.it/. [10] Casati F.: “Dynamic and adaptive composition of e-services”, Information Systems, vol. 26, no. 3, pp. 143-163, May 2001.

41

[11] Verma, K.; Gomadam, K.; Sheth, A. P.; Miller, J. A.; Wu, Z.: "The METEOR-S Approach for Configuring and Executing Dynamic Web Processes", Technical Report, June 2005. [12] Benatallah, B.; Sheng, Q.; Dumas, M.: “The Self-Serv Environment for Web Services Composition”. IEEE Internet Computing, pp. 40-48, Jan-Feb 2003. [13] Benatallah, B.; Dumas, M.; Sheng, Q.: “Facilitating the Rapid Development and Scalable Orchestration of Composite Web Services”, Distributed and Parallel Databases, 17(1): pp. 5-37, Jan. 2005.

[14] Ardagna, D.; Pernici, B.: "Global and Local QoS Constraints Guarantee in Web Service Selection," pp. 805-806, IEEE International Conference on Web Services (ICWS'05), 2005. [15] OPFRO: OPEN Process Framework Repository Organization, http://www.opfro.org (2007).

42