An architecture for negotiation and enforcement of resource usage policies

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.

Implementation of Smart Contracts Using Hybrid Architectures with On and Off–Blockchain Components

“…Alternatively, we can place them in a parallel-pipe relationship where an off-blockchain smart contract is deployed by one of the contractual parties to mirror the work of the on-blockchain smart contract, say to double-check its outputs. Other deployment alternatives are discussed in [22]. As discussed below, interaction intricacies demand systematic scrutiny to prevent buggy smart contracts.…”

On and Off-Blockchain Enforcement of Smart Contracts

“…, SC 4 are not involved in enforcing activitiesthis is entirely the responsibility of the CCC. This arrangement is useful when one or more of the contracting parties is reluctant to trust the TTP blindly, say because it is deployed within the buyer's premises-currently a common business practice [26]. In this arrangement, the d-op set will include operations aimed at creating additional records while c-op will include all the contractual operation like in IV-A.…”

Another look at the middleware for dependable distributed computing

“…Enterprise middleware needs to be enriched with services for automated support for negotiation, monitoring and enforcement of service agreements. We summarise our take on this subject, based on work presented elsewhere [34,35].…”