Grids for GeoSensors, GeoScience and GeoScientists

1. EarthScope CSIT Workshop March 25 2002 Grids for GeoSensors, GeoScience and GeoScientists PTLIU Laboratory for Community Grids Geoffrey Fox Computer Science, Informatics, Physics Indiana University, Bloomington IN 47404http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02 gcf@indiana.edu uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

2. Trends of Importance • Resources of increasing performance or functionality • Computers (ASCI, Earth Simulator to TeraGrid), storage, sensors, networks, PDA’s • Applications of increasing sophistication • Size, multi-scales, multi-disciplines • New algorithms and mathematical techniques • Computer science • Compilers, Parallelism, Objects, Components • Grid and Internet Concepts and Technologies • Enabling new applications • XML, Web Services,Portals, Collaboration uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

3. Projected Top 500 Until Year 2009 • First, Tenth, 100th, 500th, SUM of all 500 Projected in Time Earth Simulator from Japan http://geofem.tokyo.rist.or.jp/ uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

4. OC-12 vBNS Abilene MREN OC-12 OC-3 = 32x 1GbE 32 quad-processor McKinley Servers (128p @ 4GF, 8GB memory/server) PACI 13.6 TF Linux TeraGrid 574p IA-32 Chiba City 32 256p HP X-Class 32 Argonne 64 Nodes 1 TF 0.25 TB Memory 25 TB disk 32 32 Caltech 32 Nodes 0.5 TF 0.4 TB Memory 86 TB disk 128p Origin 24 32 128p HP V2500 32 HR Display & VR Facilities 24 8 8 5 5 92p IA-32 HPSS 24 HPSS OC-12 ESnet HSCC MREN/Abilene Starlight Extreme Black Diamond 4 Chicago & LA DTF Core Switch/Routers Cisco 65xx Catalyst Switch (256 Gb/s Crossbar) OC-48 Calren OC-48 OC-12 NTON GbE OC-12 ATM Juniper M160 NCSA 500 Nodes 8 TF, 4 TB Memory 240 TB disk SDSC 256 Nodes 4.1 TF, 2 TB Memory 225 TB disk Juniper M40 Juniper M40 OC-12 vBNS Abilene Calren ESnet OC-12 2 2 OC-12 OC-3 Myrinet Clos Spine 8 4 UniTree 8 HPSS 2 Sun Starcat Myrinet Clos Spine 4 1024p IA-32 320p IA-64 1176p IBM SP Blue Horizon 16 14 = 64x Myrinet 4 = 32x Myrinet 1500p Origin Sun E10K = 32x FibreChannel = 8x FibreChannel 10 GbE 32 quad-processor McKinley Servers (128p @ 4GF, 12GB memory/server) Fibre Channel Switch 16 quad-processor McKinley Servers (64p @ 4GF, 8GB memory/server) IA-32 nodes Cisco 6509 Catalyst Switch/Router uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

5. Small Devices Increasing in Importance CM5 • There is growing interest in wireless portable displays in the confluence of cell phone and personal digital assistant markets • By 2005, 60 million internet ready cell phones sold each year • 65% of all Broadband Internet accesses via non desktop appliances uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

6. The HPCC Track • The 1990 HPCC 10 year initiative was largely aimed at enabling large scale simulations for a broad range of computational science and engineering problems • It was in many ways a success and we have methods and machines that can (begin to) tackle most 3D simulations • ASCI simulations particularly impressive • DoE still putting substantial resources into basic software and algorithms from adaptive meshes to PDE solver libraries • Machines are still increasing in performance exponentially and should achieve petaflops in next 7-10 years • EarthScope community needs to harness these capabilities • Japan’s Earth Simulator activity major effort with large hardware and software (GEOFEM) efforts uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

7. Some HPCC Difficulties • An Intellectual failure: we never produced a better programming model than message passing • HPCC coding is hard work • Successes of ASCI software are like “Grid FTP” – not parallelizing compilers • An institutional problem: we do not have a way to produce complex sustainable software for a niche (1%) market like HPCC. • POOMA support just disappeared one day (foundation of first proposal GEM wrote) • One must adopt commodity standards and produce “small” sustainable modules. • Note distributed memory becoming dominant again with bizarre clustered SMP architecture – not clear that “wise” to exploit advantages of shared memory architectures uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

