Web Services Architecture

W3C Working Draft 14 November 2002

This version:
Latest version:
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>


This document describes the Web Service Architecture. The Web services reference architecture identifies the functional components, defines the relationships among those components, and establishes a set of constraints upon each to effect the desired properties of the overall architecture.

Status of this Document

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 the first public Working Draft of a document of the Web Services Architecture specification for review by W3C members and other interested parties. It has been produced by the W3C Web Services Architecture WG, which is part of the W3C Web Services Activity. This document is a work in progress and is still incomplete in many respects. Although the Working Group agreed to request publication of this document, this document does not represent consensus within the Working Group about the Web services architecture.

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

Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.

This is a draft document and may be updated, replaced or obsoleted by other documents at any time. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". This is work in progress and does not imply endorsement by, or the consensus of, either W3C or members of the Web Services Architecture Working Group. A list of all technical reports can be found at http://www.w3.org/TR/.

Table of Contents

1 Introduction
    1.1 The Need for an Architecture
    1.2 Notational Conventions
2 What is a Web service?
3 Basic and Extended Architecture
    3.1 Basic Architecture
        3.1.1 Components
        3.1.2 Roles
        3.1.3 Operations
    3.2 Extended Web Services Architecture
        3.2.1 Features
        3.2.2 Infrastructure Services
        3.2.3 Diagrammatic representation of features
        3.2.4 Flows
    3.3 Web Services Stacks
        3.3.1 Wire "Stack"
        3.3.2 XML Messaging with SOAP
        3.3.3 Description "Stack"
   Descriptions Applying to a Particular Web Service
   Description for Relationships between Web Services
       Service Level Agreements
       Business Level Agreements
        3.3.4 Discovery Agencies "Stack"
   Service Publication
       Producing Service Descriptions
       Publishing Service Descriptions
   Service Discovery
       Acquiring Service Descriptions
       Consuming Service Descriptions
        3.3.5 Overarching Concerns
        3.3.6 The Complete Web Services "Stack"
4 Web Service Architecture
    4.1 Identifiers
    4.2 Formats
        4.2.1 XML Infoset
        4.2.2 XML Schema
        4.2.3 SOAP
   SOAP Extensibility
       SOAP Module
   SOAP Protocol Binding Framework
   Process Model
        4.2.4 WSDL
   WSDL harvesting material
    4.3 Protocols
        4.3.1 HTTP
        4.3.2 Other Protocols
5 Processing Model


A Acknowledgments (Non-Normative)
B References (Non-Normative)
    B.1 Normative References
    B.2 Informative References
C The Bottom Up View of the Architecture (Non-Normative)
D Architectural Use of Technologies (Non-Normative)
E Other harvested material (Non-Normative)
    E.1 REST
    E.2 ebXML
F Web Services Architecture Change Log (Non-Normative)

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

This document describes the Web services reference architecture, and where appropriate, identifies candidate technologies that have been determined to meet the functionality requirements defined within the architecture.

The Web services reference architecture identifies the functional components, defines the relationships among those components, and establishes a set of constraints upon each to effect the desired properties of the overall architecture.

1.1 The Need for an Architecture

The generalized term "Web services" does not currently describe a coherent or necessarily consistent set of technologies, architectures, or even visions. The community of Web services evangelists, architects, developers, and vendors 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 converged to produce an amalgam of 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 over Web services 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 technologies SOAP 1.1 and WSDL 1.1 were originally developed outside the W3C; however, their successors are now being developed within the W3C Web Services Activity. These specifications are being used as the basis for creating an extensible messaging framework (SOAP 1.2) and an interface definition language (WSDL 1.2).

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

2 What is a Web service?

Although there are a number of varied and often seemingly inconsistent motivations for, and uses of, the term "Web service", at its core, the following definition captures what we believe to be the shared essence of the term:

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

This definition serves as the basis for the architetcure described in this document.


Our definition of the term "Web services" does not presuppose the use of SOAP as a packaging format or a processing model. Nor does it presuppose the use of WSDL as a service description language. There are, and will be in the future, plenty of Web services that use raw HTTP as a data transfer protocol and some mutually agreed-upon XML format as the message content. The Web Services *reference architecture* does, however, assume that the higher levels of the Web services protocol stack are built on the foundation of SOAP and WSDL.

This "blessing" of SOAP and WSDL is not logically necessary, since some other mechanism could be defined to gather XML message components into a single package, and other description mechanisms such as DAML-S could be used instead of WSDL. Perhaps in the long run, other technologies will supplant SOAP and WSDL, and it is not the intent of the WSA to discourage research and experimentation in these areas. On the other hand, the WSA WG believes that a common foundation is a *practical* necessity for the industry to move forward with additional Web services functionality, including security, choreography, etc. Thus, the WSA reference architecture builds on SOAP and WSDL as the basis for messaging and description. Specifications that conform to the WSA reference architecture MUST use SOAP and WSDL when appropriate.

3 Basic and Extended Architecture

This section is divided into two parts. In section 3.1 Basic Architecture, we describe the basic Web services architecture, the essence of the overall archietcture. In section 3.2 Extended Web Services Architecture, we explore the extended Web services architecture, which explains how extended features and functionality can be layered over the basic functionality represented in the basic architecture.

3.1 Basic Architecture

The Web services architecture places into relationship various components and technologies that comprise a Web services "stack" or completely functional implementation. Valid implementations include subsets or parts of the stack, but must at least provide the components within the basic architecture. Components and technologies that extend the basic architecture are represented within the extended architecture.

The basic architecture includes Web services technologies capable of:

  • Exchanging messages

  • Describing Web services

  • Publishing and discovering Web service descriptions

The basic Web services architecture defines an interaction between software agents as an exchange of messages between service requesters and service providers. Requesters are software agents that request the execution of a service. Providers are software agents that provide a service. Agents can be both service requesters and providers. Providers are responsible for publishing a description of the service(s) they provide. Requesters must be able to find the description(s) of the services.

The basic Web service architecture models the interactions between three roles: the service provider, service discovery agency, and service requestor. The interactions involve the publish, find, and bind operations. These roles and operations act upon the web service artifacts: the web service software module and its description. In a typical scenario a service provider hosts a network accessible software module (an implementation of a web service). The service provider defines a service description for the web service and publishes it to a requestor or service discovery agency. The service requestor uses a find operation to retrieve the service description locally or from the discovery agency (i.e. a registry or respository) and uses the service description to bind with the service provider and invoke or interact with the web service implementation. Service provider and service requestor roles are logical constructs and a service may exhibit characteristics of both.

Requesters and providers interact using one or more message exchange patterns (MEPs) that define the sequence of one or more messages exchanged between them. A service description is hosted by a discovery service, to which a provider publishes the description, and from which the requester discovers the description. The description includes data type and structure information, identifies the MEP, and contains the address of the service provider.

The extended architecture describes Web services support for MEPs that group basic messages into higher-level interactions, details how support for features such as security, transactions, orchestration, privace and others may be represented in messages (SOAP modules), and describes how additional features can be added to support business level interactions. The extended architecture builds on the basic architecture using the extensibility mechanisms inherent in the basic technologies.

Software agents in the basic architecture can take on one or all of the following roles:

  • Service requester -- requests the execution of a Web service

  • Service provider -- processes a Web service request

  • Discovery agency -- agency through which a Web service description is published and made discoverable

