What is OGSA GGF 17 OGSA and Alternative

What is OGSA? GGF 17 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 1

Trying to understand OGSA n n 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” n Does an OGSA standard have certain key features • e. g. builds on WSRF and/or WS-Naming and /or WS-I+? n 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 n Other standards activities suggest distributed computing is very complex and rapidly changes • What is a realistic scope for OGSA? 2

Summary of OGSA from GCF’s eye n Hiro’s talk this and the webcast gives a very good summary and this is a very helpful development • • • n https: //forge. gridforum. org/projects/ogsa-wg/document/GGF 17_keynote/en/6 http: //www. presentationselect. com/HPinvent/archive. asp? eventid=1188 https: //forge. gridforum. org/projects/ogsawg/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 Do. D 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 3

OGSA Issues n n 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. n 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 Ph. D’s in areas like service management that suggest they are research issues n 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 4

OGSA Suggestions n 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 W 3 C and OASIS specifications are standalone and are not a “take it or leave it” monolithic system n n n 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) n n 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 5

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