Service Level Agreements for Real-Time Service-Oriented Infrastructures

Introduction

In the context of service oriented architectures, a service is a mechanism to enable access to one or more capabilities, where the access is provided using a prescribed interface and is exercised consistent with constraints and policies as specified by the service description (OASIS).

An SLA is an agreement between the provider of the service and the consumer of the service that specifies the function performed by the service, the obligations on both the provider and consumer of the service, the agreed bounds of performance (Quality of Service, QoS) for the service, and how deviations are handled (exceptions and compensation). In this sense, an SLA is a contract between the participants in the service, which is typically the provider and the consumer of the service, but can also include mediators or other actors that are stakeholders in the service.

SLAs form part of wider frameworks used to describe, access, use and govern services (policies and contracts) for example as shown in Figure 1.

Figure 1.

OASIS SOA reference model for service description

An SLA is made in some business context, which may include decisions made by each party leading up to the agreement, the presence of an endorser for the agreement and simply some prior conditions that make the terms of the agreement acceptable to both sides. An SLA is typically established before deploying a service and covers the whole lifecycle including execution and monitoring through to decommissioning. However, it is also possible to form an SLA with an existing service, e.g. through a federation process orchestrated by an existing consumer that produces new interactions with other consumers. SLAs therefore have a huge influence on all aspects of the service, from as early as design time, to the infrastructure the service is deployed and executed on and the monitoring components that will be required for the provider to offer a service successfully in a cloud computing environment. While many aspects of context following the creation of an SLA can be shared or agreed (e.g. roots of trust, expected QoS, etc), some should not (e.g. no commercial service provider is likely to reveal their resource plan to a consumer).