A software agent in the Web services architecture can act in one or multiple roles, acting as requester or provider only, both requester and provider, or as requester, provider, and discovery agency. A service is invoked after the description is found, since the service description is required to establish a binding.

Basic Web services architecture graphic

The figure above illustrates the basic Web services architecture, in which a service requestor and service provider interact based on the service's description information published by the provider and discovered by the requester through some form of discovery agency. Service requesters and providers interact by exchanging messages, which may be aggregated to form MEPs.

In the diagram above, the nodes of the triangle represent roles, as further defined in section 3.1.2 Roles and the edges represent operations, which are further defined in section 3.1.3 Operations

One or more intermediaries may exist in a message path between requester and provider. Intermediaries, where present, cannot interfere with the MEP. Intermediaries may perform certain functions associated with the message such as routing, security, management, or other operations. Examples of MEPs include one-way, request/response, publish/subscribe, and broadcast.

Basic Web services architecture components are typically defined using XML applications, use XML infoset definitions for message data typing and structuring, and use HTTP for transport. Extended Web services architecture components are typically defined using extensions to the core XML applications and transports, including alternatives to HTTP.

A message is defined as a construct that can include zero or more headers in addition to data. The header part of a message can include information pertinent to extended Web services functionality, such as security, transaction context, orchestration information, or message routing information. The data part of a message contains the message content or data.

A web service is described using a standard, formal XML notion, called its service description, that provides all of the details necessary to interact with the service, including message formats (that detail the operations), transport protocols, and location. The nature of the interface hides the implementation details of the service so that it can be used independently of the hardware or software platform on which it is implemented and independently of the programming language in which it is written.

Web services can be used alone or in conjunction with other web services to carry out a complex aggregation or a business transaction.

Annotated Web services architecture graphic

The figure above illustrates the relationships between requesters, providers, services, descriptions, and discovery services in the case where agents take on both requester and provider roles. For example, XML messages compliant with the SOAP specification are exchanged between the requester and provider. The provider publishes a WSDL file that contains a description of the message and endpoint information to allow the requester to generate the SOAP message and send it to the correct destination.

To support the common MEP of request/response, for example, a Web services implementation provides software agents that function as both requesters and providers, as shown in Figure 2. The service requester sends a message in the form of a request for information, or to perform an operation, and receives a message from the service provder that contains the result of the request or operation. The service provider receives the request, processed the message and sends a response. The technologies typically used for this type of Web services interaction include SOAP, WSDL, and HTTP.


The Web services architecture does not include the concept of automatically correlating requests and responses, as some RPC oriented technologies do. The correletion of request and response messages is typically application-defined.

The following sections provide more formal definitions of the components, roles, and operations in Web services architecture.

3.1.1 Components

  • The Service: Whereas a web service is an interface described by a service description, its implementation is the service. A service is a software module deployed on network accessible platforms provided by the service provider. It exists to be invoked by or to interact with a service requestor. It may also function as a requestor, using other web services in its implementation.

  • The Service Description: The service description contains the details of the interface and implementation of the service. This includes its data types, operations, binding information, and network location. It could also include categorization and other meta data to facilitate discovery and utilization by requestors. The complete description may be realized as a set of XML description documents. The service description may be published to a requestor directly or to a discovery agency.

3.1.2 Roles

  • Service Provider: From a business perspective, this is the owner of the service. From an architectural perspective, this is the platform that hosts access to the service. It has also been referred to as a service execution environment or a service container. Its role in the client-server message exchange patterns is that of a server.

  • Service Requestor: From a business perspective, this is the business that requires certain function to be satisfied. From an architectural perspective, this is the application that is looking for and invoking or initiating an interaction with a service. The requestor role can be played by a browser driven by a person or a program without a user interface, e.g. another web service. Its role in the client-server message exchange patters is that of a client.

  • Discovery Agency: This is a searchable set of service descriptions where service providers publish their service descriptions. The service discovery agency can be centralized or distributed. A discovery agency can support both the pattern where it has descriptions sent to it and where the agency actively inspects public providers for descriptions. Service requestors may find services and obtain binding information (in the service descriptions) during development for static binding, or during execution for dynamic binding. For statically bound service requestors, the service discovery agent is in fact an optional role in the architecture, as a service provider can send the description directly to service requestors. Likewise, service requestors can obtain a service description from other sources besides a service registry, such as a local filesystem, FTP site, URL, or WSIL document.

3.1.3 Operations

In order for an application to take advantage of Web services, three behaviors must take place: publication of service descriptions, finding and retrieval of service descriptions, and binding or invoking of services based on the service description. These behaviors can occur singly or iteratively, with any cardinality between the roles. In detail these operations are:

  • Publish: In order to be accessible, a service needs to publish its description such that the requestor can subsequently find it. Where it is published can vary depending upon the requirements of the application (see Service Publication Stck discussion for more details)

  • Find: In the find operation, the service requestor retrieves a service description directly or queries the registry for the type of service required (see Service Discovery for more details). The find operation may be involved in two different lifecycle phases for the service requestor: at design time in order to retrieve the service's interface description for program development, and at runtime in order to retrieve the service's binding and location description for invocation.

  • Interact: Eventually, a service needs to be invoked. In the interact operation the service requestor invokes or initiates an interaction with the service at runtime using the binding details in the service description to locate, contact, and invoke the service. Examples of the interaction include: single message one way, broadcast from requester to many services, a multi message conversation, or a business process. Any of these types of interactions can be synchronous or asynchronous.

3.2 Extended Web Services Architecture

This section describes the extended Web services architecture in detail. The extended Web services architecture incorporates additional features and functionality by extending the technologies and components defined within the basic Web services architecture.

3.2.1 Features

The extended web services architecture provides for concrete use of features. Features are ..... A Feature is specified in the abstract, and is realized through one or more bindings, Message Exchange Patterns, or Modules..


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

Here is a partial list of Features:

  • Asynchronous messaging

  • Attachment - The packaging of multiple documents together, typical usage scenario is assocating binary data with SOAP messages. The XML Protocol Attachment Feature is an abstract implementation of this feature. Concrete realizations include SOAP with Attachments and DIME.

  • Caching

  • Message exchange pattern (MEP) -- an MEP is a specialized form of Feature that describes a generalized pattern of message exchange between two services.

  • Correlation - 1 solution is a binding that is HTTP, and another is an MEP is 2 requests with a correlation ID SOAP Module

  • Long running transaction, aka conversation or long-running interaction - one MEP is a series of reqests between two nodes with a conversation ID SOAP Module.

  • Reliable message - implementation of Reliable Messaging (insert reference to glossary). one MEP is a series of requests between two nodes with an acknowledgement SOAP Module.

  • Message authentication - one binding is HTTP auth, another is a SOAP Module with username/password, x.509 etc.

  • Message confidentiality - one approach is to transmit the message over a protocol that can be protected via SSL or TLS, another is use of a SOAP Module that provides for encryption and decryption.

  • Message integrity - one solution is a SOAP Module that uses a digital signature signed over a digest of the message.

  • Message routing - Dynamic specification of message paths between nodes.

  • Management messages

  • Session

3.2.2 Infrastructure Services

Editorial note  
DO: I don't know if we've modelled infrastructure services very well. Take something like WS-Coordination. It has defined services exchanged for startup and takedown of coordination. And then contexts are transferred during regular service invocation. So it defines a few features (startup and takedown) with their MEPs and it also defines a feature and a particular binding (soap headers for contexts). I think we need to have a way of expressing this notion.

