Grid(Lab) Grid Application Toolkit

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 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.

• 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.