The main subcomponents of the SLA Negotiator component are the following:

• SLAM Service Interface(s)

This subcomponent is the interface to the SLA Management Framework, or in this case to parts of it. As described previously, WS-Agreements are service per definition. Therefore, this subcomponent is exactly, what is described in the specification. WS-Agreement defines not only interfaces, which have to be implemented by service providers, but also for service customers, namely for facilitate the asynchronous creation of (pending) agreements by call-back.

• Negotiation Manager(s)

These two components, on customer’s side and provider’s side, are the central point for all negotiation related tasks. The main purpose of the negotiation Manager is to choose an appropriate Negotiation Strategy. In general, negotiation strategies will be domain-specific (and probably be considered confidential) and will not be shipped with a negotiation framework. The Negotiation Manager provides a configurable plug-in mechanism for manually setting any domain-specific negotiation strategy (a simplistic AlwaysAgree example is provided in the source).

• SLA Template & Signed SLA Registries

In these components, SLA Templates and SLA are stored. From a functional point of view, templates will be published by a provider-side template registry. However, the publication of templates is covered by WS-Agreement and defined as part of the agreement layer (specifically through the SLAM Service Interface).

Negotiating SLAs requires some obvious steps to be taken. The WS-Agreement protocol does not define them explicitly, but by having chosen a certain set of functionalities, it gives a guideline on how SLAs will be negotiated.

Summarized briefly, one could assume the following procedure takes place. A service provider has decided to sell his resources by negotiating contracts. He has chosen WS-Agreement as appropriate specification for defining all required things for him plus taking the usual advantage of a specification that is well known. The provider uses the language defined by the schema for SLA template to create a new template, describing his resources and – more important – their prices. This is done by using the metrics section of an SLA. Be aware, this is a template and not a valid SLA already! However, he publishes the template by using a registry of his choice. Now it’s the consumers turn. Following thoughts of SOAs, the consumer is now able to find this template – and of course not only this specific template but more than one. He now has to decide, which template fits his requirements or constraint for services best. In general, he is allowed to change the template according to his requirements. After he has chosen and probably adapted a template, he uses the described information to contact the provider by sending him an offer. Once a provider receives an offer, he normally will check certain constraints, for example “Is this a known customer?” or “Is he using my templates?” If all these constraints are met, he has to decide, whether he is willing to provide the service in its described quality. If accepting the offer – and this is WS-Agreement specific – a new WS-Resource (WS-RF) is created and an EPR is send back to the consumer. The SLA is legally valid and binding from this point of time.

A generalized version of the WS-Agreement Negotiation Protocol is shown in Figure #2. Agreement templates are published by the provider itself, without using an external registry. Figure #2 does not comply with the WS-Agreement terminology for service methods and is intended for comprehension purposes only.

Three, more detailed and domain specific usage scenarios - Job Submission, Advance Reservation or Pre-Establishment of Resource Preferences, Service Parameterization - are given in the WS-Agreement specification (p. 9-11, 50-81).