Presentation on theme: "Web Services for Computing Portals Marlon Pierce Community Grids Lab Indiana University."— Presentation transcript:
Web Services for Computing Portals Marlon Pierce Community Grids Lab Indiana University
What Are Web Services? Web services framework is an XML-based distributed object/service/component system. –SOAP, WSDL, WSIL, UDDI Basic ideas is to build a distributed invocation system out of existing Web standards. –Most standards defined by W3C, Oasis (IP considerations) Very loosely defined, when compared to CORBA, etc. –Take what you need –Ignore what you don’t like –Develop what’s missing.
XML Overview XML is a language for building languages. Basic rules: be well formed and be valid Particular XML “dialects” are defined by an XML Schema. –XML itself is defined by its own schema. XML is extensible via namespaces Many non-Web services dialects –RDF, SVG, MathML, XForms, XHTML Many basic tools available: parsers, XPath, and XQuery for searching, etc.
XML and Web services XML provides a natural substrate for distributed computing: –Its just a data description. –Platform, programming language independent. So let’s describe the pieces. Web Services Description Language (WSDL) –Describes how to invoke a service (compare with CORBA IDL). –Can bind to SOAP, other protocols for actual invocation. Simple Object Access Protocol (SOAP) –Wire protocol extension for conveying RPC calls. –Can be carried over HTTP, SMTP. Web Services Inspection Language (WSIL) –A very simple “discovery” mechanism for locating WSDL service definitions.
Web Services in Action The following examples illustrate how Web services interact through a browser interface. The browser interface could easily be changed to any other client.
Client Stubs DB Service 1 JDBC DB Job Sub/Mon And File Services Operating and Queuing Systems User Interface (1) (2) (3) (4) (5) (6) (7) (8) (9) (10) (11) (12)(13) (14) DB Service 2 JDBC DB (15) (16) (17) (18) (19) Host 1Host 2Host 3
Web Services Description Language Defines what your service does and how it is invoked.
WSDL Overview WSDL is an XML-based Interface Definition Language. –You can define the APIs for all of your services in WSDL. WSDL docs are broken into four major parts: –abstract interface definitions (including messages and data definitions). –protocol bindings (to SOAP, for example) –service point locations (URLs) Some interesting features –A single WSDL document can describe several versions of an interface. –A single WSDL doc can describe several related services.
WSDL Example: Job Submission The example is a simple service that can executes local (to the server) Unix commands. Service implementation (in Java) has a single method –ExecLocal takes a single string argument (the command to exec) and returns a 2D string array (standard out and error). The WSDL maps to a Java interface in this case.
WSDL Elements I Types: describes custom XML data types (optional) used in messages. –For OO languages, types are a limited object serialization. Message: abstractly defines the messages that need to be exchanged. –Conventionally messages are used to group requests and responses. –Each method/function in the interface contains 0-1 request and 0-1 response messages. –Consists of part elements. Usually you need one part for each variable sent or received. Parts can either be XML primitive types or custom complex types.
Types for Job Submission Recall that the job submission service sends a string (the command) and returns a 2D array. Strings are XML Schema primitive types, so we don’t need a special definition. Arrays are not primitive types. They are defined in the SOAP schema, so we will import that definition.
Message Elements for Job Submission Service Our service implementation has one method of the form (in Java) public String execLocalCommand(String cmd) This will require one “request” message and one “response” message. Each message has one part: –Request message must send the String cmd. –Response must get back the String array (defined previously as a custom type). If we had to pass two input variables, our “request” message would need two part elements. Note the name attributes of messages are important!
portTypes portType elements map messages to operations. You can think of portType==class, operation==class methods. Operations can contain input, output, and/or fault bindings for messages. An operation may support of the following message styles: –One-way: request only –Two-way: request/response –Solicit-response: server “push” and client response –Notification: one-way server push
portType for JobSubmit We previously defined the messages and types needed. Now we bind them into the portType structure. PortType names are important –Will be referenced by binding element. Note names of previously defined messages are used as references in the operations.
PortType Bindings portTypes are abstract interface definitions. –Don’t say anything about how to invoke a remote method. Remote invocations are defined in binding elements. Binding elements are really just place holders that are extended for specific protocols –WSDL spec provides SOAP, HTTP GET/POST, and MIME extension schema examples.
SOAP Bindings for JobSubmit Service Note that the binding element contains a mixture of tags from different namespaces (wsdl and wsdlsoap). WSDL child elements for binding element are operation, input, and output. WSDLSOAP elements are from a different XML schema (a new one, neither WSDL or SOAP). –This is how you extend WSDL bindings: define a new schema that gives mapping instructions from WSDL to the protocol of choice. The binding element name is important, will be used as a reference by the final port binding.
SOAP Binding in Detail All this really means is “encode the message by the rules in encodingStyle and put it in the SOAP body.”
Service and Port Definitions So far, we have defined the class method interfaces (portTypes) and the rules for binding to a particular protocol. Port elements define how the bindings (and thus the portTypes) are associated with a particular server. The service element collects ports.
26 Service and Port Elements for the Job Submission Service
Explanation Note the port element’s binding attribute points to the appropriate binding element by name. The only purpose of the port element is to point to a service location (a URL). This is done by extension (SOAP in this case.) Ports are child elements of the service element. A service can contain one or more ports. –Note the value of multiple ports: a single portType may correspond to several ports, each with a different protocol binding and service point.
WSDL Trivia The schema rules allow all of the elements we have discussed to appear zero or more times. A single WSDL file may contain many portTypes (although this is not usual). –You may want to do this to support multiple interface definitions of a service for backward compatibility. Multiple ports may also be used to provide different views of a service –One portType defines the interface. –Another provides access to metadata about the service. –Yet another may define how the service interacts with other services via notification/event systems. This is being exploited by OGSA.
Open Grid Services Architecture in One Slide Conventions for metadata about services –serviceData: extends portType elements to provide additional metadata needed to describe the particular service. When is the service available? –serviceDataDescription: defines serviceData element rules. Is an element a string? An int? How may times can it occur? Various supplementary portTypes –GridService: allows you to query serviceData –Notification ports: communicate state changes.
Simple Object Access Protocol A message format for exchanging structured, typed information
SOAP Basics SOAP is often thought of as a protocol extension for doing RPC over HTTP. This is not completely accurate: SOAP is an XML message format for exchanging structured, typed data. It may be used for RPC in client-server applications but is also suitable for messaging systems (like JMS) that follow one-to-many (or publish-subscribe) models.
SOAP Structure A SOAP message is contained in an envelop. The envelop element in turn contain (in order) –An optional header with one or more child entries. –A body element that can contain one or more child entries. These child entries may contain arbitrary XML data.
SOAP Headers Headers are really just extension points where you can include elements from other namespaces. –i.e., headers can contain arbitrary XML. Header entries may optionally have a “mustUnderstand” attribute. –mustUnderstand=1 means the message recipient must process the header element. –If mustUnderstand=0 or is missing, the header element is optional.
SOAP Body The SOAP body contains any number of entries that must be immediate children. Body entries are really just placeholders for arbitrary XML from some other namespace.
Example Messages Recall the WSDL interface for “SubmitJob” –Sends one string command –Returns array of strings for standard out and error. The envelop is decorated with a few useful namespaces: –soapenv defines the version –xsd is the Schema definition itself –xsi defines some useful constants. The body is just an arbitrary XML fragment. –Assumes the recipient knows what this means. –Recipient must looks up the ExecLocalCommand operation in the JobSubmit service and passes it one string argument. –The ns1 namespace tells the recipient the WSDL namespace that defines the service. –xsi:type lets the recipient know that the arbitrary XML element in0 is in fact a string, as defined by the XML Schema.
Example Response The structure is the same as the request. The interesting thing here is that the request returns a 2-element array of two strings. –Arrays not defined by XML schema –SOAP encoding does define arrays, so use xsi:type to point to this definition. – surrounds each array element. Note that arbitrary XML returns can likewise be encoded this way. –Use xsi:type to point to a schema.
Developing Web Services Using Apache Axis to develop Java implementations of Web services.
Web Service Development Tools Web service toolkits exist for various programming languages: –C++,Python, Perl, various Microsoft.NET kits. We’ll concentrate on building Java Web services with Apache Axis. Language and implementation interoperability is addressed through WS-I. –http://www.ws-i.org/
Apache Axis Overview Apache Axis is a toolkit for converting Java applications into Web services. Axis service deployment tools allow you to publish your service in a particular application server (Tomcat). Axis client tools allow you to convert WSDL into client stubs. Axis runtime tools accept incoming SOAP requests and redirect them to the appropriate service.
Developing and Deploying a Service Download and install Tomcat and Axis. Write a Java implementation –Our SubmitJob is a simple example but services can get quite complicated. –Compile it into Tomcat’s classpath. Write a deployment descriptor (WSDD) for your service. –Will be used by Axis runtime to direct SOAP calls. Use Axis’s AdminClient tool to install your WSDD file. That’s it. –Axis will automatically generate the WSDL for your service.
Explanation Use Axis’s command-line AdminClient tool to deploy this to the server. Axis will create a service called –http://your.server/services/SubmitJob WSDL for service is available from –http://your.server/services/SubmitJob?wsdl A list of all services is available from –http://your.server/services
Check your Tomcat Server for a list of deployed services.
WSDL generated by inspecting the Java implementation. Can be download from the server. (XML was shown in earlier slides)
Building a Client with Axis Obtain the WSDL file. Generate client stubs –Stubs look like local objects but really convert method invocations into SOAP calls. Write a client application with the stubs –Can be a Java GUI, a JSP page, etc. Compile everything and run.
Sample Java Client Code /**Create SubmitJob client object and point to the service you want to use */ SubmiJob sjws = new SubmitJobServiceLocator().getSubmitjob(new URL(http://your.server/services/SubmitJob)); /** Invoke the method as if local. */ String messages = sjws.execLocalCommand(command);
Two Notes On Client Stubs Axis stubs convert method calls into SOAP requests but WSDL does not require the use of SOAP. –Web Service Invocation Framework (WSIF) from IBM allows flexibility of protocols. (Alek Slominski, IU) Client stubs introduce versioning problems. –We are developing dynamic (stubless) clients that construct SOAP messages by inspecting WSDL at runtime.
Web Service URLs Java –http://xml.apache.org/axis/ XSOAP: C++ and Java toolkits for WS – http://www.extreme.indiana.edu/xgws/xsoap/ gSOAP: C++ SOAP toolkit –http://www.cs.fsu.edu/~engelen/soap.html Python Web Services: –http://pywebsvcs.sourceforge.net/ Perl: –http://www.soaplite.com/
GEM Portal Services and user interfaces for our earthquake modeling portal.
Solid Earth Research Virtual Observatory Grid A number of simulation methods for studying earthquakes are being developed by GEM consortium including: –Simplex, Disloc (JPL) –Virtual California (UC-Davis) –PARK codes (Brown) As codes become more robust and accepted, 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 link together NASA funded activity to develop SERVOGrid Interoperability framework
Grid Web Service and Portlet based Portal Architectures Web services are part of a broad industry and academic initiative to build distributed computing infrastructure around existing standards (HTTP, XML, etc). Web services can be used to provide lightweight service descriptions and send messages between components in XML. OGSA (Open Grid Service Architecture) builds on basic Web Services –Component model for Grid replacing/building on CORBA, COM, Enterprise Javabeans etc. Portlets provide component model for user interfaces
Computing Portal Grid Web Services We have built a suite of general purpose Grid Web services for managing distributed applications. Core Computing services define general purpose functions: –Ex: job submission, file transfer, job monitoring, management of jobs and results –Described as a GridShell as plays same role to Grid that Shell does for UNIX on a single machine Application Grid Web services include metadata about applications. –Built on top of core services. –Original application NOT changed We have developed a toolkit that allows one to convert general software packages into Grid Web Services and manage application collections
Raw (HPC) Resources Middleware Database Portal Services System Services Application Service System Services Grid Computing Environments User Services “Core” Grid Application Metadata Actual Application
Application Grid Web Services AGWS are designed to make scientific applications (i.e. earthquake modeling codes) into Grid Resources AGWS services are described by two XML Schemas: –Abstract descriptors describe application options. Used by the application developer to deploy his/her service into the portal. –Instance descriptors describe particular user choices and archive them for later browsing and resubmission.
Portals Aggregate Access to Distributed Services
JSP + Client Stubs DB Service 1 JDBC DB Job Sub/Mon And File Services Operating and Queuing Systems Browser Interface DB Service 2 JDBC DB Host 1Host 2Host 3
GEM Portlets and Portal Stacks User interfaces to GEM services (Code Submission, Job Monitoring, File Management for Host X) are all managed as portlets. Users, administrators can customize their portal interfaces to just precisely the services they want. Core Grid Services User facing Web Service Ports Application Grid Web Services Aggregation Portals Message Security, Information Services
File Selector Screenshot Users can view files on remote hosts –Shown is user file list for host noahsark. –Host solar is also shown. Files can be uploaded or downloaded between PC and remote host. Files may be crossloaded between two remote hosts. Same interface definition may be used to access databases.
Lists user files on selected host, noahsark. File operations include Upload, download, Copy, rename, crossload Tabs indicate available portlet interfaces. File management
Application Selection Screen Shots Users can select from available codes (Simplex, Disloc, various VirtualCalifornia) Users also select from available hosts for particular code (grids, noahsark, solar shown). Selecting solar (Sun 64 Node E10000) prompts user for information needed to use PBS script generating service.
Select desired application and host Generate script for job submission User Application Selection and Submission
Application Administrator Interfaces Application Administrators deploy and manage applications Update screen shows various application and host parameters that are set by the user. These are used to generate user interfaces for the selected codes.
Provide information about application and host parameters Select application to edit Administer Grid Portal
Futures I: General Capabilities System builds on Gateway Portal developed for NCSA Alliance and DoD HPCMO. This project intends to: Integrate portlets from other groups in collaborations (common interoperability framework for all tiers) Continue developing message-based security system (currently available as demonstration) that signs SOAP messages. Integrate AGWS and Results Manager with arbitrary Schema Wizard/Storage/Browser system used in Indiana XML newsgroups. Add negotiation capabilities to Web Services for version control Track evolving OGSA service standards and implementations. Add dynamic information service and monitoring capabilities for transient Web Services. Distributed, ant-based tools to simplify service upgrades of distributed servers (and simplify our lives).
Futures II: SERVOGrid Assist with design of common data format and associated tools for GEM codes. –i.e. SERVOGrid Object Model defined in XML Add support for service linkage (workflow) for specific GEM applications –e.g. Disloc Simplex interoperation). Add support for Web-based visualization with portlet interface. SERVOGrid portal will be publicly available
Web Services for Computational Web Portals Marlon Pierce Community Grids Lab Indiana University
Grid Computing Environments GCEs are a general name for both Grid clients and middleware. GCEs aim to bridge the gap between users and Grid infrastructure developers. GCE-RG: Official GCE forum in the GGF. –Geoffrey Fox, Dennis Gannon, Mary Thomas are co- chairs. The work presented here is an outgrowth of several GGF and workshop meetings. See Grid Computing: Making the Global Infrastructure a Reality " edited by Fran Berman, Geoffrey Fox and Tony Hey –http://www.grid2002.org
XML and Web Services Web services use Internet standard protocols and technologies for distributed computing. Basic components –Wire exchange of XML messages (SOAP) Extensible message wrapper capable of carrying general XML, binary data, remote procedure call instructions. –XML descriptions of service interfaces (WSDL) Can express detailed description of how to invoke service –But the architecture is loosely connected Web services are very loosely coupled –Distributed development –Distributed deployment
What is Missing? Transient services –Web services are not permanent or static. –May need to be created dynamically and registered. –One of the issues being addressed by the Open Grid Service Architecture/Infrastructure Still must address numerous other issues –Metadata information services. –Aggregation of web services for scientific applications. –Aggregation of clients into component environments. –Message security. –(Workflow). –(Quality of service). –(Federation of services).
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 aspects of services? –Portal developers don’t have to reinvent every single important service. –Users will have access to more services than any one project can provide. –Users will be able to pick up the best available implementation of a service. services Web browser services Back end resources ? … … …
Portals + Web Services Client Browser User Interface Server Service Provider Information Repository Service Provider Service Provider Service Provider (SOAP/HTTP) (HTTP) Publish Services Bind and Use Service Find Service Client Requests (1) (2) (0) (3)
Core Web Services Let’s get started writing services! Given WSDL and SOAP, what can you build? Site Dependent Services –Job Submission –File Transfer –Job Monitoring –Host Monitoring Site Independent Services –Context Management –Batch/RSL Generation –Archiving Services These core services are simple, stateless. Many others (from Gannon group, for example)
Example Core Service: Context Management Common problem of portals is to store all of the metadata associated with user sessions. Context Management service provides simplest possible data model –Context manager provides an easy interface to data trees. –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, etc. CM metadata stored on file systems, XML-native databases, …. –Actual data may be anywhere. Searched with XPath queries.
Application Codes as Web Services Scientific applications consist of several core Web services. –Get files to right place, script submission instructions, submit the job, get notified at various states. We need a meaningful metadata model for applications –Describe application-specific requirements –Describe bindings of applications to host environments and to Web services
Application Web Services (From discussions with Tomasz Haupt) We divide application lifecycles into several stages: –Abstract state: describes optional choices and configurations that are available. –Ready state: Specific choices are made –Submitted: Application is running (and OGSI takes over) –Completed: Application is finished, but we need to archive information about it.
AWS Schema Structure Two sets of XML schema: –Application Descriptors: describe abstract state. –Application Instance Descriptors: describe particular instance states (ready, running, archived). 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.
General Metadata Web Services (MDWS) Application web services are based around schema. They are part of a larger class of XML schema-based metadata services. We need to automate the deployment of these services. Current process is time consuming and fragile –An affront to any virtuous programmer. Deployment Steps –Develop XML schema –Bind schema to data classes (Castor) –Write Façade classes to simplify use of fine-grained interface. –Compile and deploy service –Throw WSDL to client –Create client stubs –Write Web interface or GUI client with stubs. –Scream when schema changes.
Automating Metadata Web Services (MDWS) Metadata services are extremely important, should be very wide spread. –Should just create your schema and go. Need to drastically simplify process of redeploying services when schema are updated. Need to keep metadata schema creation democratic –Keep standards at the right level: standardize around schemas and a few XML languages
Schema Wizard: First Steps for Automating MDWS The Schema Wizard reads in XML schema and maps these to JSP pages. –Nice mapping between HTML visual widgets and schema elements It also ties form actions to appropriate data objects. Use the Schema Wizard to create a user interface for your schema Use the generated User Interface to create XML instances
SchemaWizard Architecture Castor Schema Unmarshaller Castor Source Generator Castor Source Generator JavaBeans Castor SOM Schema Parser Schema Parser Velocity Templates Java Compiler Annotated XML Schema Web Application Template Web Application Template LibrariesClassesJSPs XML Form Wizard created as a Web Application
XML Schema location is given to SchemaWizard. XML Form Wizard is generated. XML instance is marshaled.
Next Steps for Schema Wizard Schema Wizard currently used to automate local (to the server) XML message creation for publication. –More about this in a minute We also want to use the SW create WSDL wizards for metadata services –Use Castor to represent schemas as Java classes on a remote server. –Note that get/sets define the interface, so any schema expressible as WSDL. –Use WSDL (actually, convenient intermediate form) in the schema wizard. –Schema Wizard forms tied to classes that can discover and dynamically invoke methods to get/set remote XML instance.
XML Metadata Nugget Management All web service entities are described with metadata and given URIs –Ex: Application Web Services define metadata about applications. –Application instance records archive all portal sessions. What do we need? –Schema wizards to simplify deployment of new schema services and creation of valid instances. –Federating messaging systems to deliver created nuggets. –Distributed persistent storage –Name based browsing and searching of XML nugget catalogs. Such systems should be able to handle any metadata –Create, post, and browse application instance data, citations, news postings, etc.
Blah blah blah Wizard Federated data storage (Files, XML, RDB) Blah blah blah Nugget Browser URI directories cataloged with RSS, documents retrieved on demand. Single Publish/Subscribe Layer Publish with JMS or Narada
Computational Web Portal Stack Web service dream is that core services, service aggregation, and user interface development decoupled. Q: How do I manage all those user interfaces? A: Use portlets. Core Web Services User Interfaces Application Web Services and Workflow Aggregate Portals Message Security, Information
Portlets in One Slide Portlets are pieces of (Java) code that run in the UI server. Each portlet corresponds to one content provider (local or remote). Portals aggregate portlets into a single, user- customizable display. Jetspeed is a free, open source portlet implementation. Jetspeed portlets need to be extended to handle our requirements.
Message Level Security Multiple layers of security. Transport level security provides point-to-point protection. Also need message level security for end- to-end protection. Core Web Services User Interfaces Application Web Services and Workflow Aggregate Portals Message Security, Information
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. Web Browser SOAP Service Kerberos Client User Interface Server HTTP(S) +SOAP +signed SAML Kerberos Server Authentication Service HTTPS
Internet (HTTP) cloud Client An assertion-based authentication service for Gateway Web Services
Acknowledgements Mary Thomas, Steven Mock and the TACC/SDSC teams. Alliance Portal Project (ask for demo) Geoffrey Fox Ozgur Balsoy (Schema Wizard, Metadata Management) Choonhan Youn (Core and Application Web Services, SAML) Galip Aydin, Ahmet Topcu, Ali Kaplan, Beytullah Yildiz (Metadata management)
Information and Downloads Web services: www.gatewayportal.orgwww.gatewayportal.org Application Metadata Schemas: www.servogrid.org/GCWS/Schema Schema wizard and metadata browser: www.xmlnuggets.org www.xmlnuggets.org Email me: email@example.com@indiana.edu See me at “Research in Indiana” booth.
Web Services Overview Web services use Internet standard protocols and technologies (XML) to build distributed services and applications. Leverages XML’s strengths –General purpose language definition rules. –Extensibility through namespaces as well as specific schema elements. –Limited inheritance –Reusable software (parsers,Castor) Limitations: –Not good for high performance messaging. –Most pieces still being developed
Information Archival Web Service (TACC/SDSC) Collects machine status info Uses various mechanisms for collecting info Queue info, job info, node info –MDS, Ganglia, Clumon, PBS qstat,…. All info expressed in schema-based XML Secure (SSL, password protected) Info is archived –Some averaged –Others are snapshots
SchemaWizard Architecture SW consists of an empty Web application, the SchemaParser, and Velocity Macro template files. First, SW unpacks and deploys a predefined and empty Web application into a Web server’s application repository. A schema whose location is provided by a user is read in to create an in-memory representation (SOM) and also to create Java files. –SOM=Castor’s Schema Object Model Java files are compiled, and binaries are placed into the new project’s classes directory. Each schema element is mapped to a self-contained JSP nugget. JSP nuggets are generated from templates. –One template for each element type (simple, complex, enumerated, unbounded,….). –Velocity is used for convenient scripting of JSP. The final JSP page is an aggregate of the JSP nuggets files (using ). Complex schema elements are mapped to JavaBeans generated from the schema with Castor. –Scripting templates set up the imports
XML Form Wizard Index Page create a root element bean as new or from existing XML include sub element pages if submitted, validate the bean content if editing is complete, generate XML Project Page create a session initialize the environment retrieve an XML instance list XML Complex Types create a complex type bean include sub elements if submitted, validate the content Simple Types if parent bean has data, display content for this type (or property) using a form element if form is submitted, update the parent bean for this type list XML instance New command includes
SchemaParser Data Flow and Actions Traverse schema for types Collect type information, create a context Decide template: Project page Index page Simple type Enumerated simple type Unbounded simple type Complex type Unbounded complex type Velocity Template Engine Castor SOM Schema object Individual types Velocity context with type info Context, template JSP JavaBeans info Templates
SchemaWizard and XML Annotated XML Schema SchemaParser XML Form Wizard XML Instances follows generates input of outputs edited SchemaWizard A Mapping of XML to SchemaWizard Parts
SAML example http://www.gatewayportal.org/agreement.xml urn:ietf:rfc:1510 A Kerberos Ticket urn:ietf:rfc:1510 A Kerberos Ticket 5
Discovering Deployed Services Our model deploys core services on distributed servers. –Need to find servers, their deployed services, WSDLs, service points. This model has usual problems of distributed systems. –Network failures, machine crashes, software failures, topological defects. Information services must be dynamic, up-to-date. –UDDI has had problems with data aging. Such problems can be addressed by peer-to-peer and/or messaging technologies. –Let’s try using NaradaBrokering for distributed events –Narada has more extensive capabilities then used here. –Shrideep Pallickara, www.naradabrokering.orgwww.naradabrokering.org
Integration of Security into Web Services 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. Users Security Mechanism Web Service …… Assertions Signing Encryption Authenticate Generating Assertions Assertions SOAP …… HTTP
Technical resources Modified Apache Axis 1.0: SOAP Engine Security assertion –SAML being standardized at OASIS is an XML-based security standard for exchanging authentication and authorization information. –SAML schema: draft-sstc-schema-assertion- 27.xsd Kerberos: Version 5, Release 1.2.2
Bridging Between Client-Server and Messaging Services Blah blah blah Browser Dynamic User Interface Component Broker Aggregator Tomcat Server Tomcat Server Tomcat Server Tomcat Server Tomcat Server Servers run Narada Notifiers Peers register themselves to Aggregator Web service request for information SOAP HTTP
The message structure of the SOAP request on the client-side. http://www.w3.org/2001/XMLSchema-instance http://www.gatewayportal.org/sign.xsd secure SAML Assertion message Kerberos http://www.gatewayportal.org/signbody.xsd secure SOAP body message
The client-side process Convert SAML schema to Java classes –Castor can be used to easily convert between XML and Java data objects. Develop utility classes for creating assertions, marshalling them back and forth between Java and SAML. –Assertion attributes filled in by the appropriate mechanism. Login process: the authentication and getting the Kerberos ticket. Establish the security context with the server for getting the shared key. Generate user’s SAML security assertion. Sign the user assertion and SOAP Body messages. Rebuild the SOAP messages.
The server-side process Establish the security context with client for getting the shared key. Handle the SOAP message. –Secure assertion message. –Secure body message. –Security mechanism name such as Kerberos, PKI. –Message format such as SAML, WS-security. Unwrap the secure assertion It checks the validity of the assertions. –Issuer name –“Conditions” time limit –Subject name –Authorization for accessing resources Unwrap SOAP body message Rebuild the SOAP message.
Blah blah blah Dynamic User Interface Component HTTP Metadata Service SOAP Gathers user requests Maps entries to WSDL expression of schema and invokes dynamically (no stubs) Assigns elements to Castor classes Browser Maps Schema to Java classes, binds to WSDL Retrieves WSDL and generates specific interface for data (1) (2) Requests form pages (3) (4) (5) (6) Schema Wizard for MDWS
Context Manager Architecture Client Axis Servlet SOAP/HTTP Context Manager Shared WSDL Interface FSXMLDB Internal Communication Context Data
Miscellaneous Info WSDL-to-Java mappings are defined by JSR 172. See http://www.jcp.org/en/jsr/detail?id=172. http://www.jcp.org/en/jsr/detail?id=172 Other language mappings for WSDL depend on appropriate standards body.