Abstract
Web Services are the next step in the evolution of the World Wide Web.
The Web of today is, for the most part, a network of documents
intended to be read by human beings; they can be read by non-human
agents like Web spiders, but for the most part such non-human agents
cannot do much with them. Web Services promise to make the Web much
more hospitable for information suited for machine processing.
This talk will give an introduction to Web Services, and an account of
why W3C is active in the area and what we hope to accomplish. The
talk will provide an overview of the Web Services standardization
landscape, beginning with an account of where the fundamental ideas of
Web Services come from and what is meant by the term. Some sample use
cases and usage scenarios will help clarify the kinds of problems
people hope to solve with Web Services; an introduction to the core
specifications in the area will help show how the problems are to be
solved. Some basic design principles and problems in Web Services
will be identified.
- 1. Overview
- 2. Where do Web Services come from?
- 3. What are Web Services? (1)
- 4. What are Web Services? (2)
- 5. What are Web Services? (3)
- 6. What are Web Services? (4)
- 7. What are Web Services? (5)
- 8. The ‘old’ Web
- 9. Web service interaction
- 10. What are Web Services? (5)
- 11. Roots / Origins / Anticipations
- 12. What problems do Web Services need to solve?
- 13. Problems to solve (2)
- 14. Use cases and usage scenarios
- 15. Use cases, cont'd
- 16. The core specifications
- 17. Service-oriented architecture
- 18. A closer look
- 19. Discovery: automated?
- 20. SOAP in one slide
- 21. WSDL in one slide
- 22. UDDI in one slide
- 23. W3C work on Web Services
- 24. Other specs
- 25. Some basic design ideas
- 26. Technical controversies
- 27. Loose coupling? HA!
- 28. Defining a messaging infrastructure
- 29. Message exchange patterns
- 30. The end
 | Overview |    1 of 30 |
