GridLab logo
Welcome
* Introduction
* News
* FAQ
* Licence
Download
* GAT Releases
* Adaptor Releases
* Documentation
* Presentations
* Publications
People
* Collaborations
* Team
* e-Mail
* Internal
Information Society Technologies  
 
| Home | Products & Technologies | Support & Downloads | Contact us |  

Grid(Lab) Grid Application Toolkit

GAT Frequently Asked Questions

The GAT frequently asked questions are grouped into the following sections

General questions about the GAT
GAT Installation
The GAT Engine
The GAT Adaptors


What is GAT?
GAT is a library which presents to the application programmer a uniform interface to Grid technologies. The actual Grid technologies which implement the GAT API functionalities are plugged into GAT by means of a plugin architecture. This allows the application programmer to worry about the application and the "Grid" technology experts to worry about the plugins which talk to their services over whatever protocols they have dreamed up. The idea of GAT is simple, yet powerful.

The GAT (Grid Application Toolkit) is a set of coordinated, generic and flexible APIs

  • for developing portable Grid applications independently of the underlying Grid infrastructure and available services and
  • for accessing Grid services from e.g. generic application codes, portals, data managements systems,

together with working implementations provided by the tools developed in the Grid Lab project (see the figure here). GAT is designed in a modular plug-and-play manner, such that tools developed anywhere can be plugged into GAT. As shown in the figure, GAT and the GAT API sit between Grid applications and numerous types of grid middleware. GAT lifts the burden of grid application programmers by providing them with a uniform interface to numerous types of grid middleware. As a result, grid application programmers need only learn a single API, that of GAT, to obtain access to the entire grid.

The main philosphy behind the GAT could be briefly described as follows:

  • The client application makes GAT API calls for operations which may be Grid-related.
  • The client application links against the GAT Engine
  • The client application runs irrespective of actual underlying infrastructure deployment
  • The GAT engine loads adaptors which are valid in the environment extant when the application starts
  • The GAT adaptors try to do Grid operations on request, on failure another adaptor provided function may be called.
  • The client application can thus be compiled, linked and tested without any Grid services, the same application executable can run in a full Grid environment
  • The GAT uses whatever underlying Grid infrastructure there is and that people have developed adaptors for.
  • GAT is not about replacing already developed infrastructure, but instead to provide a simple, clear interface which can be used with many different infrastructures as different versions of Globus, Condor or Unicore etc....


Why do I need the GAT?

Why GAT? The answer, in a word, is simplicity. The "Grid" is currently part research project, part reality, part hype, and everything but settled. The "Grid" is a word used for a collection of various semi-related technologies which allow a user to utilize decenterlized resources. The problem with the current state of the "Grid" is that this loose collection of semi-related technologies does not at present present a uniform interface to programmers. The "Grid" technology of today is all but forgotten tomorrow. For example, one of these technologies may be written in C and expect to be called using XDR protocols; a second technology may be written in Java and expect to be called using RMI; while a third technology may be written in C# and expect to be called locally. For the application programmer, the poor soul who is stuck trying to integrate all of these desperate threads, life in such a world is, let us say, less than amusing.

Application programmers are stuck between the devil and the deep blue sea. The users foist upon the application programmer their expectation of being able to use an endless ocean of resources. If the users are presented with anything less then the "Grid" hype about which they have read so much, they berate the application programmer pointing out the chasm between expectation and reality. However, if the application programmer tries to actually breath life into the "Grid" hype, they are tied to the rack of learning a myriad of differing technologies. GAT hoists the application programmer out of this Catch-22.

