Copyright © 2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
This document describes the Web Service Architecture.
This document is an editors' copy that has no official standing.
This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.
This is a public draft of a document that the Web Services Architecture Working Group intends to eventually publish as a Working Draft.
For a detailed list of changes since the last publication of this document, refer to appendix A Part 1 Change Log . A list of open issues against this document is maintained by the Working Group.
Comments on this document should be sent to [email protected] ( public archive ). It is inappropriate to send discussion emails to this address.
Discussion of this document takes place on the public [email protected] mailing list ( public archives ) per the email communication rules in the Web Services Architecture Working Group Charter
1 Introduction
1.1 What is a Web service?
1.2 Notational Conventions
1.3 Overview
2 Protocol
2.1 Base Protocol
2.2 Common Headers
2.3 Security
2.4 Reliability
2.5 Conversations
2.6 Asynchrony
2.7 Routing
2.8 Transactions
2.9 Caching
2.10 Management Messages
2.11 Packaging
3 Description
3.1 DescriptionLanguage
3.2 Choreography
3.3 Static
4 Discovery
5 System Aspects
5.1 Security
5.2 Management
6 References
6.1 Informative References
A Change Log (Non-Normative)
A.1 Web Services Architecture Changes
This document specifies the web services architecture.
The Working Group has jointly come to agreement on the following working definition:
Web service
[Definition: A Web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols]
The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.
Note:
ImageMap to link to the sections on each...
Editorial note | |
Should the Overview be a div1 section? |
This shows 3 stacks, that are closely related. A transport stack is for standards that are exchanged on the wire. Description is for describing an individual or collection of services. Discovery is the finding of services. The salmon coloured section shows specifications that are related to a particular stack. The light orange shows which specifications would be embedded in or expressed in the specification listed at the bottom. An example is security headers expressed in a soap message, or message exchange patterns described in WSDL. The orange boxes indicate individual specifications.
We expect the base standard for the transport is SOAP. This can contain the following headers:
Asynchrony - dynamic specification of ports for callback messages
Routing - forward and reverse message paths
Security - Digital signatures, Encryption, Credentials, and authentications
Caching
Reliability - typical reliability semantics of best effort, once and only once, at least once, etc.
Conversations - long running stateful conversations between services
Transactions - Compensating, two-phase, atomic, other transaction styles.
Management - These are messages, or system services, related to web services. Examples are Ping, Status, Control messages. the line in the light orange box indicates the separation between messages and headers.
Packaging - containers for SOAP messages, like MIME or DIME
Description is based upon WSDL. In general, there will be WSDL definitions of each of the elements in the transport layer. It can contain:
XML Schema definitions of types
Choreography - aka orchestration/workflow, the ordering of messages between 2 or more parties.
Service characteristics - the static information about a service, such as reliability, availability, privacy policies. This information is typically not expressed in a transport message.
Discovery, typically invoked with SOAP messages, contains a large variety of information, typically descriptions of services and businesses. It has aspects of:
Inspection, the retrieval of information about a service or an organization from that service or organization. Very limited query capabilities.
Registry based, queries are often to 3rd party registries. Examples are UDDI, ebXML Registry.
There are other aspects that are either architectural or orthogonal. Security and Manageability are aspects that are architectural in nature. Workflow Languages - these are the programmatic specification of choreography. These are not exchanged at run-time, but typically between two authoring tools.
These are aspects that broadly affect the architecture. The specific protocol, description or discovery aspects are covered in those sections.