[saga-rg] SAGA-RG charter revision 2
Andre Merzky
andre at merzky.net
Thu Feb 9 10:04:26 CST 2006
19 or 20 sounds realistic I think. As always, delivering
earlier is no problem (purely theoretical statement) :-P
Andre.
Quoting [Tom Goodale] (Feb 09 2006):
> Date: Thu, 9 Feb 2006 09:59:22 -0600 (CST)
> From: Tom Goodale <goodale at cct.lsu.edu>
> To: saga-rg at ggf.org
> Subject: Re: [saga-rg] SAGA-RG charter revision 2
>
>
> GGF20 ?
>
> On Thu, 9 Feb 2006, Andre Merzky wrote:
>
> >Hi Tom,
> >
> >there is no milestone for the "SAGA API Guidelines" doc - I
> >guess we should have that (no too early).
> >
> >Quoting [Tom Goodale] (Feb 09 2006):
> >>Date: Thu, 9 Feb 2006 06:59:22 -0600 (CST)
> >>From: Tom Goodale <goodale at cct.lsu.edu>
> >>To: saga-rg at ggf.org
> >>Subject: [saga-rg] SAGA-RG charter revision 2
> >>
> >>
> >>Latest version with Steven's comments, and spell-checked this time 8-)
> >>
> >> Informational Section
> >> ---------------------
> >>
> >> Area: Applications [Standards]
> >>
> >> Name of group: Simple API for Grid Applications Research Group
> >>
> >> Acronym: SAGA-RG
> >>
> >> Type of group: Reasearch Group (RG)
> >>
> >> Chairs: Tom Goodale, Shantenu Jha, Thilo Kielmann
> >>
> >> Secretaries: TBD
> >>
> >> Email list: saga-rg at ggf.org
> >>
> >> Web page: http://forge.ggf.org/projects/saga-rg/
> >>
> >>
> >> Charter:
> >> -------
> >>
> >> This charter is the result of a re-chartering of the SAGA Research
> >> Group.
> >>
> >> Focus/Purpose:
> >> -------------
> >>
> >> Many application developers wish to make use of the exciting
> >> possibilities opened up by the advent of the Grid. Application
> >> developers, however, have their own 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 example, the process of copying of a remote file may involve
> >> interaction with a replica location service, a data transport
> >> service, a resource management service, and a security service.
> >> It may involve communication via LDAP/LDIF, GRAM, HTTP, and GSI,
> >> as protocols or protocol extensions. A Fortran application
> >> programmer, however, 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 developed by this RG will deliver a similar
> >> level of abstraction for a range of basic operations which need to
> >> be grid aware. The precise set of operations is to be decided by
> >> the RG based upon application requirements and use cases; examples
> >> of such operations may be file access, job submission, monitoring
> >> or steering.
> >>
> >> Scope:
> >> -----
> >>
> >> The group will build on the results and feedback of the work of
> >> the former SAGA RG. As such, it will provide a forum in GGF to
> >> consolidate application driven API specifications. The primary
> >> goals of the group are two fold:
> >>
> >> 1) provide general guidelines for application driven API
> >> specifications in GGF (security guidelines, common look & feel,
> >> interoperability guidelines, conflict resolution, etc.)
> >>
> >> 2) The group will form, on an ad hoc basis, design teams
> >> which investigate new API areas for inclusion in the SAGA-API
> >> The design teams will
> >>
> >> - solicit related application use cases
> >> - issue an informal use case document
> >> - issue an informal requirement document
> >>
> >> 3) Spawn off focused working groups which will work on API
> >> specifications (standard recommendation track) for specific
> >> subsystems, e.g. RPC, CPR, application steering etc, after
> >> a design team has identified and explored an area as described
> >> in (2) above.
> >>
> >> 4) Coordinate the activities of the SAGA working groups and
> >> make sure that the resulting APIs are in line with the
> >> SAGA goals.
> >>
> >> The SAGA API does not strive to replace Globus or
> >> similar middleware systems, and does not target middleware
> >> developers, but solely application developers with no assumed
> >> background on Grid Computing 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 goals and minimise the time spent coding
> >> infrastructure functionality. The API will insulate application
> >> developers from middleware.
> >>
> >> 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
> >> be used to implement the functionality that the application
> >> developer needs. The RG will, however, actively liaise with all
> >> grid-middleware groups within the GGF.
> >>
> >>
> >> Exit Strategy:
> >> --------------
> >>
> >> No clear exit strategy for this group exists, as it is supposed to
> >> provide means to continuously spawn off focused working groups.
> >> However, the group does have a list of deliverables, and should
> >> revisit its charter after these deliverables have been completed.
> >>
> >>
> >> Goals:
> >> ------
> >>
> >> Note: As this charter is a result of a re-chartering process for
> >> the SAGA RG, it also contains goals and deliverables which have
> >> already been, or are currently in the process of being
> >> delivered.
> >>
> >> The group will produce an informal use case document ("SAGA
> >> Use-Case Document") and a informal requirement document ("SAGA
> >> Requirements Document").
> >>
> >> In continuation, and broadening its scope, the group will create a
> >> Community Practise Document "SAGA API Guidelines", which will
> >> define the Look & Feel of SAGA APIs, and describe central
> >> paradigms (such as asynchronous operations and error handling)
> >> which should be respected in SAGA API specifications. That
> >> document will build upon the experience of the SAGA-CORE WG and their
> >> initial SAGA API specification v1.0.
> >>
> >> These documents are to guide the spawned off working
> >> groups, and to ensure short and concise working agendas for these
> >> groups. The formation of design teams is informal, and should
> >> always strive to find members from the specific areas of
> >> expertise - i.e. members from the relevant GGF community groups,
> >> and members from the relevant GGF standards groups.
> >>
> >>
> >> * Informational Document:
> >> "SAGA Use Case Document"
> >> - use cases
> >>
> >> * Informational Document:
> >> "SAGA Requirements document"
> >> - define exact scope of the initial SAGA API
> >> - define target user groups for initial SAGA API
> >> - define programming languages to be supported by the initial
> >> SAGA API
> >>
> >> * Informational Document:
> >> "SAGA use of other Grid specifications"
> >> This document will survey the survey and evaluate SAGA
> >> reference implementations with underlying models of
> >> grid-middleware including, but not confined to OGSA.
> >>
> >>
> >> * Community Practise Document:
> >> "SAGA API Guidelines"
> >> This document will define the Look & Feel of SAGA APIs,
> >> and describe central paradigms (such as asynchronous
> >> operations and error handling) which should be respected
> >> in SAGA API specifications.
> >>
> >> Milestones:
> >> -----------
> >>
> >> GGF16: - Finalisation of "SAGA Use Case Document, version 1"
> >> - Presentation of "SAGA Requirements document, version 1"
> >>
> >> GGF17: - Finalisation of "SAGA Requirements document, version 1"
> >>
> >> GGF19: - Presentation of "SAGA use of other Grid
> >> specifications, version 1"
> >
> >
> >
> >
--
"So much time, so little to do..." -- Garfield
More information about the saga-rg
mailing list