The Charter Informational Section --------------------- Area: Applications and Programming Environments (APME) Name of group: Simple API for Grid Applications Acronym: SAGA-RG Type of group: Research Group (RG) Chairs: Tom Goodale goodale@cct.lsu.edu Keith Jackson krjackson@lbl.gov Stephen Pickles stephen.pickles@man.ac.uk Secretaries: Shantenu Jha s.jha@ucl.ac.uk Krzysztof Kurowski krzysztof.kurowski@man.poznan.pl Ian Taylor ian.taylor@astro.cf.ac.uk Email list: saga-rg@ggf.org Web page: http://forge.ggf.org/projects/saga-rg/ Charter: ------- Focus/Purpose: ------------- Many scientific application developers wish to make use of the exciting possibilities opened up by the advent of the Grid. These developers, however, have their own scientific agendas to pursue and often cannot spare the time or resources to fully investigate the vast wealth of Grid technologies and APIs which currently exist. They would rather be presented with a simple API close to the programming paradigms and interfaces they are used to for the fairly simple common operations they need to perform, e.g remote job submission, file transfer, etc. A Fortran application programmer wants to see a call very much like: call fileCopy (source, destination) Although this example is simplified, it illustrates the motivation for our work. The APIs specified by this RG will deliver a similar level of abstraction for a small set of basic Grid operations. The precise set of operations is to be decided by the RG based upon application requirements, but our initial focus will be on file transfer and job submission. The group will lower the barrier for scientific application developers to make use of the grid by providing a small, consistent API for the operations of interest, the Simple API for Grid Applications (SAGA). Scope: ----- The proposed API specifically targets scientific applications, which aim to take advantage of some of the features that the Grid offers. The exact coverage will be decided by the group, but simplicity and conciseness will be the governing principles. The API targets developers of scientific applications who wish to grid enable their applications whilst spending as little time as possible learning new paradigms. Such developers typically wish to devote their time to their own scientific goals and minimize the time spent coding infrastructure. The specification of services and the protocols to interact with them is out of the scope of the RG. Rather, the API seeks to hide the detail of any service infrastructures that may or may not exist to implement the functionality that the application developer needs. Various projects have been working to develop APIs for their particular scientific areas, for example the EU GridLab, the CoG Projects, and the UK e-Science RealityGrid projects. The group will identify such projects and seek their input in the development of the proposed API and its implementation. Goals: ------ The main goal of the group is the creation of an abstract API specification as a GGF informational document. On the road to that specification, the following documents are planned: * Informational Document: "Use cases and application scenarios survey" - use cases - application scenarios - operations which should be supported * Informational Document: "Requirements document" - define exact scope of API - define target user groups for API - define programming languages to be supported - define organization of API documents (e.g. one per subsystem or language, or one complete document) * Experimental Document: "Abstract definition of SAGA" - this abstract API must be language neutral but permit implementation in all targeted languages - it should describe the expected behaviour of operations in terms of objects exposed by the interface Milestones: ----------- GGF12: Presentation of "Use cases and application scenarios" survey document. GGF13: Presentation of "Requirements document" GGF14: Draft of "Abstract definition of SAGA" GGF15: Final version of "Abstract definition of SAGA" Management Issues: ------------------ Evidence of commitments to carry out RG tasks: The RG chairs are actively involved in research projects targeting grid user communities, or are actively working on the grid-enablement of scientific applications. All chairs are already active in GGF, and participate on a regular basis, and are committing time to GGF work. They will continue to do so. The RG secretaries are also familiar with the GGF work, and will commit significant time to the organisation of the group. Previous relevant work is funded by various projects world wide to address real world requirements, and several of those projects have agreed to commit person time to this working group. Pre-existing Documents: ---------------------- A specification of a Grid-API has been produced by the EU GridLab project through its work on the Grid Application Toolkit (GAT), and will serve as input to the work of the group. This document is published and maintained at http://www.gridlab.org/. 'The CoG projects have implemented simple APIs that will also be used as input to the groups work. Exit Strategy: ------------- The exit strategy is the production of the three documents described above. At that time we will evaluate the work of the RG and, if appropriate, recommend the formation of a Working Group to write the GGF Recommendation documents describing the concrete binding of the abstract SAGA API to several different target languages. Group Evaluation Criteria - The Seven Questions - ------------------------- 1. Is the scope of the proposed group sufficiently focused? As described above, simplicity and conciseness are the governing principles for the specification of the proposed SAGA. That will naturally lead to a very narrow focus. The scope of the API will be precisely specified by the first two documents, which cover application scenarios, and derive the API requirements from those. Specifically, the group intends to focus on several well defined capabilities available in Grid environments, and does not intend to meet the needs of people developing low-level grid applications or grid middle-ware. 2. Are the topics that the group plans to address clear and relevant for the Grid research, development, industrial, implementation, and/or application user community? Previous work and research in close relation to the scientific user community the group targets at has shown extremely positive response to the goals of this group. We hope to enable a vast number of applications to utilise Grid environments, and think that this is extremely important for the acceptance of Grid in general. 3. Will the formation of the group foster (consensus-based) work that would not be done otherwise? Many GGF groups work on APIs for Grid application programmers, and the group is well aware of these activities. No group is targeting scientific and Grid-unaware application programmers by providing simple interfaces to basic Grid services. We believe that the work done by this group will serve the needs of a large number of those involved in the APME area and will provide a valuable conduit between the application community and the other GGF RGs. 4. Do the group's activities overlap inappropriately with those of another GGF group or to a group active in another organisation such as IETF or W3C? Again, we are aware of some overlap with other GGF groups in the scope of the proposed API. But the design constraints of the SAGA requires significant simplification, and hence limitation, of these APIs. Other areas of the SAGA are not covered by any single group (or API) at GGF, but where there is overlap this group will work closely with the other relevant GGF RGs. The group will invest time and effort to avoid duplication or contradictory work in respect to other GGF groups, and to prevent the use of the simplified APIs we develop from providing a barrier to later adoption of the more sophisticated APIs developed elsewhere. 5. Are there sufficient interest and expertise in the group's topic, with at least several people willing to expend the effort that is likely to produce significant results over time? The group has gathered active commitments from individuals, project, communities and from industry. Active group members are actively involved in research on that topic, and provide the needed expertise. There exist commitments for active writing on all documents planned. The chairs and secretaries commit to actively work on group organisation through the lifetime of the group. 6. Does a base of interested consumers (e.g., application developers, Grid system implementers, industry partners, end-users) appear to exist for the planned work? The work of the group is triggered and initiated by user demands - that is one of our major strengths. We can list 20+ scientific application groups willing to adapt the SAGA as it emerges. The Applications and Applications Programming Interfaces RG of the EU funded GridStart project and the CoG project have agreed to focus on contributing to the proposed SAGA-RG. Prior to the successful BoF at GGF 9, the group leaders received very positive feedback to the group's purpose. The BoF itself produced further positive feedback, in particular from the industrial sector, such as Cisco, IBM, and Intel, all of whom expressed interest in collaboration in the development of the API and its adoption. 7. Does the GGF have a reasonable role to play in the determination of the technology? The scope of SAGA is a subset of capabilities of the Grid, and hence a subset of the capabilities and interfaces defined by GGF groups. The group will naturally follow and profit from the expertise present in these groups.