3.2.3 Diagrammatic representation of features

The following diagram shows the three stacks, with concrete realizations of features. Asynchrony, caching, reliability, routing, conversations, security are realized as SOAP Modules. Management is realized as SOAP MEPs. 3 Stack Diagram

3.2.4 Flows

The following views represent...

Peer to Peer view

As we see above, a Web service instance can serve multiple roles simultaneously. In the peer to peer scenario, each peer Web service instance serves in both the Service Requester and Service Provider roles.

Derivative view

In the graphic above, we see that the Service Requester and Discovery Agency role are fulfilled by the client.

Intermediary view

discuss intermediary's role

Oneway view

discuss oneway

3.3 Web Services Stacks

To ensure interoperability when performing the publish, find and bind operations expressed in the Service Oriented Architecture (SOA) diagram; conceptual and technical standards must be defined for each role and type of interaction. This section will explore each of roles and interactions in order identify each relevant stack of technologies.

There are over arching concerns involving security, management and quality of services that must be addressed at each layer in the conceptual and technical stacks. The various solutions at each layer may or may not be independent of one other. More of these overarching concerns will emerge as the web services paradigm is adopted and evolved. What is most important is building a framework through which all such concerns may be applied to each of the layers in the stack so that as new concerns emerge they may be dealt with flexibly and consistently.

At the end of this section we assemble the independent stacks into a single stack where each additional layer builds upon the capabilities provided by those below it. The vertical towers represent the variety of over arching concerns that must be addressed at every level of each of the stacks.

An important point is that, towards the bottom layers of the stack, the technologies and concepts are relatively more mature and achieve a higher level of standardization than many of the upper layers. The maturation and adoption of Web services will drive the continued development and standardization of the higher levels of the stack and the overarching concerns.

3.3.1 Wire "Stack"

The wire stack encapsulates the concepts and technologies dealing with the actual physical exchange of information between any of the roles in the SOA diagram. This includes the variety network transport, message packaging and message extensions that may be utilized to facilitate data exchange.

Wire Stack diagram Transport

The foundation of the web services stack is the network. Web services must be network accessible to be invoked by a service requestor. Web services that are publicly available on the Internet use commonly deployed network protocols. Because of its ubiquity, HTTP is the de facto standard network protocol for Internet-available web services. Other Internet protocols may be supported including SMTP and FTP. Intranet domains may use proprietary or platform and vendor specific protocols such as MQSeries, CORBA, etc.. The specific choice of network protocol used in any given scenario depends entirely upon application requirements, including concerns such as security, availability, performance, and reliability. This allows web services to capitalize on existing higher function networking infrastructures and message oriented middleware, such as MQSeries.

Within an enterprise with multiple types of network infrastructures, HTTP can be used as a common, interoperable bridge to connect disparate systems. One of the benefits of web services is that it provides a unified programming model for the development and usage of private Intranet as well as public Internet services. As a result, the choice of network technology can be made entirely transparent to the developer and consumer of the service. Packaging

Moving up the Wire stack, the next layer, Packaging, represents the technologies that may be used to package information being exchanged. XML has been broadly adopted as the basis for Web service message packaging protocols.

SOAP is a simple and lightweight XML-based mechanism for creating structured data packages that can exchanged between network applications. SOAP consists of four fundamental components: an envelope that defines a framework for describing message structure, a set of encoding rules for expressing instances of application-defined data types, a convention for representing remote procedure calls (RPC) and responses, and a set of rules for using SOAP with HTTP. SOAP can be used in combination with a variety of network protocols; such as HTTP, SMTP, FTP, RMI/IIOP, or a proprietary messaging protocol.

SOAP is currently the de facto standard for XML messaging for a number of reasons. First, SOAP is relatively simple, defining a thin layer that builds on top of existing network technologies such as HTTP that are already broadly implemented. Second, SOAP is flexible and extensible in that rather than trying to solve all of the various issues developers may face when constructing Web services, it provides an extensible, composable framework that allows solutions to be incrementally applied as needed. Thirdly, SOAP is based on XML. Finally, SOAP enjoys broad industry and developer community support. Extensions

Building on the transport and packaging layers, the final layer in the Wire stack provides a framework that allows additional information to be attached to Web service messages representing a variety of additional concerns; such as context, routing, policy, etc. As a key part of its envelope message structure, SOAP defines a mechanism to incorporate orthogonal extensions (also known as features) to the message in the form of headers and encoding rules. It is expected that as Web services are adopted and evolved, a broad collection of such extensions will emerge and be standardized.

3.3.2 XML Messaging with SOAP

Here is an example of how SOAP, HTTP, and the internet can be used to implement the Wire stack. The following figure shows how XML messaging (SOAP) and network protocols can be used as the basis of the web services architecture.

Example of wire technologies
Editorial note  
CBF: missing graphic...

The basic requirements for a network node to play the role of requestor or provider in XML Messaging based distributed computing are the ability to build and/or parse a SOAP message and the ability to communicate over a network (receive and/or send messages).

Typically, a SOAP Server running in a web application server performs these functions. Alternatively, a programming language-specific runtime library can be used that encapsulates these functions within an API. Application integration with SOAP can be achieved by using four basic steps:

  • In the Figure 1 above at (1), a service requestor’s application creates a SOAP message. This SOAP message is the request that invokes the web service operation provided by the service provider. The XML document in the body of the message can be a SOAP RPC request or a document-centric message as indicated in the service description. The service requestor presents this message together with the network address of the service provider to the SOAP infrastructure (e.g. a SOAP client runtime). The SOAP client runtime interacts with an underlying network protocol (e.g. HTTP) to send the SOAP message out over the network.

  • The network infrastructure delivers the message to the service provider’s SOAP runtime (e.g. a SOAP server) (2). The SOAP server routes the request message to the service provider's web service. The SOAP runtime is responsible for converting the XML Message into programming language specific objects if required by the application. This conversion is governed by the encoding schemes found within the message.

  • The web service is responsible for processing the request message and formulating a response. The response is also a SOAP message. The response SOAP message is presented to the SOAP runtime with the service requestor as the destination (3). In the case of synchronous request/response over HTTP, the underlying request/response nature of the networking protocol is used to implement the request/response nature of the messaging. The SOAP runtime sends the SOAP message response to the service requestor over the network.

  • The response message is received by the networking infrastructure on the service requestor’s node. The message is routed through the SOAP infrastructure; potentially converting the XML message into objects in a target programming language (4). The response message is then presented to the application.

This example uses the request/response transmission primitive that is quite common in most distributed computing environments. The request/response exchange may be synchronous or asynchronous. Other transmission primitives such as one-way messaging (no response), notification (push style response), publish/subscribe are possible using SOAP. Interactions
  • One way: Message sent from requestor to provider. Provider may or may not return a response. If the provider returns a response, the requester may have already stopped ‘listening’ for it or closed the communications channel. Response will be ‘thrown away’ and not processed by the requester

  • Conversational: Requester and Provider exchange multiple messages. Can be defined by choreography language.

  • Many-to-Many: Requester sends message to many providers. Or, service provider responds to many requestors. Can be defined by choreography language.

3.3.3 Description "Stack"

Editorial note  

