1. Chair(s):
   1. Geoffrey Fox (fox@mailer.scri.fsu.edu)
   2. Dennis Gannon (gannon@cs.indiana.edu)
   3. Mary Thomas (mthomas@sdsc.edu)
2. Mailing List: gce-wg@gridforum.org
   Archives http://www-unix.gridforum.org/mail_archive/gce-wg/maillist.html

   To subscribe to our email list, send email to majordomo@gridforum.org with the body "subscribe gce-wg". Do not include the quotation marks. You must be a member of an email list to post to it.

   If you subscribe to the working group list please be sure to also subscribe to the general list. To do this, send email to majordomo@gridforum.org with "subscribe grid-announce" as a single line in the message body.

The Grid Computing Environment working group is aimed at contributing to the coherence and interoperability of frameworks, portals, PSE's, and other Grid-based computing environments and Grid services. We will do this by deriving standards, protocols, API's and SDK's from "best practices" projects that are required to integrate technology implementations and solutions.

Definition of a Grid Computing Envrionment:
A GCE extends the users desktop by providing tools that access the Grid services.

Examples:

Portals: users, education - web, other
CACTUS, UNICORE, HotPage, LaunchPad, Mississippi Web Portal
Workflow: systems to help manage large tasks involving multiple steps
Applications - Cactus
Collaborative Envs: WebDav,  (a subset?)
Object frameworks:  application composition tools
How do we consider:
Shell/env, NES: Network enable service (Ninf, Netsolve)

One of the primary functions of this WG will be to collect information on GCE's, and synthesize the data into a set of relevant categories and subcategories of CGE activities. We then plan to use this information to define what GCE's are and what they do, how they accomplish their tasks, what technologies are used to do this, and what the resultant Grid services are needed to do these tasks, and how well are these projects able to use the existing Grid services and technologies.

We see the role of CGE with respect to the other WGs as shown below (this in not to imply that they do not have their own relationships):

   Portals/Apps/Users                 Grid Services

                                      |<--> GIS-WG
    Models-WG  <-->|                  |<--> Accts-WG
    Apps-WG    <-->| <--> GCE-WG <--> |<--> Performance-WG  
    Users-WG   <-->|                  |<--> Data-WG
    GCE-WG     <-->|                  |<--> Scheduling-WG
                                      |<--> Security-WG

Our function is to identify how developers are using the Grid and it's services, and by using a task-oriented approach to extract out functionality, API's, and protocols and to facilitate interoperability between users of the Grid and developers of the Grid based on what can be done today and what can/should be done in with next generation of software. Our information will have a bi-directional flow between service working groups and those that sit at "higher" levels of the 3-tier Grid architecture.

The GCE working group will initially focus on generating TS documents to provide API and protocol recommendations for the GCE group and other working groups. We will limit these to existing working projects. These API's and protocols will be built using the following process:

1. Identify "Best Practices" projects such as
   1. User portals
   2. Application Area portals and PSEs: CACTUS
   3. Grid Application workflow management
   4. Others.
2. Identify Tasks and "Atomic Tasks"
   1. User views to Grid services
   2. Abstract tasks for each GCE
   3. Identify if task matches to a working group
   4. Not all tasks will have a WG, nor will it need them
3. For each task, identify items such as:
   1. Associate with current WG's where possible
   2. Common/standard grid services, APIs, SDKs and Protocols, technologies
   3. Grid/Industry standard interop
   4. Architecture(s) for GCE framework(s).
   5. language independent
   6. common technologies used
   7. Note: API's can hide/encapsulate component architecture
4. Collect Software Toolkits for building Grid applications such as
   1. Java and Perl CoG's
   2. MyProxy, GSI
   3. GridPort and GPDK
5. Identify leads to champion each of these CP summaries - we won't start one unless we have a lead to do it.
6. Publish information into NLANR C/Klearinghouse
7. http://dast.nlanr.net/Clearinghouse
8. Generate TR's

GF Working Groups are expected to produce documents that fall into one of several categories including (but not limited to):

1. Applicability Statements (AS): documents that describe implementation of relevant standards, requirements and best practice to promote interoperability.
2. Community Practice (CP): Informational documents that describe best practices within the Grid community as they relate to particular areas of implementation, support, etc.
3. Informational, such as evaluation of real-world results of implementing and using Grid technologies, surveys of relevant technologies and approaches to a particular class of Grid service, generally aimed at determining interoperability mechanisms or choosing a particular approach for community practice.
4. Technical Specifications (TS) that describe specific approaches: API's, protocols, etc. All documents developed by a Working Group are subject to review as described below before being published as GF outputs. Milestones shall consist of deliverables that can be qualified as showing specific achievement; e.g., "Draft Document on Topic X finished" is fine, but "discuss via email" is not. It is helpful to specify milestones for every 3-6 months, so that progress can be gauged easily. This milestone list is expected to be updated periodically.

Expected impact with respect to Grid architecture, Grid infrastructure, or Internet Architecture in general.