Proposed Grid Protocol Architecture Working Group

1. ProposedGrid Protocol Architecture Working Group (Johnston, Foster, Moore) GGF-1

2. Issues • How do we answer the question “what is a minimal set of protocols?” • characterize existing Gird protocols and where GF WGs are working • straw examples – IPG arch.; Moore-Johnston picture from last GF meeting; Foster, et al, Anatomy of Grid • What should a GPA WG accomplish in year one? Grid Protocol Architecture Working Group

3. GGF-1 BOF • About 40 people attended Grid Arch. BOF • 25 signed up for an email list • points of the draft charter were discussed • Consensus: developing an architecture is useful • Less consensus: What is it’s utility? • vision for the Grid for GF • identify missing components and surplus components in GF work • a tool for guidance of GF working groups (via GFSC) Grid Protocol Architecture Working Group

4. GGF-1 BOF • Proposal: • Form a GGF WG • A WG charter, including work plan, will be developed prior to July meeting • The charter will be discussed, finalized, and forwarded to GFSC at July meeting Grid Protocol Architecture Working Group

5. Sample Architectures • Johnston • Moore and Johnston • Moore • Moore • Aydt • Foster, Kesselman, et al Grid Protocol Architecture Working Group

6. Problem SolvingEnvironment Tools to implement the human interfaces, and the mechanisms to express, organize, and manage the workflow of solving a problem Applicationsand SupportingTools Data PublicationandSubscriptionToolkits InstrumentManagementToolkits CollaborationToolkits ApplicationCodes VisualizationToolkits Grid Enabled Libraries ApplicationDevelopmentSupport Globus MPI CORBA PRE/CORBA Condor Java/Jini OLE/DCOM =Globus service collective Global Queuing Co-Scheduling Data Cataloguing Fault Management Brokering Grid Information Service Security Services GridCommonServices Collaboration and Remote Instrument Services UniformResourceAccess Authentication Authorization Global EventServices Auditing / Accounting Uniform Data Access Monitoring Communication Services resource LocalResources ResourceManager ResourceManager ResourceManager ResourceManager ResourceManager ResourceManager ResourceManager Communication Services Tertiary Storage On-Line Storage Scientific Instruments Network Monitors Highspeed Data Transport QoS CPUs fabric What services are the basic building blocks?

7. Grid Forum “Interactions” What services are the basic building blocks?

8. API that provides “glue” to underlying data handling systems (security, scheduling, QoS, access protocol, data format/model, adaptively, info discovery, location control) Grid Data Architecture -1 Application + authentication + authorization Data Model Management Condor, GSIFTP, GASS, NILE, [SRB], I-2 caching Remote Procedure Execution Armada D’agents, FEL, ADR GRAM, SRB Information Discovery Data Handling Systems (e.g., filtering) Condor, GSIFTP, GASS API that provides “glue” to underlying storage, QoS, etc. [GSIFTP, GASS, IBP, SRB] Dynamic Info Discovery Storage System Description Storage Manager Storage Resources GloPerf, Netlogger, NWS HRM (MSS tape request & staging, time estimates, isolates local policy – e.g. number of access channels, number of simultaneous tape requests) (which perf. Monitor, what QoS, location, what access control, replication) DPSS, HPSS, ADSM, DMF, Unitree, NASstore, DFS, DB2, Oracle, Illustra, Sybase, O2, ObjectStore, Objectivity Complex services may be difficult to reduce to “basic” protocols” that are useful.

