SOA, Fault, Failure, Composition
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?
Selecting services for compositions based on QoS Metrics
A forthcoming paper describes our work on tool support for composite services.
Jamie Hillman (j<dot>hillman<at>comp<dot>lancs<dot>ac<dot>uk)
|Page Maintainer: email@example.com||Credits||Project Members only||Last Modified: 10 August, 2005|