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@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"
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
To: saga-rg@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@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
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
To: saga-rg@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@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"
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
To: saga-rg@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
To: saga-rg@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@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
participants (2)
-
Andre Merzky
-
Tom Goodale