9. API that provides “glue” to underlying data handling systems (security, scheduling, QoS, access protocol, data format/model, adaptivity, info discovery, location control) Grid Data Architecture -2 Application + authentication + authorization Data Model Management Condor, GSIFTP, GASS, NILE, [SRB], I-2 caching Remote Procedure Execution Armada D’agents, FEL, ADR GRAM, SRB Information Discovery Data Handling Systems (e.g., filtering) Condor, GASS API that provides “glue” to underlying storage, QoS, etc. [GSIFTP, GASS, IBP, SRB] GridFTP Dynamic Info Discovery Storage System Description Storage Manager Storage Resources GloPerf, Netlogger, NWS HRM (MSS tape request & staging, time estimates, isolates local policy – e.g. number of access channels, number of simultaneous tape requests) (which perf. Monitor, what QoS, location, what access control, replication) DPSS, HPSS, ADSM, DMF, Unitree, NASstore, DFS, DB2, Oracle, Illustra, Sybase, O2, ObjectStore, Objectivity People tend not to think in terms of protocols.

10. 3) Event producer & Event schema information 4) Query or Subscribe 2) Lookup 5) Event data 1) Event publication information Architecture Consumer Directory Service (LDAP?) Producer = API & wire protocol & data format Another challenge will be to compare protocols that arebeing developed to the GPArch and make the assessmentas to whether this is a “basic” building block or can it bebuilt on lower level protocols or should it use existingbuilding blocks (e.g. an event service). Plus security! Ruth Aydt – GGF1 Performance Working Group

11. A p p l i c a t i o n D i s c i p l i n e - S p e c i f i c D a t a G r i d A p p l i c a t i o n s U s a g e R e q u e s t R e q u e s t C o n s i s t e n c y A c c o u n t i n g M a n a g e m e n t P l a n n i n g M a n a g e m e n t C o l l e c t i v e S e r v i c e s S e r v i c e s S e r v i c e s S e r v i c e s R e p l i c a R e p l i c a S y s t e m R e s o u r c e S e l e c t i o n M a n a g e m e n t M o n i t o r i n g B r o k e r i n g S e r v i c e s S e r v i c e s S e r v i c e s S e r v i c e s D i s t r i b u t e d C o m m u n i t y O n l i n e I n f o r m a t i o n C o a l l o c a t i o n C a t a l o g A u t h o r i z a t i o n C e r t i f i c a t e S e r v i c e s S e r v i c e s S e r v i c e s S e r v i c e R e p o s i t o r y S t o r a g e C o m p u t e N e t w o r k C a t a l o g C o d e S e r v i c e E n q u i r y M g m t M g m t M g m t M g m t M g m t R e g . R e s o u r c e P r o t o c o l P r o t o c o l P r o t o c o l P r o t o c o l P r o t o c o l P r o t o c o l P r o t o c o l C o n n e c t i v i t y C o m m u n i c a t i o n , s e r v i c e d i s c o v e r y ( D N S ) , a u t h e n t i c a t i o n , d e l e g a t i o n Knowledge C o d e S t o r a g e C o m p u t e N e t w o r k s C a t a l o g s F a b r i c R e p o s i t o r i e s R e p o s i t o r i e s S y s t e m s S y s t e m s Foster, Kesselman, et al, Architecture

12. Grid Protocol Architecture Working Group DRAFT Charter • The role of the Grid Protocol Architecture Working Group is to provide a conceptual framework for discussing the interrelationships, completeness, and minimality of the protocol approach to Grid services that is coming out of GF. Grid Protocol Architecture Working Group

13. Charter discussion points • The GPA-WG will define an architecture for the protocols, services, and API model of Grids • An architecture document will identify Grid functions and services, and their relationship to applications, resources, and the other services. The document will also attempt to identify a minimally complete set of functions and services. Grid Protocol Architecture Working Group

14. Charter discussion points • The GPAWG will examine the work of the other WGs in the context of this architecture and comment on both minimality and completeness of the overall GF work. • document missing protocols in a way that encourages action in existing WGs or creation of new WGs. • document what appears to be non-minimal elements and modify the architecture and/or convey these observations to the WGs. Grid Protocol Architecture Working Group

15. Charter discussion points • The GPA-WG will also examine the relationship of the architecture that it produces with respect to other approaches such as CORBA, peer-to-peer, etc. Grid Protocol Architecture Working Group