Why GAT?

Beginnings are sacred things. So, with this in mind, we begin this user's guide with a ``why'' instead of a ``how.'' ``Why's'' are always more illuminating in my opinion, and ``how's'' are a dime a dozen.

So, we begin. 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 do 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 then 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.

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