W3C Web Services Architecture An Overview and Update

Document Sample
W3C Web Services Architecture An Overview and Update Powered By Docstoc
					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/
                                                                1
                   or: http://tinyurl.com/2bp55
           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

                                            2
               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



                                        3
         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
                                     4
     “Web Services” is Confusing!
•Bewildering number of
specifications, some
                                 SOAP          WSDL
overlapping
•Difficult to track and
make sense of it all                                    UDDI

•Mixture of real
standards, proto-
                                           ?
standards, good ideas,                                   WS-
                                                       Security
marketing fluff           BPEL
                                                Etc.
•See also:                                      etc.
                                    WS-
http://www.w3.org/2003/          Reliability    etc.

03/ws-specs.html
                                                                  5
                   W3C
• Consortium of nearly 400 member companies
• Mission: "Lead the Web to its full potential"




                                                  6
        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/
                                                    7
 W3C Work on Web Services –
       Foundations
XML Activity:
• XML, XML Schema, XML Query, XKMS

Technology and Society Domain:
• XML Encryption, Canonicalization,
  Digital Signatures, P3P



                                      8
 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)
                                            9
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.

                                                                   10
           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?




                                             11
      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
                                                                12
      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]



                                                       13
  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"

                                                                         14
     The Web and Web Services
•WSA attempts to be
based on Web                Web of URIs

architecture                Web of HTTP
                                                                    Other
                                                                  protocols
•But WSA is protocol-        RESTful Web
neutral                   Web of widely                       HTTP
                                                            tunneled
   – WSA must support     deployed media
                          types
     any “transport”                            RESTful
                                               Web Services
     protocol                      SOAP
•Diagram clarification:
SOAP use is not
always RESTful, but        Adapted from Noah Mendelsohn, "How Many
                           Webs" http://www.w3.org/2003/Talks/techplen-ws/
can be                     w3cplenaryhowmanywebs.htm




                                                                              15
  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?



                                          16
          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)
                                          17
    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
                                                   18
    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


                                        19
            Overview of the W3C Web
              Service ArchitecturePolicy Model:
                                  Concepts relating to
                                  constraints on the
Service Oriented Model:           behavior of agents
Concepts related to               and services, e.g.
services offered and              security, quality of
requested, as well as             service,
their semantics,                  management, etc.
choreography, etc.




                               Resource Oriented
  Message Oriented Model:      Model:
  Concepts related to          Concepts relating to
  message structure,           the abstraction of a
  transport issues without     Web resource, how it
  reference to the             is identified, and how
  significance of the          it is manipulated.
  messages themselves


                                                         20
        The Message Model




• Concepts & relationships are defined in
  "mind map" diagrams (above) and in prose
                                             21
The Service Model




                    22
The Resource Model




                     23
The Policy Model




                   24
     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

                                                                    25
     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>




                                                               26
              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

                                                   27
  "Orchestration" is architecturally
   distinct from "Choreography"
BPL




                                           CDL




 An Orchestration has one       A Choreography is an
   agent in charge, executing     interaction among
   the processes as               equals, each guided by
   prescribed by a Business       the Choreography
   Process Language               Description Language
   document
                                  document                 28
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


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




                                            30
       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

                                                       31
     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



                                       32
                 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
                                                                         33
                 WS Semantics
                           WSD


                 defines         defines
        Client                             Web
        App                                Service
                           Web




• 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
                                                                    34
     Semantics and Discovery




• Semantics are also critical to discovery
• Need machine-processable "Functional Description" that   35
  captures partial semantics
     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                          36
 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

                                              37
               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



                                        38
                  END
• W3C Mission: "Lead the Web to its full
  potential"




                                           39