The service description layer is actually a stack of description documents defined using XML Schema.

It is through the service description that the service provider communicates all the specifications for invoking the Web service to the service requestor. The service description is a key contributor to making the Web services architecture loosely coupled and to reducing the amount of required shared understanding, custom programming and integration between the service provider and the service requestor. For example, neither the requestor nor the provider must be aware of the other's underlying platform, programming language, or distributed object model (if any). The service description combined with the underlying XML Message infrastructure defined in the Wire stack sufficiently encapsulates this detail away from the service requestor's application and the service provider’s Web service.

We describe the constituent parts of the service description used in the Web services architecture in two groups, those used to fully describe one Web service and those used to describe interactions or relationships between sets of Web services. Descriptions Applying to a Particular Web Service

The first two layers of the description stack describe the mechanics of invoking a Web service. The interface, or messages the service expects and returns, and the implementation, how to encode the messages and where to send them to. These two layers are satisfied by Web Services Description Language (WSDL) [WSDL]. The interface and implementation are the minimum service description necessary to support interoperable Web services.

The Web services architecture uses WSDL (Web Services Definition Language)[WSDL 01] for base-level service description. WSDL has been submitted to the W3C and is being actively developed by the W3C Web Services Description WG. WSDL is an XML document format for describing Web services as a set of endpoints operating on messages containing either document-oriented or procedure-oriented (RPC) messages. The operations and messages are described abstractly, and then bound to a concrete network protocol and message format to define an endpoint. Related concrete endpoints may be combined into services. WSDL is sufficiently extensible to allow description of endpoints and their messages regardless of what message formats or network protocols are used to communicate. WSDL1.1 describes bindings for SOAP1.1, HTTP POST, and MIME. WSDL1.2 will add binding support for SOAP1.2.

The policy description layer is where the additional description necessary to specify the business context, qualities of service, security requirements and offerings, and management requirements. The WSDL document can be complimented by other service description documents to describe these higher-level aspects of the Web service. For example, business context can be described using Universal Data Description Interface (UDDI) [UDDI] data structures in addition to the WSDL document.

The presentation layer describes how to render the input and output messages on a screen for a user to interact with. This is particularly useful for rendering Web services to users on many different types of devices.

wsdl Interface

A service interface definition is an abstract or reusable service definition that may be instantiated and referenced by multiple service implementation definitions. Think of a service interface definition like an IDL (Interface Definition Language), Java interface, or Web service type. This allows common industry standard service types to be defined and implemented by multiple service implementers. This is analogous to defining an abstract interface in a programming language and having multiple concrete implementations. Service interfaces may be defined by industry standards organizations, such as RosettaNet or HL7 for the health industry.

In WSDL, the service interface contains elements that comprise the reusable portion of the service description: binding, portType, message and type elements as depicted in Figure 2 - Basic Service Description above. In the portType element, the operations of the Web service are defined. The operations define what XML messages can appear in the input, output and fault data flows. The message element specifies which XML data types constitute various parts of a message. The message element is used to define the abstract content of messages that comprise an operation. The use of complex data types within the message is described in the types element. The binding element describes the protocol, data format, security and other attributes for a particular service interface (portType). Implementation

The service implementation definition describes how a particular service interface is implemented by a given service provider. It also describes its location so that a requester can interact with it. In WSDL, a Web service is modeled as a service element. A service element contains a collection of port elements. A port associates an endpoint (e.g. a network address location (URL)) with a binding element from a service interface definition.

