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: data (SEUD)

Typical characteristic: No computing expertise

Example use-case / scenarios:

• Example 1: PhD Biologist submitting large data sets for processing to a service such as BASIS. BASIS (Biology of Ageing e-Science Integration and Simulation System http://www.basis.ncl.ac.uk/ ) is a UK e-Science pilot project which delivers a grid enabled system that serves the biology of ageing research community by helping to integrate data and hypotheses from diverse biological sources. From the user's point of view, the service is presented through a web portal (further information Shawn Gillespie et al's 'Web-services for the biology community: the BASIS project', AHM 2005).

• Example 2: Humanities researcher asking very complex questions of a service (e.g. requiring complex textual analysis).
• Example 3: User or organisation receiving regular output (without necessarily sending input) e.g. the BBC or Meteorological Office receiving bulletins from a 'Weather' SP.

• Example 4: Social scientist submitting various problems or scenarios to a social modelling and simulation service (with full graphical interface like the games 'The Sims'™ as well as 'SimCity'™, as suggested by the MOSES project. A use-case suggested by the MOSES project (Modelling and Simulation for e-Social Science) is that "a user with an interest in crime patterns might access data on propensities to commit crimes (or the likelihood of falling victim to crime) together with intelligence relating to the crimes reported to various local police forces. This could lead to a model which allows the effectiveness of crime prevention to be benchmarked." (Further information Mark Birkin et al's 'MOSES: Modelling and Simulation for e-Social Science', AHM 2005.

AM/security characteristic: SEUD 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.

Service end-user: executables (SEUX)

Typical characteristic: Little computing expertise but may use a tool to generate executable code or scripts

Example use-case / scenarios:

• Scientist wishing to run Matlab code in a grid environment.

Similar AM/security characteristic to SEUD. However, greater risks for the SP and the grid nodes will exist from supporting these types of users due to the nature of their input/output. Further defenses will be needed to support these users, who may eventually show a risk profile similar to the PUAs (see below).

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:

• Technical expert programmer supporting end-user. Submits the programs and data to a resource broker or primary node, which, in turn, submits jobs to (other) grid resource nodes. The PUA does not care which resource takes on the job.
  • Example: Takes data from PhD Biologists (as above example) as there is no service available for their needs. Packages data and algorithms and submits these to the grid for processing.

AM/security characteristic: PUA need not be 'known' by the grid AM service (but some sort of mapping to a billing account may be necessary). It is possible that the grid AM service may need status information from an identity provider (for authZ purposes).

Power user requiring specific grid resource nodes (PUS)

Typical characteristic: As PUA but may (or may not) have more platform etc. dependent expertise and some sysadmin expertise. (High degree of computing expertise).

Example use-case / scenarios:

• As above (PUA) but PUS does not wish, or cannot, use a resource broker (in its normal method of operation). The PUS writes specifically for jobs to be run on defined grid nodes. This could involve interaction with a resource broker, but for accounting purposes only.
• Example 1: (The example of an expert serving the needs of PhD Biologists or Humanities researchers fits equally well here). Code developed (as is common at the present time) that is very platform-specific and it is necessary that the PUA has a relationship with one or more remote computers.
• Example 2: PUS has a project that calls a grid-connected telescope studying sunspot activity. PUS has to be specific about the telescope and may or may not have to be specific about other computing resources used.

AM/security characteristic: PUS may or may not need to be 'known' by the grid AM service (but some sort of mapping to a billing account may be necessary). All of the text regarding AM/security for PUA is equally valid here. However, in addition (or instead), grid node owners may wish to have a direct authN/authZ (and accounting) relationship with the PUS.

Power user developing a service (PUDS)

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

Example use-case / scenarios:

• As PUA or (more likely) PUS where the user wishes to allow the developed application to run as a service for SEUs but the service is still in development.
• Almost any current major grid project developer could be used as an example here.

• Example 1: BRIDGES developers

• Example 2: BASIS developers

• Example 3: NeuroGrid developers (See John Geddes et al's 'NeuroGrid: Collaborative Neuroscience via Grid Computing', AHM 2005).

AM/security characteristic: As for PUS or PUA, but moving into arrangements like SP (see below). May need to begin interacting with and accounting for SEUs in an experimental manner.

Service Provider (SP)

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

Example use-case / scenarios:

Many of the developers, administrators and owners of projects already mentioned will play the role of SP when the applications mature. A popular method of providing this service is to build a portal, possibly using web services to give an easy interface to the SEU.

SP provides a user interface (possibly via web, not necessarily via grid middleware) for SEUs. The SP interfaces directly with SEUs and then adopts a role as PUA or PUS in order to execute the processing job.

• Example 1: Accepts large spreadsheets or XML files of data from PhD Biologists (or digital texts and complex textual analysis questions from humanities researchers).
• Example 2: A 'Weather service' SP runs constant 'chains' of jobs on the grid that call upon satellites and weather stations for 'moment in time' data. Grid jobs compute predictions. SP builds reports to present to SEUs.

• Example 3: Offers immersive virtual reality interfaces over access grid technology, such as developers for the project Advanced Grid Interfaces for Environmental e-science in the Lab and in the Field. This project has been exploring areas of e-Science involving significant field-based activity, including environmental monitoring in the Antarctic and urban pollution in London. In this project they have also explored ways of integrating with the Access Grid, in particular the Access Grid Toolkit version 2 (currently version 2.3). Specifically, they have worked to (1) integrate a collaborative mobile pollution monitoring and visualisation application, and (2) allow immersive virtual reality interfaces (e.g. CAVE™ and RealityCentre™ type devices) to be used as nodes. (Further information Chris Greenhalgh et al's 'Integrating with the Access Grid: Experiences and Issues', AHM 2005; and Steve Benford et al's 'e-Science from the Antarctic to the GRID', AHM 2003; and Anthony Steed et al's 'e-Science in the Streets: Urban Pollution Monitoring' AHM 2003; and The Access Grid Project; and Chris Greenhalgh's 'Equip: An Extensible Platform For Distributed Collaboration'.

• Example 4: Offers the management and processing of data, including banks of high resolution .TIF images of manuscripts from private collections for comparison and analysis by partner organisations, such as via the "The Online Froissart : texts, manuscripts, and digital tools" project'. The Froissart Project led from the University of Sheffield has created and archived high-quality .TIFF images, at 133MB each, and JPEGs are in daily use for transcription and research. See also Colin Dunn's and Peter Ainsworth's 'The Medieval Book: Online Froissart Project: HEIF KNOWLEDGE EXCHANGE AWARD Report of activities, Aug-Sept 2004 (Project Title : "Virtual Vellum : digital tools for the medieval manuscript, Research & Development and Public Dissemination")'.

• Example 5: Offers orchestral performances to an audience, to be delivered via the Access Grid, (part of the CSAGE project's investigations into the issues of linking researchers with each other). The Collaborative Stereoscopic Access Grid project (CSAGE, Manchester) is building user (i.e. audience) 'presence' into an extension of existing Access Grid infrastructure by establishing stereoscopic extensions to an existing Access Grid node. This will deliver new and far more sophisticated means of one-to-one, or one-to-many communication. Orchestral performances, for example, can be delivered to the 'audience' with the familiar speed, cost-efficiency and flexibility of the Access Grid, but stereophonically. The project will achieve this by digitising objects in 3D and infiltrating them into virtual environments as believable, life-sized entities. Referred to in Anderson, Dunn and Hughes' 'VREs in the arts and humanities', AHM 2005.

The SP may need to identify or authZ the SEU for access or accounting purposes. The SP then submits the 'job' to the grid, possibly via a resource broker or possibly directly to particular grid nodes. The SP collates the returning output and sends or presents it to the user.

AM/security characteristic: SP may be trusted to provide services only to those supposedly authorised to use the grid. SP may need to identify (authN) SEUs but will probably need to recognise status (authZ). SP will need strong authN between it and the primary grid service or grid resource nodes. Accounting may be required between the grid resource nodes (or primary grid service) and the SP and between the SP and the SEU (although this latter requirement may not need to be met using grid middleware).

As an individual, the SP could use any method (including that of devolved authentication) of access management to his/her machines (to which the SEUs connect or utilise in some way). Moreover, those machines may or may not be considered to be part of the grid.

Infrastructure sysadmin (Grid-Sys)

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

Example use-case / scenarios:

• A Grid-Sys may manage dedicated grid resource nodes (including clusters) and any grid system objects such as resource brokers, authN, authZ or accounting points. As well as possibly managing a resource, a GRID-SYS is likely to be responsible for (and may be expert in) security and access management. A Grid-Sys may be the resource manager of a node that accepts jobs (from PUAs) from the resource broker, or of a node that may authenticate or authorise PUS users directly where they wish to be specific and use the Grid-Sys's resource without any involvement of the resource broker. A special type of Grid-Sys is someone who hosts a grid resource node for a particular SP, or a set of SPs.

AM/security characteristic: A Grid-Sys may need to authenticate directly to particular grid resource nodes. However, in theory, it is possible that s/he may authenticate elsewhere and the node computer may trust that external authentication point (or identity provider).

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:

Data belonging to or pertaining to a TPB may be handled by one or many grid nodes. These data may be required to be guaranteed to be confidential and the TPB may require anonymity.

• Example: A SEU could ask an SP for a TPB's records to be processed and for the SEU to receive the results of the processing. Irrelevant data concerning the TPB may be required to be kept from the SEU and all other grid users, owners and administrators. The TPB should be anonymous or untraceable by other grid users, owners and administrators.

• Example: Extracting information from clinical records for British Medical Association or the World Health Organisation. e.g. AMBIT (text analysis). Further informationfrom Henk Harkema et al's 'Information Extraction from Clinical Records', AHM 2005.

AM/security characteristic: The TPB typically does not interact with the grid (whereby s/he would become a SEU) and therefore no direct AM may be required, except for interaction with the database that holds the confidential data (and this may not be considered a grid interaction – merely database authN/authZ). However, there is a possible security characteristic in that the TBP’s data and identity may have to be kept secret from other grid users.