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.edu http://www.infomall.org

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?

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

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 OGSA Does not require a monolithic approach

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

DoD Net Centric Core Services NCOW Service or Feature WS-* Service area GGF Areas Others CES 1: Enterprise Services Management WS-8 Management Management CIM CES 2: Information Assurance(IA)/Security WS-5 WS-Security Security (Authorization) Grid-Shib, Permis Liberty Alliance etc. CES 3: Messaging WS-2, WS-3 Service Internet Notification NaradaBrokering, Streaming/Sensor Technologies CES 4: Discovery WS-6 UDDI Extended UDDI CES 5: Mediation WS-4 Workflow Treatment of Legacy systems. Data Transformations CES 6: Collaboration Shared Web Resources Asynchronous Virtual Organizations XGSP, Shared Web Service ports, Anabas CES 7: User assistance WS-10 Portlets GridSphere NCOW Capability Interfaces, JSR168 CES 8: Storage (not real-time streams) Data NCOW Data Strategy CES 9: Application Applications Best Practice in building Grid/Web services (proxy or direct) Environmental Control Services ECS WS-9 Policy