SAGA: Simple API for Grid Applications

SAGA: Simple API for Grid Applications Steven Newhouse Application Standards Area Director

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 2

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 3

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 4

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 5

Code examples 2 • Asynchronous combined operations saga::task task = f.copy <saga::task::Async> ("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 6

Use cases Requirements Liaisons Group structure SAGA-RG SAGA-Core-WG Specifications • Look & feel • Core API • Extensions 7

Functional Requirements • Planned API Scope: • Taken from use case document • Number of use cases • Implementation • Prioritized by active participation • Separated into packages 8

Non-Functional Requirements • Drawn from use cases as well • Orthogonal to functional req’s • Define look & feel 9

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 10

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 11

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) 12

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 13

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 14

SAGA: Simple API for Grid Applications