To illustrate the allocation of responsibility, the Open Applications Group[OAG] may define a service interface definition for the OAGIS purchase order standard. This service interface definition would define WSDL type(s), message(s), portType(s) and binding(s). This specification would be published at some well-known site (e.g. http://www.openapplications.org/serviceInterfaces/).

A service provider may choose to develop a web service that implements the OAGIS purchase order service interface. The service provider would develop a service implementation definition document that describes the WSDL service, port, and address location elements that describe the network address of the provider’s Web service and other implementation specific details.

The service interface definition together with the service implementation definition makes up a complete WSDL definition of the service. This pair contains sufficient information to describe to the service requestor how to invoke and interact with the Web service. The service requestor may require other information about the service provider’s end-point. This information is provided by the complete Web service description of the service. Policy

Policy for Web services consists of facts, or assertions, and rules that apply to a particular Web service. The policy may be associated with an interface (portType), a binding of that interface to a protocol, or a service instance. Policy would be used to describe or point to documents describing the owning business, associated products, keywords, taxonomies for the service, security policies, quality of service attributes, etc. Policy may be used by the over-arching concerns: security, quality of service, and management; as well as higher layers of the description stack. Presentation

A Web service description may be accompanied by another description document which defines how to display a service to a user and what the interactions between the service and the user should be. This description could be used to render the service on a variety of devices including phones, PDAs, and systems. Description for Relationships between Web Services

There are two types of relationships between services: programmatic and agreements. Programmatic relationships are captured by the composition and orchestration description layers. Agreements are more contractual indicating an agreement, possibly legally binding. Agreements are captured by the service level agreement and business agreement description layers.

Since a Web service’s implementation is a software module or ‘component’, it is natural to produce Web services by composing web services. A composition of Web services could play one of several roles. Intra-enterprise Web services might collaborate to present a single Web service interface to the public. Optionally, the Web services from different enterprises may collaborate to perform machine-to-machine or business-to-business transactions. Alternatively, a workflow manager may call each Web service as they participate in a business process. The composition and orchestration layers describe how service-to-service communications, collaborations, and flows are performed. Description languages like BPEL4WS can be used to describe these interactions. Composition

@@@ Orchestration

An orchestration description reflects a simple choreography of Web service invocations between two business partners to complete a multi-step business interaction. For example an agreement definition defines roles such as buyer and seller within a purchasing protocol. The agreement definition outlines the requirements that each role must fulfill. For example, the seller must have web services that receive request for quote (RFQ) messages, purchase order (PO) messages and payment messages. The buyer role must have Web services that receive quotes (RFQ response messages), invoice messages and account summary messages. This simple choreography of web services into business roles is critical for establishing multi-step service-oriented interactions between business parties. A given service requestor or service provider might be able to play the buyer or seller role in a number of different business process flow standards. By explicitly modeling business agreements and each node’s ability to play roles in the business agreement, the requestor can choose which business agreement to engage in with various provider business partners. Service Level Agreements

@@@ Business Level Agreements


3.3.4 Discovery Agencies "Stack"

While the bottom three layers of the stack identify technologies for compliance and interoperability, the service publication and service discovery can be implemented with a range of solutions.


Any action that makes a WSDL document available to a requestor, at any stage of the service requestor’s lifecycle, qualifies as service publication.

Since a web service cannot be discovered if it has not been published, service discovery depends upon service publication. The variety of discovery mechanisms parallels the set of publication mechanisms. Any mechanism that allows the service requestor to gain access to the service description and make it available to the application at runtime qualifies as service discovery. The simplest, most static example of discovery is static discovery wherein the service requestor retrieves a WSDL document from a local file. This is usually the WSDL document obtained through a direct publish or the results of a previous find operation. Alternatively, the service may be discovered at design time or run time using a local WSDL registry, or a public or private registry such as UDDI. The variety of service discovery mechanisms is discussed in more detail in the section titled Service Discovery. Service Publication Producing Service Descriptions

The service description may be generated, hand coded, or pieced together based on existing service interface definitions etc. Developers may hand code the entire service description, including the UDDI entry. Tools exist to generate parts of the WSDL and potentially parts of the UDDI entry from metadata artifacts from the programming model and the deployment of the web service executable. Parts of the service description may already exist (for example the web service may be based on an industry standard service interface definition) such that very little needs to be further generated.

Editorial note  
CBF: needs to be made less UDDI-centric Publishing Service Descriptions

A service description can be published using a variety of mechanisms. These various mechanisms provide different capabilities depending on how dynamic the application using the service is intended to be. The service description may be published to multiple service registries using several different mechanisms. The simplest case is a direct publish. A direct publish means the service provider sends the service description directly to the service requestor. This can be accomplished using an e-mail attachment, an FTP site, or even a CDROM distribution. Direct publish can occur after two business partners have agreed on terms of doing e-business over the Web, or after fees have been paid by the service requestor for access to the service. In this case the service requestor may maintain a local copy of the service description. Slightly more dynamic publication uses WSIL. WSIL defines a simple HTTP GET mechanism to retrieve Web services descriptions from a given URL. An enhanced service description repository would provide a local cache of service descriptions, but with additional search capabilities.

Another means of publishing service descriptions available to Web services is through a UDDI registry. There are several types of UDDI registries that may be used depending on the scope of the domain of Web services published to it. When publishing a Web service description to a UDDI registry, complete business context and well thought out taxonomies are essential if the service is to be found by its potential service consumers.

  • Internal Enterprise Application UDDI registry: Web services for use within a company for internal enterprise applications integration should be published to a UDDI registry of this kind. The scope of this UDDI registry may be single application, departmental, or corporate. These UDDI registries sit behind the firewall and allow the service publishers more control over their service registry and its accessibility, availability, and publication requirements.

  • Portal UDDI registry: Web services published by a company for external partners to find and use may use a portal UDDI registry. A portal UDDI registry runs in the service provider’s environment outside the firewall or in a DMZ between firewalls. This kind of private UDDI registry contains only those service descriptions that a company wishes to provide to service requestors from external partners. This allows companies to retain control of their service descriptions, access to the UDDI registry and quality of service for the UDDI registries. Moreover, by using the Role based visibility inherent in portals, and emerging in newer drafts of the UDDI specs themselves, the enterprise may limit visibility of service descriptions to the partners authorized to see their existence.

  • Partner Catalog UDDI registry: Web services to be used by a particular company can be published to a Partner Catalog (rolodex like) UDDI registry. A Partner Catalog UDDI registry sits behind the firewall. This kind of private UDDI registry contains only approved, tested, and valid web service descriptions from legitimate business partners. The business context and metadata for these web services can be targeted to the specific requestor.

  • e-Marketplace UDDI registry: For web services that the service provider intends to compete for requestors' business with other web services, the service description should be published to an e-Marketplace UDDI registry or the UDDI Business Registry. E-Marketplace UDDI registries are hosted by an industry standards organization or consortium and contain service descriptions from businesses in a particular industry. These services may be required to support specific standards, searchable meta data, interfaces, or data types E-Marketplace UDDI registries will generally provide some filtering of illegitimate entries as well as some guaranteed qualities of service.

  • UDDI Business Registry: Web services may also wish to publish to the UDDI Business Registry in some other public registry in order that they may be discovered by new potential business partners or service users.

This figure shows the continuum from the most static, easiest technologies for publish and discovery to the most dynamic, more complex technologies. Users or implementers of web services may not follow this progression in strict sequence.

Editorial note  
CBF: is there a missing graphic here? Service Discovery Acquiring Service Descriptions

As with publishing Web service descriptions, acquiring Web service descriptions will vary depending on how the service description is published and how dynamic the Web service application is meant to be. Service requestors will find Web services during two different phases of an application lifecycle – design time and run time. At design time, service requestors will search for web service descriptions by the type of interface they support. At run time service requestors will search for a web service based on how they communicate or qualities of service advertised.

With the direct publish approach, the service requestor will cache the service description at design time for use at runtime. The service description may be statically represented in the program logic, stored in a file, or in a simple, local service description repository.

Service requestors can retrieve a service description at design time or runtime from a Web page (URL), a service description repository, a simple service registry or a UDDI registry. The look-up mechanism will need to support a query mechanism that provides find by type of interface (based on a WSDL template), the binding information (i.e. protocols), properties (such as QOS parameters), the types of intermediaries required, the taxonomy of the service, business information, etc.

The various types of UDDI registries have implications on the number of runtime binding web services can choose from, policy for choosing one among many, or the amount of pre screening that must be done by the requestor before invoking the service. Service selection can be based on binding support, historical performance, quality of service classification, proximity, or load balancing. E-Marketplace UDDI registries will have more runtime services to choose from. Some pre screening must be done to verify that the web service provider is a worthy partner and is not nefarious or inept. Choosing a service may be done based on price promises, cost, presence on approved partners list, as well as binding support, historical performance, quality of service classifications, and proximity. If service requestors query the UDDI Business Registry for web service providers, they will have to exercise the most caution and diligence when prescreening potential service providers. An efficient and accurate filter will have to be in place to return only suitable descriptions and potential business partners. Consuming Service Descriptions

Once a service description is acquired, the service requestor will need to process it in order to invoke the service. The service requestor uses the service description to generate SOAP requests or programming language specific proxies to the web service. This generation can be done at design time or at runtime to format an invocation to the web service. Various tools can be used at design time or runtime to generate programming language bindings from WSDL documents. These bindings present an API to the application program and encapsulate the details of the XML messaging from the application. Inspection

Inspection technologies such as WSIL provide a de-centralized service discovery method. It may be used to discover Web services at the service provider's point-of-offering. The WSIL specification defines a document format that contains a list of WSDL URLs and other related WSIL URLs within a domain. WSIL can also reference UDDI entries/repositories and RDF documents as well. It can actually contain references to anything. The WSIL specification defines a convention for naming and placing the files so that they are easier to locate (similar to index.html and robots.txt files). Inspection technologies, unlike registries, is not suited for many/most of the dynamic discovery/bind scenarios, simply because there is no searching capability.

They may or may not be local to the system. WSIL documents can be used to enable a variety of discovery agent patterns:

  • Local service discovery for ‘local’ web service applications (micro SOAs that don’t leave the box… all else is the same except it limits where it looks for services).

  • Application integration.

  • Discovery agents populated by crawlers looking for WSIL documents.

  • Management topologies of available services (but its not a discovery source).

Editorial note  
CBF: this section needs more, we can get some help the WSIL folks

3.3.5 Overarching Concerns

Editorial note  
CBF: To be developed...
Overarching concerns


3.3.6 The Complete Web Services "Stack"

Extended Web services architecture graphic

The figure above illustrates the complete stack of functions contained in the extended Web services architecture. The extended functionality includes additional technologies in the following areas: discovery agencies, description, and wire. The extended architecture also includes overarching concerns such as security, management, and qualites of service that apply to all components in the Web services architecture.

Editorial note  
CBF: what about privacy? where should this be reflected in the stack?

Editorial note  
EN: As with the basic architecture, a next step after completing the description of the diagrams will be to fill in the diagrams with reference technologies and specifications.

4 Web Service Architecture

The Web services architecture consists of:

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

4.1 Identifiers

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

Issue (qnames):

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


None recorded.

Issue (uuids):

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


None recorded.

Constraint: URIs as identifiers

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

4.2 Formats

As with identifiers (see section 4.1 Identifiers), the Web services architecture builds upon the definition of, and architectural constraints placed on, formats from Architecture Principles of the Web[7].


4.2.1 XML Infoset

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

Editorial note  
CBF: cite examples of possible alternate serializations such as compressed or binary XML.

4.2.2 XML Schema

Specification of message formats, structures and datatypes SHOULD be based on the W3C XML Schema: Structures[4] and XML Schema: Datatypes [5] specifications.

Issue (otherschema):

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


None recorded.

4.2.3 SOAP

One of the key specifications used in the context of Web services is SOAP [8]. 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. 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 3.2.1 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 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 4.2.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 4.2.4 WSDL).

