Web Services Architecture

Editors' copy $Date: 2002/08/21 12:12:04 $ 04 June 2002

This version:
ws-arch.html
Editorial note
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.
Latest version:
http://www.w3.org/TR/ws-arch/
Previous versions:
Editors:
Michael Champion, Software AG <Mike.Champion@SoftwareAG-USA.com>
Chris Ferris, IBM <chrisfer@us.ibm.com>
Eric Newcomer, Iona <Eric.Newcomer@iona.com>
David Orchard, BEA Systems <dorchard@bea.com>

Abstract

This document describes the Web Service Architecture.

Status of this Document

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 www-wsa-comments@w3.org ( public archive ). It is inappropriate to send discussion emails to this address.

Discussion of this document takes place on the public www-ws-arch@w3.org mailing list ( public archives ) per the email communication rules in the Web Services Architecture Working Group Charter


Short Table of Contents

1. Introduction
2. Identifiers
3. Formats
4. Protocols
5. Processing Model
6. Conceptual Model
7. System Architecture
8. Web Services Features
9. Protocol
10. Description
11. Discovery
12. System Aspects
13. References
A. Change Log (Non-Normative)


Table of Contents

1. Introduction
1.1 Notational Conventions
1.2 What is a Web service?
1.3 Web services Architecture
2. Identifiers
3. Formats
3.1 XML Infoset
3.2 XML Schema
3.3 SOAP
3.3.1 SOAP Extensibility
3.3.1.1 SOAP Module
3.3.2 SOAP Protocol Binding Framework
3.3.3 Process Model
3.4 WSDL
4. Protocols
4.1 HTTP
4.2 Other Protocols
5. Processing Model
6. Conceptual Model
7. System Architecture
8. Web Services Features
9. Protocol
9.1 Base Protocol
9.2 Common Headers
9.3 Security
9.4 Reliability
9.5 Conversations
9.6 Asynchrony
9.7 Routing
9.8 Transactions
9.9 Caching
9.10 Management Messages
9.11 Packaging
10. Description
10.1 DescriptionLanguage
10.2 Choreography
10.3 Static
11. Discovery
12. System Aspects
12.1 Security
12.2 Management
13. References
13.1 Normative References
13.2 Informative References

Appendix

A. Change Log (Non-Normative)
A.1 Web Services Architecture Changes


1. Introduction

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 [2].

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.

Editorial note
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:

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.

Editorial note
CBF: relocated this discussion temporarily. Probably belongs somewhere under features since MEPs are specialized features as defined by SOAP1.2.
Editorial note
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.
Editorial note
CF: Not sure that I agree that we necessarily want diagrams here. Early on, yes, but this is too premature.
Editorial note
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. xxx

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

Figure 3 illustrates that a Web services receiver can also be a sender, constructing a request/response message interaction pattern. xxx

Figure 4 illustrates the concept that Web services message patterns can include intermediaries, which are by definition both senders and receivers. xxx

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

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

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

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:

Detailed objectives are laid out in the accompanying Requirements document [WSAREQ], but at a high level the W3C Web Services Architecture is intended to:

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.

1.1 Notational Conventions

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.

1.2 What is a Web service?

[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.]
Editorial note
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.

Editorial note
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.

1.3 Web services Architecture

The Web services architecture consists of:

  • A single specification of the way in which artifacts of the system are identified: the Uniform Resource Identifier (URI) [1] (see section 2. Identifiers.).

  • 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).

    Issue (procmod):

    Is Process Model a foundational architectural aspect?

Each of these is discussed in detail in the following sections.

2. Identifiers

The Web services architecture builds directly upon the Web Architecture [2]. As such, the Web services architecture directly leverages the definition of, and architectural constraints placed on, identifiers from the Architecture Principles of the Web[2].

Issue (qnames):

What about QNames as identifiers as used by WSDL? TAG Finding.

Issue (uuids):

What about UUIDs as identifiers as used by UDDI? Don't believe that there is a formally registered URI scheme for UUIDs.

Constraint: URIs as identifiers

URIs MUST be used to identify all conceptual elements of the system (see Web Services Architecture Requirements: AR009.3).

3. Formats

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[2].

...

3.1 XML Infoset

Specifications for data formats used in the context of Web services SHOULD be based on XML Infoset [3]. 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 [4]. 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 [4]. However, this is not a requirement. The flexibility in choice of serialization format(s) allows for broader interoperability between agents in the system.

3.2 XML Schema

say something nice about XML Schema [5]. Probably want to say something about preference for use of XML Schema Datatypes [6] if nothing else.

Issue (otherschema):

What about other schema languages such as RELAX NG, Schematron, DTD?

3.3 SOAP

One of the key specifications used in the context of Web services is SOAP [7]. 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.
Editorial note
refer to (and develop!) other sections describing extensibility, binding framework, and process model.

3.3.1 SOAP Extensibility

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

Constraint: URIs as identifiers

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.

Constraint: URIs as identifiers

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

Issue (wsdlmep):

WSDL identifies MEPs using QNames, not URIs.

3.3.1.1 SOAP Module

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.

3.3.2 SOAP Protocol Binding Framework

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.

Constraint: URIs as identifiers

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

Issue (soapbinduri):

SOAP1.2 does not REQUIRE that a binding specification be identified with a URI.

3.3.3 Process Model

...

Editorial note
CBF: think that this might really belong under the Protocols section rather than the Formats section...