So the GAT is abstracting the Grid from the application developer, thus it is a good idea to use it to

  • avoid changing the main application codes whenever a new grid service has to be integrated.
  • allow application development outside the deployment environment (actulally development could be done on a standalone machine without any grid access.


What can GAT do for me?
The first release of the GAT provides the following functionalities:
  • File Management - the ability to copy, move, delete, and examine files in a "Grid" environment independent of the file access protocols.
  • File Stream Management - the ability to seek and read or write bytes to files in a "Grid" environment independent of the file access protocols.
  • Logical File Management - the ability to replicate and examine files in a "Grid" environment in a manner independent of the file access protocols and so as to make most efficient use of network cwresources.
  • Advertisable Management - the ability to persistently store and retrieve object instances in and "object DB" independent of its access protocols.
  • Resource Management - the ability to find and reserve time upon hardware or software resources in a "Grid" environment in a protocol independent manner.
  • Interprocess Communication - the ability to stream byes between any two processes in a "Grid" environment in a protocol independent manner.
  • Job Management - the ability to schedule, un-schedule, stop, checkpoint, clone, and migrate jobs in a "Grid" environment in a manner independent of the underlying job management software.
  • Monitoring - the ability to monitor any number of resources including jobs, files, hardware resources, software resources... all while shielding the application programmer from the peculiarities of each resource.


Which platforms are supported by the GAT?

The C based implementation of the GAT is supported on the following platforms:

  • Windows-9x or newer
  • Windows-NT4 or newer
  • Linux with gcc-3.x or newer
  • IRIX64 6.5 or newer

All Unix like OS's SHOULD be fine, but are untested. Problems are known on MacOS-X, please contact the GAT mailing list.

We have developed language bindings for the C++ and Python programming languages, which may require additional preconditions.

The Java based implementation of the GAT is supported on any platform which has a Java V1.4 environment installed.



How may I get support for the GAT?

The best way to get in contact with the developers and other users of the GAT libraries is to subscribe to the GAT mailing list. If you are interested in the development of the GAT and its adaptors or if you want to develop an adaptor by yourself you probably should subscribe to the GAT-devel mailing list as well.



Where to get the GAT from?

The newest and latest snapshots and releases are published here. Just download the package you need and proceed with the installation as described in the next FAQ. If you are interested in getting the current development version you may download the sources for the GAT engine and the external GAT adaptors anonymously from our CVS repository at

export CVSROOT=:pserver:readonly@cvs.gridlab.org:/cvs/gridlab
cvs login
cvs co wp-1/Codes/GATEngine
cvs co wp-1/Codes/Adaptors

The password for the readonly account is "anon" (without the quotes).



How to install the GAT?

The README coming with the package is fairly detailed, and should answer most questions wrt the installation of the GAT. The default adaptors are coming with the engine package as well, and are installed by default.

Basically

./configure --prefix=$HOME/gat/
make
make install

leaves you with a working GAT installation. You can the run examples with

setenv GAT_ADAPTOR_PATH $HOME/gat/lib/GAT/adaptor-list
setenv GAT_LOCATION $HOME/gat
setenv GAT_VERBOSE 1
cd $GAT_LOCATION/bin/examples
./example_03_-_file_size ./example_03_-_file_size
...

The adaptors listed in $HOME/gat/lib/GAT/adaptor-list are the local adaptors, and these are used unless you install other adapotors and fix the adaptor-list.



What's the GAT engine good for?

The GAT engine is a (shared) library which provides the function bindings for the GAT-API. It's a piece of client side software linked directly to the client application. The engine handles the selection and loading of adaptors depending on the client request, configuration information, Grid service availability and other constraints specified by the user. It allows to register callback functions for Grid service related events.



What's a GAT adaptor?
These are dynamically loadable libraries which the GAT Engine loads to contact specific GridLab services or other capability providers. If you are interested in more details about GAT adaptors please have a look at the GAT Adaptors FAQ.


Which adaptors do exist?
A list of currently available adaptors and adaptors under development can be found here.







GridLab: Grid Application Toolkit and Testbed is co-funded by the European Commission under the Fifth Framework Programme (IST-2001-32133).
Web admin: Petr Holub, web design: Radoslaw Strugalski

Last update on Tuesday, 05-Jul-2005 18:38:49 CEST.