8. HPCC Advice to EarthScope • KISS: Keep it Simple and Sustainable • Use MPI and openMP if needed for performance on shared memory nodes • Adaptive Meshes • Load Balancing • PDE Solvers including fast multipoles • Particle dynamics • Other areas such as datamining, visualization and data assimilation quite advanced but still significant research } Are well understoodto get high performanceparallel simulationsUse broad communityexpertise uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

9. Use of Object Technologies I • The claimed commercial success in using Object and component technology has not yet been a clear success in HPCC • Object technologies do not naturally support either high performance or parallelism • C++ can be high performance but Java (as a language) is not uniformly so (it is improving) • Web Services could change this • Fortran (including Fortran90) will continue to decline in importance and interest – the community should prefer not to use it • It’s use will not attract the best students • Not essential to write modules in object oriented language • It is essential to package modules in object framework uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

10. Use of Object Technologies II • There is emerging HPCC component architecture allowing production of more modern libraries (integration Infrastructure) • DoE has very large CCA – Common Component Architecture – effort • Package software (“system and applications”) as distributed objects – not as traditional libraries • CORBA Java and Web Services are not naturally high performance as component models • High performance often not essential for coarse grain objects • Web Services support multiple implementations allowing performance functionality trade-off uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

11. Application Structure • Earth Science applications are typically multi-scale and multi-disciplinary • i.e. a given simulation is made of multiple components with either different time/length scales and/or multiple authors from possibly multiple fields • I am not aware of a systematic “Computational renormalization group” – a methodology that links different scales together • However composition of modules is an area where (component) technology of growing sophistication is becoming available • Needed commercially to integrate corporate functions • Easiest for large coarse grain components • Integration of data and simulation is one example of fine-scale composition which is “understood” uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

12. Object Size & Distributed/Parallel Simulations • All interesting systems consist of linked entities • Particles, grid points, people or groups thereof • Linkage translates into message passing • Cars on a freeway • Phone calls • Forces between particles • Amount of communication tends to be proportional to surface area of entity whereas simulation time proportional to volume • So communication/computation is surface/volume and decreases in importance as entity size increases • In parallel computing, communication synchronized; in distributed computing “self contained objects” (whole programs) which can be scheduled asynchronously uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

13. Some Problem Classes • Classic HPCC: synchronized objects with regular time structure (communication overhead decreases as problem size increases) • Includes PDE and interacting particle based applications • Give scaling parallelism on large MPP’s • Internet Technology and Commercial Application Integration: Large objects with modest communications and without difficult time synchronization • Compose as independent (pipelined) services • Includes some approaches to multi-disciplinary simulation linkage • Hardest: smallish objects with irregular time synchronization • Interesting Los Alamos SDS technology for this uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

14. What is a Grid or Web Service? • There are generic Grid system services: security, collaboration, persistent storage, universal access • OGSA (Open Grid Service Architecture) is implementing these as extended Web Services • An Application Web Service is a capability used either by another service or by a user • It has input and output ports – data is from sensors or other services • Consider Satellite-based Sensor Operations as a Web Service • Satellite management (with a web front end) • Each tracking station is a service • Image Processing is a pipeline of filters – which can be grouped into different services • Data storage is an important system service • Big services built hierarchically from “basic” services • Portals are the user (web browser) interfaces to Web services uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

15. Sensor Web Service Distributed Sensor Web Service Out Web Service portsUniversal sensor accessfor people/computers In Web Service portsDifferent formatSensor Data uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

16. Prog1WS Prog2WS Filter1WS Filter2WS Filter3WS Build as multiple interdisciplinaryPrograms Build as multiple Filter Web Services Sensor Data as a Webservice (WS) Simulation WS Simulation WS Data Analysis WS Data Analysis WS Sensor ManagementWS Visualization WS Visualization WS Application Web Services • Note Service model integrates sensors, sensor analysis, simulations and people • An Application Web Service is a capability used either by another service or by a user • It has input and output ports – data is from users, sensors or other services • Big services built hierarchically from “basic” services SLE (space Link Extension) as a WS uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

