[saga-rg] SAGA-RG charter revision 2

[Tom Goodale]

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"
>
>
>
>