Issue (wsdlmep):

WSDL identifies MEPs using QNames, not URIs.


None recorded. 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. 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 4.2.4 WSDL).

Issue (soapbinduri):

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


None recorded. Process Model


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

4.2.4 WSDL

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. WSDL harvesting material
WSDL plays a descriptor role in the overall Web Services
architecture.  WSDL is static as it does not define dynamic interactions
Web Services.


WSDL defines
 1. abstract functionality of a service
 2. concrete binding details for SOAP 1.2, HTTP, and MIME


wsdl   "http://www.w3.org/2002/07/wsdl" A normative XML Schema [XML Schema:
Structures], [XML Schema: Datatypes] document for the
"http://www.w3.org/2002/07/wsdl" namespace can be found at
soap12 "http://www.w3.org/2002/07/wsdl/soap12" Defined by WSDL 1.2: Bindings
[WSDL 1.2 Bindings]. 
http   "http://www.w3.org/2002/07/wsdl/http" Defined by WSDL 1.2: Bindings
[WSDL 1.2 Bindings]. mime "http://www.w3.org/2002/07/wsdl/mime" Defined by
WSDL 1.2: Bindings [WSDL 1.2 Bindings].

WSDL has dependencies on XML schema. 

Web Services model by WSDL

Summary: http://www.w3.org/TR/2002/WD-wsdl12-20020709/#intro

"WSDL describes Web services starting with the messages that are exchanged
between the service provider and requestor. The messages themselves are
described abstractly and then bound to a concrete network protocol and
format. A message consists of a collection of typed data items. An exchange
messages between the service provider and requestor are described as an
operation. A collection of operations is called a portType. Collections of
portTypes are grouped and called a serviceType. A service represents an
implementation of a serviceType and contains a collection of ports, where
port is an implementation of a portType, which includes all the concrete
details needed to interact with the service."

Components: requestor and provider
Connector: ports.
Data element: typed data item, messages

Architectural concept:

1. Messages are abstract and then bound to a concrete network protocol and
message format;
2. Operation is an exchange of message and there are only four types of
operations  (Input-Output,Output-Input, Input only, and Output only)

Architectural decisions:
1. Data types are described by XML schema.
2. Both interface and implementation is defined in one WSDL. 

WSDL bindings
"A binding defines message format and protocol details for operations and
messages defined by a particular portType. There may be any number of
for a given portType."

WSDL SOAP 1.1 bindings 

"1. An indication that a binding is bound to the SOAP 1.2 protocol.
 2. A way of specifying an address for a SOAP endpoint.
 3. The URI for the SOAPAction HTTP header for the HTTP binding of SOAP.
 4. A list of definitions for Headers that are transmitted as part of the
SOAP Envelope"
WSDL HTTP bindings


"1. An indication that a binding uses HTTP GET or POST
 2. An address for the port
 3. A relative address for each operation (relative to the base address
defined by the port) "

WSDL MIME bindings
"1. 'multipart/related', defined in [IETF RFC 2387].
 2. 'text/xml', defined in [IETF RFC 3023].
 3. 'application/x-www-form-urlencoded', defined in Form content types
([HTML 4.01], section 17.13.4).
 4. Others (by specifying the MIME type string) "

WSDL extensibility


"WSDL has an open content model: every element in the
'http://www.w3.org/2002/07/wsdl' namespace allows arbitrary extension
attributes and extension elements as long as their names are fully qualified
and they are defined in a namespace other than

WSDL issues:

1. Link handling

2. Does not support description of dynamic interactions.

Editorial note  
CBF: WSDL harvested material above needs to be turned into appropriate prose.

4.3 Protocols

Now provide description of Web service protocols

SOAP protocol binding framework
 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

  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  
CBF: This is harvested material that needs to be turned into prose.
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.3.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.3.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 Service Provider's protocol

  • proprietary messaging systems

5 Processing Model

Now provide description of SOAP and WSDL Processing models

                Processing model
 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.

 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

 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:

 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.

 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

 An ultimate SOAP receiver MUST correctly process the immediate
 children of the SOAP body

 Rules for SOAP processing and the kinds of faults that must be

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

Editorial note  
CBF: This is harvested material that needs to be turned into prose.

A Acknowledgments (Non-Normative)

This document has been produced by the Web Services Architecture Working Group

The editors would like to thank Heather Kreger of IBM for her substantial contributions to this document.

Members of the Working Group are (at the time of writing, and by alphabetical order): Daniel Austin (W. W. Grainger, Inc.), Mukund Balasubramanian (Infravio, Inc.), Mike Ballantyne (EDS), Abbie Barbir (Nortel Networks), David Booth (W3C), Allen Brown (Microsoft Corporation), Mike Brumbelow (Apple), Doug Bunting (Sun Microsystems, Inc.), Greg Carpenter (Nokia), Dipto Chakravarty (Artesia Technologies), Jun Chen (MartSoft Corp.), Alex Cheng (Ipedo), Tom Carroll (W. W. Grainger, Inc.), Michael Champion (Software AG), Martin Chapman (Oracle Corporation), Ugo Corda (SeeBeyond Technology Corporation), Roger Cutler (ChevronTexaco), Jonathan Dale (Fujitsu), Suresh Damodaran (Sterling Commerce(SBC)), Glen Daniels (Macromedia), James Davenport (MITRE Corporation), Alan Davies (SeeBeyond Technology Corporation), Paul Denning (MITRE Corporation), Ayse Dilber (AT&T), Zulah Eckert (Hewlett-Packard Company), Gerald Edgar (The Boeing Company), Colleen Evans (Progress Software Corp.), Chris Ferris (IBM), Daniela Florescu (XQRL Inc.), Shishir Garg (France Telecom), Yaron Goland (BEA Systems), Hugo Haas (W3C), Mark Hapner (Sun Microsystems, Inc.), Hao He (The Thomson Corporation), Dave Hollander (Contivo), Yin-Leng Husband (Hewlett-Packard Company), Nigel Hutchison (Software AG), Mario Jeckle (DaimlerChrysler Research and Technology), Mark Jones (AT&T), Tom Jordahl (Macromedia), Heather Kreger (IBM), Sandeep Kumar (Cisco Systems Inc), Hal Lockhart (OASIS), Michael Mahan (Nokia), Francis McCabe (Fujitsu), Michael Mealling (VeriSign, Inc.), Jens Meinkoehn (T-Nova Deutsche Telekom Innovationsgesellschaft), Jeff Mischkinsky (Oracle Corporation), Nilo Mitra (Ericsson), Himagiri Mukkamala (Sybase, Inc.), Eric Newcomer (IONA), Henrik Nielsen (Microsoft Corporation), Mark Nottingham (BEA Systems), David Orchard (BEA Systems), Srinivas Pandrangi (Ipedo), Fabio Riccardi (XQRL Inc.), Don Robertson (Documentum), Waqar Sadiq (EDS), Krishna Sankar (Cisco Systems Inc), Igor Sedukhin (Computer Associates), Jim Shur (Rogue Wave Software), Hans-Peter Steiert (DaimlerChrysler Research and Technology), Katia Sycara (Carnegie Mellon University), Patrick Thompson (Rogue Wave Software), Steve Vinoski (IONA), Scott Vorthmann (TIBCO Software, Inc.), Prasad Yendluri (webMethods, Inc.), Jin Yu (MartSoft Corp.), Sinisa Zimek (SAP).