17. The Application Service Model • As bandwidth of communication (between) services increases one can support smaller services • A service “is a component” and is a replacement for a library in case where performance allows • Services (components) are a sustainable model of software development – each service has documented capability with standards compliant interfaces • XML defines interfaces at several levels • WSDL at Service interface level and XSIL or equivalent for scientific data format • A service can be written as Perl, Python, Java Servlet, Enterprise Javabean, CORBA (C++ or Fortran) Object … • Communication protocol can be RMI (Java), IIOP (CORBA) or SOAP (HTTP, XML) …… uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

18. Services support Communities • Grid Communities (Earth Science, SCEC, DoD, Earth Science, High School Classes) are groups of communicating individuals sharing resources implemented as Web Services • Access Grid from Argonne/NCSA is high-end Audio/Video conferencing technology • Peer to Peer networking describes a set of technologies supporting community building with an emphasis on less structured groups than classic “users of a supercomputer” • Peer to peer Grids combine the technologies and support “small worlds” – optimized networks with short links between each community member uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

19. Database e-Science is just a pile of XML • Each leaf is a piece of XML either defining a nugget of information and/or containing links to other XML or “raw resources” uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

20. Biased History of Computing • In almost the beginning, there was Fortran and formats (6I5, 5F10.4) for data • ………………………….. • 1993-1997: HTML came along for Web Pages • 1998-…: XML was developed to define information in documents while HTML defining rendering • But soon it became used for specifying all data and their format • 2001: Web Services allowed XML to specify methods (subroutines) as well as data • Java, C++, Python, Perl, .. Fortran are now “just” the insides of XML specified programs uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

21. XML (RSS) Specification of Information Nuggets • <itemrdf:about="http://xml.com/pub/2000/08/09/xslt/xslt.html"> • <title> Processing Inclusions with XSLT </title> • <link>http://xml.com/pub/2000/08/09/xslt/xslt.html</link> • <description> • Processing document inclusions with general XML tools can be • problematic. This article proposes a way of preserving inclusion • information through SAX-based processing. • </description> • </item> • <item rdf:about="http://xml.com/pub/2000/08/09/rdfdb/index.html"> • <title> Putting RDF to Work </title> • <link>http://xml.com/pub/2000/08/09/rdfdb/index.html</link> • <description> • Tool and API support for the Resource Description Framework • is slowly coming of age. Edd Dumbill takes a look at RDFDB, • one of the most exciting new RDF toolkits. • </description> • </item> • </rdf:RDF> Example of XML meta-data in the “pile”pointing to other (outside) resources uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

22. What is a Web Service I • A web service is a computer program running on either the local or remote machine with a set of well defined interfaces (ports) specified in XML (WSDL) • In principle, computer program can be in any language (Fortran .. Java .. Perl .. Python) and the interfaces can be implemented in any way what so ever • Interfaces can be method calls, Java RMI Messages, CGI Web invocations, totally compiled away (inlining) but • The simplest implementations involve XML messages (SOAP) and programs written in net friendly languages like Java and Python • Web Services separate the meaning of a port (message) interface from its implementation • Enhances/Enables Re-usable component model of ANY electronic resource uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

23. Web Service (WS) WS WS WS WS WS WS RawResources Raw Data Raw Data (Virtual) XML Data Interface WS WS etc. XML WS to WS Interfaces (Virtual) XML Knowledge (User) Interface Render to XML Display Format (Virtual) XML Rendering Interface Clients uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

24. Database Database Classic Grid Architecture Resources Content Access Composition Middle TierBrokers Service Providers Netsolve Security Collaboration Computing Middle Tier becomes Web Services Clients Users and Devices uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

25. PaymentCredit Card WSDL interfaces Security Catalog Warehouse shipping WSDL interfaces What is a Web Service II • Web Services have important implication that ALL interfaces are XML messages based. In contrast • Most Windows programs have interfaces defined as interrupts due to user inputs • Most software have interfaces defined as methods which might be implemented as a message but this is often NOT explicit uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

26. What is a Web Service III • “Everything electronic” is a resource • Computers; Programs; People • Data (from sensors to this presentation to email to databases) • “Everything electronic” is a distributed object • All resources have interfaces which are defined in XML for both properties (data-structure) and methods (service, function, subroutine) (Resources are Services) • We can assume that a data-structure property has getproperty() and setproperty(value) methods to act as interface • All resources are linked by messages with structure, which must be specifiable in XML • All resources have a URI such as unique://a/b/c ……. uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

