W3C Web Services Architecture: An Overview and Update

1
W3C Web Services Architecture An Overview and
Update

• David Booth, Ph.D.W3C Fellow /
  Hewlett-Packarddbooth_at_w3.org
• OOP2004 Munich, Germany 22 January 2004
• Slides http//www.w3.org/2004/Talks/0122-munich-w
  sa-dbooth/ or http//tinyurl.com/2bp55  

2
Speaker Info

• Fellow at W3C
• Sponsored by Hewlett-Packard / Software
• Working on W3C standards technologies
• Web Services
• Semantic Web
• PhD in Computer Science from UCLA
• Many years of programming and OSs

3
Outline

• Web Services work at W3C
• W3C Web Services Architecture (WSA) Working Group
  (WG)
• Goals and challenges
• W3C Web Services Architecture
• Lessons learned
• Status of WS work at W3C

4
Acknowledgements

• Thanks to
• Carine Bournez, W3C
• Hugo Haas, W3C
• Yves Lafon, W3C
• Philippe Le Hégaret, W3C
• C. M. Sperberg-McQueen, W3C
• Special thanks to
• Michael Champion, for allowing me to adapt many
  of his slides

5
Web Services is Confusing!

• Bewildering number of specifications, some
  overlapping
• Difficult to track and make sense of it all
• Mixture of real standards, proto-standards, good
  ideas, marketing fluff
• See alsohttp//www.w3.org/2003/03/ws-specs.html

6
W3C

• Consortium of nearly 400 member companies
• Mission "Lead the Web to its full potential"

7
W3C Standards Work

• Four umbrella domains, many activities
• Architecture
• XML, Web Services, Internationalization, etc.
• Interaction
• HTML, Graphics, Voice Browser, Device
  Independence, etc.
• Technology Society
• Semantic Web, Privacy, Patent Policy, etc.
• Web Accessibility Initiative
• See http//www.w3.org/WAI/ 

8
W3C Work on Web Services Foundations

• XML Activity
• XML, XML Schema, XML Query, XKMS
• Technology and Society Domain
• XML Encryption, Canonicalization, Digital
  Signatures, P3P

9
W3C Work on Web Services Web Services Activity

• Web Services Activity
• XML Protocol (SOAP 1.2)
• Web Services Architecture Working Group
• Web Services Description Working Group (WSDL 2.0)
• Web Services Choreography Working Group
• Semantic Web Services Interest Group (NEW)

10
W3C Web Services Architecture Working Group (WSA
WG)

• Formed in Feb. 2002
• Goals
• Describe vendor-neutral architecture of Web
  services
• Consistent with existing Web architecture and
  Semantic Web
• Identify new W3C work needed
• Challenge
• Vendor architectures propose what should happen
• WSA tries to analyze what is happening.

11
Not an Easy Task

• It's hard to define exactly what some common
  terms really mean
• E.g., "Web service" or "asynchronous"!
• How can an industry-wide technical group achieve
  consensus on matters that their employers are
  hotly disputing in public?

12
What Is a "Web Service"?(Informal, Street
Definition)

• Web service
• Application intended for use by another (client)
  application
• By exchanging XML messages
• Via the Web or network

13
What Is a "Web Service"?(WSA WG Definition)

• "A Web service is a software system designed to
  support interoperable machine-to-machine
  interaction over a network. It has an interface
  described in a machine-processable format
  (specifically WSDL). Other systems interact with
  the Web service in a manner prescribed by its
  description using SOAP messages, typically
  conveyed using HTTP with an XML serialization in
  conjunction with other Web-related standards."
  Emphasis added

14
What is the Web Architecture?

• W3C Technical Architecture Group (TAG) document
  at http//www.w3.org/TR/webarch/
• A networked information system involving
  "agents"
• Each URI identifies a Resource
• Representations of this resource may be
  retrieved (if available)
• Representations may use an open-ended set of
  formats such as HTML, XML, CSS, RDF

Source W3C TAG "Architecture of the World Wide
Web"
15
The Web and Web Services

• WSA attempts to be based on Web architecture
• But WSA is protocol-neutral
• WSA must support any transport protocol
• Diagram clarification SOAP use is not always
  RESTful, but can be

Web of URIs
Web of HTTP
Other protocols
RESTful Web
HTTP tunneled
Web of widely deployed media types
RESTful Web Services
SOAP
Adapted from Noah Mendelsohn, "How Many Webs"
http//www.w3.org/2003/Talks/techplen-ws/w3cplena
ryhowmanywebs.htm
16
The Great Debate over REST

• Consumed much time and bandwidth, BUT
• Raised important architectural issues
• Key questions
• What is a RESTful WS?
• Should WSA support RESTful WS?
• Should WSA require WS to be RESTful?

17
What is REST?

• REpresentational State Transfer
• Architectural style defined in Ph. D. thesis by
  Roy Fielding, a key developer of HTTP, to explain
  the Webs success
• Key Points
• "Stateless" (a misnomer) Message meaning does
  not depend on the recipient's state
• "Uniform interface" Set of actions should be
  generic (e.g. HTTP verbs)

18
Thoughts on REST Debate

• REST perspective has been taken seriously
• SOAP 1.2 supports HTTP and REST more fully than
  SOAP 1.1 did
• "Asynchronous Document exchange" approaches are
  getting mindshare at the expense of "RPC"
  approaches
• There is an increasing tendency to use Web URIs
  in specs when a universal identifier is needed
• State management much more explicitly discussed
• But it has not prevailed overall in the WG

19
Web Services and REST

• WSA encompasses both RESTful and non-RESTful
  styles
