SLA Template

This Common Capability relates to the creation and definition of SLA Templates, which will be published by a provider. SLA Templates are the key component of SLA Negotiation and of Service Provider discovery, as templates are the tools that support the advertisement of services to the outside world and negotiation always begins with a client requesting an SLA Template from a provider.

It goes without saying that, regarding SLA Templates in total, they should be easy to understand on their own without losing expressiveness. This not only enables any client to easy comprehend what exactly is specified in the template but it also facilitates the creation of SLA Templates from the provider side. It needs to be taken into account that there may be service providers which are not in experienced in the creation of SLA Templates. Therefore the creation, from a service providers point of view, should be as intuitive as possible without giving up the expressiveness deemed necessary. Although it can be tempting to tailor the SLA Templates to suit customer needs, it is important to regard the service providers needs as the more important ones; in conflicting cases, the service providers needs should have preference over the service customers needs. In general it is necessary to provide support-tools that help to create templates. Without that, usage of SLA (Templates) in business will not really find uptake.

There already exists a certain number of standards on top of which an SLA Template can be built, like WSLA and WS-Agreement, and as much components as possible should be based on these standards, However, what has been learnt in other IST projects, like NextGRID, is that the standards dont necessarily deliver expressiveness that is domain-specific enough for providers. Another example is GRIA, which has a full fledged SLA framework, based on internal specifications. Business experiments need to carefully select terms which need to be provided. Figure 3 shows the structure of an agreement in WS-Agreement. In WS-Agreement, the name is an optional component. The context contains meta-data for the entire agreement, including provider and customer details and the agreements lifetime. The third section contains the terms and therefore specifies the agreement itself.

This structure has been proven to be sufficient for business needs, e.g. in NextGrid, but certainly the terms will have to be enriched and adapted to the domain-specific necessities needed by the various business experiments. Careful selection of additional terms needs to be done to keep the structure of SLA Templates concise.

Furthermore it has been noted in NextGRID that it is of utmost importance to provide a schema for SLA Templates, which describes how these templates are to be built, as early as possible and to adhere to this schema. This does not prohibit necessary changes which can become obvious only at a later time, but a general agreement on the schema should be reached quickly because it enables the providers to be sure that templates that have been worked out do not need to be revoked and revised constantly.

The SLA Template Common Capability would provide not only the SLA schema but also an SLA Editing Framework, which supports service providers in the creation of SLA Templates. SLA Template creation is by no means a trivial task and service providers without previous experience need assistance in specifying SLA Templates for the services they provide, so it is not enough to only provide the definition of what the template may contain. Additionally, it seems reasonable to provide components which ease the burden of creating an SLA Template. This may be, on the one hand, a step-by-step tutorial which guides the creation of SLA Templates, on the other hand tools which provide a simple interface for the creation of framework SLA Templates which can then be refined by the provider.

One last aspect with respect to SLA Templates is to identify legal issues that could automatically define (or except) terms and terminologies. The usage of SLA Templates and SLAs should always to be in-line with legal aspects; this is critical to be usable in the business domain.