Web Services for Computational Web Portals

1
Web Services for Computational Web Portals

• Marlon Pierce
• Community Grids Lab
• Indiana University

2
Grid Computing Environments

• GCEs are the general name for Grid clients and
  enabling middleware.
• GCEs aim to bridge the gap between user 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.

3
Web Services Overview

• Web services use Internet standard protocols and
  technologies (XML) to build distributed services
  and applications.
• Leverages XMLs strengths
• General purpose language definition rules.
• Extensibility through namespaces as well as
  specific schema elements.
• Limited inheritance
• Much reusable software.
• Limitations
• Not good for high performance messaging.

4
XML and Web Services

• 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
• Basic web services can use one or both
• Web services are very loosely coupled
• Take as much or little as you want.
• Which is fundamental?
• SOAP is key for message-centric architecture.
• WSDL is key for interface-centric architecture.
• Real applications will need both.

5
What is Missing?

• Transient services
• Web services are not permanent or static.
• May need to be created dynamically and
  registered.
• Addressed by the Open Grid Service
  Architecture/Infrastructure
• Still must address numerous other issues
• Metadata Information services.
• Federation of services.
• Message security.
• Aggregation of web services for real
  applications.
• Aggregation of clients into component
  environments.
• Workflow
• Quality of service

6
Web Service Overview
7
Problems with Traditional Portal Architecture

• Portals accesses heterogeneous back ends 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 dont 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.

Web browser
Web browser
?
services
services


Back end resources
Back end resources
8
Core Web Services

• Lets 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.

9
TERAGRID HotPage
10
Scientific Applications as Web Services

• Science applications consist of one or more core
  Web services.
• Get files to right place, script submission
  instructions, submit the job, get notified at
  various states.
• More needs to be done
• Describe application-specific requirements
• Describe bindings of applications to host
  environments and to Web services

11
Application Lifecyles

• (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.

12
AWS Schema Structure

• We found it useful to divide schema into two
  different 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
• Dont like my queue description schema? Plug in
  your own.

13
Some General Remarks

• Application services are based around schema.
• They are part of a larger class of XML
  schema-based services.
• We need to automate the deployment of these
  services.

14
Sample Steps for Creating Metadata Web Service

• 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.

15
Problems with this Approach

• Previous structure is extremely fragile as any
  change to data model will propagate through the
  system.
• Façade creation is an art form that must
  anticipate usage.
• Client stubs need to be regenerated if the façade
  changes.

16
Automating Metadata Web Services

• 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 democratize schema creation
• Standards should be XML languages, not instances
  of those languages.

17
SchemaWizard and XML
18
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 servers
  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.
• SOMCastors Schema Object Model
• Java files are compiled, and binaries are placed
  into the new projects 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

19
SchemaWizard Architecture
20
SchemaParserData 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

21
XML Form Wizard
22
XML Schema location is given to
SchemaWizard. XML Form Wizard is generated. XML
instance is marshaled.
23
Next Steps for Schema Wizard

• Schema Wizard currently used to automate local
  (to the server) XML message creation.
• 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.

24
(1)
(2)
(3)
Maps Schema to Java classes, binds to WSDL
Retrieves WSDL and generates specific interface
for data
Requests form pages
Dynamic User Interface Component
Browser
Metadata Service
Blah blah blah
HTTP
SOAP
Gathers user requests
Maps entries to WSDL expression of schema and
invokes dynamically (no stubs)
Assigns elements to Castor classes
(4)
(6)
(5)
25
Computational Web Portal Stack

• Web service dream is that core services, service
  aggregation, and user inteface development
  decoupled.
• How do I manage all those user interfaces?
• Use portlets.

Aggregate Portals
User Interfaces
Application Web Services and Workflow
Core Web Services
26
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.

27
(No Transcript)
28
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 very dynamic,
  updated often.
• UDDI has had problems with data aging.
• Such problems can be addressed by peer-to-peer
  and/or messaging technologies.
• Lets try using NaradaBrokering for distributed
  events
• Narada has more extensive capabilities then used
  here.
• Shrideep Pallickara, www.naradabrokering.org

29
Bridging Between Client-Serverand Messaging
Services
Browser
Peers register themselves to Aggregator
Tomcat Server
Blah blah blah
Tomcat Server
Broker Aggregator
Tomcat Server
HTTP
SOAP
Dynamic User Interface Component
Tomcat Server
Tomcat Server
Web service request for information
Servers run Narada Notifiers
30
XML Metadata Nugget Management

• Key to computational web services is information
  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 data
• Create, post, and browse application instance
  data
• Create, post, and browse citations
• Create, post, and browse news groups.

31
Wizard
URI directories cataloged with RSS,
documents retrieved on demand.
Blah blah blah
Nugget Browser
Federated data storage (Files, XML, RDB)
Blah blah blah
32
(No Transcript)
33
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
Authenticate
Security Mechanism
Generating Assertions
Signing
Assertions
Encryption

HTTP
HTTP
HTTP
Web Service
Web Service
Web Service

34
Example Kerberos Message Signing

• Establish both servlet session and GSS context
  between the UI and AS.
• UI signs SAML assertion and SOAP Body message
  with GSS Contexts wrap method.
• Converts signed SAML assertion and SOAP Body
  message to string and attach it to SOAP message.
• Requests SOAP service.
• Service extracts SAML assertion and SOAP Body
  message with GSS Contexts unwrap method from AS
  and verifies it.
• If valid, executes request and returns response.

Web Browser
User Interface Server
Authentication Service
Kerberos Client
Kerberos Server
HTTP(S) SOAP signed SAML
SOAP Service
35
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

36
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 users SAML security assertion.
• Sign the user assertion and SOAP Body messages.
• Rebuild the SOAP messages.

37
The message structure of the SOAP request on the
client-side.

• xmlnssoapenvhttp//schemas.xmlsoap.org/soap
  /envelope/
• xmlnsxsdhttp//www.w3.org/2001/XMLSchema
• xmlnsxsihttp//www.w3.org/2001/XMLSchema-in
  stance
• rg/sign.xsd
• secure SAML
  Assertion message
• KerberosrityMechanism
• wayportal.org/signbody.xsd
• secure SOAP body
  message

38
SAML example

• sis-open.org/committees/security/docs/draft-sstc-s
  chema-assertion-27.xsd"
• MinorVersion"0"
• AssertionID"156.56.104.10.1037385546507"
• Issuer"Gateway Web Portal"
  IssueInstant"2002-11-15T133906.507-0500"
• 406.518-0500" NotOnOrAfter"2002-11-15T134906.
  518-0500"
• http//www.gatewaypo
  rtal.org/agreement.xml
• AuthenticationMethod"urnietfrfc151
  0" AuthenticationInstant"2002-11-15T133906.558-
  0500"
• SecurityDomain"www.gatewaypor
  tal.org" Name"cyoun"/
• urnie
  tfrfc1510
• A
  Kerberos Ticket

39
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.

40
An assertion-based authentication service for
Gateway Web Services
41
Acknowledgements

• Mary Thomas, Steven Mock and the TACC/SDSC team.
• The Alliance Portal Team
• Geoffrey Fox
• Ozgur Balsoy (SW, MDB)
• Choonhan Youn (AWS, SAML)
• Shrideep Pallickara (NaradaBrokering)
• Galip Aydin, Ahmet Topcu, Ali Kaplan, Beytullah
  Yildiz (MDB)

42
Information and Downloads

• Web services www.gatewayportal.org
• Schema wizard and metadata browser
  www.xmlnuggets.org
• NaradaBrokering www.naradabrokering.org
• Email me marpierc_at_indiana.edu