WS-Agreement itself only supports a one round negotiation process: based on a template an offer is created, which then can be accepted by the consumer or can be rejected; when the consumer accepts the offer, the SLA will be created. In some scenarios a more flexible and dynamic negotiation specification and process is required. WS-Agreement Negotiation specification adds negotiation and re-negotiation capabilities on top of the WS-Agreement specification. It describes the basic concepts of SLA negotiation and re-negotiation and defines the relevant data structures, XML schemas and interfaces of the relevant components. For a complete reference of WS-Agreement Negotiation, refer to the WS-Negotiation specification.
The WS-Agreement Negotiation model consists of three layers with a clear separation between these layers: the negotiation layer, the agreement layer and the service layer. These layers are depicted in the Figure below.
The negotiation layer provides a protocol and a language to negotiate agreement offers and counter offers, and to create agreements based on negotiated offers. The negotiation process comprises the exchange of negotiation offers and counter offers. Negotiation offers, as defined in this specification, are non-binding by nature. They do not comprise any promise of the agreement responder that it will create an agreement based on a negotiated offer. They only indicate the willingness of the two negotiating parties to subsequently create an agreement. However, it is possible to define languages that can be used in conjunction with this specification in order to realize binding negotiation processes.
The agreement layer provides the basic functionality to create and monitor agreements. It comprises the port types defined in the WS-Agreement specification.
At the service layer the actual service defined by an agreement is provided. This service may or may not be a web service, and it may consist of multiple services. A resource provisioning service may for example comprise the provisioning of the specified resources and a monitoring service for the provided resources. The services on the service layer are governed by the agreement layer.
The negotiation service defines a service instance that is used by the negotiation participants to dynamically exchange information in order to reach a common understanding of a valid agreement offer. During the negotiation process the participants exchange negotiation offers in order to indicate their negotiation goals and requirements.
Negotiation Context defines the roles of the negotiation participators, their obligations, and the nature of the negotiation process such as negotiation of the new agreements or re-negotiation of the exisiting agreements. It optionally can specify additional domain specific negotiation parameters, such number of negotiation rounds or expiration time.
Negotiation Offer is a non-binding proposal for a potential agreement that one negotiation party makes to another. One or more negotiation offers made by one or more negotiating parties may precede a binding agreement offer as defined in the WS-Agreement specification. The offer describes the service for which an SLA is going to be negotiated and the associated quality of service in terms of guarantees. An offer that is created on the base of a previous offer is called counter offer. In general each offer in a negotiation process is a counter offer. In the context of this specification the term counter offer refers to the relationship of the originating offer and the offer that was created on the base of it.
The structure of a negotiation offer shown in the Figure below is basically the same as an Agreement Template. However, a negotiation offer contains the additional elements Negotiation Offer Context and Negotiation Constraints.
Negotiation Offer Context represents meta data associated with a specific negotiation offer. It contains information such as the id of the offer that was used to create this offer and the expiration time of the offer. It may also contain domain specific extensions in order to define augmented negotiation protocols.
Negotiation Constraints are a method to control a negotiation process. A negotiation participator uses negotiation constraints to define the structure or specific values that are applicable for counter offers that are based on a specific offer. Therefore, negotiation constraints are a means to express the requirements of a negotiating party. Negotiation Constraints are structurally identical to the Creation Constraints defined in an agreement template.
The negotiation offer state is used to describe a specific state in the life cycle of a negotiation offer. The negotiation offer state can include domain specific data that can be used by the negotiating parties to exchange information related to the offer life cycle, and advance the negotiation process in an efficient way. The Figure below illustrates the states that negotiated offers can have and the valid state transitions.
Since Negotiation Offers extend the wsag:AgreementType, new agreement offers can easily be created based on a negotiated offer. These agreement offers can be used to create new agreements on the agreement layer. Moreover, since negotiated agreement offers bear no obligations for either of the negotiating parties, the creation of agreements based on a negotiated offer is totally independent of the negotiation process. This means that the negotiation layer and the agreement layer are totally decoupled and there is no need for additional extensions or control mechanisms to create new agreements based on negotiated offers. Nevertheless, it is still possible to design augmented negotiation protocols that tightly couple to the negotiation layer and the agreement layer by using the provided extension points.
While this is also true for renegotiated agreements, additional information is required when a renegotiated agreement is created. This information is stored in a Renegotiation Extension document and is passed to the createAgreement (createPendingAgreement) method of an Agreement Factory (PendingAgreementFactory) as Critical Extension. The Renegotiation Extension document contains the endpoint reference of the original agreement that is renegotiated and possibly domain specific extensions. In case a renegotiated agreement is successfully created, the state of the original agreement(s) MUST change to Complete.