CONTRACT MANAGEMENT 131

5.4.2 Incentives (Rewards/Penalties)

Due to the economic focus of the DRIVE prototype several remunerative financial incentives have been implemented. Positive incentives are inherent in a DRIVE economy as providers are re-warded by consumers for providing the agreed upon levels of service. Negative incentives (or penalties) have been implemented in the prototype to evaluate their effect on allocation. In par-ticular constant and dynamic penalties are defined. In the constant model penalties are statically defined irrespective of the “size” or value of the failed task or the impact of the violation. Dy-namic penalties attempt to reflect the value of the breach by determining the value of the job.

For example penalties are defined as a percentage of the job value, metrics can also be used to determine a penalty based on job requirements. In the case of overbidding, penalties are calcu-lated based on the difference between the original defaulting price and the substitute provider price to cover any losses experienced by the consumer. These penalty functions are explained and evaluated in Chapter 6.

5.4.3 Contract Manager

The Contract Manager is composed of two services, one acts as a general interface to create and manage contracts, while the other (context service) manages contract resources. When a contract request is made the Contract Manager discovers the auction result, creates a contract resource, and places the result on a confirmation queue. The Contract Manager contains a thread pool of confirmation threads, which respond to contract events on the confirmation queue to create and confirm contracts with one or more providers. If a contract is rejected some protocols allow re-computation of the auction (second chance substitute), in this case the Contract Manager obtains a substitute from the Auction Manager and attempts to re-confirm the agreement with the new winner. If there are multiple rejections, substitute requests are batched so as to limit the number of requests to the Auction Manager.

Contract resources store the contract for the duration of the provision. Specific security poli-cies can be implemented allowing only certain entities access to the contract details. Guarantee terms are stored in resource properties to provide fine grained management and in the future monitoring of individual terms. The WS-Agreement specification also outlines a state model to represent the state of an agreement (or individual guarantee terms), this is not included in the current prototype as monitoring has not been implemented.

Establishing a Contract

Figure 5.7 shows the interactions between services in DRIVE when creating a contract. At the completion of an auction participating entities (clients and providers) are notified of the result, the same results are also published to Publishing Services. Any of the participating entities can initiate the contract creation process at any point after the auction concludes. The Contract Man-ager begins by obtaining the authoritative auction result from the Auction ManMan-ager, this result is

used to create one or more contracts containing the job description, participating parties, rewards and penalties specified. A contract resource is created to represent the contract for the duration of the provision. The Contract Manager then iteratively attempts to confirm contracts with each of the winning bidders. Bidding Agents are expected to ensure they can meet contractual obli-gations and confirm the agreement, if they cannot they will reject the contract and a penalty is likely to be enforced. Assuming all Bidding Agents confirm the contract(s) all parties are notified of the completed contract(s) and the client is able to submit the job to the Execution Service at the specified time.

ContractManager Context Contract Manager

ContractInitiator Client/Broker AuctionManager

Policies Confirm Agreement

Create Contract

BiddingAgent

Get Auction Result

Create Agreement(s)

Confirm Create Agreement Resource (s)

Notify Contract Notify Contract

Figure 5.7: Contract creation.

Computing Second Chance Substitute Providers

Some protocols permit computation of second chance substitute providers in the event a provider withdraws from an auction after the auction has completed. This approach has the advantage of determining a new winner without recomputing the whole auction. Figure 5.8 shows the pro-cess of confirming a contract using substitute providers when the winning Bidding Agent cannot honour the tentative agreement. The winning Bidding Agent returns a signed rejection message to the Contract Manager indicating it cannot confirm the requested agreement, this message is self signed to verify that the message originates from the specified Bidding Agent. The Contract Manager passes the signed message to the hosting Auction Manager to determine if substitute providers can be computed. If so, the Auction Manager recomputes the winner by excluding the previous winner from the auction and returns the new auction result to the Contract Manager.

5.5. REGISTRATION AND DISCOVERY 133 The contract hardening process is restarted for the new winner, replacing the original contract resource and contacting the new winner for confirmation.

ContractManager Context Contract Manager

ContractInitiator Client/Broker AuctionManager

Policies Create Contract

BiddingAgent

