Introduction

GRIA is designed to support business Grid requirements, which include the fact that it does matter where resources and services are deployed, and that it is necessary for human operators to control the relationships between organisations. To handle this, GRIA is designed to address the needs of different actors, including:

• service managers in a service provider domain, whose role is to install services, and control which customers can access them to what extent, and how the service provider makes money from this;

• project managers in a service consumer domain, whose role is to manage how much project workers spend on services, and to control which services they can use; and

• project workers in a service consumer domain, who need application services and a way to access them subject to constraints imposed by the other two actors.

In practice, not every business scenario will involve all these actors. GRIA provides different packages of services and software for each type of user, and is designed to support different deployments using some or all of these packages to match different business scenarios.

Single Trusted Domain Deployment

The simpliest scenario is deploying GRIA within a single domain where service providers and consumers are highly trusted; for example, both within a single organisation (intra-Grid), or in a small, tightly-knit academic collaboration. In this case, the basic application service package is deployed and configured to run without GRIA's management infrastructure because there is no requirement for users to pay for services, and so no need for usage monitoring, management and billing.

Single trusted domain deployment scenario

Consumers can then access the application services directly using a WS-I compatible Web Services toolkit, or by using the GRIA Client package. This provides a framework into which user interfaces for different services can be added, and comes with interfaces for the basic GRIA applications (Job and Data Storage services) pre-installed. The main advantage of using the GRIA Client framework is that it also supports interfaces to GRIA management services, making it easier for users to make the transition to a less informal deployment scenario.

Inter-Domain Deployment

GRIA can be deployed to support trusted and secure business partnerships operating in different domains of control. The partnerships could be between different organisations engaged in applications such as collaborative design engineering, or between departments in a single organisation where there is a security, regulatory or accountability requirement for separating IT resources from the department(s) that use them.

GRIA's Service Provider Management package supports a procurement and billing process that allows consumers and server providers to set up trusted accountable relationships and to negotiate service level agreements (SLAs). The service provider deploys the management package in addition to the basic application services package, allowing them to constrain access to application services based on SLAs and the ability of a consumer to pay for service. Note that this payment may be expressed in currency units (e.g. Pounds, Euros or Dollars) or, if the provider and consumer are part of the same organisation, in quota units defined by an internal budgeting group or by the IT department providing the services.

The consumer establishes a trusted account with a service provider and negotiates an SLA before they use the application services. This can all be achieved using the standard GRIA Client. When the consumer uses an application service they present an SLA. The application service checks that the requested service is within the commitment of the SLA before proceeding, and generates usage reports that are monitored by service provider management. If the user exceeds the SLA promise whilst accessing an application service, GRIA's SLA manager may terminate the activity. The SLA Manager also bills the consumer's account for the total usage at the end of each billing period, as defined by the terms of the SLA.

Inter-domain deployment scenario

Federated Domain Deployment

The inter-domain deployment scenario works well when a single user in the consumer organisation is able to procure and use services for themselves. This is usually the case if the consumer is actually a home user, buying services using their personal credit card.

However, most companies allow only senior staff to procure goods and services, and have processes to manage how these are used by other staff working in different departments or projects. For this to work, it is necessary for someone other than the eventual application user (e.g. their project manager) to open accounts and agree service levels and pricing terms, etc. The project manager must then be able to specify who else can use the application services provided under their SLA. The resulting policies must be federated with those of the service provider, so that other users cannot bypass the consumer organisation's rules by simply sending service requests direct to the service provider. This federation must also be dynamic so that, when staff are moved around, all relevant service providers instantly allow or deny access to services by the individuals joining or leaving the relevant department or project. The inter-domain scenario does allow a project manager to set up an account and an SLA with different service providers, and to enable and disable access for their users, but the project manager must manually update the polices at each provider whenever there is a change.

In a federated domain deployment, the client organisation installs a single Client Management Service package somewhere within their organisation. This allows project managers to federate their policies with those of service providers, so policy changes are instantly recognised by all providers. It also allows users to prove to service providers whether they are allowed to access services, even if they are not known to the service provider in advance.

Federated domain deployment scenario

The project manager starts by requesting a trade a account with a service provider, as in the basic inter-domain scenario described above. However, once a service provider approves the trade account, the Client Management Service becomes the root of trust for users that want to access the trade account. The project manager can also define local project accounts at the client management service, and assign users to each project, allowing them to obtain authorisation tokens from the client management service for the projects to which they are assigned. The project manager can then associate the local project accounts with trade accounts and/or SLAs at the remote service providers that the project team should be allowed to use. The service provider will then accept requests from users that have tokens from these project accounts, and thus enforce policies set up within the customer organisation.

The benefit for service providers is that they do not have to maintain access control lists for every user on the Grid, because they trust the project manager with the responsibility of assigning permission to access a trade account. Once the relationship is established, the service provider has no further administration tasks, no matter how many users need to access the services, thus significantly reducing the operating costs.

The benefits for consumers are that they can maintain a single access control list for multiple supplier relationships under their own control, and collect usage statements from all the service providers to get an overall picture of how much service each of their projects is using.