FULL TITLE

Service Composition

KEYWORDS

SOA, Fault, Failure, Composition

SUMMARY

Non-trivial services often cross organisational boundaries and so must be constructed as composite services, with each organisation providing a service to carry out part of the task. Composition can also be more tightly coupled, where an operation within one application is carried out by composing several simple atomic services. In each case the task of constructing a dependable composite service is not a simple one. Many issues not present when dealing with a simple atomic service are introduced by composition, for example:

• Functional and non-functional compatibility of components to be composed.

Will the components you want to compose work together? How is it possible to tell?

• QoS implications of composition - How are the individual QoS characteristics of a set of services affected by composition?

Is it possible to infer the QoS characteristics of the composition by looking at the components within it?

• Control of a composite service

How is the composition controlled, is there a central point of control?

• Failures in composite services

What happens when a component within a composition fails? Who or what detects the failure and how can failures be avoided or tolerated?

• Hierarchical Composition

What is a simple service and what is an atomic service? Can a composite service be considered an atomic service within another composition?

Our work in the area of service composition, detailed below, considers a number of these issues:

Alternative architectures to support long running composite services

Services which carry out business processes and computationally intensive tasks can often run for hours, days, even weeks. The current dominant model of service construction, which is essentially a remote-procedure-call-based model, is designed for interactions that take seconds or minutes at the most. A growing number of developers and standards organisations are moving to an asynchronous and document oriented model for service construction, which shows great promise in particular for constructing composite long running services. The DIRC project has been studying architectures for long running composite services and constructing long running services using these architectures. The most promising of the architectures examined during this study, REST (representational state transfer) was used for a case study detailed below.

Restpedia, a case study in REST architecture

Restpedia is a travel booking service similar to Expedia, constructed according to the REST (representational state transfer) principles proposed by Roy Fielding in his thesis, and supported by a growing number of web services developers. Restpedia consists of hotel booking services, flight booking services, car rental services and aggregation services. Aggregator services provide an interface to each of the individual booking services which allows a complete holiday to be booked through one service, so it is a composite service. Our forthcoming paper on Restpedia details the benefits of the REST architecture for loosely coupled composite services and highlights some areas of weakness for future research.

Composite Service Cost Calculation

Services are often composed to carry out larger, more complex tasks. Modelling the cost of these composite services is troublesome as there is often no means of inferring the cost of the composite service from the cost of each of the services involved. We have developed a tool, CompCost, for modelling the cost structure of composite services. A visual representation of a composite service workflow is presented to the user, who then assigns cost functions to components and workflow operators and configures their behavior. The tool then provides best and worst case cost estimates for the composite service, based on the configuration the user has input.

Specifying composite service configuration preferences

The services that make up a composite service are often complex and configurable. Also, in many cases the order of invocation of the services in a composition may not be fixed. These two facts bring about a configuration problem. How should each of the components in a composition be configured, and how should they be ordered?
The configuration of one component may affect the necessary configuration of another component and so the order in which components are configured affects the performance of the composite service. Additionally, if a service invocation reserves or consumes resources, and the outcome of that invocation affects the execution of the remaining service invocations, the ordering of services in the composition could affect the success or failure of the service.
We have identified classes of concern in the composition of services and are developing a means of specifying the preferences of the composer in terms of these concerns. These preferences can then be used to order and configure the components in the composition as optimally as possible. The CompCost tool, described above, has been extended to allow it to be used to specify other service properties and to draw inferences based upon these properties.

LINKS

Selecting services for compositions based on QoS Metrics

PAPERS

A forthcoming paper describes our work on tool support for composite services.

Author

Jamie Hillman (j<dot>hillman<at>comp<dot>lancs<dot>ac<dot>uk)