1. © 2007 Open Grid Forum SAGA: Simple API for Grid Applications Steven Newhouse Application Standards Area Director

2. © 2007 Open Grid Forum 2 Why SAGA? Using a Grid is very, very hard work Application Research Group workshops Ed Sidel, Simon Cox, et. al. Evolving & different interfaces Grids need users & users need stability Write once, run anywhere – code portability Compare with parallel computing PVM vs. MPI

3. © 2007 Open Grid Forum 3 Portability & Interoperability User communities want portability Run across a single grid Run across many grids Maximum return on minimal application coding Service providers want interoperability Avoid lockin to a single product/supplier Federate resources around standards

4. © 2007 Open Grid Forum 4 SAGA - Overview SAGA: Simple API for Grid Applications Define application level abstractions A stable look & feel for all APIs (core APIs) Packages for particular abstract APIs (e.g. jobs, files, …) Renderings of abstract APIs to concrete language bindings Influences: GAT, CoG, DRMAA, GridRPC, LSF, OREP, JSDL, … Use case driven: Simplicity versus control: 80:20 rule Primary API activity within OGF APIs are the main focus of the Application Standards area Other OGF standards activity focusses on protocols SAGA: Application Client Protocols: Server Client interaction

5. © 2007 Open Grid Forum 5 Code examples 1 Synchronous file access saga::file f ("gridftp://remote.host.net/data/data.bin"); char buf[100]; if ( f.get_size() >= 223 ) { int pos = f.seek (123, Current); int len = f.read (buf, sizeof(buf)); } Read 100 bytes from a given remote file starting at byte position 123

6. © 2007 Open Grid Forum 6 Code examples 2 Asynchronous combined operations saga::task task = f.copy ("b"); saga::job job = js.run_job ("remote.host.net", "/bin/date"); saga::task_container tc; tc.add (task); tc.add (job); tc.wait (); // wait for task and job to complete Copy file, run job and wait for both

7. © 2007 Open Grid Forum 7 Group structure SAGA-RGSAGA-Core-WG Use cases Requirements Liaisons Specifications Look & feel Core API Extensions

8. © 2007 Open Grid Forum 8 Functional Requirements Planned API Scope: Taken from use case document Number of use cases Implementation Prioritized by active participation Separated into packages

9. © 2007 Open Grid Forum 9 Non-Functional Requirements Drawn from use cases as well Orthogonal to functional reqs Define look & feel

10. © 2007 Open Grid Forum 10 Participation Design team formed from members of: GAT, CoG, DRMAA, JSDL, PyGlobus… First meeting Summer 2004 Participation is decreasing over time Please get involved Active core of about 10 people LSU, VU, EPCC, OMII-UK, NAREGI/NEC Getting good feedback from other groups inside & outside of OGF, though

11. © 2007 Open Grid Forum 11 Documents Existing: Use Cases (GFD.70), Requirements (GFD.71) SAGA-Core API (GFD.90), out of public comment Upcoming (OGF20/21): SAGA-Message API (GFD.91) SAGA-CPR API (GFD.92) SAGA-Advert API (GFD.93) C++ and Java bindings Planned (no agreed timeline): SAGA-Service Discovery API SAGA-Steering API SAGA-DAIS

12. © 2007 Open Grid Forum 12 Existing implementations C++ Implementation (LSU/VU) Implements full API plugin architecture (any middleware) Java Implementations: DEISA/EPCC: Partial API (Job and File package) Binds to UNICORE only NAREGI/NEC Partial API (Job package) Binds to NAREGI only OMII-UK Implements full API Binds to OMII-UK (being superseeded)

13. © 2007 Open Grid Forum 13 Upcoming Implementations C++ Implementation (LSU/OMII-UK) Bindings to OMII (GridSAM) Bindings for Globus GT4 pre-WS Java Implementation (VU/OMII-UK) Implements full API, plugin architecture Bindings to OMII (GridSAM) Bindings for Globus GT4 pre-WS C and Python bindings (LSU/OMII-UK) On top of C++ implementation

14. © 2007 Open Grid Forum 14 Summary SAGA is primary application oriented API for OGF Specification work is going well Implementation is progressing Outreach has to be improved Need vendor adoption Need participation SAGA needs YOU