An Architecture for Negotiation and Enforcement of Resource Usage Policies Carlos Molina–Jimenez School of Computing Science Newcastle University, UK Carlos.Molina@ncl.ac.uk Santosh Shrivastava School of Computing Science Newcastle University, UK Santosh.Shrivastava@ncl.ac.uk Stuart Wheater Arjuna Technologies, UK Stuart.Wheater@arjuna.com Abstract—Advances in Cloud computing are making it possible for service providers to offer computational resources such as storage and compute power (infrastructure as a service, IaaS) to sophisticated enterprise application services (software as a service SaaS) to remote clients for a fee on a highly dynamic basis. As in any business transaction, client access to a service is regulated by a legal Service Agreement (SA). A service agreement needs to be negotiated and agreed between the provider and the client before the latter can use the service. Then on, both the client and the provider will need assurances that service interactions are in accordance with the SA, and any violations are detected and their causes identified. There is thus a need for automated support for negotiation and enforcement of service agreements. This paper discusses key design issues for such a system, of which the main one is to ensure that the policies (termed also clauses) contained in an SA are logically sound and that they work in harmony with any private policies of the client and the provider. The paper presents an architecture and a proof of concept implementation. Keywords-service oriented computing; service agreement negotiation, updating, termination and enforcement; policy consistency. I. I NTRODUCTION We consider a cloud computing environment that enables service providers to provision, in a rapid manner, on-demand network access to shared pool of compute resources (that can range from storage, compute power to applications and ser- vices) to consumers for a fee. As in any business transaction, consumer (client) access to a service will be underpinned by a contract, that we will refer to here as a Service Agreement (SA). A service agreement needs to be negotiated and agreed between the provider and the client before the latter can use the service. Then on, both the client and the provider will need assurances that service interactions are in accordance with the SA, and any violations are detected and their causes identified. There is thus a need for automated support for negotiation and enforcement of service agreements. Electronic representation of the relevant parts of an SA is a pre-requisite for any such automation. Here we are most interested in service description part of an SA that specifies resource usage in terms of service delivery (dealing with quality of service) and consumption (dealing with usage pattern). For example, the SA might stipulate that a client is permitted to submit 100 requests per second and that the provider is obliged to respond within three seconds. Ideally, it should be possible to encode an SA as a set of executable business policies that can be evaluated by either party for controlling service interactions. organizational boundary gateway gateway SA ’ + LP SA ’ + LP d) policy manager policy manager client service organizational boundary gateway SA LP gateway SA LP b) policy manager policy manager client service organizational boundary gateway LP gateway SA organizational boundary gateway LP c) policy manager policy manager policy manager client service gateway SA LP organizational boundary a) policy manager client service Figure 1. Deployment alternatives. Fig. 1–a) shows a simple scheme where the provider uses a Policy Manager (PM) module (loaded with an executable version of the SA) for controlling access to the service by the client. The gateway acts as a policy enforcement point that either allows or prohibits access to the service as directed by the PM which is in essence a policy decision point. For example, let us consider the following policies from a simple SA about a service provided on a pre-paid basis: 1) Clients can open an account by purchasing a single unit of prepaid time at the price of 10 euros. 2) A unit of prepaid time is considered consumed when the client consumes 100 minutes of connection time. 3) An open account can be topped up by the client by purchasing additional units of prepaid time. 4) Accounts with no prepaid time left will be declared closed by the service. a) The service is entitled to evict calls in progress that run out of prepaid time. Typically, a provider will have a set of local (private) business policies (LP) for customising an SA for different classes of clients. For example, the provider could be a bit