|Grid Remote Procedure Call WG (GRIDRPC-WG)|
Group Type: Working Group
Group Secretary(s): Yusuke Tanimura
This Working Group will produce an OGF Recommendation for a grid-enabled, remote procedure call (RPC) mechanism. The first document entitled A GridRPC Model and API for End-User Applications has been completed and published as GFD-R.52. Currently we are concentrating on the second recommendation document, which defines GridRPC API for middleware developers that extends the model and GridRPC API for end-users, and also focuses on data management mechanism within the GridRPC model. The GridRPC middleware tools developed will further lower the barrier to acceptance for grid use by hiding the tremendous amount of infrastructure necessary to make grids work, while providing even higher-level abstractions for domain-specific middleware.
|Group Focus and Scope|
The top-level objective of defining a proposed middleware recommendation can be decomposed into (at least) the following specific objectives:
* Definition of a specific data structure to be used for arguments in GridRPC middleware.
* Definition of the data type to be used in conjunction with the argument data structure.
* Definition of the argument data structure creation, destruction, lifetime and copy semantics.
* Definition of possible introspection capabilities for call arguments and attributes of remote functions (e.g. data types, counts, etc.).
* Definition of mechanisms for handling persistent data, e.g., definition and use of a concept such as "data handles" (which might be the same as or similar to a grpc_data_t data type). This may also involve concepts such as lazy copy semantics, and data leases or time-outs.
* Definition of API mechanisms to enable workflow management.
* Evaluate the compatibility and interoperability with other systems, e.g., WSRF.
* Desirable Properties -- the Proposed Recommendation will not necessarily specify any properties, such as thread safety, security, and fault tolerance, but it should not be incompatible with any such useful properties.
* Demonstrate implementability of all parts of the API.
* Demonstrate and evaluate at least two implementations of the complete GridRPC middleware recommendation.
We specifically exclude the following topics as non-objectives:
* Generalized Workflow -- the GridRPC WG does not wish to define or develop general workflow management tools, rather we will endeavor to make it possible for end-users and middleware developers to interact with workflow tools developed elsewhere through the GridRPC API.
* Services names -- the Middleware GridRPC Proposed Recommendation will not define the Naming Service for service discovery but will have requirements for its use.
* Wire protocol interoperability between implementations -- achieving binary level interoperability between implementations requires defining, in essence, a wire protocol. This is actually orthogonal to the problem of defining the user-level model and API and, hence, can be done later as part of a separate effort. Note that interoperability at the client source code level (100% compatibility if the client source code is GridRPC API compliant) is in our scope.