[saga-rg] SAGA-RG charter revision 2

[Andre Merzky]

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