We investigated Service Level Agreements (SLAs) as a mechanism for defining Virtual Grid (VG) requirements. However, this aspect of our research is not currently active, since the VG definition and implementation work took a different route.

SLAs are contracts between service providers and customers that define the services provided, the metrics associated with these services, acceptable and unacceptable service levels, liabilities on the part of the service provider and the customer, and actions to be taken in specific circumstances. They are the contractual component of Quality of Service (QoS) and are usually implemented as part of a larger Service Level Management (SLM) initiative. It’s clear that for a collaborative computing environment like the Grid, SLAs are of critical importance for both service providers and service consumers. The former group uses the SLA to plan effective delivery of services, while the latter needs to SLA to control costs .

The SLA itself must be of sufficient detail and scope for the service covered. Typical SLA sections include: a) services to be delivered, b) performance measuring, monitoring and reporting, c) problem management, d) compensation such as price and service delivered times, e) customer duties and responsibilities, f) warranties and remedies, g) security issues, h) intellectual property rights and confidential information, i) legal compliance and resolution of disputes, j) termination and k) signatures. Other sections may also be applicable. Obviously, it is a non-trivial work to set up a digital SLA.

Besides drawing up a SLA, measuring and monitoring the services,  reviewing periodically, conducting and monitoring service improvement, and amending the SLA are normally included to complete the life cycle of SLM. The figure below depicts a layered architecture of SLA-driven framework with the components required to implement SLM.

Co-Scheduler:  coordinative scheduler    Lo-Scheduler: local scheduler in compare to Co-scheduler SC-SP SLA: SLA between service provider and service consumer SP-DP SLA: SLA between service provider and device provider

To start the service delivery cycle, the first step is to implement the SLA. A consumer looks up a service catalog and proposes a draft first. Then the two parities negotiate, review the underpin contract, may renegotiate and finally settle down the agreement. The objectives for the service consumer are usually to finish the tasks as soon as possible in a reasonable cost. The targets of the service providers are usually maximizing the overall profit with limited resources. From the above, we can see that prediction of the service execution time and negotiation make up the core of setting up a digital SLA for this scenario. In a large scale distributed shared resources as Grids, maximizing the autonomy of SLA implementation is significant to make SLA execution practical.

We predict the service execution time with the parameterized performance models. For example, in deploying EMAN service, the models take input (bio-images in this case) scale and computing resources’ attributes. An automatic negotiation is a non-trivial task and will be the near future work.