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

6 COMPUTATIONAL METHODS IN SCIENCE AND TECHNOLOGYD. gLite and othersA number of more domain-specific interfaces exist whichtry to shield application developers from the complexities anddynamic behavior of grid middleware in that domain. Notablyamongst these interfaces is gLite’s ’Grid Access Service’(GAS) [34]. Similar to SAGA, the GAS defines a Servicewhich provides a simplified, stable and abstract interface to thecomplete gLite middleware infrastructure. Despite its differingarchitectural approach, the goals and scope of the GAS is verysimilar to the SAGA effort, and are considered as valuableinput to the SAGA design.V. SAGA DETAILSAs of October 2005, the SAGA API specification is convergingtoward a coherent document. The intended scopeseems well covered, and the use cases which have beenmotivating that scope seem to be well implementable withthe current API version. SAGA endeavors to provide the gridapplications programmer with a common look & feel across allfunctional areas. Any potential future extensions of the SAGAAPI will inherit the same look & feel and so form an integraland easy to learn new parts of the API.This section describes the API in its current state in somedetail, and shows examples of its usage. However, this descriptionand the examples are not meant to be normative, andwill with some certainty differ in many details from the finalSAGA API specification, which is expected in 2006.A. Session Handling and SecurityAn essential part of the SAGA programming model isformed by the API’s session management and security handling.In order to keep the API usage simple and transparentto the application, however, any session and security handlingis optional. A default session handle is used if no explicithandle is specified, and a SAGA implementation is requiredto initialize available default security tokens as available, e.g.,the default Globus certificate is to be used if it is found in itsstandard location.However, if required, an application can create multipleindependent session handles. To each of these sessions, explicitsecurity tokens (called context in SAGA) can be attached.Any SAGA object creation and method invocation can thenassociated with that session handle, and is required to use thespecified security tokens. The code example in Figure 2 showshow to access a remote file using a myproxy login.B. Data ManagementRemote data access and management certainly belong tothe most understood and most widely used paradigms indistributed environments. Grids however apply subtle changesto the well known remote paradigms, which need to bereflected in the SAGA API. The data management parts ofthe API are hence a blend of well known paradigms (suchas POSIX like directory navigation) and new grid paradigms(such as replica management).Fig. 2.Code Example: Session and Security Handling in SAGA#include #include void sample_session (){try{// create a SAGA session handlesaga::session s;// create a myproxy context ...saga::context c (saga::context::MyProxy);// ... and fill itc.set_attribute ("username", "andre");c.set_attribute ("password", "secret");// attach the context to the sessions.add_context (c);// create a file in that sessionsaga::file f (session,"gsiftp://ftp.host.net/pub/INDEX");// further code see later file examples}catch ( saga::exception e ){std::cerr