• General GAT Design
• 1 Scope of Document
• 2 Structure of Document
• 3 How to read this Document
• 4 Status of this Document
• 5 RFC 2119 and this Document
• 6 UML and this Document

1 Introduction

In the Grid community the demand for real applications using the emerging Grid infrastructure is steadily increasing. Over the last years much of the Grid Middleware advanced from pure experimental and research state to mature and widely supported software systems. The complexity of theses systems, both in terms of administration and application usability, remains high. One of these aspects, the usability for application programmers, is the focus of Grid Application Toolkit as developed in the EU GridLab project.

The purpose of the Grid Application Toolkit (GAT) is to provide a complete application oriented abstraction layer to the underlying Grid middleware. Application oriented here means, that the toolkit provides those functionality (capabilities) the application programmer needs. Such capabilities are often composed of several Grid operations, and may involve more than one Grid service, different protocols etc. Exactly that complexity should be hidden from the application programmer.

For example, the simple read access to a remote file may involve interaction with a replica location service, a data transport service, a GridFTP service, a resource management service, and a security service. It may involve communcation via LDAP/LDIF, GRAM, HTTP, and GSI, as protocols or protocol extensions.

All the application programmer should see are calls very much like:

  fileCopy (source, destination);

Although that example is somewhat too simple, it surely illustrates the motivation for the present work. The API specified in this document is supposed to deliver a similar level of abstraction to the application programmer.

General GAT Design

One of the major strengths and major challanges of the Grid is its diverse nature in terms of technology used. The range of available Grid services is wide, and constantly growing. Although the Global Grid Forum (GGF) aims at a global standardization for these services, that efforts will take time; will not cover all Grid aspects; will not necessarily simplify usage of Grid middleware (on application level); and will not cover all Grid middleware systems (as research projects, propretiary systems etc.).

The GAT is designed to handle that diversity of Grid middleware. The API exposed to the application is, as far as possible, independent of the Grid middleware incarnation used.

In general terms, the capabilities provided by the GAT API implementation, a library, are handled by the GAT Engine. The GAT Engine picks from currently available adaptors, which implement that specific capability. The adaptors are lightwight modular software elements which interface to the specific Grid middleware to be used. The technical reasoning for this design is outlined in the GAT Technical Specification [2].

1 Scope of Document

As described, the GAT consists of a library -- the GAT Engine -- which implements the GAT API, and which all applications utilize; and a set of adaptors which provide the bindings between the called in the application and the underlying providers, e.g. Grid services.

The GAT API can be split into four parts:

• GAT Application API

  This is the API which provides the ``Grid'' . It is called by applications which want to utilise the Grid infrastructure. This API part is very high level, and application oriented.

• GAT Application Utility API

  This API provides helper calls to support interaction between the application and the GAT Engine, and to support the exploitation of the GAT Application API.

• GAT Adaptor Registration API

  This is the mirror of GAT Application API and is the way in which adaptors provide those functions.

• GAT Adaptor Utility API

  These are the additional functions an adaptor needs to interact with the GAT Engine and possibly with other adaptors and utility libraries.

This document provides a language-independent, object-oriented description of the GAT Application API, and the GAT Application Utility API, based upon a set of . It is the second in a sequence of two language-independent API documents. The first is the GAT API SPECIFICATION [1]

After acceptance of the this API specification, language-specific specifications will be developed. These will include language specific GAT Adaptor Registration and Utilities APIs as well as language of the APIs described in this document.

This document does not detail any GAT implementation. In particular, the expected behaviour of the GAT Engine in respect to adaptor selection, fail safety etc. is not fully specified. A later document will cover this.

As the GAT is an adaptation layer, it cannot enforce security in lower-level components -- the adaptors and the capability providers they use. However, the GAT API will provide functions which allow the application to specify credential information to the underlying adaptors. Adaptors may use these information to authenticate to services and to delegate security, as determined by the underlying security model of these services.

Generally, all GAT calls should have asynchronous equivalents. However, this version of the API does not provide a general scheme for asynchronous GAT implementations, and touches that topic only on rare occasions (Streamable) -- such functionality will be, at a general level, added in a later version.

All GAT calls are reentrant (thread safe), unless noted otherwise.

2 Structure of Document

This document consists of three sections. Section lists all the , with brief summaries of each, section details the GAT Application API, and details the GAT Application Utility API. Section  describes classes used but not provided by the GAT. Section  provides a glossary about the terms used in this document.

Throughout the GAT API description in this document a number of examples are listed. That listing is provided in pseudocode, and is not supposed to represent real code.

The GAT Application API description is annotated with some sections explaining the separate API subsystems. These subsystems are loosely coupled and related API objects and calls, but do not define any particular substructure in the API -- their nature is purely illustrative.

3 How to read this Document

4 Status of this Document

This document is still a draft -- the API is currently being developed on. However, this document should be taken as a good indication of the final API.

Follow up versions and complementary documents cover:

• GAT asynchronous calls
• GAT error states
• GAT security aspects
• GAT Engine specification
• GAT object serialisation specification
• GAT language bindings (Java, C, C++, Fortran), inclusive GAT Adaptor Registration and Utility API

5 RFC 2119 and this Document

The keywords ``MUST'', ``MUST NOT'', ``REQUIRED'', ``SHALL'', ``SHALL NOT'', ``SHOULD'', ``SHOULD NOT'', ``RECOMMENDED'', ``MAY'', and ``OPTIONAL'' in this document are to be interpreted as described in RFC 2119 [4].

6 UML and this Document

Keywords in set in sans serif in this document are to be interpreted as described in the The Unified Modelling Language Reference Manual [5]. In addition, all figures in this document are written using the UML syntax and vocabulary [5].