Previous members of the Working Group were: Mark Baker (Idokorro Mobile, Inc. / Planetfred, Inc.), Tom Bradford (XQRL, Inc.), Sharad Garg (Intel), Joseph Hui (Exodus/Digital Island), Marcel Jemio (DISA), Timothy Jones (CrossWeave, Inc.), Jim Knutson (IBM), Bob Lojek (Intalio, Inc.), Anne Thomas Manes (Systinet), Joel Munter (Intel), David Noor (Rogue Wave Software), Kevin Perkins (Compaq), Darran Rolls (Waveset Technologies, Inc.).

B References (Non-Normative)

B.2 Informative References

Web Services Architecture Charter (See http://www.w3.org/2002/01/ws-arch-charter.)
DRAFT: Architecture Principles of the World-Wide Web; Ian Jacobs, 30 August 2002 (See http://www.w3.org/TR/2002/WD-webarch-20020830/.)
SOAP Version 1.2 Part 1: Messaging Framework Working Draft, eds. M. Gudgin, M. Hadley, J. Moreau, H. Nielsen, 26 June 2002 (See http://www.w3.org/TR/soap12-part1/.)
SOAP Version 1.2 Part 2: Adjuncts Working Draft, eds. M. Gudgin, M. Hadley, J. Moreau, H. Nielsen, 26 June 2002 (See http://www.w3.org/TR/soap12-part2/.)
SOAP 1.2 Part 0 (See http://www.w3.org/TR/2002/WD-soap12-part0-20020626/.)
SOAP 1.2 Part 0 (See http://www.w3.org/TR/soap12-af/.)
SOAP Messages with Attachments (See http://www.w3.org/TR/SOAP-attachments.)
XML Protocol (XMLP) Requirements, W3C Working Draft 26 June 2002, eds V. Apparao et al. (See http://www.w3.org/TR/2002/WD-xmlp-reqs-20020626.)
XML Protocol Usage Scenarios (See http://www.w3.org/TR/2001/WD-xmlp-scenarios-20011217/.)
Web Services Description Language (WSDL) Version 1.2 Working Draft, eds. R. Chinnici, M. Gudgin, J. Moreau, S. Weerawarana (See http://www.w3.org/TR/wsdl12/.)
Web Services Architecture Requirements Working Draft, eds. D. Austin, A. Barbir, C. Ferris, S. Garg (See http://www.w3.org/TR/wsa-reqs.)
Web Services Glossary Working Draft, eds. H. Haas (See http://www.w3.org/TR/ws-gloss.)
Web Services Architecture Usage Scenarios Working Draft, eds. H. Haas, D. Orchard (See http://www.w3.org/TR/2002/WD-ws-arch-scenarios-20020730/.)
Message Service Specification, ebXML Message Service Specification Version 2.0 (See http://www.ebxml.org/specs/ebMS.pdf.)
Web Services Routing Protocol (WS-Routing) (See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsrvspev/html/ws-routing.asp.)

C The Bottom Up View of the Architecture (Non-Normative)

Editorial note  
CBF: The material in this section has been largely reconstituted in section 3 above. It remains here so that the editors can further harvest the concepts covered here. It is the editor's intent that this section will be removed and subsumed in the next published draft.

This section describes the bottom-up view of Web services architecture. The bottom-up view presents Web services as fundamentally comprised of XML messages and the software agents that process them. The software agents can be any one or combination of the following:

The bottom-up Web services architecture describes a system comprised of related technologies that exchange messages between senders and receivers, potentially including intermediaries. 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 infoset definitions for message data typing and structuring. The bottom-up view of Web services architecture defines the message exchange patterns and extended functionality by placing the fundamental aspects of Web services into relationship: the message, sender, receiver, intermediary, and extended functionality data or context.

Figure 1 illustrates the basic concept of the Web services architecture. An XML message is sent from a sender and received by a receiver. The sender typically generates the XML message but may also forward it. Messages include zero or more headers and data. The header part of a message includes information pertinent to functional aspects of the message, such as security, transaction context, orchestration information, or message routing information. The data part of a message includes the application-defined content. Messages typically have one or more XML schema content models associated with them: one for each header, and one for the data. Messages are associated with endpoints using URIs. The URI identifies the endpoint to which a sender sends an XML message, and at which a receiver is listening for a message. Compatible content models for the header and the data must be available at both the sender and 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. Thus the fundamental building blocks of Web services architecture are the XML message, message sender, and message receiver. Each is described furture in this document. Basic Web services applications use this level of functionality. More complicated Web services applications add to this basic level of functionality. Figure 1: A Web services implementation sends and/or receives XML messages

Figure 2 illustrates a common message exchange pattern: request/response. To support the request/response message exchange pattern a Web services implementation provides software agents that function as both senders and receivers. The sender sends an XML message in the form of a request for information or to perform an operation and the receives an XML message that contains the result of the request or operation. The receiver receives the XML request message and sends a response. The request/response pattern is also often called the remote procedure call (RPC) oriented interaction style. Web services architecture does not include the concept of automatically correlating requests and responses, as some RPC oriented technologies do. The correletion of request and reply messages is application-defined. Figure 2: A Web services implementation can be both sender and receiver

Figure 3 illustrates the role of an intermediary in message exchange patterns. An intermediary is by definition both a sender and a receiver. However, an intermediare receievs a message from a sender and forwards it to another receiver. Multiple intermediaries are possible, each one receiving a message from a sender and forwarding it to another receiver, until the ultimate destination of the message is reached. Intermediaries are restricted in their capability to process an XML message, however. Intermediaries are allowed to process a message header information only. When processing a message, intermediaries must not disturb the data content, but may add or remove header content. Figure 3: Web services messaging can include intermediaries

Figure 4 illustrates the concept that a Web services message can include headers that provide associated semantic information for higher level functions such as security, transaction coordination, reliability, and orchestration. The headers carry contextual information such as a security token, transaction identifier, or message destination. Messages are associated with content models (i.e. XML Schemas) that define the meaning, or semantics, of the header information and context data. Figure 4: Web services messages can carry semantic information relevant to their processing

Figure 5 illustrates the concept that intermediaries can process semantic information, potentially removing one or more headers after processing the header or headers and forwarding the message to another receiver (which could also be an intermediary). Intermediaries may also add header information to a message, but cannot disturb message data. Figure 5: Web services intermediaries can process or add semantic information (in headers) relevant to message processin

Figure 6 illustrates the concept that 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. The description is a form of an XML content model describing the message data and header(s). Figure 6: A Web services implementation can provide a service description for a message to be exchanged

Figure 8 illustrates the major components of the Web services architecture in relationship to each other: XML messages, senders, receivers, intermediaries, and header information potentially processed by intermediaries. The illustration includes a representation of persistent data storage systems into and out of which messages are transformed or natively stored. Figure 8: Web services message patterns are constructed out of senders, receivers, intermediaries, and headers

Editorial note  
EN: The above diagram might be the only one really necessary here, the others might be moved to a tutorial if they seem to basic or numerous.

D Architectural Use of Technologies (Non-Normative)

As previously stated, a Web services interaction is two, or more, software agents exchanging information in the form of messages, using a variety of Message Exchange Patterns (MEP). A very common Message Exchange Pattern for Web services is the Request Response MEP. 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. The Web Services Description Language (WSDL) provides a format for defining the allowable formats for messages to and from agents. These include SOAP, XML, MIME, and simple HTTP requests.

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 to have over the concepts and technology in 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.

E Other harvested material (Non-Normative)

Editorial note  
CBF: placeholder. this material needs to be considered and folded in as necessary.


Since REST is so well defined, listing the architectural elements is pretty
easy.  They're already listed here;


Data elements are; resources, resource identifiers, representation,
representation metadata, resource metadata, control data

Components are; origin server, gateway, proxy, user agent

Connectors are; client, server, cache, resolver, tunnel

"features", as I understand what it is that we're mining, are difficult
to extract from an architecture.  But looking at the Web through REST
eyes, I'd say that the following could be considered features, even
though some are also listed above;

- generic interface
- intermediaries
- stateless interaction
- visibility of messages too all components
- caching
- data streams as arguments

E.2 ebXML

In brief: The ebXML suite of specifications enables enterprises to conduct
business over the Internet using a service based architecture. ebXML
(http://www.ebxml.org/ and http://www.oasis-open.org) consists of 5
specifications currently, addressing different aspects of B2B e-commerce
over the Internet: ebXML Message Service (ebMS), ebXML Collaboration
Protocol Profile and Agreement (ebCPPA), ebXML Registry (ebR), ebXML
Business Process Specification Schema (ebBPSS), and ebXML Core Components
(ebCC). Each specification is designed to be implementable independent of
other specification, though appropriate mappings and hooks are provided to
support efficient integration of components built using other ebXML

Components: Party, Role, Service, Actions, Collaboration Protocol Profile
(CPP), Collaboration Protocol Agreement (CPA), Registry, Attachment.

Connectors: Message Service Handler (MSH), Business Service Interface (BSI)

Data Elements: ebXML Message, Business Process Specification, Business
Document, Business Transaction, Binary Collaboration.

There are several name spaces used in all the specifications, and I haven't
pulled them out.

Architectural Concepts: 

    Concept of Operation:  An ebXML Message from a Party A invokes an
Action within a Service at Party B. The message is received and processed by
the MSH at Party B according to a prior agreement  (CPA) between Party A and
Party B. This agreement is a CPA. The agreement between Party A and Party B
may be arrived at by negotiation (ebXML does not specify the details how
this negotiation happens) between them based on the CPP of Party A and CPP
of Party B. The integration of the MSH and the business application
executing at a Party is carried out through a BSI (not fully specified by
ebXML). An ebXML Message may be in a conversation consisting of multiple
messages that implements a Business Transaction. A Business Transaction may
include at a request, and the corresponding response, and acknowledgements
for the request/response. A Binary Collaboration contains an aggregation of
related Business Transactions. A Binary Collaboration and/or CPP may be used
to identify and  implement the Services. Party A and Party B may retrieve a
specified Binary Collaboration and CPPs from Registry. 
    Message based service invocation - ebMS:
-   An MSH is implemented conforming to ebMS. ebMS specifies
peer-to-peer, asynchronous, synchronous, reliable interactions between Party
A and Party B. An ebXML Message extends SOAP 1.1
(http://www.w3.org/TR/2000/NOTE-SOAP-20000508/) for such specification. An
ebXML message can be signed. Signature processing  is specified in ebMS, and
extends  XML Signature (http://www.w3.org/TR/xmldsig-core/). An ebXML
Message may have attachments (per "SOAP with Attachments"
http://www.w3.org/TR/SOAP-attachments) that are Business Documents such as
Purchase Order. These Business Documents may be in EDI, XML, or any other
format. MIME is used to physically package the ebXML Message with the
Attachments. ebMS provides an XML Schema for a ebXML Message. ebMS uses a
CPAId to identify the CPA that governs the ebXML Message reception and

Implementation independent Service specification - ebCPPA:
A CPPA specifies XML Schemas for CPP and CPA, and also guidelines to form a
CPA from two CPPs. The CPP contains elements that specify Roles (e.g.,
Seller, Buyer), Services, Actions, and message attributes  (e.g., number of
retries, time out interval, and so on for reliable messaging, certificates
for trust management). It is possible to derive WSDL from CPP
ex.shtml - see 4th F2f Web Services Zip File).
    Registry : http://www.oasis-open.org/committees/regrep/
    Registry is a registry ("catalog") as well as a repository
("warehouse"). Interfaces to manage the lifecycle of Registry entries and to
support queries on Registry entries are provided. Primarily, a Registry is
intended as a repository of CPPs and public business processes, though
information in any format may be stored in the repository and registered in
the Registry.

ebBPSS: http://www.geocities.com/ebtwg_bp/
ebBPSS is used to specify the externally visible ("public") business process
between Party A and Party B. It provides an XML Schema to specify Binary
Collaboration between Party A and Party B. A Binary Collaboration may
consist of multiple Business Transactions. Each Business Transaction is
specified in terms of Business Envelopes, Business Documents, and Business
Signals that are communicated between Party A and Party B. 

ebCC specifies the semantic elements of a Business Document to eliminate
dependencies on syntax (e.g., EDI) of Business Documents.

Architectural Decisions:
-   Modular specifications: each specification can be independent of
another to facilitate easy adoption
-   The operations described in the "Concept of Operation" earlier are
divided into three phase: Implementation, Discovery, and Run-time. A CPA
formed during the discovery phase is not changed during the execution of
business transactions in run-time phase.
-   Mappings among specifications: Whenever an ebXML specification can
use a component built to another ebXML specification, the necessary mappings
between the specifications are specified.
-   Evolve the current state of the art instead of impose a new
infrastructure - In B2B world EDI is still used heavily, and the best
practices of such usage is used in the design of ebXML.
-   Never reinvent the wheel - use other specifications (use of SOAP 1.1
and XMLDSIG in ebMS, for example) whenever available and appropriate. 

F Web Services Architecture Change Log (Non-Normative)

20021029 CBF tweaked intro per Hugo's suggestion/comment.
20021028 CBF incorporated Jean-Jacques' and Hugo's comments on description. amended status and abstract. some restructuring of the references and appendicies.
20021025 CBF incorporated Heather's description prose. Incorporated Hugo's comments
20021024 CBF incorporated feedback from Joel Munter and some from Jean-Jacques Moreau.
20021022 CBF incorporated revised graphics
20021020 CBF incorporated Eric's section 1.2 updates. Converted to xmlspec-v2.2.
20020720 CBF incorporated SOAP harvest, weaved into the revised flow. added normative biblio.
20020604 DBO Initial Rev