W3C Web Services Workshop

1
W3C Web Services Workshop
Position Paper

• Marwan Sabbouh, ms_at_mitre.org
• Stu Jolly, smjolly_at_mitre.org
• Paul Denning, pauld_at_mitre.org
• Dock Allen, dock_at_mitre.org
• Paul Silvey, psilvey_at_mitre.org
• 4/11/2001

Organization D590 Project 03017496-00,
03016026-WA, 03016078-C0, 03014000-C2
2
Acknowledgements

• The authors thank the MITRE Corporation and their
  sponsors for making this possible. Also, we thank
  those who contributed to this work. In
  particular, Dan Hebert, John Morris, Bede McCall,
  Doug Norman, Amanda Martino, Eric Chamberlin, and
  Vuhuy Phan for their comments.

3
Agenda

• Web Model
• Any to Any Computing
• Extensibility
• Interoperability
• Description and Discovery
• Users Context
• Quality of Service
• Security

4
Web Model

• Browser-Web Server interaction is easy,
  transparent, and works
• Relationship any browser to any web server
  interaction
• No apriori knowledge by the client of the server
• Standardizing on HTTP, HTML, and URL
• Allows for intermediaries proxy servers, caching
  servers
• Disadvantage
• Web server to Web server interaction is difficult
• Client must make request of various Web sites
• Result
• Isolated Web islands

5
Web Services Potential

• Web server to Web server interaction is easy
• Relationship Any-to-any
• Should all Web services interact at a basic
  level?
• Web sites collaborating on behalf of users
• Extending firewalls across corporate networks
• Different classes of services on the Web
• Extensibility vs. Interoperability?
• Made possible by adherence to standards
• W3C XML Protocol
• Description and Discovery of Web Services
• Context
• Quality of Service
• Semantics

6
Extensibility

• XML Protocol Architecture is based on a
  layered/extensible approach
• Protocol binding allows for the adoption of
  different protocol stacks
• SOAP encoding allows for the adoption of
  different data models
• Modules allow for evolution
• Intermediaries provide for reverse proxy,
  transfer protocol bridges, etc.

7
Interoperability

• Middleware interoperability
• XML Protocol, XML Schema
• Syntactic interoperability
• XML
• Uniform way that describes how to access services
• WSDL
• Structural interoperability
• Standardizing on a data model
• SOAP encoding
• Mapping different data models
• RDF?
• Semantic interoperability
• Ultimate goal

8
Ensuring Any to Any Computing

• Services must bind to standard Internet Protocols
• Client must support various Internet Protocols
  (SMTP, HTTP, FTP)
• Adopting a standard data model if possible
• Else, provide mapping of distinct data models
• WSDL
• Strict conformance to specifications
• Standards that address module extensions (XAML,
  reliable delivery semantics)
• Tools interoperability
• Standards that describe what a service does
• Standards that describe users context
  information and needs
• Adopting Internet security standards

9
WSDL

• WSDL is used to expose Web Services by defining
• Behavior
• Abstract Operations
• Concrete Operations
• Methods of Access
• Style of Payload (RPC/Document)
• WSDL files are defined using the following
  elements
• Type
• Message
• PortType
• Binding
• Port
• Service

10
UDDI

• Provides yellow, green, and white pages
  functionality
• Provides a standard API for registration and
  lookup of services
• Security
• Registry enjoys a self-supported business model
• Maintains data integrity
• Validates entries on registration
• Requires renewal of registration periodically
• Removes outdated entries

11
Users Context

• Identity
• Role
• Access device
• Location
• Time
• Privacy Constraints
• Must travel with request

12
Quality Of Service (QoS) for Web Services

• See Usage Scenario in XMLP Requirements Document
• Define QoS extensions to XMLP as multiple XMLP
  Modules
• XMLP Blocks for QoS
• Use XML Schema to standardize QoS information
  carried within XMLP Envelope
• XMLP Handlers for QoS
• QoS processing
• Relates to BindingContext (see Abstract Model)
• BindingContext assumed to hold parameters needed
  for lower layer QoS mechanisms (Diffserv, etc.)
• XMLP Block propagates QoS (or Class of Service)
  across XMLP Intermediaries (and potentially
  different transports)
• Preserve end-to-end QoS throughout XMLP message
  path

13
Example XMLP QoS Modules

• SLA Module
• Block Carries UUID or URI of Service Level
  Agreement (SLA) or ebXML Trading Partner
  Agreement (TPA)
• XMLP Handler looks up Service Level Specification
  (SLS) for given SLA/TPA (cached), writes
  appropriate DiffServ parameters into
  BindingContext
• Assumes Binding is QoS-aware (knows how to
  interpret BindingContext.QoS)
• ResponseTime Module
• Block Carries timestamps
• Handler inserts timestamps, collects Response
  Time statistics
• SLA Monitor Module
• Uses data from ResponseTime Module to verify SLA
  compliance, traffic shaping via SLA Module

14
Forum for XMLP QoS Module Defintion

• Propose a new W3C WG under the XMLP Activity
• Specify QoS Modules using XMLP WGs Module
  Template
• Standardize XML Schema of XMLP Blocks for QoS
• Define information model for BindingContext QoS
  data
• Define information model for ModuleContext
• Develop QoS usage scenarios
• Coordinate with other groups
• QoS Taxonomy (Open Group QoS Task Force)
• UDDI registration of Web Service QoS capabilities
• ebXML Collaboration Protocol Profile

15
Security

• Web services provide new security challenges
• WSDL
• Web services infrastructure must be secure
• Security model for UDDI