Get Auction Result

Create Agreement(s)

Create Agreement Resource (s)

Notify Contract

Backup BiddingAgent

Compute Backup (Signed Message)

Confirm Agreement

Confirm

Notify Contract

Policies Reject (Signed Message)

Confirm Agreement

Figure 5.8: Contract creation using second chance substitute providers.

5.5 Registration and Discovery

There are two types of registration in DRIVE; first users and providers must register to join a VO (user registration), secondly providers also register services and capabilities to participate in the VO (service registration).

5.5.1 User Registration

User registration is vital for identification, authentication, and authorisation of entities within the system. The DRIVE prototype uses VOMS to manage VO membership and authenticate actions within the VO. The design of DRIVE is not bound to VOMS as other membership services may by more suitable in different domains. To demonstrate this flexibility the DRIVE based Social Cloud presented in Chapter 8 leverages Facebook as a means of user registration and authentication (VO management).

VOMS is a database-based mechanism used to manage authorisation information within multi-institutional collaborations. User roles and capabilities are stored in a database and a set of tools are provided for accessing and manipulating data. Credentials for users and resource providers are generated when required based on stored authorisation information. VOMS credentials ex-tend authorisation information stored in standard X.509 based Grid proxies by including role and capability information as well as VOMS server credentials. Resource providers maintain access control lists to make authorisation decisions based on groups, VOs, roles, or capabilities. VOMS has the advantage that resource sites do not need to retrieve all VO lists multiple times a day, rather VO information is pushed through the certificate.

In the DRIVE prototype users and providers join the VO by registering with VOMS, this is done by passing an existing Grid certificate to the VOMS server. As is the case with normal Grid environments participants obtain certificates from Certificate Authorities. VOMS records user information and issues proxy certificates (extended Grid certificates with VO information) to be used for authentication. In the DRIVE model VO members may be part of several VOs and have any number of assigned roles and groups.

Having been granted VO membership by VOMS, users can generate a proxy to access Grid services using voms-proxy-init. Like the standard GT4 grid-proxy-init, a proxy certificate is cre-ated that is then used to transparently access services. An example of a VOMS proxy in DRIVE is shown in Appendix C (Listing C.5), the embedded VO information is included at the bottom of the proxy. DRIVE Services include specific security descriptors which direct access decisions to the specified Policy Decision Point (PDP) which in turn extends the abstract VomsPDP meth-ods. Services call context methods to obtain user credentials, including VomsCredentialInformation which provides methods to get VO information and user roles relating to the caller. The DRIVE prototype only uses a subset of VOMS capabilities. Currently it checks VO membership of users to ensure they are in the DRIVE VO. However, the infrastructure is easily extensible to make fine grained access decisions based on user or VO roles and capabilities.

There are several limitations using VO management infrastructure in a global federated envi-ronment. As the main authorisation mechanism used in DRIVE it must be trusted and as such requires dedicated infrastructure to ensure the service is not compromised. Additionally con-sideration must be placed on scalability and fault tolerance ensuring the system is suitable for large scale environments. To limit these problems VOMS resides in the trusted core of the DRIVE implementation.

5.5.2 Service Registration

Providers register obligation and participation services upon joining the VO, the addresses of which along with resource profiles describing capabilities are registered with the Globus MDS Index Service. This DRIVE specific metadata allows auction advertisements to be targeted to-wards suitable entities that support the chosen protocol and have sufficient capacity. In addition a general purpose description of the service and the hosting environment is specified according

5.5. REGISTRATION AND DISCOVERY 135 to CaGrid Metadata schemas². This semantic metadata describes the service and also specifies non-functional information such as the hosting provider description, physical address, and ad-ministrator contact details.

The proof of concept resource profile schema is shown in Appendix C (Listing C.6). This pro-file quantifies available capacity in terms of a three tuple containing Computation, Memory and IO. The profile also attempts to classify the provider according to one or more of these categories to indicate the type of jobs the provider is most interested in hosting. Auction protocols sup-ported by the Bidding Agent are listed so auctions are not targeted at providers who are unable to participate in the chosen protocol. The initial value for each element is set in a bidding proper-ties file deployed with the Bidding Agent, run time updates are based on user specified policies.

