1 / 46

Web Services Based Architecture in Computational Web Portals

Web Services Based Architecture in Computational Web Portals. Choonhan Youn cyoun@ecs.syr.edu. Department of Electrical Engineering and Computer Science Syracuse University. Advisor : Dr. Geoffrey C. Fox gcf@grids.ucs.indiana.edu. Presentation Outline • Introduction – Grids

mcashwell
Download Presentation

Web Services Based Architecture in Computational Web Portals

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript


  1. Web Services Based Architecture in Computational Web Portals Choonhan Youn cyoun@ecs.syr.edu Department of Electrical Engineering and Computer Science Syracuse University Advisor : Dr. Geoffrey C. Fox gcf@grids.ucs.indiana.edu

  2. Presentation Outline • Introduction – Grids – What is the Computational web portal? – Limitations of traditional approach • Architecture of a Web Service based Computing Portal – Standard services, interfaces, and protocols – Consequences of Web service architecture • Areas of research – How to break up services into Web Services ==> Core Web services and Application Web services – Integration of Security into Web Services – Data Service for the Earthquake simulation – Web services negotiation • Application: Interacting Data Services for Distributed Earthquake Modeling • Conclusion and Future Work Nov. 7, 2003 Choonhan Youn 2

  3. Grids Concept The basic Grid concept is based on coordinated resource sharing and problem solving in dynamic, multi-institutional Virtual Organizations. – From I. Foster (ANL) in Globus: Technical paper Grid software enables loosely coupled, globally distributed computing. What does that really mean? – Specific services such as global authentication, resource allocation management, aggregated information services – Centered around a few wire protocols and service implementations OGSI/OGSA – Define mechanisms for creating, managing, and exchanging information among entities called Grid Services, building on both Grid and Web services technologies. – Use XML (WSDL) that define a Grid Service to provide a service definition language – Extend WSDL to support metadata about services • • • • Nov. 7, 2003 Choonhan Youn 3

  4. Grid Computing Environments (GCE) GCEs are a general name for both Grid clients and middleware. GCEs aim to bridge the gap between users and Grid infrastructure developers. Organizations setting up Grids have seen the value of developing user environments, or Grid Computing Environments. – 28 articles in November-December 2002 issue of Concurrency and Computation: Practice and Experience – IPG Launchpad, HotPage, Alliance Portal, and others World-wide development community interacts through the GCE research group in the Global Grid Forum. – G. Fox (IU), D. Gannon (IU), and M. Thomas (TACC) co-chair Grid portal technology is coming of age. – Reusability of components – Common frameworks • • • • • Nov. 7, 2003 Choonhan Youn 4

  5. Computational Web Portals Computational Web Portals provide seamless access to HPC resources – You can log in anywhere through any general web browser. Portals simplify the use of HPCs for novice users. – Basics: batch script generation, job submission and monitoring, file service and …… – Computational grid services: Globus, Condor Portals can simplify the use of unfamiliar codes. – GEM code: disloc, simplex, GeoFEST, Virtual California, RIVA, … Provide a work management environment for all users. – You can see what you did last week. Other PSEs/Web portals – NASA IPG (Information Power Grid) LaunchPad – NPACI Hotpage – Pacific Northwest National Laboratory’s Ecce (Extensible Computational Chemistry Environment) system – ZAM (in Germany) UNICORE (Uniform Interface to Computing Resources) – Our own Gateway/ServoGrid projects • • • • • Nov. 7, 2003 Choonhan Youn 5

  6. JDBC, Local, or Remote Connection Grid and Web Protocols Portal Client Stub Database Service Portal User Interface Database Portal Client Stub HPC or Grid Resource Broker Service Compute Cluster Portal Client Stub Information and Data Services Grid Information Services, SRB The three-tiered architecture is a standard for accessing Grid and other services. Nov. 7, 2003 Choonhan Youn 6

  7. Problems with Traditional Portal Architecture Portals accesses heterogeneous back ends and grids through a particular middle tier. Most portal projects are not interoperable – Middle tier software incompatible – Wide range of protocols. Why do we need the portal interoperability? – Portal developers avoid reinventing every single important service (lesson from GGF GCE). – Users will have access to more services than any one project can provide and interact with someone else’s services. – Users will be able to pick up the best available implementation of a service and plug it into my portal. • … • Web browser Web browser ? • services services … … Back end resources Back end resources Nov. 7, 2003 Choonhan Youn 7

  8. What will be our approach for solving the interoperability problem? What is interoperability? – In a network environment, interoperability means common protocols to which portal groups need to agree. General approaches. – Bridge-based: services using different protocols. • Immediate bridging • Mediated bridging – Direct (universal protocols): all services using the same protocol. Web services provides universal protocol approach and are part of a broad industry and academic initiative to build distributed computing infrastructure around existing standards (HTTP, XML, etc). Basic components – A common, simple wire protocol such as SOAP that most portals can agree to use and that can be delivered using standard wire protocols such as HTTP. – A common format, that is, service description language such as WSDL for describing services provided. – A common interface to information services such as a service registry UDDI or WSIL that portals obtain information about which service providers have what kinds of services. A standard definition mechanism, standard lookup services, and standard transport definitions via SOAP. SOAP aims to achieve success in the open Internet environment as the distributed object technology. • • • • • • Nov. 7, 2003 Choonhan Youn 8

  9. Architecture of a Web Service based Computing Portal - 1 • Based on problems in the previous slide, we define a new service- oriented architecture for computing portals. – Distributed service model: The point of view that we take is that all back end resources should be considered as distributed services. – Resource and service description: The generalized view of resources as services requires that we describe the metadata associated with the service and provide a means of locating and using it. WSDL is appropriate service description language. – Resource and service discovery: Once we have described our service, it must be placed in an XML repository that can be searched by client, UDDI or WSIL as service discovery. – Service binding: Following the discovery phase, the client must bind to the remote service. WSDL supports bindings to services using different mechanisms including SOAP. Nov. 7, 2003 Choonhan Youn 9

  10. Architecture of a Web Service based Computing Portal - 2 JS: Job submission JM: Job Monitoring FT: File Transfer CM: Context Manager SG: Script Generation AWS: Application Web Service HIS: Host Independent Service HSS: Host Specific Service Simulation Component Data Component HPC Backend Resources Data Base HSS HSS FT FT Web Services Provider … SOAP Middle Tier (Web Server) JS JS JS JS JM JM Publish JM JM FT FT SOAP Publish SOAP Service Repository SOAP SOAP SOAP SOAP Publish Middle Tier (Web Server) CM CM AWS AWS Repository Client SOAP Client SOAP SOAP SG SG User Interface Server Portal Server HIS … HTTP HTTP Web Browser Nov. 7, 2003 Choonhan Youn 10

  11. Shortcomings of Web Service Model • Primitive services must be designed properly. – Interfaces must be simple for external users – Implementation must be self-contained • Must extend Web Service to provide security. – Message-level security infrastructure • Must combine primitive services into useful application services. – Application management service • Must extend Web Service to provide quality of service for service compatibility. – Negotiation for Web Services Nov. 7, 2003 Choonhan Youn 11

  12. Problems Defining Web Services for Computing Portals • Standard interface and standard wire protocol XML languages are not enough. • Web Service will still fail if particular service interfaces are not designed properly. • Examples of this: – Gateway’s Context Manager class itself has 60(?) methods. But, this does not make it externally useful. – Lessons learned from Batch Script Generation service exercise we performed with SDSC. • Internally, our batch script service depended on the Context Manager service. That is, we are passing around overweight, local objects with unnecessary configuration setup. Nov. 7, 2003 Choonhan Youn 12

  13. How to break up services into Web Services • Services can be complicated but need to be self contained, have a simple interface, should only communicate with XML. • Services are separated from user interface. – Everything runs on a different server. • User interface itself can be distributed. – Define user interface web services (session state management). • Services can be composite and selectable for clients. Nov. 7, 2003 Choonhan Youn 13

  14. Proposal of Work: Web Service Design • Will define basic computing services and their WSDL interfaces. – What are basic computing services? Job submission. File transfer and manipulation. Context manager( State information management ). Batch script generation service. Job monitoring service. • Need to come up with best practice design patterns for distributed web services. • These basic services will be combined to create application web services. Nov. 7, 2003 Choonhan Youn 14

  15. Computing Portal Web Services We have built a suite of general purpose Grid Web services for managing distributed applications. Given WSDL and SOAP, what can you build? Core Computing services define general purpose functions: – Host-Specific Services (HSS) • Instances of these services are bound to particular hosts. • Job Submission • File Transfer • Job & Host Monitoring – Host-Independent Services (HIS) • Informational services that are not tied to specific service points • The service provided does not depend on the location. • Context Management • Script Generation Application Web services include metadata about applications. – Built on top of core services. – Original application NOT changed • • • • Nov. 7, 2003 Choonhan Youn 15

  16. Core Web services - 1 • Job Submission – Allow users to execute scientific applications – Execute operating system calls directly or may interact with Grid services through, for example, the CoG client API to Globus. – We use Java Runtime processes to run external (non-Java) commands, for example, PBS qsub. • File Manipulation – Upload and download files between their desktops and various backend destinations. – Allow users to transparently move, rename, and copy files on remote back-ends and crossload between different backend sites. – File uploading and downloading service illustrate the use of SOAP messages with attachments in the RPC messaging style. – SOAP attachments are non-XML files that are appended to the SOAP message and are useful for sending binary data and files with known MIME formats. Nov. 7, 2003 Choonhan Youn 16

  17. Core Web services - 2 Context Management (CM) – Archives interactions with the computational portal and stores all of the metadata associated with user sessions. – Provides simplest possible data model • CM provides an easy interface to an arbitrarily deep and complex tree-shaped data structure. • Context data nodes are defined by recursive schema that hold optional, unbounded name/value pairs and child nodes. – We use CM to store locations of job scripts, miscellaneous file URIs, user’s application instance XML files, etc. – CM metadata stored on file systems, XML- native databases, …. • Actual data may be anywhere. – Actual service interface for manipulating contexts and the context data • Add one or more contexts. • Search and store the context data with XPath queries. • Remove the specified context. • List the child contexts. • CM XML schema Nov. 7, 2003 Choonhan Youn 17

  18. Core Web services - 3 Script Generation – For users who are unfamiliar with HPC systems. – Generate the job script which could be broken down into two parts: a queue script for a particular queuing system and a user script for running the application code. – Generating batch scripts from user requests is a common task implemented by a several portals (including Gateway and HotPage). • A good first test service of interoperability. • IU and SDSC support different queuing systems, so collectively they benefit from a shared service. (IU: PBS <==>SDSC: LSF, LoadLeveler, NQS) Job & Host monitoring – Has been built in the polling method. – Monitor the execution of a job running in a queuing system. – For example, PBS qstat, Unix top. • • Nov. 7, 2003 Choonhan Youn 18

  19. Application Web Services (AWS) • Application: specifically some code developed by the scientific community. – Example: Finite element codes, grid generation codes and so on. • AWS are designed to make scientific applications (i.e. earthquake modeling codes) into Grid Resources. • We need a meaningful metadata model for applications – Describe application-specific requirements – Describe bindings of applications to host environments and to Web services in a general way that is independent of the particular portal. • Scientific applications consist of several core Web services. – Get files to right place, script submission instructions, submit the job, get notified at various states. Nov. 7, 2003 Choonhan Youn 19

  20. AWS Schema Structure • Two sets of XML schema: – Application Descriptors: • describe abstract state. • describe application options. Used by the application developer to deploy his/her service into the portal. – Application Instance Descriptors: • describe particular instance states (ready, running, archived). • describe particular user choices and archive them for later browsing and resubmission. • Schema sets are arranged hierarchically – Applications contain hosts – Schema are designed to be pluggable • Don’t like my queue description schema? Plug in your own. Nov. 7, 2003 Choonhan Youn 20

  21. AWS XML Descriptors Application description schema – A “basic information” element that contains information such as application name, version, option flags. – An “internal communication” element that contains child elements for describing input, output, and error fields for the code. – An “execution environment” element that contains a list of core services needed to execute the application. – An optional, generic parameter to hold arbitrary information about the application. Host description schema – Contains information about the resource such as DNS name and IP address – All of the information needed to invoke the parent application on that resource such as location of the executable, location of the workspace or scratch directory, and so on. Queue description schema – Contains information needed to perform queue submissions such as memory size, number of CPUs and so on( in case of PBS). • • • Nov. 7, 2003 Choonhan Youn 21

  22. Example: Deploy an application code, Simplex on a particular host as a service and this form is used to edit the Application XML descriptor file Nov. 7, 2003 Choonhan Youn 22

  23. Sample generated user view of application code, Simplex: this form is generated from the Application XML descriptor for a particular application runs: the input files used, the location of the output, the resources used for the computation, etc. Nov. 7, 2003 Choonhan Youn 23

  24. Security Requirements for Web Services Need mutual authentication between clients and User Interface Server (UIS) – Clients are browsers: understand SSL but not Kerberos. provide a browser interface that will create a Kerberos TGT on the UIS for the user. Need a secure SOAP messaging system to connect UIS, the repository, and service providers. What are security problems for Web Services? – How do I prove identity? – How do I verify the source of the message? – How do I check message integrity? – How do I keep sensitive messages private? – How do I define and enforce access control? • Web Browser Security ? User Interface Server • SOAP SOAP • Security ? Service Repository Service Provider SOAP Nov. 7, 2003 Choonhan Youn 24

  25. Integration of Security into Web Services Users Authentication through single sign-on. – Kerberos, PKI – Distributed ticket system – Getting assertions about authentication, authorization, user attribute SOAP security should be provided through standard interfaces to specific mechanisms. General methods are – Message signing. – Message integrity. – Message encryption. Kerberos, PKI are specific mechanisms. Assertion is an XML document describing the information about authentication acts performed by subjects, attributes of subjects and authorization decisions, created with a specific mechanism. • Authenticate Security Mechanism Generating Assertions • Signing • Assertions Encryption • • Assertions SOAP HTTP …… HTTP HTTP Web Service Web Service Web Service …… Nov. 7, 2003 Choonhan Youn 25

  26. Proposal of Work: Web Services Security • Propose to investigate Web Services security. – SAML • Will define abstract security mechanisms (authentication, etc.) for web services with specific security bindings (Kerberos, PKI). – Message signing. – Message encryption. • Will implement mechanism-independent assertions based on SAML standard. Nov. 7, 2003 Choonhan Youn 26

  27. Message Signing with SAML and Kerberos SAML expresses security assertions in XML. Demonstration Steps – Establish both servlet session and GSS context between the UI and AS. – UI signs SAML assertion and SOAP Body message with GSS Context’s wrap method. – Service extracts SAML assertion and SOAP Body message with GSS Context’s unwrap method from AS and verifies it. Implementations – SAML assertion converted to Java data objects with Castor. – Apache Axis modified to handle authentication, translation. – Used GSS API’s wrap and unwrap methods to do the security. • • Web Browser HTTPS User Interface Server Authentication Service Kerberos Client Kerberos Server • HTTP(S) +SOAP +signed SAML SOAP Service Nov. 7, 2003 Choonhan Youn 27

  28. An assertion-based authentication service for Gateway Web Services The authentication service Process the SOAP message Client login process for the user authentication Check type WS-security security such as Kerberos, PKI. the assertion as SAML, and mechanism Initialize the secure context to get the shared key. such the Client Generate the assertion such as SAML, WS-security. Unwrap the assertion. Test the user validity. Sign the assertion. Unwrap the SOAP Body message. Add it to SOAP Header. Rebuild the SOAP message. Sign the SOAP Body message. Internet (HTTP) cloud Process the SOAP message. Add it to SOAP Body. Send the SOAP request. Nov. 7, 2003 Choonhan Youn 28 Send the SOAP response.

  29. Web service negotiation Needed for managing multiple versions of services – Negotiation of quality of service – For example, File Transfer service that has different bindings Motivating examples – Secure Socket Layer (SSL) handshake protocol • Authenticate uni- or bi-directionally using PKI certificate, and securely distribute shared secrets for exchanging the data. • Negotiate the cipher suite, etc. – Session Initiation Protocol (SIP) • A standard of Internet Engineering Task Force, especially for Voice over IP. • An application-layer control protocol that can establish, modify and terminate multimedia sessions or calls. • Negotiate the compression algorithms, encryption algorithms, code book size, etc. Offer/Answer approach – The offerer has the offer, for example, a set of protocols and services, service version which she wishes to use . – The answer has a desired service request in the offer, indicating whether the service request parameter is accepted or not. • • • Nov. 7, 2003 Choonhan Youn 29

  30. Proposal of Work: Web Service Negotiation • Will extend WSDL to support the metadata about the negotiation. • Will design and implement the negotiation XML schema as the namespace in WSDL. • Will design and implement the family of parameter XML schema which is pluggable in negotiation XML descriptor. Nov. 7, 2003 Choonhan Youn 30

  31. Integrating the negotiation into Web Service Implement Web service negotiation through extensions to WSDL. – Negotiation type may be specified in separate portTypes in the same WSDL document. The negotiation “portType” XML schema contains two elements: – The “operation” element is intended to be extended by another URI that defines a standard negotiation message format. – The “parameters” element is extended to contain the actual data used in the negotiation. Describe family of parameter XML schema which is applicable to the “parameter” element in the negotiation XML descriptor. – Version picking (namespace: http://.../Negotiate/../Version) schema which contains a Version service name and a set of Version values. – Protocol picking (namespace: http://.../Negotiate/../Protocol). The basic interaction of a Web service negotiation for version control – The client-side process is as follows: • For managing the operation messages between participants, we should pick a parameter family defined by a URI such as http://.../Negotiate/Version. • sends its parameters configuration and the URI of that configuration. – The targeted SOAP server-side process is as follows: • makes a decision when receiving the client’s parameter list and URI for the negotiation information. • selects the particular version based on any desired choosing algorithm. • sends the chosen version back to the client. • • • • Nov. 7, 2003 Choonhan Youn 31

  32. Negotiation namespace Negotiation portType Definition Nov. 7, 2003 Choonhan Youn 32

  33. Application: GEM Portal Overview • Put basic Web services and architecture to work in GEM computational web portal. • URL for portal : http://complexity.ucs.indiana.edu:8282/jetspeed/index.jsp • Portal testbed – UI server: complexity.ucs.indiana.edu – Backend services: danube.ucs.indiana.edu, grids.ucs.indiana.edu, solar.uits.indiana.edu, noahsark.ucs.indiana.edu • Requirements for enabling code interoperability: data models and services • Manipulating data: data service interfaces and inheritance organization. • Plugging data services into the architecture. Nov. 7, 2003 Choonhan Youn 33

  34. GEM Portal Architecture Portlet Based User Interface HTTP Client Stubs SOAP SOAP SOAP Job Sub/Mon And File Services SOAP DB Service 1 DB Service 2 JDBC JDBC Operating and Queuing Systems DB DB Host 1 Host 2 Host 3 Nov. 7, 2003 Choonhan Youn 34

  35. GEM Computing Portal • A number of simulation methods for studying earthquakes are being developed by GEM consortium including: – Simplex, Disloc, GeoFEST (JPL) – Virtual California (UC-Davis) – PARK codes (Brown) • As codes become more widely used, problems emerge: – Need to manage information about distributed data sources: multiple databases, sensors, simulated data. – Need to organize, manage information about multiple code installation sites. – Need to simplify access to data, use of codes, and use of visualization/analysis tools for broad range of users – Need to support metadata information such as job archives, validation, benchmark information, etc. Nov. 7, 2003 Choonhan Youn 35

  36. Code Linkages in Initial System Elastic Dislocation Inversion Viscoelastic FEM Viscoelastic Layered BEM Elastic Dislocation Pattern Recognizers Fault Model BEM Nov. 7, 2003 Choonhan Youn 36

  37. Data Service What are problems? – Codes all use “legacy” text formats for describing input and output. – Input and output data often combined with code-specific information, for example, number of iterations, starting temperature and so on. – Data not always represented uniformly We designed and built the following: – Data models: Fault, Displacement, Disloc and Simplex data XML schema – Programming interfaces to data – Interfaces themselves need structural organization – Implementations of the interfaces – Integration of the interfaces and implementations into our service architecture. The structural organization should allow extension to specific applications – Anticipating integration of VC, PARK, GeoFEST, etc. We are using WSDL and SOAP for interface description and protocol implementation. – WSDL defines service APIs in XML • • • • Nov. 7, 2003 Choonhan Youn 37

  38. Interactions of the Disloc data service User selects codes, resources, and code data. Browser Interface User requests translated to XML data formats using the remote service. HTTP User Interface Server SOAP/HTTP Disloc Data Service Disloc Execution Service Input data exported to legacy format and transferred to execution host. Legacy output transferred back to data service and imported back into XML formats. Nov. 7, 2003 Choonhan Youn 38

  39. Simplex and Disloc code share data through the Data Hub Service. User Interface Server (3) Signals Simplex to request displacement data from Data Hub. (1) Requests formatted Disloc output data be pushed to Data Hub. Simplex Data Service Disloc Data Service Execution Host Execution Host (2) XML displacement data is transferred. (4) Requests and receives displacement data. Data Hub Service Nov. 7, 2003 Choonhan Youn 39

  40. Data Transfer Performance with SOAP • We classified four mechanisms for sending messages: – SOAP : For this, We implemented “MessageTest” service which just take the message. – SOAP with Attachments: We used “uploadFile” method in “FileService” Web service. – WebFlow : “RemoteFile” service module. – Plain Socket • Testing environments – Server part: SunOS 5.8 (grids.ucs.indiana.edu) – Client part • Desktop PC (winnipeg.ucs.indiana.edu) • SunOS 5.8 (apollo.ecs.syr.edu) – Message type : text file only • We tested two cases according to the domain name. – From ucs,indiana.edu for the client to ucs,indiana.edu for the server – From ecs.syr.edu for the client to ucs.indiana.edu for the server Nov. 7, 2003 Choonhan Youn 40

  41. Perform ance Test (From winnipeg.ucs.indiana.edu to grids.ucs.indiana.edu From winnipeg.ucs.indiana.edu to grids.ucs.indiana.edu) SOAP SOAPwAttach WebFlow Socket 300 250 200 Transfer time(ms) 150 100 50 0 100000 1000 2000 3000 4000 5000 6000 7000 8000 9000 10000 20000 30000 40000 50000 55000 60000 70000 80000 90000 0 Message Size(Byte) Nov. 7, 2003 Choonhan Youn 41

  42. Performance Test (From apollo.ecs.syr.edu to grids.ucs.indiana.edu From apollo.ecs.syr.edu to grids.ucs.indiana.edu) SOAP SOAPwAttach WebFlow Socket 700 600 500 Transfer Time(ms) 400 300 200 100 0 100000 10000 20000 30000 40000 50000 55000 60000 70000 80000 90000 1000 2000 3000 4000 5000 6000 7000 8000 9000 0 Message Size(Byte) Nov. 7, 2003 Choonhan Youn 42

  43. Conclusions - 1 We defined a new service based architecture for computing portals for gaining interoperability and reusability. We defined interfaces for services and built several general purpose services. – Job submission – Job & Host monitoring – Context management – Script Generation – File transfer and manipulation – Application service We designed and implemented a message-based security system for Web service security. We designed and implemented a negotiation system for Web Services. We put our services to work in GEM computing portal. We designed and implemented a data sharing architecture (Using a new service based architecture can be extended for new services). – Designed XML data models – Designed hierarchy of services – Designed translators – Built services to allow legacy codes (Disloc, Simplex) to exchange data • • • • • • Nov. 7, 2003 Choonhan Youn 43

  44. Conclusions - 2 By designing and implementing several core portal services and Application Web Services around Web services, we gain interoperability and reusability. The emphasis on the development of reusable services that can form the basis for multiple PSEs. The portal developer can construct specific implementations and composites of primitive service components and can also provide services that may be shared among different portals. Application-specific services and data models that can be used to encapsulate entire applications independently of the portal implementation. User interfaces to application services become distributed portlets. Web service security is one aspect of our overall program for building Grid Computing Environments. GEM application and data model services for use in earthquake modeling and prediction • • • • • • • Nov. 7, 2003 Choonhan Youn 44

  45. Future Work • Use of service architecture with proxy-style portal front- ended by the aggregation portal – Applications, Portal shell commands, Content services – WSRP (Web Services for Remote Portlets) for “Pluggable” integration with all portals • Particular services needed – The workflow management service for handling the web services using WSFL, or our own XML dialects which is needed for the computing portal. • Issues connected to security with different needs in different cases – Incorporate strategies to detect a security compromise among organizations Nov. 7, 2003 Choonhan Youn 45

  46. Software Downloads • Get QuakeSim XML schemas from here: http://www.servogrid.org/GCWS/Schema/index.html • Get QuakeSim Services bundle from here: http://www.servogrid.org/slide/GEM/Interop/Downloads/S PBundle.tar.gz • Get QuakeSim UI bundle from here: http://www.servogrid.org/slide/GEM/Interop/Downloads/U ISBundle.tar.gz • Get SAML+Kerberos bundle from here: http://www.gatewayportal.org/Downloads/SAML.zip Nov. 7, 2003 Choonhan Youn 46

More Related