|MC: I have an admittedly "discursive rather than authoritative" specwriting style. This is not universally appreciated .... probably much of what I have added really belongs in a Primer to put the WSA in context and leaves the normative spec written in a rigorous, authoritative style. For this initial draft, and considering the various constraints we are under, I do think that this explanatory/big picture prose helps.|
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.
5. Processing Model
6. Conceptual Model
7. System Architecture
8. Web Services Features
12. System Aspects
A. Change Log (Non-Normative)
1.1 Notational Conventions
1.2 What is a Web service?
1.3 Web services Architecture
3.1 XML Infoset
3.2 XML Schema
3.3.1 SOAP Extensibility
220.127.116.11 SOAP Module
3.3.2 SOAP Protocol Binding Framework
3.3.3 Process Model
4.2 Other Protocols
5. Processing Model
6. Conceptual Model
7. System Architecture
8. Web Services Features
9.1 Base Protocol
9.2 Common Headers
9.10 Management Messages
12. System Aspects
13.1 Normative References
13.2 Informative References
The use of Web Services on the World Wide Web is expanding rapidly as the need for application-to-application communication and interoperability grows. These Web services provide a standard means of communication among different software applications, running on a variety of platforms and/or frameworks. The architecture presented in this document is intended to promote interoperability and extensibility among these various applications, platforms and frameworks in a manner that remains consistent with the architecture of the Web .
This document describes the Web services reference architecture, including the identification of candidate technologies that meet the functionality defined within the architecture. For example, the reference architecture includes transport services, and references SOAP as a candidate technology that meets the defined functionality.
The Web services reference architecture identifies the functional components comprising the Web services stack of technology, and defines the relationships among the components in the stack. The architecture also illustrates the execution environment for Web services technologies.
|MC: I've added a lot of stuff here ...|
"Web Services" does not currently describe a coherent set of technologies, architectures, or even visions. The community of web services developers represents a merging of at least three major sources of inspiration, with various ideas taken from other sources as well. Several streams of thought and practice have merged to produce what we think of as web services, including:
"Distributed Objects" or "Application Integration" -- exchange of programming objects or invocation of software functions over a network.
EDI / B2B - the exchange of electronic business documents over a network.
The World Wide Web itself - accessing human readable documents and posting requests for information, products, or services via the HTTP protocol.
The excitement about web services in the last two years or so is based largely on the potential for a combination of XML, the Web, the SOAP and WSDL specifications, and to-be-defined protocol stacks to address many of the problems these technologies have encountered. For example, distributed object systems such as Microsoft's COM family and the OMG CORBA standard did not interoperate, each presented numerous security and administration challenges when deployed over the internet, and neither quite meet the scalability expectations created by the Web. Various XML-based B2B systems have showed much potential, but created incompatible protocols on top of the internet standards which lead to interoperability problems. The Web has proven enormously popular, scalable, and interoperable, but it too presents many challenges -- reliability, security, database-level transactions, details of how to map platform-neutral data, URIs and HTTP operations to back-end application systems, and many others -- that must be handled by Web applications rather than some standardized infrastructure.
The popular Web services standards; SOAP and WSDL, were originally developed outside the W3C but are now being refined and standardized within the Web Services Activity of the W3C. These de-facto standards have helped by creating and extensible messaging framework within which some of these problems can be addressed, and an interface definition language and data encoding conventions that facilitate mapping to back end systems.
|CBF: relocated this discussion temporarily. Probably belongs somewhere under features since MEPs are specialized features as defined by SOAP1.2.|
|MC: Put it back in the Introduction at Dave's request. I guess the editors need to talk about this ...The discussion of MEP probably belongs somewhere else, but the simple diagrams belong early in the document.|
|CF: Not sure that I agree that we necessarily want diagrams here. Early on, yes, but this is too premature.|
|CF: begin Eric's contribution.|
The Web services architecture describes a system of related technologies that exchange messages between senders and receivers. The architecture extends the message exchange into "patterns" such as one-way, request/response, and pub/sub. Message exchange patterns are further extended with functionality to ensure privacy, coordinate transactions, orchestrate multiple message exchange patterns, among other things. Web services architecture components are defined using XML applications, and use XML for message data typing and structuring.
Figure 1 illustrates the basic concept of the Web services architecture. A message is sent from a sender and received by a receiver. The level of abstraction at which Web services operates encompasses such interaction styles as RPC emulation, asynchronous messaging, one-way fire and forget style messaging, broadcast, and publish and subscribe. All message interaction styles, or patterns, are composed of one or more one-way asynchronous messages.
Figure 2 illustrates a second fundamental concept of Web services architecture: a receiver can publish a service description that the sender can use to construct the message and send it to the receiver. The service description provides the message definition and the receiver's endpoint address.
Figure 3 illustrates that a Web services receiver can also be a sender, constructing a request/response message interaction pattern.
Figure 4 illustrates the concept that Web services message patterns can include intermediaries, which are by definition both senders and receivers.
Figure 5 illustrates the concept that web services messages can carry semantic information for higher level functions such as security, transaction coordination, reliability, and orchestration.
At a high level, a Web service is two, or more, software agents exchanging information using a variety of Message Exchange Patterns (MEP). A very common Message Exchange Pattern for Web services is the Request Response MEP. This is illustrated below. A sender sends a request to a receiver, and the receiver responds. The data that is exchanged in the request or the response is usually XML carried over an underlying transport or transfer protocol, such as HTTP. The XML can be XML Element/attribute syntax or it can be defined as an XML Infoset, or it can be information solely in the underlying protocol. An example of this is an HTTP GET request that does not contain an XML message, but the response may carry an XML message.
SOAP provides an extensible framework for the XML data that is interchanged. The format that SOAP defines has restrictions and places of extensibility. Web Services Description Language provides a format for defining the allowable formats for messages to and from agents. These include SOAP, XML, MIME, and simple HTTP requests. The relationship between Web Services, SOAP and WSDL is shown below.
Many "real" products and projects are successfully using SOAP and WSDL, and it is clear that a critical mass of knowledge and technology are forming around them, and they will remain at the center of the web services architecture. Nevertheless, there are numerous architectural questions that remain unsolved, or at least whose solution is not widely agreed upon. These include:
Integration with the Web - SOAP 1.1 web services use the HTTP infrastructure to move messages around, and allow standardization of the format of the payload of a POST command, but conventional Web applications are not able to directly access most web services. In particular, it is not possible to hyperlink to SOAP 1.1 web service via HTML links, XSLT document() functions, etc. As many critics have noted, hyperlinks are the very essence of the World Wide Web, and this limitation is quite severe. SOAP 1.2 addresses this issue at a technical level, but there is little architectural guidance available as to when and how to use the various HTTP-friendly and protocol-neutral aspects of the SOAP protocol.
Extension mechanism - SOAP 1.2 provides an extension mechanism via headers, but the implications, --such as when to use XML markup in the body of a message, when to use headers -- are not spelled out. Likewise, it is not clear how SOAP-based protocol extensibility would interoperate with or complement traditional Web applications.
Overall understanding of modules and layering - SOAP 1.2 provides a framework within which additional features can be added via headers, but there is little agreement on the specific categories of functionality that these headers will specify nor on specific format standards.
Detailed objectives are laid out in the accompanying Requirements document [WSAREQ], but at a high level the W3C Web Services Architecture is intended to:
Integrate different conceptions of web services under a common "reference architecture". There isn't a simple one to one correspondence between the architecture of the web and the architecture of existing SOAP-based web-services, but there is a substantial overlap, and the Web Services Architecture needs to identify what they have in common and how they differ.
Describe the "best practice" for the set of rules that existing Web service agents typically follow, and to rationalize the best practices from the different communities. The objective is not to say "this practice is good" or "that practice is bad", but rather to say "this specific approach is brittle in the following ways." or "That common practice works better if X occurs as well as Y."
Prescribe a framework for the future evolution of web services standards that will promote a healthy mix of interoperability and innovation. That framework must accommodate the edge cases of pure SOAP-RPC at one side and HTTP manipulation of business document resources at the other side, but focus on the area in the middle where the different architectural styles are both taken into consideration.
It is a non-objective to resolve all of the profound disagreements that web services theorists and practitioners continue have over the concepts and technology we the shared area. The W3C WSA will accomodate divergent opinions on whether various services should be implemented at the application or infrastructure level, whether it is appropriate to "tunnel" remote procedure calls over HTTP, etc. Similarly, it is unrealistic to expect the W3C Web Services Architecture to define a set of "Lego blocks" that can be snapped together to build real applications. That is a reasonable vision for the web services industry, but it will require considerable research, experimentation, and standards-building to achieve. This reference architecture is intended to help clear the way for these activities by forming a consensus on what the basic types of components might be, the ways in which they relate to one another, and what to name them.
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.
[Definition: A Web service is a software system identified by a URI, 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.]
|CF: I've included the revised, gramatically improved, definition of Web service here. 08/13/02. The WG may wish to consider this when it comes back from its summer hiatus.|
A Web service is a software agent that acts upon messages from other agents according to some set of principles that must be agreed upon among all agents involved in delivering and consuming a web service.
|MC: "according to the principles defined in this document" makes it sound more authoritative than it really is, and could put some people off. I changed it to something I felt to be more realistic. Also let's refer to this as the W3C WSA so as to distinguish it from several member companies' very similar concepts, e.g. Microsoft's GXA.|
The Web services architecture consists of:
A non-exclusive set of data formats designed for interchange between agents in the system (see section 3. Formats.).
A small and non-exclusive set of protocols for interchanging information between agents (see section 4. Protocols.).
A small and non-exclusive set of ... (see section 5. Processing Model).
Each of these is discussed in detail in the following sections.
The Web services architecture builds directly upon the Web Architecture . As such, the Web services architecture directly leverages the definition of, and architectural constraints placed on, identifiers from the Architecture Principles of the Web.
What about QNames as identifiers as used by WSDL? TAG Finding.
What about UUIDs as identifiers as used by UDDI? Don't believe that there is a formally registered URI scheme for UUIDs.
URIs MUST be used to identify all conceptual elements of the system (see Web Services Architecture Requirements: AR009.3).
As with identifiers (see section 2. Identifiers), the Web services architecture builds upon the definition of, and architectural constraints placed on, formats from Architecture Principles of the Web.
Specifications for data formats used in the context of Web services SHOULD be based on XML Infoset . XML Infoset is not a data format per se, but a formal set of information items and their associated properties that comprise an abstract description of an XML document . The XML Infoset specification provides for a consistent and rigorous set of definitions for use in other specifications that need to refer to the information in a well-formed XML document.
Serialization of the XML Infoset definitions of information MAY be expressed using XML1.0 . However, this is not a requirement. The flexibility in choice of serialization format(s) allows for broader interoperability between agents in the system.
One of the key specifications used in the context of Web services is SOAP . The format of a SOAP message is formally defined in the SOAP1.2 Part 1: Messaging Framework specification. However, SOAP is much more than simply a message format.
|refer to (and develop!) other sections describing extensibility, binding framework, and process model.|
SOAP provides a simple messaging framework whose core functionality is concerned with providing extensibility. Extensions to the base messaging framework defined by SOAP are modeled and specified as abstract features. Example features include "reliability", "security", "correlation", and "routing". The Web services architecture describes a number of these features (see section 8. Web Services Features), their inter-relationships with one another, and their purpose within the overall architecture.
A SOAP feature MUST clearly and completely specify the content and semantics of the properties used to implement the desired behavior, including any modifications to the SOAP Processing Model (see section 3.3.3 Process Model).
All SOAP Features MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 3.4 WSDL).
Expression of a SOAP Feature is accomplished through one of the two mechanisms provided for by SOAP:
One special type of SOAP Feature is the Message Exchange Pattern (MEP). A MEP is a template that establishes a pattern for the exchange of messages between SOAP nodes. Examples of MEPs include: request/response, oneway, peer-to-peer conversation, etc. A MEP MAY be supported by one or more underlying protocol binding instances either directly, or indirectly with support from software that implements the required processing to support the SOAP Feature as expressed as a SOAP Module.
All MEPs MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 3.4 WSDL).
A SOAP Module is a formally specified expression of a SOAP Feature as one or more SOAP header blocks. Refer to the SOAP specification for the detailed requirements of a SOAP Module. A SOAP Module is typically used to express a feature that is not provided for either directly or indirectly through mechanisms of the bound transport, or transfer, protocol. They are also used for the expression of end-to-end SOAP Features that might span multiple, disparate transport, or transfer, protocols as the message is conveyed from original sender to ultimate receiver.
SOAP provides for the exchange of messages between software agents known as SOAP nodes using a variety of underlying transport, or transfer, protocols. The formal set of rules for exchanging a SOAP message via an underlying protocol is called a binding. The SOAP Protocol Binding Framework provides general rules for the specification of bindings to an underlying protocol. The framework also describes the formal relationship between bindings and the SOAP nodes that implement those bindings.
All SOAP Protocol Bindings MUST be identified by a URI so that they may be unambiguously referenced in contexts such as WSDL (see section 3.4 WSDL).
say something nice about WSDL. e.g. it is the preferred format for describing Web services.
|CF: Eric's thoughts on WSDL process model|
Both the sender and receiver of a Web services message must have access to the same service description. The sender needs the service description to know how to format the message correctly and the receiver needs the service description to understand how to receive the message correctly.
As long as both the sender and receiver have the same service description, (e.g. WSDL file), the implementations behind the Web services can be anything. Web services typically are implemented using programming languages designed for interaction with the web, such as Java Servlets or Application Server Pages (ASPs) that call a back-end program or object. These Web service implementations are also typically represented using a Web services description language.
The Web services description language contains the message data type and structure definition, the message exchange pattern definition, and the endpoint address the receiver listens on. When a sender wishes to send a message to a receiver, the sender obtains the service description and generates a message corresponding to the data type and structure information contained within the service description, and sends the message to the endpoint address identified in the service description. The receiver listens at the defined address for messages. When the receiver receives a message, the receiver validates the message using the data type and structure information in the service description, and uses information in the service description and associated with the service description to transform or map the message contents onto an executable program. Similarly, the sender's executable program generates the message using information in the service description and information associated with the service description.
Web service definitions can be mapped to any language, object model, or messaging system. Simple extensions to existing Internet infrastructure can implement web services for interaction via browsers or directly within an application. The application could be implemented using COM, JMS, CORBA, COBOL, or any number of proprietary integration solutions.
Now provide description of Web service protocols
SOAP protocol binding framework ------------------------------- http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#transpbindframew The SOAP Protocol Binding Framework provides general rules for the specification of protocol bindings; the framework also describes the relationship between bindings and SOAP nodes that implement those bindings. http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#bindfw The creation, transmission, and processing of a SOAP message, possibly through one or more intermediaries, is specified in terms of a distributed state machine. ... each SOAP message is modeled as an XML Infoset ... ... the XML Infoset of a SOAP message MUST NOT include a DTD ... Bindings MAY provide for streaming when processing messages. Bindings MAY depend on state that is modeled as being outside of the SOAP XML Infoset.
|talk about modules and layering ... interoperability is possible without all "web services" using the same set of features and modules, but there has to be a conceptual agreement on what the features are, how they are packaged, and how they are layered ...|
something about HTTP, possibly as normative binding described for SOAP.
HTTP has a special status in the W3C Web Services Architecture for a number of both practical and theoretical reasons. For one, early versions of SOAP (and XML-RPC, which is still widely used in existing web services) were explicitly tied to HTTP. SOAP 1.1 implied a certain amount of protocol-independence, and SOAP 1.2 makes this explicit, but HTTP is still the dominant means of communicating between web services agents. Also, HTTP is
Many believe that HTTP is the "native" protocol of the Web because it was designed to work with the URIs that identify Web resources. While HTTP has become almost ubiquitous, and many of the issues surrounding its earlier incarnations have been resolved in subsequent versions of the standard and by "industrial strength" implementations, it is not the only protocol upon which Web Services can be built. For example
proprietary messaging systems
Now provide description of SOAP and WSDL Processing models
Processing model ---------------- http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#msgexchngmdl SOAP provides a distributed processing model that assumes a SOAP message originates at an initial SOAP sender and is sent to an ultimate SOAP receiver via zero or more SOAP intermediaries. http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#soapnodes A SOAP node can be the initial SOAP sender, an ultimate SOAP receiver, or a SOAP intermediary. A SOAP node receiving a SOAP message MUST perform processing according to the SOAP processing model. http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#soaproles In processing a SOAP message, a SOAP node is said to act in one or more SOAP roles, each of which is identified by a URI known as the SOAP role name. This specification defines the following SOAP roles: http://www.w3.org/2002/06/soap-envelope/role/next http://www.w3.org/2002/06/soap-envelope/role/none http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#targettingblocks A SOAP header block MAY carry a role attribute information item that is used to target the header block at SOAP nodes operating in the specified role. http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#muprocessing A SOAP header block is said to be understood by a SOAP node if the software at that SOAP node has been written to fully conform to and implement the semantics conveyed by the combination of local name and namespace name of the outer-most element information item of that header block. ... for every mandatory SOAP header block targeted to a node, that node MUST either process the header block or not process the SOAP message at all, and instead generate a fault http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#structinterpbodies An ultimate SOAP receiver MUST correctly process the immediate children of the SOAP body http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#procsoapmsgs Rules for SOAP processing and the kinds of faults that must be generated. http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#envvermodel A SOAP Version 1.2 message has a child element information item of the document information item with a local name of Envelope and a namespace name of "http://www.w3.org/2002/06/soap-envelope". If a SOAP node receives a message whose version is not supported it MUST generate a fault with a Value of Code set to "env:VersionMismatch". Any other malformation of the message construct MUST result in the generation of a fault with a Value of Code set to "env:Sender".
This diagram shows a System compliant with the web services architecture, and the data flow between various parties.
It is not the intent of this specification to provide a normative specification of the features described below. That work is intended to be the product of an other W3C Working Group, an external SDO, or of a proprietary nature such as an internal IT organization or vendor-specific specification. The descriptions of Web service features described in this specification are intended as a generalized description, combined with a set of constraints that would serve as input to the formal development of a specification for such a feature.
ImageMap to link to the sections on each...
|CBF: really? can this be done in xmlspec?|
|CF: added Eric's stack diagram here.|
This shows 3 stacks of Web Services Features, 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 that a 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
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.
This section details the various protocol extensions in the web services architecture.
These are aspects that broadly affect the architecture. The specific protocol, description or discovery aspects are covered in those sections.