The AssessGrid Negotiation Manager was started shortly before the BEinGrid SLA negotiation component. Then both projects had a mutual influence, and as a result the design of the AssessGrid Negotiation Manager is identical to the one presented in BEinGrid. You may want to refer to the BEinGrid SLA Negotiation Design Pattern. The Negotiation Manager source tree has the following top-level structure:

• ag_provider_client/ - An AssessGrid specific WS-Agreement client 
•  ag_provider_common/ - AssessGrid specific common content that is shared between client and service 
• ag_provider_service/ - AssessGrid specific negotiation service (extends wsag_service/)
• wsag_common/ - WS-Agreement parts that are shared with the generic service (wsag_service/) and the domain specific implementation 
• wsag_service/ - generic WS-Agreement implementation

The different users : An end-user is a participant from a broad public approaching the Grid in order to perform a specific task which comprises of one or more services. The user must indicate the task and associated requirements formally within an SLA template. Based on this information, the end-user wishes to negotiate access with providers offering these services, in order that the task is completed. The end-user must make informed, risk-aware decisions on the offers it receives so that the decision is acceptable and balances cost, time and risk. A further role within the end-user layer is that of the customer. A customer is responsible for agreeing payment and long term contractual agreements to govern usage of Grid resources and services (e.g. brokers). Typically, a customer has a number of end-users, belonging to the same legal entity and is consequently responsible for providing the end-user interface through which end-users access the system. A provider offers access to resources and services through formal SLA offers specifying risk, price and penalty. Providers need well-balanced infrastructures, so they can maximise the Quality of Service and minimise the number of SLA violations. Such an approach increases the economic benefit and motivation of end-users to outsource their IT tasks. A prerequisite to this is the trustworthiness of the provider and their ability to deliver an agreed SLA offer. Assessments of risk allow the provider to selectively choose which SLA requests are responded to with offers. This approach ensures that offers are not made which are contrary to a provider’s policy and allows the provider to build a reputation for reliable QoS provision.

 Scenario 1 - Direct SLA negotiation with a Provider :

In this simplest scenario, an end-user negotiates an SLA directly with a known resource provider. No third-party is involved in this negotiation. The contract is defined through an SLA between the provider and the end-user. The following sequence diagrams shows: 

1. The user requests the templates (service description) of the provider

2. The user receives the templates

3. The user creates a quote request based on the initial templates

4. The user sends the quote request to the provider

 5. The provider analyses the request of the user, and depending on resource availability, creates quotes representing (possibly several) service offers

6. The user receives the quote

7. a. If the user is not satisfied with the offer, the user changes his quote request, and sends it again to the provider (step 4)

7. b. If the user is satisfied with one of the offers, the user signs this offer, and sends this back as an agreement request.

8. a. The provider can no longer fulfill the offer, and rejects the agreement. The user can ask for a new offer.

8. b. The provider is happy with the agreement requests, and signs it too, making it an SLA shared between both parties.

Scenario 2 - Broker as intermediary

In this scenario, three participants appear. It is a variation of the first scenario. The End-user relies on the broker to contact several providers, in order to have a broader range of offers. This can be imagined as a marketplace, where the broker acts as a place to exchange (possibly as a paying service). In this scenario, the offer is presented by the broker, who contacts the providers on behalf of the user. The user specified his needs in a quote request, forwarded by the broker to the providers. The user is presented the different provider's offers. The contract can then be signed between the user and the selected provider. The broker should not appear in the final SLA, as his role is not in the execution of the contract, but only in its creation.

Scenario 3 - Meta-provider

In this scenario, workflows are contemplated. The user's service request is a workflow of tasks (which can be seen as unitarian). The Meta-provider's role is to find adequate providers which can fulfill the tasks. The Meta-provider presents the whole workflow as a unique SLA between the user and the broker. The tasks are also represented by SLAs, but between the Meta-provider and the provider. The Meta-provider is taking an important responsability, to the point of acting in delegation of the user. In this scenario, the Meta-provider is entrusted with the user's delegated credentials.