Introduction

The object of the Grid ASCII Helper Protocol (GAHP) is to allow the use of the client library or package of a grid or cloud service via a simple ASCII-based protocol. A process which implements GAHP is referred to as a GAHP server. GAHP is designed to handle both synchronous (blocking) and asynchronous (non-blocking) calls.

The first GAHP specification focused on the GRAM and GASS grid services of the Globus Toolkit. Later GAHP specifications were then developed to communicate with other grid and cloud services.

Why GAHP?

Although most grid and cloud services provide client libraries or modules in various languages that can be incorporated directly into applications that wish to use those services, there are several distinct advantages to using an independent GAHP server process instead. For instance, parts of the native API may provide only synchronous/blocking calls. Users who require a non-blocking/asynchronous interface must make use of multiple threads. Even if the native module is thread-safe, thread safety requires that _all_ modules linked into the process be both re-entrant and in agreement upon a threading model. This may be a significant barrier when trying to integrate the service client module into legacy non-thread-safe code, or when attempting to link with commercial libraries which either have no support for threads or define their own threading model. But because the GAHP server runs as a separate process, it can be easily implemented as a multi-threaded server, and still present an asynchronous non-blocking protocol. Worse yet, there may not be a client module available in the language of the application wishing to use the service. With a GAHP server, langauage choice is immaterial.

GAHP facilitates the construction of multi-tier systems. A first tier client can easily send ASCII commands via a socket (perhaps securely via an SSH or SSL tunnel) to a second tier running a GAHP server, allowing grid or cloud services to be consolidated at the second or third tier with minimal effort.

Furthermore, GAHP, like many other simple ASCII-based protocols, supports the concept of component-based development independent of the software language used with minimal complexity. When a grid service has client modules available in multiple languages, those interfaces can look very different from each other. By using GAHP, a body of software could be written once with one interface and then subsequently utilize a GAHP server written in C, Java, or Perl -- and said GAHP server could be running locally or as a daemon on a remote host.

Downloads

There are several GAHP protocols available, each designed to communicate with a specific remote job submission system. At the time of this writing they are:

• Globus 2 GAHP (the original GAHP). The GT2 GAHP protocol spec is here.
• Globus 3.2 GAHP. The GT3.2 GAHP protocol spec is here.
• Globus 4 GAHP. Spec coming soon
• C-GAHP (HTCondor GAHP). The C-GAHP protocol spec is here
• BLAHP (from INFN). The BLAHP protocol spec is here
• EC2 GAHP (Amazon's Elastic Compute Cloud). The EC2 GAHP protocol spec is here
• GCE GAHP (Google Compute Engine). The GCE GAHP protocol spec is here
• Azure GAHP (Microsoft Azure Cloud). The Azure GAHP protocol spec is here
  Documentation from Microsoft:
  • Azure GAHP Commands
  • Installation and Setup for the Azure GAHP

The HTCondor Project at University of Wisconsin-Madison has developed the following GAHP server implementations:

The National Computing Science Alliance (NCSA) has developed a GAHP server written in pure Java, using the Java CoG. Any platform with a Java 1.2 virtual machine available can run this GAHP server. Contact jalameda@ncsa.uiuc.edu for up-to-date information about this Java CoG-based GAHP server.

Our collaborators at INFN have developed a GAHP server (unoficially called BLAHP) for submitting to PBS & LSF schedulers. Please contact Francesco Prelz (Francesco.Prelz@mi.infn.it) for more info.