# Presentation: 444579

## BOF -DRMAA: Distributed Resource Management Application APIProposed Co-chairs:John Tollefsrud [j.t@sun.com], Sun MicrosystemsHrabri Rajic [rabri.rajic@intel.com], Intel

- www.cs.northwestern.edu/~jms/sched-wg
- sched-wg@gridforum.org

## Proposed Scope: Run a Job API(Steps from:  Ten Actions when SuperScheduling”, GGF SchedWD 8.5, J.M. Schopf, July 2001)

**Phase 1: Resource Discovery**
- Step 1 Authorization Filtering
- Step 2 Application requirement definition
- Step 3 Minimal requirement filtering
**Phase 2 System Selection**
- Step 4 Gathering information (query)
- Step 5 Select the system(s) to run on
**Phase 3 Run job**
- Step 6 (optional) Make an advance reservation
- Step 7 Submit job to resources
- Step 8 Preparation Tasks
- Step 9 Monitor progress (maybe go back to 4)
- Step 10 Find out J is done
- Step 11 Completion tasks

## Why “API”?  Code Re-Use

- Command Line standards
- Script re-use
- API (Application Programmer Interface)
- Code re-use
- Protocol
- Interoperability
- Language/Syntax
- Re-use & interoperability

## An API can have Multiple ProtocolsE.g., Message Passing Interface

- MPI provides portability: any correct program compiles & runs on a platform
- Does not provide interoperability: all processes must link against same SDK
- E.g., MPICH and LAM versions of MPI

*[Slide courtesy of Globus Tutorial – www.globus.org]*

## A Protocol can have Multiple APIsE.g., TCP/IP

- TCP/IP APIs include BSD sockets, Winsock, System V streams, ...
- The protocol provides _interoperability_: programs using different APIs can exchange information
- I don’t need to know remote user’s API

**TCP/IP Protocol: Reliable byte streams**

**WinSock API**

**Berkeley Sockets API**

**Application**

**Application**

*[Slide courtesy of Globus Tutorial --  www.globus.org]*

## Slide 6

## Slide 7

## Slide 8

## Slide 9

## Slide 10

## Slide 11

## Slide 12

## Slide 13

## Slide 14

## Slide 15

## Slide 16

## Slide 17

## Slide 18

## Proposed Focus

- Timing: API defined in ~9 months
- E.g., Jul’02: DRMAA v1.0 GWD submitted for review
- Standardize existing systems
- Don’t invent something new

## Next Steps...

- Solicit participation  YOU ARE HERE
- Especially resource management vendors & application developers
- Finalize charter, milestones, ...
- Discuss via sched-wg email list
- Submit to GGF chair to form DRMAA working group
- Draft/standardize API...

## Proposed Charter

**Develop an API specification for the submission and control of jobs to one or more Distributed Resource Management (DRM) systems.**
**The scope of this specification is all the high level functionality which is necessary for an application to consign a job to a DRM system including common operations on jobs like termination or suspension.**
**The objective is to facilitate the direct interfacing of applications to today's DRM systems by application's builders, portal builders, and Independent Software Vendors (ISVs).**

## Notes

- Good focus if it’s both quick, simple, and based on existing systems
- If it drags along, then maybe we should do a more in depth process
- Is this applicable from a web service point of view?
- XML? SOAP objects? Or some such