Understanding OGSA: Features, Standards, and Recommendations

1. What is OGSA? GGF17 OGSA and Alternative Grid Architectures Panel Tokyo Japan May 10 2006 Geoffrey Fox Computer Science, Informatics, Physics Pervasive Technology Laboratories Indiana University Bloomington IN 47401 http://grids.ucs.indiana.edu/ptliupages/presentations/ gcf@indiana.eduhttp://www.infomall.org

2. Trying to understand OGSA • What features of process or specification characterizes components of the OGSA architecture? • Is OGSA a “bag of services” produced by GGF from which I can pick and choose and produce profiles within OGSA or just build a Grid • Or is it a complete “architecture” • Does an OGSA standard have certain key features • e.g. builds on WSRF and/or WS-Naming and /or WS-I+? • Does OGSA have well defined requirements? • At what level of detail are requirements specified • How do lessons from many successful Grid projects feed into OGSA? • e.g. It is said that requirements drove development of WSRF – maybe but then what is defective in Web Service-based Grids not using WSRF • Other standards activities suggest distributed computing is very complex and rapidly changes • What is a realistic scope for OGSA?

3. Summary of OGSA from GCF’s eye • Hiro’s talk this and the webcast gives a very good summary and this is a very helpful development • https://forge.gridforum.org/projects/ogsa-wg/document/GGF17_keynote/en/6 • http://www.presentationselect.com/HPinvent/archive.asp?eventid=1188 • https://forge.gridforum.org/projects/ogsa-wg/document/OGSA_Webcast_slides_April_2006_final/en/9 • OGSA carves up service space into 6 areas in a reasonable but non-unique fashion (another different decomposition developed by DoD for example) • Execution -- Requirements Identified – Good progress • Data – Interesting good progress but important issues not addressed • Information – Requirements and services unclear • Security – OGSA one player in a complex field • Resource-Management -- Active Research • Self-Management – Active Research

4. OGSA Issues • OGSA presents a complete picture that does not clearly distinguish between maturity, relevance of outside activities, and clarity of definition of 6 components • OGSA is open to those that join OGSA • Monolithic picture makes it hard for others making different choices to contribute • The gathering of use cases and analysis of them is not transparent and mechanism for outside (to OGSA) input unclear. • Many Grids – including those that I work on -- need some things (e.g. BES OGSA-DAI) from OGSA but also capabilities (such as SRB style services and real-time streams) that are not clearly addressed • Students are getting PhD’s in areas like service management that suggest they are research issues • Profiles (such as HPC Profile) select a few OGSA specifications and build around them and perhaps work of those outside OGS • Does not require a monolithic approach

5. OGSA Suggestions • OGSA becomes a GGF process that develops (a bag of) generically important Grid services that can be taken or not on an individual basis • Most W3C and OASIS specifications are standalone and are not a “take it or leave it” monolithic system • OGSA identify those services/specifications (like BES) where requirements and GGF activities are well developed • OGSA define key features that an OGSA named activity must satisfy • The driving requirements be identified and the process for developing them separated from standards generation • Analyze success of many existing Grids – how did they succeed without using OGSA? • Analyze missing capabilities both internally and externally (Grid interoperation) • OGSA be clearly open to new contributors by not appearing to prescribe approach to service areas not currently well developed • Keep it simple and develop incrementally

6. DoD Net Centric Core Services