One simple, yet effective, mean to execute jobs on a computing grid is to use a GridRPC middleware, which relies on the GridRPC paradigm. For each request, the GridRPC middleware manages the management of the submission, of the input and output data, of the execution of the job on the remote resource, etc. To make available a service, a programmer must implement two codes: a client, where data are defined and which is run by the user when requesting the service, and a server, which contains the implementation of the service which is executed on the remote resource. One step to ease the development of such codes conducted to define a GridRPC API, which has been proposed as a draft in November 2002 and which is an Open Grid Forum (OGF) standard since September 2007. Thus a GridRPC source code which does not involve specific middleware data can be compiled and executed with any GridRPC compliant middleware. Due to the difference in the choice of implementation of the GridRPC API, a document describing the interoperability between GridRPC middleware has also been written. Its main goals are to describe the difference in behaviour of the GridRPC middleware and to propose a common test that all GridRPC middleware must pass. Discussions have then been undertaken on the data management within GridRPC middleware. A draft of an API has been proposed during the OGF'21 in October 2007. The motivation for this document is to provide explicit functions to manipulate the data exchange between a GridRPC platform and a client since (1) the size of the data used in grid applications may be large and useless data transfers must be avoided; (2) data are not always stored on the client side but may be made available either on a storage resource or within the GridRPC platform. Hence, a side effect is that a fully GridRPC-compliant code can be written and compiled with any GridRPC middleware implementing the GridRPC Data Management API.
GridRPC Paradigm The GridRPC model is pictured in the following figure. Here is how communications are handled: (1) servers register their services to a registry; (2) when a client needs the execution of a service, it contacts the registry and (3) the registry returns a handle to the client; (4) then the client uses the handle to invoke the service on the server and (5) eventually receives back the results.
GridRPC API Mechanisms involved in the API must provide means to make synchronous and/or asynchronous calls to a service. If the latter, clients must also be able to wait in a blocking or non-blocking manner after the completion of a given service. This naturally involves some data structures and conducts to a rigorous definition of the functions of the API.
GridRPC Data Types Three main data types are needed to implement the API: (1)
grpc_function_handle_t is the type of variables representing a remote function bound to a given server. Once allocated by the client, such a variable can be used to launch the service as many times as desired. It is explicitly invalidated by the user when not needed anymore; (2)
grpc_session_t is the type of variables used to identify a specific non-blocking GridRPC call. Such a variable is mandatory to obtain information on the status of a job, in order for a client to wait after, cancel or know the error status of a call; (3)
grpc_error_t groups all kind of errors and returns status codes involved in the GridRPC API.
GridRPC Functions grpc_initialize() and
grpc_finalize() functions are similar to the
MPI initialize and finalize calls. It is mandatory that any GridRPC call is performed in between these two calls. They read configuration files, make the GridRPC environment ready and finish it. In order to initialize and destruct a function handle,
grpc_function_handle_init() and
grpc_function_handle_destruct() functions have to be called. Because a function handle can be dynamically associated to a server, because of resource discovery mechanisms for example, a call to
grpc_function_handle_default() let to postpone the server selection until the actual call is made on the handle.
grpc_get_handle() let the client retrieve the function handle corresponding to a session ID (
e.g., to a non-blocking call) that has been previously performed. Depending on the type of the call, blocking or non-blocking, the client can use the
grpc_call() and
grpc_call_async() function. If the latter, the client possesses after the call a session ID which can be used to respectively probe or wait for completion, cancel the call and check the error status of a non-blocking call. After issuing a unique or numerous non-blocking calls, a client can use:
grpc_probe() to know if the execution of the service has completed;
grpc_probe_or() to know if one of the previous non-blocking calls has completed;
grpc_cancel() to cancel a call;
grpc_wait() to block until the completion of the requested service;
grpc_wait_and() to block until all services corresponding to session IDs used as parameters are finished;
grpc_wait_or() to block until any of the service corresponding to session IDs used as parameters has finished;
grpc_wait_all() to block until all non-blocking calls have completed; and
grpc_wait_any() to wait until any previously issued non-blocking request has completed. == GridRPC Compliant Code ==