The WS-Agreement language defines the data types for expressing the content of an agreement. This language is defined independently from the WS-Agreement protocol and can therefore be used in a wide set of scenarios, for example with other protocol bindings. It is defined in the form of XML schema and describes the data types and the structure of the Agreement document, the Agreement Template document, and the Agreement Offer document. The WS-Agreement specification defines two separate schemata, the agreement schema and the agreement state schema. The agreement schema that defines the WS-Agreement core data types and the agreement state schema that includes the data types for the dynamic agreement monitoring, namely the agreement states, service term states and guarantee term states.
Figure above depicts the basic structure of an agreement. An agreement contains an agreement identifier, its name, an agreement context and a term compositor with a detailed description of the service to provide. The following sections give an overview of the most important language constructs of WS-Agreement.
The agreement context contains a set of meta data that is associated with an agreement. First of all, the context provides information on the parties that created the agreement. The context therefore contains two elements: Agreement Initiator and Agreement Responder. The content of these two elements is not further specified. They can contain an arbitrary, domain specific description of each party in order to resolve them to real world entities. Such a description can for example be an endpoint reference or a distinguished name that identifies the party in a security context. Additionally, the agreement context associates each party with its respective role in the agreement by specifying which party is the service provider and which is the service consumer. By that, the involved parties in the agreement are identified and bound to their roles. The agreement context may also contain an expiration time that defines how long an agreement (and an associated service) is valid. The context should also reference the template that was used to create the agreement. This is of particular importance for the agreement offer validation process. Besides that, the agreement context may contain any domain specific data.
In general, each term in WS-Agreement is identified by a term name. Service terms additionally contain a service name. The service name allows the semantically grouping of multiple service terms in an agreement. A single service in an agreement can therefore be described by multiple service terms. Each service term describes a different aspect of the service. Service terms can be distinguished into Service Description Terms, Service References, and Service Properties.
Service Description Terms give a functional description of the service to provide. Therefore, the service description terms contain a domain specific description of the service. This can comprise a complete or a partial description. Since the WS-Agreement is designed to be domain independent, the content of a service description term can be any valid XML document. Both parties involved in the agreement (agreement initiator and agreement responder) must understand the domain specific service description, e.g. the XML schema for the domain specific language must be known to both parties.
Service References provide a way to refer to existing services within an agreement. This can be useful when a certain service quality should be provided for an existing service rather than for a new one. Similar as in service description terms, service references can contain an arbitrary XML document that describes the service reference. Here the same rules and restrictions apply as for service description terms.
Service Properties are the last type of service terms. From an abstract point of view, they provide a way to define variables in the context of an agreement. A variable definition comprises a name, a metric, and a location. The location refers to a distinct element in the agreement, e.g. by using an XML query language such as XPath. Service Properties are used to define and evaluate guarantees in WS-Agreement.
Guarantee Terms are the second group of agreement terms. They provide the required capabilities to express service guarantees in agreements, define how guarantees are assessed and which compensation methods apply in case of meeting or violating the service guarantees. Guarantee terms consist of four elements: a Service Scope, a Qualifying Condition, a Service Level Objective and a Business Value List.
Service Scope specifies which services in the agreement are covered by the guarantee. Since a single agreement can comprise a set of different services, one guarantee may apply to one or more services.
Qualifying Condition specifies preconditions that must be fulfilled before a guarantee applies. Not all guarantees apply during the whole lifetime of an agreement. The qualifying condition specifies the preconditions that must be met before a guarantee is evaluated.
Service Level Objective (SLO) defines an objective that must be met in order to provide a service with a particular service level or with a particular quality of service (QoS). The QoS properties of a service are defined in the service description terms of an agreement. These are the agreed service properties. At the service provisioning time the actual QoS properties are derived from the service monitoring system. This service level objective essentially defines how the agreed QoS properties are related to the actual QoS properties. It defines a logical expression that can be assessed in order to determine the fulfillment of a guarantee.
Business Value List defines the penalties and rewards that are associated with a guarantee. WS-Agreement already defines a model to express business values for guarantees. These predefined business values range an abstract importance of a guarantee to arbitrary value expressions, such as Euro or US-Dollar.
Besides the definition of service and guarantee terms, the language provides a simple grammar to structure these terms in an agreement. WS-Agreement therefore defines an XML data structure that can easily be interpreted and that supports the composition of agreement terms in a flexible way. Different agreement terms are structured in an expression tree called Term Tree which contains a Term Compositor that represents a non-terminal of the WS-Agreement language. The language defines three types on term compositors: the All compositor, the OneOrMore compositor, and the ExactlyOne compositor. These term compositors correspond to the logical AND, OR, and XOR functions. A term compositor can contain zero or more other term compositors or agreement terms, but it must contain at least one element. A term compositor can also contain agreement terms, which are the terminals in the WS-Agreement language. Agreement terms are service description terms, service references, service properties and guarantee terms.