- where do Web Services come from?
- what are Web Services?
- use cases and usage scenarios
- the core specifications
- SOAP
- WSDL
- UDDI?
- W3C work in the area
- design principles and problems
| | Where do Web Services come from? | 2 of 30 |
This is not certain, but the term Web Services appears to
have originated as an answer to the question “What are you
developing SOAP for?”
The main evidence for this is the
chaotic nature of replies to the question “What is a Web
Service?”
| | What are Web Services? (1) | 3 of 30 |
The term Web Services refers to an architecture that allows applications to talk to each other. Period. End of statement.
-Adam Bosworth
| | What are Web Services? (2) | 4 of 30 |
Web Services are enabling technologies that facilitate the assembly and integration of applications in order to create new, more meaningful and/or more user-specific applications, all at the speed of the Internet.
-HEKATE (Higher Education Knowledge and Technology Exchange),
"Web Services Enabling Technology for Application Integration and
Assembly"
| | What are Web Services? (3) | 5 of 30 |
Basically, Web Services are a means of allowing applications to talk to one another using XML (Extensible Markup Language) messages sent via the standard Web protocol of HTTP (HyperText Transfer Protocol is used to request Web pages from Web servers, and combines it with XML to pass structured information back and forth between computers).
| | What are Web Services? (4) | 6 of 30 |
[1] A Web service is a software system identified by a URI [RFC 2396], whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols.[2] A collection of EndPoints. [WSD Reqs]
| | What are Web Services? (5) | 7 of 30 |
- distributed system
- in which applications communicate with applications
- via XML messages
| | The ‘old’ Web | 8 of 30 |
Humans read HTML served by Web applications.
| | Web service interaction | 9 of 30 |
Applications exchange XML with Web services.
| | What are Web Services? (5) | 10 of 30 |
- distributed system
- in which applications communicate with applications
- via XML messages
Everything else follows from this. Most obviously:
- messaging (e.g. SOAP, XML)
- description (e.g. WSDL, XML Schema)
- discovery (e.g. UDDI)
- security (e.g. TLS, SSL)
| | Roots / Origins / Anticipations | 11 of 30 |
- distributed objects / application integration
- EDI (electronic data interchange)
- WWW
And don't forget:
- SGML-based client/server systems (Jean-Pierre Gaspart, Sema)
| | What problems do Web Services need to solve? | 12 of 30 |
- message structure and infrastructure
- describing what messages a service accepts and sends
- routing messages
- describing message exchange patterns (choreography, workflow)
- finding services to exchange messages with
| | Problems to solve (2) | 13 of 30 |
- security, authorization, access control
- authentication (e.g. HTTP auth, SOAP Module with username/password, x.509 etc.)
- confidentiality (SSL, TLS, encryption)
- integrity (digital signatures)
- transactions (succeed or rollback)
- asynchronous messaging (needs reliable messaging)
- reliable messaging
- attachment - e.g. shipping binary data with SOAP messages
- caching and cache control
- correlation: tying messages together into a sequence
- session management
- * implementing all this stuff
| | Use cases and usage scenarios | 14 of 30 |
- Employee negotiates travel reservation with travel booking service for planned trip.
- Send stock price update every 15 minutes, to one or to many receivers.
- Send request to central accounting system to create a purchase order; get back confirmation or error message.
- Blind auction marketplace serving as broker between buyers and suppliers. Buyers submit requirements to hub, hub broadcasts info to multiple suppliers, who respond to hub; information is logged and ultimately delivered to buyer.
| | Use cases, cont'd | 15 of 30 |
- Conversation exchange in a procurement process: B requests price quotation; S gives quote; B places purchase order; S accept; S offers delivery dates; B accepts; B acks delivery; S acks; B pays; S sends receipt.
- Bank A buys Bank B. Bank A has always used SAP for internal processes; Bank B uses IBM dbms running PeopleSoft software. You work for the IT department; you now have three weeks to provide access to the customer records of Bank B to the Bank A systems. Oh, and your colleagues in Bank B don't trust you yet.
- Amalgamated Interkludge runs a Huge Mainframe Application which handles queries submitted through a proprietary message queueing system. Your job: provide Web access to the HMA.
| | The core specifications | 16 of 30 |
General consensus is that the core WS specs are
- SOAP: for message structure, generic message-processing model, extensibility model
- WSDL: for describing messages and services
- UDDI: for discovery of services
Oddly, security isn't on most lists as a core problem.
| | Service-oriented architecture | 17 of 30 |
Viewed this way, it seems clear what specs are needed.
| | A closer look | 18 of 30 |
The clustering is less obvious on closer inspection.
| | Discovery: automated? | 19 of 30 |
Discovery step seems to be logically necessary. But it
may be out of band:
| | SOAP in one slide | 20 of 30 |
SOAP makes all things possible, but it doesn't do
much itself. It's a lot like XML that way.
What it does define:
- message construction (envelope, header, body)
- message exchange patterns (MEP) and how to define more
- processing model for messaging: originator, intermediaries, destination
- extensibility mechanism and mustUnderstand attribute
- fault system
- bindings to transport protocols (HTTP, SMTP, ...)
| | WSDL in one slide | 21 of 30 |
A WSDL document describes a service:
- message(s) accepted and emitted: abstract description (XML Schema)
- network protocol(s) and message format(s)
- operation: exchange of messages
- port type: collection of operations
- port: implementation of a port type
- service: collection of ports
N.B. operations are atomic response+request
pairs, not transition networks or state machines.
Rules of operation are not captured completely.
Controversy over general vs specific interfaces.
| | UDDI in one slide | 22 of 30 |
Universal description, discovery, and integration
- registry system
- business entities, business services, specifications, service types
- standard taxonomies to describe businesses, services, and service types (?!)
- “The UDDI Business Registry is intended to serve as a global, all-inclusive listing of businesses and their services. The UDDI Business Registry does not contain detailed specifications about business services. It points to other sources that contain the service specifications.”
- private registries also possible
UDDI began as ad hoc consortium; now housed at OASIS.
| | W3C work on Web Services | 23 of 30 |
- XML Activity
- XML
- XML Schema
- XML Query
- Technology and Society Domain:
- XML Encryption, Canonicalization, Signatures
- Web Services Activity:
- XML Protocol (SOAP 1.2)
- Web Services Architecture Working Group
- Web Services Description Working Group (WSDL 1.2)
- Web Services Choreography Working Group
| | Other specs | 24 of 30 |
See also http://www.w3.org/2003/03/ws-specs.html
- ebXML (lots of sub-parts)
- security
- WS-Security
- SAML
- choreography / orchestration / workflow
- WSCL
- WSCI
- Business process execution language for Web Services (BPEL4WS)
- WS-Coordination
- attachments
- Direct internet message encapsulation (DIME)
- SOAP with attachments
- WS-Attachments
- transactions
- WS-Transaction
- Watch this space ...
| | Some basic design ideas | 25 of 30 |
Adam Bosworth lists these design principles for
Web Services:
- relatively coarse-grained communication: in stateless protocols, round trips are expensive, so minimize them. (Don't send 1000 requests for individual rows of the table: send one request for a thousand rows.) An issue for scalability.
- loose coupling. Learn from the problems of old client/server work, OO work: don't know too much about what's on the other side. The format of the XML messages you accept and receive is your contract with the world. “So it's critical that the thing in charge here is the WSDL and not the code.”
- asynchrony: don't block if you don't get an immediate response. (Hence: message-based architecture.)
| | Technical controversies | 26 of 30 |
- What is the extension framework? SOAP extensibility? Features and properties? Out-of-band messages?
- How do we exploit REST where possible / appropriate without creating a straitjacket for implementors? (Social and technical aspects)
- Where does WSDL end? What belongs in a description and what belongs elsewhere?
- How do we define synchronous?
| | Loose coupling? HA! | 27 of 30 |
Q If Web Services is about loose coupling, why does SOAP
make it easy to dump objects straight to XML and reconstitute them at
the other end? In a loosely coupled system, object structure is the
last thing you want to expose!
A Well spotted. The RPC usage of SOAP is not loosely
coupled (but looser than binary calls). If old-style RPC, fine
granularity, and tight coupling work for your application, SOAP-RPC
should be fine for you.
| | Defining a messaging infrastructure | 28 of 30 |
- extensible message infrastructure
- basic rules of message structure
- basic rules of message processing
- rules for extending
- rules for handling extensions
- minimal commitment on other things: handle them by extensions
| | Message exchange patterns | 29 of 30 |
If we want to build applications which communicate by
passing messages, there are several patterns to consider:
- One-way message (SOAP basic model)
- Message + response
- RPC (a subtype of message + response)
- conversation
- publish/subscribe
- broadcast
- ...
- (we don't even know how many more items belong in this list)
Don't foreclose possible new patterns!