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 compatability 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 compoosition 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?
• Hierchical Composition - What a simple service and what is an atomic service? Can a composite service be considered an atomic service within another composition?

Selecting services for compositions based on QoS Metrics

Our work using Agrajag (introduced in more detail here) investigates the possibility of inferring the likely QoS attributes of a composite service by looking at the QoS attributes of the components that make up the composition and how they are composed. For more details please see our publications here

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 an RPC-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 DSCC project has been studying architectures for long running composite services and constructing long running services using these architectures. Our work in this area can be found on the publications page.

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.

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.

The DSCC project has identified classes of concern in the composition of services and is 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.