Open Grid Forum

 Active Groups
 Completed Groups
 Hibernating Groups

OGF Active Groups


Area Director: Wolfgang Ziegler

The Applications Area explores grid application development issues and programming interfaces required by grid applications.
Distributed Resource Management Application API WG (DRMAA-WG)
Group Information
Group Type: Working Group
Group Secretary(s): Roger Brobst
Group Description
The 'Distributed Resource Management Application API (DRMAA)' working group develops and maintains a set of API specifications for tightly coupled and portable programmatic access to cluster, grid, and cloud systems. The DRMAA working group deliverables are intended to facilitate the development of portable application programs and high-level libraries such as SAGA or OGSA-BES. DRM system vendors can provide a standardized access to their product through a DRMAA implementation. High-level API designers, meta-scheduler architects and end users can rely on such DRMAA implementations for a unified access to execution resources. The scope of the API standardization is focused on job submission, job control, reservation management, and retrieval of job and machine monitoring information.
Group Focus and Scope
2012: Development of language bindings for GFD-R-P.194 (DRMAAv2). Support for implementors through a reference implementation.
Group Links
Grid Remote Procedure Call WG (GRIDRPC-WG)
Group Information
Group Type: Working Group
Group Chair(s): Eddy Caron, Hidemoto Nakada
Group Secretary(s): Yusuke Tanimura
Group Description
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.
Group Links
Simple API for Grid Applications WG (SAGA-WG)
Group Information
Group Type: Working Group
Group Description
This working group is the first working group spawned by the SAGA-RG, and will concentrate on defining a concrete API for the functional areas identified by the initial SAGA-RG design team:
- Files
- Logical files
- Job submission and management
- Streaming communication between processes
along with the core API areas which are independent of specific Grid operations:
- Tasks
- Sessions
- Security
Group Focus and Scope
The initial SAGA-RG collected a number of application use cases which are published in the SAGA-RG Document "SAGA Use Case Document". The work of this group will be based on these use cases, which will define the scope and target application areas for the API. Simplicity and parsimonious will be the governing design principles for the API.

The specification of services and the protocols to interact with them is out of the scope of the WG. Rather, the API seeks to hide the detail of any service infrastructures that may or may not exist to implement the functionality that the application developer needs. The WG will, however, actively liaise with relevant grid-middleware groups within the GGF.

The WG will continue to identify projects outside GGF with similar API-focus and goals, and will seek their input in the development of the API and its implementation. The WG will provide detailed non-normative examples and 'cook-books' showing how the specified APIs could be used.
Group Links

> login   RSS RSS Contact Webmaster

OGFSM, Open Grid ForumSM, Grid ForumSM, and the OGF Logo are trademarks of OGF