1 W3C Web Services Architecture: An Overview and Update David Booth, Ph.D. W3C Fellow /...

1

W3C Web Services Architecture: An Overview and Update

David Booth, Ph.D.W3C Fellow / Hewlett-Packard

dbooth@w3.org

OOP2004 Munich, Germany 22 January 2004

Slides: http://www.w3.org/2004/Talks/0122-munich-wsa-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

AcknowledgementsThanks 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 also:http://www.w3.org/2003/03/ws-specs.html

SOAP WSDL

UDDI

BPEL

?WS-

Security

WS-Reliability

Etc. etc. etc.

6

W3C• Consortium of nearly 400 member companies

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

7

W3C Standards WorkFour 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

Adapted from Noah Mendelsohn, "How Many Webs" http://www.w3.org/2003/Talks/techplen-ws/w3cplenaryhowmanywebs.htm

Web of URIs

Web of HTTP

RESTful Web

Web of widely deployed media types

SOAP

RESTful Web Services

HTTP tunneled

Otherprotocols

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 Web’s 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 RESTWSA 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

Service Oriented Model:Concepts related to services offered and requested, as well as their semantics, choreography, etc.

Policy Model:Concepts relating to constraints on the behavior of agents and services, e.g. security, quality of service, management, etc.

Message Oriented Model:Concepts related to message structure, transport issues without reference to the significance of the messages themselves

Resource Oriented Model:Concepts relating to the abstraction of a Web resource, how it is identified, and how it is manipulated.

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

<!-- Restriction: a message can have at most one description -->

<!-- inferred from the wording "...may have a... -->

<owl:Class rdf:about="Message"> <rdfs:comment> A message can have at most one message description </rdfs:comment> <rdfs:subClassOf> <owl:Restriction> <owl:onProperty rdf:resource="#describedUsing"/> <owl:maxCardinality rdf:datatype=

"&xsd;nonNegativeInteger">1</owl:maxCardinality> </owl:Restriction> </rdfs:subClassOf></owl:Class>

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"

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

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

CDL

BPL

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

WSD

ClientApp

Web

WebService

definesdefines

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"