Grid services are distinguished from ad hoc Grids by the fact that the service they provide is clearly defined. It is obvious that an organisation that wishes to provide a Grid service must consider how that service will be defined, but organisations that plan to be users, rather than providers, of Grid services also need to review the service definitions to confirm that the service is appropriate and that the organisation (and the user) can satisfy any technical and procedural requirements that may be placed on them.

Technical Specification

The service definition should include details of what technologies (software, interfaces, etc.) are supported by the service. At present there is a wide variety of incompatible software that is able to run a Grid, and it is always likely that there will be restrictions on the programming and application tools that can be used on any particular Grid service. Different types of Grid software will make different demands on the networks used for communications (see later) so the prospective user and their network providers must ensure that they can support these before spending time preparing to use a Grid service that may, in practice, be unusable. Anything claiming to be a ‘service’ should provide some technical support for its users, but thought must be given to what level of support can be provided by the service and whether this matches the requirements of its intended users. For all of the defined services – both technical and support – it should be clear whether the level of service is guaranteed or provided on a best efforts basis. Even a best efforts service will allow some users to do things they could not otherwise achieve, but for others a lower-performance guaranteed service will be preferable to a service that may complete their job much faster but offers no guarantee that it will not be slower.

Users, Authorisation and Virtual Organisations

Grid service providers must also consider who will be permitted to use the Grid service. Restricting the service to local users avoids many problems, from technology through authentication and policy enforcement to support and communications, but loses many of the potential benefits of Grids as a collaborative tool for a widely distributed research community. Whatever user group is chosen, the grid provider must consider whether the service will be automatically available to all users in that class (staff, students, etc.) or whether users will be accepted individually. Again there is a trade-off between the additional administration required for individual authorisation and the uncontrolled demand for service and support if the service is available to all. As discussed later, not all applications will be appropriate for a Grid service, so it may be best to start working with selected research groups to allow both the users and the service provider to develop their understanding of what the technology can and cannot achieve.

Some Grid services are made available to particular groups, such as research projects or communities of interest. Where these groups include individuals from a number of different organisations, it is common to view them as a Virtual Organisation and to pass to them the responsibility for authenticating and accounting for the activities of individual users. Some Virtual Organisations will be formally constituted organisations in their own right, but others may have no existence other than through the Grid. This may raise issues for the service provider who may no longer be able to identify individual users, for the Virtual Organisation which must ensure it can meet the requirements of the services its members access, and for the members’ home organisations which may be expected to act as the ultimate enforcers of policy for services they were not aware their users were using. The responsibilities of these various parties need to be clearly stated and agreed in advance to reduce potential problems.

Service providers may also wish to remove access permissions, either temporarily or permanently, from certain users or groups, for example because their period of authorisation has ended or because problems have arisen. Definitions of when and how this will be done must be clear.

Policies

Any computing or network resource is likely to have some policies that regulate its use and may impose obligations on its users and their organisations. These policies will aim, among other things, to ensure that the resource is available on a fair basis to all those who are authorised to use it. Typically, policies will state what the acceptable uses of the resource are (including who is allowed to use it), and the steps that are taken by the service and required of its users to ensure the security of the service. Security is important both to ensure that the service is available and reliable and that it does not present an undue risk to its users or to others. By their nature, Grids tend to be relatively open to authorised users, so are likely to depend more on users behaving responsibly and abiding by policies than on controls enforced by technical means. There is therefore the possibility that users may accidentally or deliberately breach the Policies of a Grid and that their home organisations will be expected by the Grid provider to enforce any sanctions that apply for these breaches.

Grids also present a Policy problem in that Grid providers may not know who their users are and users may not know which Grid resources they are using. Determining what Policies apply to a particular user, and informing the user of those Policies in advance, may therefore be difficult. Grid providers can help by ensuring that their terms of use are similar to those generally used by a particular type of service or group of users, and by publicising their Policies to users wherever possible; users also need to be sensitive and cease any activity that they are informed is a breach of a particular local policy. Organisations must support the Policies of others, even where a particular activity would not have breached the Policy of the home organisation.