3.4 WSDL

say something nice about WSDL. e.g. it is the preferred format for describing Web services.

Editorial note
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.

4. Protocols

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.

Editorial note
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 ...

4.1 HTTP

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

4.2 Other Protocols

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

  • TCP

  • UDP

  • BEEP

  • JMS

  • proprietary messaging systems

5. Processing Model

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

6. Conceptual Model

Conceptual Model Diagram

This diagram shows a conceptual model of web services.

7. System Architecture

System Architecture Diagram

This diagram shows a System compliant with the web services architecture, and the data flow between various parties.

8. Web Services Features

Note:

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.

3 Stack Diagram

Note:

ImageMap to link to the sections on each...

Editorial note
CBF: really? can this be done in xmlspec?
three stack diagram
Editorial note
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:

  1. Asynchrony - dynamic specification of ports for callback messages

  2. Routing - forward and reverse message paths

  3. Security - Digital signatures, Encryption, Credentials, and authentications

  4. Caching

  5. Reliability - typical reliability semantics of best effort, once and only once, at least once, etc.

  6. Conversations - long running stateful conversations between services

  7. Transactions - Compensating, two-phase, atomic, other transaction styles.

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

  9. 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:

  1. XML Schema definitions of types

  2. Choreography - aka orchestration/workflow, the ordering of messages between 2 or more parties.

  3. 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:

  1. Inspection, the retrieval of information about a service or an organization from that service or organization. Very limited query capabilities.

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

9. Protocol

This section details the various protocol extensions in the web services architecture.

9.1 Base Protocol

SOAP, HTTP, others

9.2 Common Headers

Headers common to some or all specific extensions

9.3 Security

Headers and protocol for security

Security Dependency Diagram

9.4 Reliability

9.5 Conversations

9.6 Asynchrony

9.7 Routing

9.8 Transactions

9.9 Caching

9.10 Management Messages

9.11 Packaging

10. Description

10.1 DescriptionLanguage

10.2 Choreography

10.3 Static

11. Discovery

12. System Aspects

These are aspects that broadly affect the architecture. The specific protocol, description or discovery aspects are covered in those sections.

12.1 Security

12.2 Management

13. References

13.1 Normative References

[1]
IETF RFC 2396 Uniform Resource Identifiers (URI): Generic Syntax, T. Berners-Lee, R. Fielding, L. Masinter, August 1998 (See http://ietf.org/rfc/rfc2396.txt.)
[2]
DRAFT: Architecture Principles of the World-Wide Web (See http://www.w3.org/2001/tag/2002/0813-archdoc.)
[3]
XML Information Set, W3C Recommendation, eds. J. Cowan, R. Tobin, 24 October 2001 (See http://www.w3.org/TR/xml-infoset/.)
[4]
Extensible Markup Language (XML) 1.0 (Second Edition), W3C, eds. T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler. 6 October 2000 (See http://www.w3.org/tr/rec-xml/.)
[5]
W3C Recommendation "XML Schema Part 1: Structures", eds. H. Thompson, D. Beech, M. Maloney, N. Mendelsohn, 2 May 2001. (See http://www.w3.org/TR/xmlschema-1/.)
[6]
W3C Recommendation "XML Schema Part 2: Datatypes", eds. P. Biron, A. Malhotra, 2 May 2001. (See http://www.w3.org/TR/xmlschema-2/.)
[7]
W3C Working Draft "SOAP Version 1.2 Part 1: Messaging Framework", eds. M. Gudgin, M. Hadley, J. Moreau, H. Nielsen, 26 June 2002 (See http://www.w3.org/TR/soap12-part1/.)
[8]
W3C Working Draft "SOAP Version 1.2 Part 2: Adjuncts", eds. M. Gudgin, M. Hadley, J. Moreau, H. Nielsen, 26 June 2002 (See http://www.w3.org/TR/soap12-part2/.)
[9]
Web Services Description Language (WSDL) Version 1.2, eds. R. Chinnici, M. Gudgin, J. Moreau, S. Weerawarana (See http://www.w3.org/TR/wsdl12/.)

13.2 Informative References

[ebMS]
Message Service Specification, ebXML TRP Version 1.0 (See http://www.ebxml.org/specs/ebMS.pdf.)
[SOAPAttach]
SOAP Messages with Attachments (See http://www.w3.org/TR/SOAP-attachments.)
[SOAPPRIMER]
SOAP 1.2 Part 0 (See http://www.w3.org/TR/2002/WD-soap12-part0-20020626/.)
[SOAPREQS]
XML Protocol (SOAP) Requirements (See http://www.w3.org/TR/2001/WD-SOAP-reqs-20010319/#N2082.)
[USAGE]
XML Protocol Usage Scenarios (See http://www.w3.org/TR/2001/WD-xmlp-scenarios-20011217/.)
[CHARTER]
Web Services Architecture Charter (See http://www.w3.org/2002/01/ws-arch-charter.)
[WSAREQ]
Web Services Architecture Requirements (See http://www.w3.org/tr/wsa-reqs.)
[WSRP]
Web Services Routing Protocol (WS-Routing) (See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsrvspev/html/ws-routing.asp.)

A. Change Log (Non-Normative)

A.1 Web Services Architecture Changes

20020720CBFincorporated SOAP harvest, weaved into the revised flow. added normative biblio.
20020604DBOInitial Rev