[saga-rg] Group Charters...
Andre Merzky
andre at merzky.net
Sun Feb 5 09:51:28 CST 2006
Hi,
notwithstanding the fact that the group did not yet finalize
its decision on WG/RG formationsplitflip, we don't have much
time until GGF16 to settle the formal issues of that
process. As a split is amongst our options, we need to
discuss the appropriate charter updates for the resulting
groups (Thanks to the ADs for the reminder).
Attached are drafts for a WG and RG charter (they are in
CVS).
Please note that the groups in question are named SAGA RG
and SAGA WG -- that is not normative ;-) as we did not
decide on the names yet, either.
Please also note that the list of deliverables etc. is
sketchy at best - I am not sure what document should get
finalized in which group. However, feedback would be most
welcome to the scope and goals section of the RG charter.
As we settle on that part, the remaining pieces should fall
into place.
The drafts are solely my opinion right now, and probably
somewhat off target - so don't blame the other chairs,
please :-)
I assume that we don't need to answer the (in)famous 'Seven
Questions' again, as I think there is no doubt that the
groups have a right to exist - they are called for by the
GFSG, right?
Cheers, Andre.
--
"So much time, so little to do..." -- Garfield
-------------- next part --------------
The Charter
Informational Section
---------------------
Area: Applications [Standards]
Name of group: Simple API for Grid Applications
Acronym: SAGA RG
Type of group: Reasearch Group (RG)
Chairs: TBD
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 specified by this WG 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 WG based upon application requirements and use cases; examples
of such operations may be file access, job submission, monitoring
or steering.
The group will lower the barrier for 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 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 guidlines for application driven API
specifications in GGF (security guidlines, common look & feel,
interoperability guidlines, conflict resolution, etc.)
2) spawn off focused working groups which will work on API
specifications (standard recommendation track) for specific
subsystems, such as RPC, CPR, application steering etc.
To ensure that the API developments spawned off by this Research
Group do not merrily reflect what GGF middleware groups deem
useful for applications, but are indeed really application driven,
the scope of the research group and its spawned off working groups
will primarily be defined by use cases. Simplicity (80:20 rule)
and conciseness will be the governing principles for API design.
Specifically, the SAGA API does not strive to replace globus or
similar middlerware systems, and does not target middlware
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 WG. 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. The RG will, however, actively liase with all
grid-middleware groups within the GGF to ensure compatability.
The SAGA RG has close historical ties to the SAGA WG, which
depends on the work of this RG. In fact, for all practical
purposes the SAGA WG can be considered to be the first group
spawned off from the SAGA RG. As such, an additional task of the
SAGA RG is to support accompany and support the work of the
SAGA WG.
Exit Strategy:
--------------
No clear exit strategy for this group exists, as it is supposed to
provide means to continously 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 already
have been delivered, or are currently in the process of beeing
deliverd.
The group will produce an informal use case document ("SAGA
Use-Case Document") and a informal requirement document ("SAGA
Requirements Document"). Both of these documents are the basis
on which the SAGA WG will define the initial SAGA API v1.0.
In continuation, and broadening its scope, the group will create a
Community Practice Document "SAGA API Guidlines", which will
define the Look & Feel of SAGA APIs, and describe central
paradigms (such as asynchroneous operations and error handling)
which should be respected in SAGA API specifications. That
document will build upon the experience of the SAGA WG and their
initial SAGA API specification v1.0.
Further, the group will form, on an ad hoc basis, design teams
which prepare the spawn off of dedicated API working groups.
The design teams are supposed to
- solicit related application use cases
- issue an informal use case document
- issue and informal requirement document
These documents are supposed to guide the spawned off working
groups, and to ensure short and concise working agendas for these
groups. The formation of design teams is informell, and should
always strive to find members from the specific areas of
expertiese - 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 compatability with GGF middleware"
This document will survey the compatability of SAGA
reference implementations with underlying models of
grid-middleware including, but not confined to OGSA.
Milestones:
-----------
GGF16: - Finalization of "SAGA Use Case Document"
- Presentation of "SAGA Requirements document"
- Form a "SAGA GridRPC Design Team"
- Form a "SAGA GridCPR Design Team"
- Form a "SAGA Steering Design Team"
- Form a "SAGA Persistency Design Team"
GGF17: - Finalization of "SAGA Requirements document"
- Form a "SAGA Security Design Team"
- Presentation "SAGA Use Case Document for GridRPC"
- Presentation "SAGA Requirement Case Document for GridRPC"
- Presentation "SAGA Use Case Document for GridCPR"
- Presentation "SAGA Use Case Document for Steering"
- Presentation "SAGA Use Case Document for Persistency"
-------------- next part --------------
The Charter
Informational Section
---------------------
Area: Applications [Standards]
Name of group: Simple API for Grid Applications
Acronym: SAGA-WG
Type of group: Working Group (WG)
Chairs: TBD
Secretaries: TBD
Email list: saga-wg at ggf.org
Web page: http://forge.ggf.org/projects/saga-wg/
Charter:
-------
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 specified by this WG 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 WG based upon application requirements and use cases; examples
of such operations may be file access, job submission, monitoring
or steering.
The group will lower the barrier for 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 initial SAGA-RG collected a number of application use cases
which are published in the GGF Document n umber GFD-???. The work
of this group will be based on this use cases, which will define
the scope and target application areas for the API. Simplicity
and conciseness will be the governing design principles.
The specification of services and the protocols to interact with
them is out of the scope of the WG. 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. The WG will, however, actively liase with all
grid-middleware groups within the GGF to ensure compatability.
The WG will continue to identify projects outside GGF with similar
API-focus and goals, and will seek their input in the development
of the API and its implementation. The WG will provide detailed
examples and cook-book.
Exit Strategy:
--------------
The group will finish its work after the publication of the API
Specification as GGF standard recommendation, accompanied by
documents for API language bindings.
Goals:
------
The SAGA-WG is the logical evolution of the SAGA-RG, which
produced the informational document ("SAGA Use-Case Document").
The main goal of the WG is the creation of an API specification as
a GGF standard recommendation. On the road to that specification,
SAGA-WG will build upon the SAGA-RG documents and produce the
following:
* Informational Document:
"Requirements document"
- define exact scope of API
- define target user groups for API
- define programming languages to be supported
- define organisation of API documents (e.g. one per subsystem
or language, or one complete document)
* Informational Document:
"SAGA compatability with GGF middleware"
This document will survey the compatability of SAGA
reference implementations with underlying models of
grid-middleware including, but not confined to OGSA.
* Recommendation Document:
"SAGA-API Specification"
The SAGA API specification.
Milestones:
-----------
GGF16: - Presentation of "Requirements document"
- SAGA API Specification pre-v1.0
GGF17: - Submission of SAGA API Specification v1.0
- Submit Informational Document "SAGA Compatability with GGF middleware"
- Implementation details review.
GGF19: - Present Draft Language Bindings (C++/Java/Fortran)
More information about the saga-rg
mailing list