27. WSDL Abstractions • WSDL abstracts a program as an entity that does something given one or more inputs with its results defined by streams on one or more outputs. • Functions are defined by method name and parametersmethodname(parm1,parm2, … parmN) • Where parameters are “Input” “Output” or both • In WSDL, we will have a Web Service which like a (Java or CORBA Program) can be thought of as a (distributed) object with many methods • Instead of a function call, the “calling routine” sends an XML message to the Web Service specifying methodname and values of the parameters • Note name of function is just another parameter uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

28. UDDI or WSIL WSFL WSDL SOAP or RMI HTTP or SMTP or IIOP or RMTP TCP/IP Physical Network Details of WSDL Protocol Stack • UDDI finds where programs are • remote( (distributed) programs are just Web Services • WSFL links programs together(under revision?) • WSDL defines interface (methods, parameters, data formats) • SOAP defines structure of message including serialization of information • HTTP is negotiation/transport protocol • TCP/IP is layers 3-4 of OSI • Physical Network is layer 1 of OSI uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

29. Examples of Web Services I • OGSA (Open Grid Service Architecture) • Integrate Web Service and Grid Concepts and allows Globus to be implemented as Web Services • Audio-Video Conferencing as a Web Service • Integrates H323, SIP, JXTA (etc.) protocols by mapping to single XML Interface • Provides VRVS reflector model from Messaging Web Service • Messaging or Event Web Service provides intelligent routing and buffering of messages • Computing as a Web service • Job submittal, status, composition, data services, visualization • Performance WS allows access to distributed monitoring data, analysis, models, and final benchmarks with interoperable XML interfaces uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

30. Examples of Web Services II • Education as a Web Service • One of easiest to do as object standards well defined (IMS) and little performance issues • Grading, Homework submission, registration, assessment etc. • Universal Access and Web Services • As Web Services allow multiple implementation of a particular interface, one can adjust to needs of particular clients (PDA v. versus, impaired sight etc.) • Can build custom implementations of certain web services for particular communities but re-use others • Collaborative Web Services • As interfaces all message based, much easier to share Web Services than other applications (PowerPoint interface is NOT message based and harder to share than server app) uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

31. Education as a Web Service • Can link to Science as a Web Service and substitute educational modules • “Learning Object” XML standards already exist from IMS/ADL http://www.adlnet.org – need to update architecture • Web Services for virtual university include: • Registration • Performance (grading) • Authoring of Curriculum • Online laboratories for real and virtual instruments • Homework submission • Quizzesof various types (multiple choice, random parameters) • Assessment data access and analysis • Synchronous Delivery of Curricula • Scheduling of courses and mentoring sessions • Asynchronous access, data-mining and knowledge discovery • Learning Plan agents to guide students and teachers uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

32. Distributed Information Actually the XML is distributed all around in a dynamic Grid uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

33. Structured (XML) Information Note XML specifiesboth internal andexternal nodes of tree root earthscope://root/one/two/bottom one two bottom uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

34. Matching Information/Service Providers and Consumers I • Classic Centralized Approach • Those with services publish information as to location – this is percolated up and down the tree of brokers • At simplest, publish location; better publish location and meta-data allowing easier discovery of value • Those wanting service, look it up using either • Some search of information registered with brokers • A search using a system like Google • Because they were told some key • Like using an encyclopedia; very reliable and fast for well established information uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

35. Hoosier National Forest showingstructured trees and a Gallimaufry of unstructured leaves (fall 2001) Unstructured and Structured XML root earthscope://root/one/two/mess one two mess “mess” can be multiple levels of tree uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

36. Database Database Event/MessageBrokers Event/MessageBrokers Integrate P2P and Grid/WS Peer to Peer Grid JXTA Web Service Interfaces Web Service Interfaces JXTA Peer to Peer Grid uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

37. Matching Information/Service Providers and Consumers II • Peer-to-peer Approach (or how to search the “mess”) • Those with services publish XML advertisements to their friends; their friends may forward it to other friends • Those wanting a service, publish an XML request to a chosen set of friends • Friends use their personal idiosyncratic approach to matching requests with advertisements and to choosing who else should be asked • Analogous to way communities exchange information as in a meeting like this • Uncertain reliability but scales well (communities intra-exchange information independently and supports rapidly varying information (Web Services) uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

38. XMLSkin XMLSkin Data base e-Science is XML Specified Resourcesconnected by XML specified messages Message Or Event Based InterConnection Software Resource Software Resource Implementation of resource and connection may or may not be XML uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

39. Technology Trends and Principles • All performance and capability measures of infrastructure continue to improve • Gilder’s law says that network bandwidth increases 3 times faster than CPU Performance (Moore’s Law) • The Telecosmeclipses the Microcosm(but don’t look at Wall Street)…. George Gilder Telecosm :How Infinite Bandwidth Will Revolutionize Our World (September 2000, Free Press; ISBN: 0684809303, #146(3883) in Amazon Sales Jan 15 2001(July 29 2001)) uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

40. Rival Estimate MainlyDigital Video Cohen’s Grid/P2P Use of Internet I ROBERT B. COHEN, PH.D. COHEN COMMUNICATIONS GROUP bcohen@bway.net 212-986-7720 Global Grid Forum Toronto Feb 18 2002 uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

41. S2S Server to Server Digital Video“on demand” Grid/P2P Use of Internet II uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

42. Meta-Data and Web Services • Enriching resources with meta-data is critical idea • Enables one to identify and link resources around the globe • Allows one to find out “meaning” of a Web service not just syntax of interface • Semantic Grid implies linkage of Grid/Web services enabled by meta-data leading to “digital brilliance” phase transition • We can experiment with Semantic Web techniques for specifying meta-data RDF DAML OIL • These encompass both straightforward enriched data as well as Artificial Intelligence assertions uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

43. Semantic Grid & Digital Brilliance I • The (XML) advertisement-request matching provides a publish-subscribe linkage between resources – these are people, computers and raw/processed data • The richer the meta-data, the more precise the linkage • This is spirit of Semantic Web – RDF/DAML/OIL metadata enables meaningful linkage • In a physics analogy, resources can be thought of as spins and the meta-data induced linkage as interactions • Phase transitions will occur when “enough” resources are linked – one will get associated spins to align in the direction of new knowledge • Term this digital brilliance uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

44. Semantic Grid & Digital Brilliance II • This suggests ways of quantifying value of metadata induced linkages and ways of identifying where one “should” add more resource specifications • Note that related resources are not necessarily directly connected but rather messages are forwarded through friends • Study of Peer to Peer networks teach us that we can build “small worlds” where distance between resources is logarithmic in number of nodes • This physics based picture provides an interesting underlying formalism to give a theory of e-Science …. • All you need to do is to build a lot of XML Meta-data specification wizards uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

45. Semantic Grid & Digital Brilliance III • EarthScope Collaboratory consists of a set of connected “spins” (being a physicist; resources if I was W3C) • Resources are anything with a digital signature • Raw data, Analysers, Simulators, Simulations, Processed Information, Extracted Knowledge, Scientists …. • The linkage of Earthquake Fault Simulator Web Service to the Greens Function Solver Web Service is as program to subroutine; must have agreement on both syntax and Semantics • The linkage of Granular Physics model to (my) remark that Los Alamos has interesting new simulation technology is less precise • So linkages with very precise ontologies and those which are more qualitative are both part of Semantic Grid uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

46. Directory mode for Google uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

47. Web (Unstructured) mode for Google Quite Similar to Directory mode uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

48. Portals and Web Services • Web Services allow us to build a component model (see CCA) for resources. • Each resource naturally has a user interface (which might be customized for user) • Web Service <--> Portlet • Natural to use a component model for portal building displayed web page from collection of portlets • So can customize each portlet and customize which portlets you want • Apache Jetspeed seems good open source technology supporting this model • JSP model is better than say a client-side Java integration in that also message based so this is “Portal as a Web Service” uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

49. 4 available portletslinking to Web ServicesI choose two Jetspeed Computing Portal: Choose Portlets uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"

50. Choose Portlet Layout Choose 1-column Layout Original 2-column Layout uri="http://grids.ucs.indiana.edu/ptliupages/presentations/earthscopemar02" email="gcf@indiana.edu"