Content deleted Content added
m fix RAS syndrome |
ShelfSkewed (talk | contribs) Edited disambig hatnote |
||
(19 intermediate revisions by 16 users not shown) | |||
Line 1:
{{Short description|Grid computing application programming interface}}
{{Redirect|SAGA (computing)||Saga (disambiguation)#Computing}}
{{Infobox software
| logo = [[File:Logo saga.png|220px|SAGA C++/Python logo]]
| screenshot =
| developer = [[Center for Computation and Technology]] at [[Louisiana State University|LSU]], [http://radical.rutgers.edu/ RADICAL Group] at [[Rutgers University]], [http://www.in2p3.fr/ IN2P3 (France)], and [http://www.vu.nl/ Vrije Universiteit (Amsterdam,
| programming language = [[C++]], [[Python (programming language)|Python]], [[Java (programming language)|Java]]
| platform = [[Cross-platform]]
Line 17:
The SAGA specification for distributed computing originally consisted of a single document, GFD.90, which was released in 2009.
The SAGA [[API]] does not strive to replace
The specification of services, and the protocols to interact with them, is out of the scope of SAGA. Rather, the API seeks to hide the detail of any service infrastructures that may or may not be used to implement the functionality that the application developer needs. The API aligns, however, with all middleware standards within [[Open Grid Forum]] (OGF).<ref name="gdf90">{{Cite journal | author1=T. Goodale
The SAGA API defined a mechanism to specify additional API ''packages'' which expand its scope. The SAGA Core API itself defines a number of packages: job management, file management, replica management, remote procedure calls, and streams. SAGA covers the most important and frequently used distributed functionality and is supported and available on every major grid systems - [[Extreme Science and Engineering Discovery Environment]] (XSEDE), EGI and FutureGrid. SAGA not only supports a wide range of distributed programming and coordination models but is also easily extensible to support new and emerging middleware.<ref>SAGA: A Simple API for Grid applications, High-Level Application Programming on the Grid
Tom Goodale, Shantenu Jha, Harmut Kaiser, Thilo Kielmann, Pascal K leijer, Gregor von Laszewski, Craig Lee, Andre Merzky, Hrabri Rajic, John Shalf
Computational Methods in Science and Technology, vol. 12 # 1, 2006</ref><ref>Grid Interoperability at the Application Level Using SAGA
Line 28:
== Standardization ==
The SAGA API is standardised in the SAGA Working Group the [[Open Grid Forum]].<ref>{{cite web | url=http://redmine.ogf.org/projects/saga-wg | title=Overview - SAGA WG - Open Grid Forum }}</ref> Based on a set of use cases
<ref>Shantenu Jha, Andre Merzky: "A Collection of Use Cases for a Simple API for Grid Applications", OGF Informational Document, [http://www.ogf.org/documents/GFD.70.pdf GFD.70 (pdf)]</ref>
,<ref>Shantenu Jha, Andre Merzky: "A Requirements Analysis for a Simple API for Grid Applications", OGF Informational Document, [http://www.ogf.org/documents/GFD.71.pdf GFD.71 (pdf)]</ref>
the SAGA Core API specification<ref
All SAGA specifications are defined in (a flavor of) [[Interface description language|IDL]], and thus object oriented, but language neutral. Different language bindings exist (Java, C++, Python), but are, at this point, not standardised. Nevertheless, different implementations of these language bindings have a relatively coherent API definition (in particular, the different Java implementations share the same abstract API classes).
Line 48:
[[File:SAGA Architecture.png|thumb|236px|The SAGA C++/Python architecture: a light-weight [[run-time system|runtime system]] dispatches API calls from the application to the [[middleware]] through a set of [[plug-in (computing)|plug-ins]] or ''adaptors''.]]
SAGA is designed as an [[Object-oriented programming|object oriented]] interface. It encapsulates related functionality in a set of objects, that are grouped in functional [[namespace]]s, which are called ''packages'' in SAGA. The SAGA core implementation defines the following packages:<ref>{{Cite web | title=The SAGA C++ Reference API (Documentation)
* saga::advert - interface for [[Advert Service]] access
Line 59:
* saga::stream - interface for data stream client and servers
The overall architecture of SAGA follows the [[adaptor pattern]], a [[software design pattern]] which is used for translating one interface into another. In SAGA it translates the calls from the API packages to the interfaces of the underlying middleware. The SAGA run-time system uses [[late binding]] to decide at [[program lifecycle phase|run-time]] which [[plug-in (computing)|plug-in]] (''middleware adaptor'') to load and bind.<ref>{{Cite web | title=SAGA: How it works|
== Supported middleware ==
Line 74:
| [[Eucalyptus (computing)|Eucalyptus]] || saga-adaptors-aws || saga::job
|-
|
|-
| Globus [[GridFTP]] || saga-adaptors-globus || saga::filesystem
Line 105:
== Implementations ==
Since the SAGA interface definitions are not bound to any specific programming language, several implementations of the SAGA standards exist in different programming languages. Apart from the implementation language, they differ from each other in their completeness in terms of standard coverage, as well as in their support for distributed middleware.
=== SAGA C++ ===
=== RADICAL-SAGA(Python) ===
=== JavaSAGA ===
JavaSAGA is a Java implementation of SAGA. This status of JavaSAGA remains uncertain.
<syntaxhighlight lang="java">
import java.util.io.*
int main (int argc, char** argv)
{
namespace sa = saga::attributes;
namespace sja = saga::job::attributes;
try
{
saga::job::description jd;
jd.set_attribute (sja::description_executable, "/home/user/hello-mpi");
jd.set_attribute (sja::description_output, "/home/user/hello.out");
jd.set_attribute (sja::description_error, "/home/user/hello.err");
// Declare this as an MPI-style job
jd.set_attribute (sja::description_spmd_variation, "mpi");
// Name of the queue we want to use
jd.set_attribute (sja::description_queue, "checkpt");
jd.set_attribute (sja::description_spmd_variation, "mpi");
// Number of processors to request
jd.set_attribute (sja::description_number_of_processes, "32");
saga::job::service js("gram://my.globus.host/jobmanager-pbs");
saga::job::job j = js.create_job(jd);
j.run()
}
catch(saga::exception const & e)
{
std::cerr << "SAGA exception caught: " << e.what() << std::endl;
}
}
</syntaxhighlight>
=== jSAGA ===
=== DESHL ===
The
== Examples ==
Line 166 ⟶ 167:
===Job submission===
A typical task in a distributed application is to submit a ''job'' to a local or remote [[distributed resource manager]]. SAGA provides a high-level API called the ''job package'' for this. The following two simple examples show how the SAGA job package API can be used to submit a [[Message Passing Interface]] (MPI) job to a remote Globus GRAM resource manager.
<
#include <saga/saga.hpp>
Line 205 ⟶ 206:
}
</syntaxhighlight>
<
#!/usr/bin/env
import sys
import
import bliss.saga as saga
def main(jobno: int, session, jobservice) -> None:
bfast_base_dir = saga.Url("sftp://india.futuregrid.org/N/u/oweidner/software/bfast/")
try:
workdir = "%s/tmp/run/%s" % (bfast_base_dir.path, str(int(time.time())))
Line 224:
jd = saga.job.Description()
jd.wall_time_limit = 5 # wall-time in minutes
jd.total_cpu_count = 1
jd.environment = {
jd.working_directory = workdir
jd.executable =
jd.arguments = [
myjob = js.create_job(jd)
myjob.run()
print
% (jobno, myjob.jobid, workdir))
myjob.wait()
print
% (jobno, myjob.jobid, myjob.exitcode, workdir))
basedir.close()
except saga.Exception, ex:
print
sys.exit(-1)
if __name__ == "__main__":
▲ execution_host = saga.Url("pbs+ssh://india.futuregrid.org")
ctx = saga.Context()
ctx.type = saga.Context.SSH
ctx.userid =
ctx.userkey =
session = saga.Session()
Line 262 ⟶ 261:
js = saga.job.Service(execution_host, session)
for i in range
main(i, session, js)
</syntaxhighlight>
== Grants ==
The work related to the SAGA Project is funded by the following grants: NSF-CHE 1125332 (CDI),<ref>[https://archive.
== External links ==
|