SAGA: A Simple API for Grid Applications High-Level Application ...

4 COMPUTATIONAL METHODS IN SCIENCE AND TECHNOLOGYB. GridRPC-WGThe GridRPC API [13] represents ongoing work to standardizeand implement a portable and simple remote procedurecall (RPC) mechanism for grid computing. This standardizationeffort is being pursued through GridRPC WorkingGroup at GGF. The initial work in that group showed thatclient access to existing grid computing systems such asNetSolve [14], Ninf [15], and DIET [16], can be unified via acommon API, a task that has proven to be problematic in thepast. The group successfully created such an API specification,which is now a GGF Draft Recommendation [17].The cooperation with the SAGA-WG allows the GridRPC-WG to broaden the target user community for GridRPCsignificantly, and would also equip the GridRPC API witha look & feel which is compatible with the one used for othergrid programming paradigms. For example, the model forasynchronous calls used for RPCs will match the model forasynchronous calls of other paradigms, e.g. remote file access.C. GridCPR-WGGGFs Grid Checkpoint and Recovery (GridCPR) WorkingGroup [18] is devising an architecture for checkpointing longrunning applications for later recovery, possibly on differentgrid resources. GridCPR use cases include fault resilience,intermittent operation (using small time slices until final completion),as well as parameter space exploration using various,related checkpoints.The currently envisioned architecture encompasses servicesfor authentication/authorization, job management, checkpointstate management, checkpoint transfer, and event handling.Applications are supposed to use a GridCPR library, providingan API to these services. Details of this API arecurrently under investigation. As several concepts are similarto those defined by the SAGA API (copy/move checkpointfiles, read/write data, find files etc.), compatibility with SAGAis desired. That would provide application programmers witha more complete and consistent interface to the grid relatedcapabilities offered by the APIs.D. OGSA-WGThe Open Grid Services Architecture (OGSA) WorkingGroup at GGF defines a Web Service based architecture whicheventually will be the overarching design principle for all gridservices. The problem space targeted by the OGSA group atfirst seems unrelated to the SAGA effort but, in fact, representsthe class of service-oriented, middleware architectures thatcould be the target platform for many SAGA implementations.Such service-oriented architectures address many issues, suchas resource naming, state management, and security, that willrequire a simplified mapping into the SAGA API. Hence, theSAGA-WG is in active communication with the OGSA groupand other OGSA-related efforts to ensure the proper levelof compatibility by cross-reviewing their respective standarddocuments and by providing SAGA reference implementationson OGSA-based middleware systems.E. Other GGF Working GroupsThe Grid File Systems (GFS) Working Group [19] targetsthe definition of a architecture which integrates physical filesystems into a single global, uniform name space [20]. TheSAGA-WG uses the definitions for name spaces defined bythe GFS-WG, and hence has the same notion of files anddirectories as that group.The Byte-IO Working Group [21] defines an OGSA compatibleservice which allows for efficient remote access tobinary data, e.g. files. Also, the GridFTP Working Group [22]defined extensions to the standard FTP protocol which allowsfor efficient memory-to-memory and disk-to-disk data transferin grids. Both groups invest significant time in exploringparadigms for efficient remote data access. These paradigmsare partially reflected by the SAGA API.The JSDL Working Group [23] defines a XML based JobSubmission and Description Language. Although the SAGAAPI currently refrains from any explicit usage of XML, thekeywords used for the SAGA job descriptions reflect thosedefined by JSDL.The Persistent Archive (PA) Research Group [24], DataReplication (REP) Research Group [8] and the OGSA ReplicaServices (OREP) Working Group [25] have all worked onthe services that manage distributed data files for data grids.Their work [26] is reflected in the SAGA Logical File API,which adopts the concept of logical files (or ’replicas’) thatwas defined by these groups.IV. RELATED WORKThe work on the SAGA API is not an isolated effort, butbuilds on top of a number of previous projects targeting thesame problem space. The Globus-CoG is probably the mostprominent representative of an API which tries to specificallyabstract the Globus package. The GAT from the EU-GridLabproject targets already a more general abstraction of gridparadigms, and follows similar design principles as SAGA.Other projects such as RealityGrid and DataGrid/EGEE/LHCtarget the same problem space, but with interfaces withstronger focus on specific community needs. This sectiondescribes these efforts and their influence on SAGA in somedetail. In general, the SAGA-WG can be seen as the “GrandUnification” of all these grid APIs, which provides a moreuniform, middleware independent and standardized solutionfor grid application programmers.DRAFTA. GATThe design of the Strawman API and the ongoing workon a SAGA engine implementing this Strawman API is verymuch influenced by the experiences collected with the GridApplication Toolkit (GAT [3]).Figure 1 shows the GAT architecture. It mainly distinguishesbetween user space and capability space. In user space runsthe application code that has been programmed using the GATAPI. The GAT engine is a lightweight layer that dispatchesGAT API calls to service invocations via GAT adaptors.Adaptors are specific to given services and hide all servicespecificdetails from the GAT. A GAT engine typically loads