Registration properties such as MDS addresses and refreshment periods are also configurable and are described in a separate registration properties file.

Each DRIVE Agent periodically submits resource profiles to be stored in the Index service, the values of which can be set dynamically or loaded from configuration files located on the host ma-chine. Through Index service aggregation this information propagates around the VO ensuring global knowledge of the provider. The resource provider may choose to also register a standard Globus service data entry which summarises capabilities and current load of the provider in terms of processors, jobs, and waiting times. This information however is not currently considered in the DRIVE prototype.

The DRIVE approach to resource profiling is simplistic, however it can be used to great effect to reduce auction size by targeting auction advertisements at suitable providers. A more thorough representation of provider capacity could be used to increase the accuracy and expressiveness of resource profiles. For example mathematical functions can be used to describe projected or mea-sured capacity over time. However in commercial environments providers may be unwilling to divulge projected capacity as it may be commercially sensitive. There may also be motivation to lie about capacity to ensure providers are notified of all auctions. Expressing capacity with functions has been proposed in SLA negotiation [224], in this work SLA terms are represented as multidimensional functions (or systems of functions) rather than constant values or variable ranges. The major limitation with this approach is difficulty generating the functions and in-creased matchmaking complexity.

5.5.3 Resource Discovery

Discovery mechanisms in any distributed infrastructure provide the backbone for cooperation.

DRIVE relies on discovery of previously unknown entities to implement meta-scheduling mech-anisms, locate providers, and determine market conditions. Users discover DRIVE services to manage auctions and create contracts while DRIVE services discover other services to implement auction protocols. In DRIVE filtered discovery mechanisms are used to identify suitable resource providers based on resource profiles in an effort to optimise allocation through targeted

adver-2http://www.cagrid.org/display/metadata13/Metadata+Models

tising. In addition both users and providers may want to discover auction results to determine market conditions.

Service and provider discovery relies on the Globus MDS Index service. Due to the standard-ised nature of the Index service there are a number of ways to access metadata. MDS exposes mechanisms by which XPath statements are evaluated against registered metadata and filtered results are returned. For most use cases in DRIVE the data is extracted using the generic Resource Property API, in which any resource property from any WSRF resource can be retrieved (assum-ing the entity is authorised to access the information). By specify(assum-ing an XPath statement the resource providers returned are filtered against specific criteria. XPath queries are very expres-sive and are not limited to straight equality comparisons, there are capabilities to use inequalities, functions such as search or count, or parts of other elements. For example, when advertising a resource allocation in DRIVE, the Auction Manger can query the index service to return all providers classified as heavy computation providers or specify a ranking “of more than x” for each of the identified resource profile categories. An example query used to discover appropriate providers is shown in Appendix C (Listing C.7).

The DRIVE Publishing Service acts as a general purpose whiteboard where Auction Managers can publish auction advertisements and auction results for entities within the system to act upon.

Auction advertisements allow any provider not explicitly notified of an auction the chance to participate. Published auction results allow non-winning entities and non-participating entities the chance to determine market conditions. While similar functionality could be implemented using MDS a separate Publishing Service has been implemented as it provides complete control of information and the ability to implement fine grained security and sharing policies. Additionally, providers can contribute Publishing Services to the VO as they do not need to be trusted entities and there is no requirement for information propagation.

5.6 Security

Grid and federated systems present complex security considerations as VOs span multiple ad-ministrative domains and contain heterogeneous resources each with independent security mech-anisms, implementations, and policies. The DRIVE prototype considers a number of levels of se-curity ranging from VO level sese-curity down to securing individual resources and communication channels.

The DRIVE prototype is based on the Grid Security Infrastructure (GSI) [202] as it is the de facto Grid security standard. GSI provides single sign on, credential delegation, secure commu-nication using Secure Sockets Layer (SSL), and supports implementation of security mechanisms across organisational boundaries. Like Globus, the DRIVE prototype relies on X.509 certificates for authentication, every entity and service in the system is identified by a certificate. VO level security is required for general VO operations to make all parties accountable for the actions they take within the VO. DRIVE requires mechanisms that maintain site autonomy whilst also