This is a version of the document ESP-GRID (Draft) Use cases for a generic grid. Previous versions are available by clicking on this link [http://users.ox.ac.uk/~markn/GridUseCases/ Grid Use Cases] which will show the document produced for and after the Focus Group Meeting.

Use cases for a generic grid

Introduction

An appeal

The authors of this document appeal strongly for feedback and for criticisms of our use-cases. We would also like to hear examples of other use-cases that we may not have considered.

What is this document?

This document is the first step in establishing the types of actors and some example use cases, and then requirements for access management and security in a 'generic grid'. We use the term generic grid to denote something which is a grid (defined in appendix XXXX) but which does not (as yet) mandate any particular technology or middleware. Once the general use cases are established that reflect the types of users that a generic grid would support, and possibly some of the scope of activities within a grid, then the requirements for the middleware/access management and security can be generated.

What this document is not!

This document is not about building requirements for access management and security. The approach taken with this document is to try to capture some scope of a generic grid, identify the basic actors in such grids using example use-cases and from there to open the way for thinking (in documents) regarding general access management and security requirements.

Use-cases for grids

Introduction

Please note that section 2.3 addresses the use-case scenarios from the point of view of a user, rather than the technology or machines involved. The use-cases in section 2.3 do not consider issues such as personal privacy (as in service providers knowledge of who is the end-user) and data confidentiality (as in service providers being able to steal sensitive or confidential data). These issues are considered in section 2.4.

See section 2.2 for short definitions of the terms used in the next section.

The accompanying/later document Requirements gathering exercise:(2) Authentication, authorisation, accounting and security goes on to consider some of the issues of authentication, authorisation, accounting and security (AAAS) that arise from such use-cases and the types of grids that are proposed in this document. It should be noted that the subsequent document is fully dependent upon the contents of this present document and any changes to the use-cases may affect the AAAS findings as laid out in that later document.

As a point of interest with which to explore the actors and to test the generalised use-cases given in section 2.3, Appendix XXXX n. XXXX gives some example user stories.

Terms defined

• AuthN Authentication.

  AuthZ Authorisation.

  Grid AM service Grid access management service (left undefined further).

  Grid resource node Any computer or instrument connected as part of the grid that is available for grid use.

  GRID-SYS Grid Infrastructure System Administrator (or similar role).

  Identity provider Authentication (and possibly authorisation) service run by an organisation to which the user belongs. The grid, or the grid AM service may trust this identity provider to perform the authentication task and it may also trust this provider to supply reliable authorisation/status information.

  Primary grid service A grid infrastructure service (e.g. grid cluster, resource broker, access management point etc., as opposed to other 'services' which may run as applications and which may use the primary grid services.)

  PUA Power user that does not care which grid resource node is used to run his/her job.

  PUDS Power user developing an application service.

  PUS Power user requiring specific grid resource nodes upon which to run jobs.

  Resource broker Some kind of service running on 'the grid' that accepts jobs from users and SPs and allocates those jobs to individual grid resource nodes. It may also play a role in accounting. Note: This document seeks to avoid mandating architectures or middleware technology. Therefore, the resource broker could also be taken to mean the first node to which the user submits a job. That primary node could also negotiate with other nodes in order to run jobs.

  Secondary resource Computer that is not dedicated to only grid use. Its primary purpose may cause it to be under-utilised at certain times and (as a secondary purpose) it can be used as a grid resource.

  SP Service Provider.

  SEU Service end-user.

  TPB Third party beneficiary of grid processing. This entity (individual or organisation) is not a user (PUA, PUS, PUDS or SEU) but a grid user may invoke a grid procedure that processes that entity's data.

Types of grid users and very basic example scenarios

We propose the following types of grid users and give some example use scenarios. Terms in italics are defined in the previous section.

Service end-user (SEU)

Typical characteristic: No computing expertise

• Example use-case / scenarios:

  • PhD Biologist submitting large data sets for processing or Humanities researcher asking very complex questions of a service (e.g. requiring complex textual analysis). or User or organisation receiving regular output (without necessarily sending input) e.g. the BBC or Meteorological Office receiving bulletins from a 'Weather' SP.

  AM/security characteristic: SEU does not need to be 'known' by the grid AM service (as the grid trusts and accounts the SP not the user). SP may need to authN/authZ and account for the user.

Power user agnostic of ''grid resource node'' (PUA)

Typical characteristic: Develops programs and data but does not care where processing takes place

• Example use-case / scenarios:

  AM/security characteristic:

Power user requiring specific ''grid resource nodes'' (PUS)

Typical characteristic: As PUA but may have more platform etc. dependent expertise and some sysadmin expertise

• Example use-case / scenarios:

  AM/security characteristic:

Power user developing a service (PUDS)

Typical characteristic: As PUA/PUS but developing expertise like SP

• Example use-case / scenarios:

  AM/security characteristic:

Service Provider (SP)

Typical characteristic: As PUA/PUS but has expertise in authZ and possibly identity management

• Example use-case / scenarios:

  AM/security characteristic:

Infrastructure sysadmin (GRID-SYS)

Typical characteristic: System administration of grid nodes with possibly infrastructure delivery and security expertise

• Example use-case / scenarios:

  AM/security characteristic:

Third party beneficiary TPB (non-user)

Typical characteristic: Person or organisation who does not interact directly with the grid but where his/her/its personal data are being handled on the grid

• Example use-case / scenarios:

  AM/security characteristic:

Appendix

What is a grid?

Other people's definitions

"An environment in which individual users can access computers, databases and experimental facilities simply and transparently, without having to consider where those facilities are located." [RealityGrid, Engineering & Physical Sciences Research Council, UK 2001] http://www.realitygrid.org/information.html

"A means of network computing that harnesses the unused processing cycles of numerous computers, to solve intensive problems that are often too large for a single computer to handle, such as in life sciences or climate modeling." http://www.consultingtimes.com/glossary.html

After admitting that there is a short answer and a very long answer, the GridCafé web pages at CERN (http://gridcafe.web.cern.ch/gridcafe/whatisgrid/whatis.html) say that:

"The short answer is that, whereas the Web is a service for sharing information over the Internet, the Grid is a service for sharing computer power and data storage capacity over the Internet. The Grid goes well beyond simple communication between computers, and aims ultimately to turn the global network of computers into one vast computational resource."

Wikipedia (http://en.wikipedia.org/wiki/Grid_computing on 29 March 2005), described grid computing, thus:

"Grid computing offers a model for solving massive computational problems by making use of the unused resources (CPU cycles and / or disk storage) of large numbers of disparate, often desktop, computers treated as a virtual cluster embedded in a distributed telecommunications infrastructure."

The same article later asserted:

"Grid computing involves sharing heterogenous resources (based on different platforms, hardware/software architectures, and computer languages), located in different places belonging to different administrative domains over a network using open standards. In short, it involves virtualizing computing resources."

Ian Foster (with Carl Kesselman) updated his previous definitions of a grid in 2004. It should be noted that Foster has also come up with checklists and other, more lengthy text to explain what is a grid. Foster and Kesselman stated:

"We define a Grid as a system that coordinates distributed resources using standard, open, general-purpose protocols and interfaces to deliver nontrivial qualities of service."

Our definitions

For the purposes of this document, we take much of the spirit encompassed in Foster and Kesselman's definition, but find the phrases "standard, open" and "nontrivial qualities of service" laudable but not necessarily defining terms for a grid. We therefore define a grid as:

A set of networked computers and/or other devices, including remote instrumentation, that have been made available so that their operation can be shared. The sharing of these resources must be via an agreed set of protocols.

Foster and Kesselman's "system" is an object because it is identifiable by the agreed set of protocols. Any grid system which the ESP-GRID project produces will use "standard, open, general-purpose protocols", but it is possible that other grids may use proprietary code and standards, as long as all components of the grid use the same protocols. However, for resources that are geographically remote and non-contiguous in network terms, the feature of the set of resources that conveys the essence of being a grid is the common protocols (or possibly middleware).

N.B. For the purposes of the ESP-GRID project, we must also assume that the 'generic grid' is of a mixed economy – i.e. that commercial, academic and non-profit use may co-exist within the same grid. This means that we must consider grids where detailed accounting must be possible. However, this does not need to affect the definition of "a grid".