• Web services can be RESTful, but
• Web services are not required to be RESTful
• Whether they should be remains in dispute

20
Overview of the W3C Web Service Architecture
Policy ModelConcepts relating to constraints
on the behavior of agents and services, e.g.
security, quality of service, management, etc.
Service Oriented ModelConcepts related to
services offered and requested, as well as their
semantics, choreography, etc.
Resource Oriented ModelConcepts relating to the
abstraction of a Web resource, how it is
identified, and how it is manipulated.
Message Oriented ModelConcepts related to
message structure, transport issues without
reference to the significance of the messages
themselves
21
The Message Model

• Concepts relationships are defined in "mind
  map" diagrams (above) and in prose

22
The Service Model
23
The Resource Model
24
The Policy Model
25
Formalization in OWL Ontology Language

• In addition to prose, the working group is using
  OWL to define the concepts and relationships
  involved in the WSA
• OWL is a Web ontology language defined by
  W3C("Ontology" A defined set of concepts and
  the relationships between them)
• Conversion from prose to OWL is being done by
  collaborators at Carnegie-Mellon University
• OWL formalization helps find ambiguities and
  inconsistencies in the prose descriptions

26
OWL Formalization Example

• lt!-- Restriction a message can have at most one
  description --gt
• lt!-- inferred from the wording "...may have a...
  --gt
• ltowlClass rdfabout"Message"gt
• ltrdfscommentgt
• A message can have at most one message
  description
• lt/rdfscommentgt
• ltrdfssubClassOfgt
• ltowlRestrictiongt
• ltowlonProperty rdfresource"describedUsin
  g"/gt
• ltowlmaxCardinality rdfdatatype
  "xsdnonNegativeInteger"gt1lt/owlmaxCardinalitygt
• lt/owlRestrictiongt
• lt/rdfssubClassOfgt
• lt/owlClassgt

27
Spin-off Work

• WSA WG recommended chartering a Web Services
  Choreography group in late 2002
• Soon after, a similar effort was launched to
  standardize the Business Process Execution
  Language (BPEL4WS) at OASIS
• WS Choreography working group chose to try to
  minimize overlap with the BPEL effort
• BPEL and WS-Choreography arose from similar ideas
  and proto-requirements, but are moving in
  different directions

28
"Orchestration" is architecturally distinct from
"Choreography"
BPL
CDL

• A Choreography is an interaction among equals,
  each guided by the Choreography Description
  Language document

• An Orchestration has one agent in charge,
  executing the processes as prescribed by a
  Business Process Language document

29
What Have We Learned?

• Noted architectural gaps between specs
• Intermediaries!
• Concepts of MEP, Choreography, Orchestration,
  composition
• Noted the role of semantics, and the need for
  machine-processable semantics
• Clarified the role of discovery
• Clarified relationships among WS and Web, REST, OO

30
What Have We Learned?-- WS Specs

• WS specs form a "cloud", not a "stack"
• There is no One True Web Services Stack
• Stack diagrams are vendor-specific
• Each reflects its own viewpoint
• None of this will come easily
• Industry-wide consensus is elusive.

31
What Have We Learned?-- Objects and the Web

• No contradiction between REST and Web services
• WSA discussions helped clarify
• Distributed Object / RPC perspective not
  fashionable
• Still appropriate in fast, secure, well-managed
  environments
• XML/SOAP/WSDL help bridge platforms as COM/CORBA
  could not
• Either is appropriate in some situations, not all

32
What Have We Learned?-- It's Hard!

• No methodology, business process diagramming
  tool, IDE, programming language, etc. is going to
  make implementing a "service oriented
  architecture" quick and easy.
• Collaboration between business and technical
  people is required

33
Remaining Needs

• Handling diversity
• It's clear that we're not close to having a
  single standard format/protocol for every "box"
  in the WSA
• Finding the right tradeoff between innovation and
  standardization will be difficult
• Performance
• Many reports of 10X overhead of XML vs "binary"
• Good performance interoperability tradeoff may
  be hard to achieve. Moore's Law may rescue us
• SOAP 1.2 binding framework permits optimizations,
  e.g. MTOM
• Machine processable semantics
• Discovery
• Evolution of concepts
• Subtle incompatibilities in message vocabularies

34
WS Semantics

• WSDL only defines syntactic-level interface
• Client and Service must also agree on semantics
• "Semantics" "meaning"
• Can be oral or written (preferably)
• Can be human-oriented (e.g., English) or
  machine-processable (e.g., RDF)
• Subtle differences can arise if not formalized

35
Semantics and Discovery

• Semantics are also critical to discovery
• Need machine-processable "Functional Description"
  that captures partial semantics

36
Status of W3C WS Work

• WSA WG
• coming to end of chartered lifetime
• WSA document will be published as a W3C Note to
  capture what we learned
• SOAP 1.2
• essentially done working on MTOM
• WSDL 2.0
• in progress
• WS-Choreography
• in progress
• Semantic Web Services Interest Group
• recently started

37
Semantic Web Services Interest Group

• Forum for exchange
• Breeding ground for new work
• Some topics under discussion
• WS Semantics in Discovery Composition
• Mapping WS technologies to Semantic Web
• Leveraging Semantic Web technologies to enhance
  Web services
• OWL-S
• Ontology language for Web Services

38
Outline

• Web Services work at W3C
• W3C Web Services Architecture (WSA) Working Group
  (WG)
• Goals and challenges
• W3C Web Services Architecture
• Lessons learned
• Status of WS work at W3C

39
END

• W3C Mission "Lead the Web to its full potential"