[Text extracted from the attached ppt presented in the "OGSA and Alternative Architectures" panel session at GGF17]


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 OGS
	 - 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