Web Services Architecture

Working Draft @@ @@@ 2002

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

Abstract

This document defines the Web Service Architecture. The 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 document is an editors' copy that has no official standing.

This section describes the status of this document at the time of its publication. Other documents may supersede this document. The latest status of this document series is maintained at the W3C.

This is the second 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.

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 Document Overview
    1.3 Notational Conventions
2 What is a Web service?
3 Architecture Overview
    3.1 Basic Architecture
        3.1.1 agents
        3.1.2 Roles
        3.1.3 Operations
    3.2 Extended Web Services Architecture
        3.2.1 Features
            3.2.1.1 Packaging
            3.2.1.2 Transactions
            3.2.1.3 Publish/Subscribe
            3.2.1.4 Choreography
            3.2.1.5 Semantics
        3.2.2 Infrastructure Services
        3.2.3 Diagrammatic representation of features
        3.2.4 Flows
4 Web Services Stacks
    4.1 Wire "Stack"
        4.1.1 Transport
        4.1.2 Packaging
        4.1.3 Extensions
    4.2 XML Messaging with SOAP
        4.2.1 Interactions
    4.3 Description "Stack"
        4.3.1 Descriptions Applying to a Particular Web Service
            4.3.1.1 Interface
            4.3.1.2 Implementation
            4.3.1.3 Policy
            4.3.1.4 Presentation
        4.3.2 Description for Relationships between Web Services
            4.3.2.1 Composition
            4.3.2.2 Orchestration
            4.3.2.3 Service Level Agreements
            4.3.2.4 Business Level Agreements
    4.4 Discovery Agencies "Stack"
        4.4.1 Service Publication
            4.4.1.1 Producing Service Descriptions
            4.4.1.2 Publishing Service Descriptions
        4.4.2 Service Discovery
            4.4.2.1 Acquiring Service Descriptions
            4.4.2.2 Consuming Service Descriptions
            4.4.2.3 Inspection
    4.5 Overarching Concerns
        4.5.1 Security Concern
        4.5.2 Quality of Service Concern
        4.5.3 Management Concern
            4.5.3.1 Managed Resources
            4.5.3.2 Management
            4.5.3.3 Manageability
            4.5.3.4 Manager Role
            4.5.3.5 Manageable agents
            4.5.3.6 Manageability Information
            4.5.3.7 Access to Manageability Information
            4.5.3.8 Manageability Discovery
            4.5.3.9 Realization in Web Services Architecture
    4.6 The Complete Web Services "Stack"
5 Web Service Architecture
    5.1 Identifiers
    5.2 Formats
        5.2.1 XML Infoset
        5.2.2 XML Schema
        5.2.3 SOAP
            5.2.3.1 SOAP Extensibility
                5.2.3.1.1 SOAP Module
            5.2.3.2 SOAP Protocol Binding Framework
            5.2.3.3 Process Model
        5.2.4 WSDL
            5.2.4.1 WSDL harvesting material
    5.3 Protocols
        5.3.1 HTTP
        5.3.2 Other Protocols
6 Processing Model

Appendices

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

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 defines 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 architecture document identifies the technologies necessary for Web services to be used, described, discovered, how Web services interact with each other (such as long-time conversations, routing, composition, ...), etc. The architecture document delimits the boundaries of each identified functional area, and models the interfaces between them, so that the scope of web services related specifications created to address each piece of functionality is unambiguously defined. The architecture provides a model of the Web services concepts used in various specifications in order to ensure that the specifications actually work together and use the same concepts and terminology. The architecture document provides additional material to the W3C Web Services Architecture Glossary.

The generalized term "Web services" does not currently describe a coherent or necessarily consistent set of technologies, architectures, or even visions. Several streams of thought and practice have converged to produce an amalgam of what we think of as "Web services", including:

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


Service Oriented Architecture

[EN: Here's the proposed new text to position WSA as an SOA -- essentially everything is a service, but often is more than a service]

The Web Services Architecture (WSA) is an instance of a Service Oriented Architecture (SOA) in which services have descriptions and access each other via a transport. A service is executed by an agent when it receives a request to do so, and returns a response if one is defined. The service execution conforms to the interface and semantics (if any) expresssed within its description. A combination of services and requesters comprises a Web services application.

Artifacts of the WSA are modeled either as properties of the transport or of a service. Services are modeled and described as endpoints on a transport that provides access to them. Properties such as security, transactions, discovery, and choreography can be both services and qualities of the architecture. For example, a security service generates and manages security context, but security context propagation is also an attribute of the transport.

Attributes of the transport include such things as reliability, transactions, and security. To the extent that a quality such as reliability in invisible to the Web services application, it is not modeled as a service, but only as an attribute of the transport. However, reliability is a quality that pertains to multiple levels of the system, including the application level. Reliability mechanisms available at the application level are therefore modeled as services.

Services are logical entities, and some of them might be realized as physical instantiations and therefore executable. The architecture does not impose any such requirement on them, and imposes no restriction on how services might be combined.

[EN: This seems like it belongs in the concepts/definitions section]
The minimum definition of a service is a software agent with the following properties:

  • A service name
  • Data types and structures for input and optionally output messages
  • An address in the form of a Web URI

Services are implemented using agents that support Web technologies, minimally including XML and URIs, but optionally including HTTP and RDF. For example:

  • A discovery agent is an instance of a service that can be invoked by a requester to find a service description.
  • A security agent is an instance of a service invoked by a requester to check the authorization of the requester to access another service (or invoked by the target service to check whether the requester is authorized -- this way seems more likely)
  • A choreography is a service invoked by an agent when a series of Web services needs to be executed to return a result (one Web service execution isn't enough).


Contract with the reader

[EN The following is the new contract section:]

The Web Services Architecture (WSA) is an instance of a service-oriented architecture (SOA). The WSA is comprised of a service transport, various services accessible via the transport, descriptions of the services, and qualities and constraints of the transport and services.

[EN: I've got a diagram to propose here, will send separately]

The WSA document presents the architecture as a set of core concepts within specific relationships that determine the core framework or foundation of the architecture. Examples of core concepts include service, transport, message, and description. Qualities, capabilities, and constraints are overlaid atop the core concepts to validate the architecture's suitability for supporting various complex applications of Web services technologies. Examples of qualities, capabilities, and constraints include security, reliability, and consistency with Web architecture.

The WSA is intended to guide Web services product implementers, Web services specification authors, Web services application developers, and Web services students by providing a common definition of a Web service, and defining its place within a larger Web services framework.

The WSA provides a model and a context for understanding Web services, and a context for placing Web services specifications and technologies into relationships with each other and with other technologies outside the WSA. The WSA document lists the major concepts behind Web services, their relationships to each other, and the constraints, qualities, and capabilities of the concepts within the overall WSA.


1.2 Document Overview

This document is intended for a large and diverse audience. Expected readers include users and creators of individual Web Services, Web Service specification authors, and others. It is organized to introduce overview material, followed by normative material.

The first section provides a definition of web services

The next section, Architecture Overview, provides introductory material. It contains a Basic Architecture and an Extended Architecture sections. These sections provide a descriptive overview of the architecture. These sections are written in a free-form text style to provide general.

The next section, Web Service Architecture, provides normative specifications of the architecture. This is a distillation of the architecture overview section with some additional information to provide a normative section. It is written in the W3C Web Architecture style to define the elaborations that the Web Services Architecture provides as part of the web architecture.

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.

Note:

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


[EN: Here's the start of the reworked core concepts section Frank put together, with my annotations]

Concepts and relationships

The architecture is enumerated as a set of concepts and their relationships.

Concepts

The core concepts that form the architecture are laid out in this section.

The ordering of the concepts in this section is alphabetical; this should not be understood to imply any relative importance.

[EN:] Not sure this is correct, but maybe necessary. It would be difficult to decide on an order of importance, and especially if we could only figure out a partial order of importance. The first few would be: service, transport, requester, provider, description... Then what? Context? Security? Choreography?

An agent

Summary

[EN: slight change to wording] An agent is a computational process or execution environment that implements a service.

Relationships to other elements
an agent
has an owner
an agent
has an identifer
an agent
may adopt the role of service provider
an agent
may adopt the role of service requestor
Description

Agents are the computational representatives of business entities and people in the context of Web services.

An actor

Summary

[EN: Added from Roger's email] An actor is a legal entity - such as a person or a corporation - that may be the owner of agents that either seek to use Web services or provide Web services.

Choreography

Summary

Choreographies define how multiple web services are used together, specifying the linkages and usage patterns involved. The linkages between Web Services consist of interactions between those services implemented by sending messages between those Web Services, for example by invoking operations as defined in WSDL

[EN:] A choreography is an instance of a service, executed on request.

Relationships to other elements
a choreography
is a description of how one or more services can be coordinated together to form a coherent whole
a choreography
may be expressed in a choreography description language
Description

A single web service is limited to accepting a request for information or the execution of a process and providing the information or process results in return. Richer functionality can be provided when multiple web services are used together.

A choreography definition describes the sequence and conditions which control how the interactions occur. Successful execution of a choreography should result in the completion of some useful function, for example: the placement of an order, information about its delivery and eventual payment.

[EN for consistency with SOA unifying concept:] Choreographies exist as services accessible via the transport and described to the transport as services, thereby representing aggregates or composites of other services.

Correlation

Summary

Correlation is an activity that uses an identifier for matching messages. A message identifier is a piece of information that is used to establish a relationship between one or more messages. A conversation identifier is used to establish a relationship between one or more parties that may exchange multiple messages.

[EN:] Correlation ensures that the agent requesting a service execution can match the reply with the request, when multiple replies may be possible.

Relationships to other elements
correlation
is a feature
correlation
may be realized by including message identifiers to enable messages to be correlated.
Description

Various requirements and higher-level features identified in this architecture lead to the need for correlation. For example, asynchronous interactions often require higher-level correlation between otherwise distinct messages. One implementation of this concept makes use of message identifiers for correlation itself, allowing a response to be correlated with the original request. The message identifier is an identifier that allows the response to be correlated with the originating request. The sender may also add an identifier for a service, not necessarily the originating sender, who will be the recipient of the message (see asynchronous messaging).

Correlation may be realized by the underlying protocol; it may be realized by an intermediary between the protocol and the application, ie specification of a conversation ID header; or it may be realized by the application. Application uses the identifier directly and it must be passed thru and available to the application. The need for the application to do that depends on how much infrastructure intermediary software is present or not present.

[EN:] Correlation can be a feature of the transport or the application.

Discovery agency

Summary
Relationships to other elements
a discovery agency
is a a searchable set of descriptions
Description

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.

[EN:] A discovery agency is a service accessible via the transport for the purpose of finding a service description when an agent requesting a service execution doesn't have one.

Feature

Summary

A feature is a subset of the architecture that relates to a particular requirement or larger scale property.

Relationships to other elements
a feature is a
related set of concepts
a feature has a
realization
Description

A feature is a subset of the architecture that relates to a particular requirement of the architecture. It may be realized through a number of mechanisms, such as bindings, message exchange patterns or modules.

For example, asynchronous messaging is a potential feature of the architecture. As a result of a message, a service may respond to the requestor or a different party using a separate message channel that the request. The service must know where to send the response(s). This is specified in a service identifier The service identifier can be passed in one of several ways:

[EN:] I'm not sure a feature is a really concept of WSA...?

Identifier

Summary

An identifier is a preferably opaque string of bits that may be used to associate with a resource

Relationships to other elements
an identifier is a
string of bits
an identifier should not have
any externally discernable structure
Description

Identifiers are used to identify resources. In the architecture we use Uniform Resource Identifiers to identify resources.

[EN:] Every service has a unique identifier>

[EN:] Aren't we saying identifiers are URIs? And if so, is this the same as a service name? Or does a service name have both a "human" readable name and a URI?

Message

Summary

A message is the basic unit of interaction with Web services. The architecture defines an interaction between software agents as an exchange of messages.

Relationships to other elements
a message
is a unit of interaction between software agents (EN: services)
a message
may be part of a message exchange pattern
a message
has zero or more message headers
a message
has an message envelope
a message
has a message content

[EN:] Not sure about this wording, since a message is more like the data passed to a service...? Also note the recent discussion on XMLP about what constitutes a message (I guess basically whether or not the header and associated metadata are considered part of the message or not). We can certainly base our definition on their once that's resolved.

Description

A message is defined as a construct that can include zero or more headers, an envelope, data within the envelope and data external to the envelope. 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.

[EN:] Within WSA, a message represents the data structure passed to a service during its request, and received from a service during its response (if any). Messages are defined in service descriptions.

Message Exchange pattern

Summary

A message exchange pattern is a minimal set of messages, together with their sender and receivers, that constitutes a single use of a service.

[EN:] If we define message as the data passed into and received out of a service, then an MEP would be confined to a set of messages, and would not require further definition, would it?

Relationships to other elements
a message exhange pattern
is a set of messages between software agents that corresponds to a single use of a service
a message exhange pattern
is a feature
a message exhange pattern
has a unique identifier
a message exhange pattern
expresses the lifecycle of a message exchange
a message exhange pattern
describes the temporal and causal relationships, if any, of multiple messages exchanged in conformance with the pattern.
a message exhange pattern
describes the normal and abnormal termination of any message exchange conforming to the pattern
Description

A Message Exchange Pattern (MEP) is a template that establishes a pattern for the exchange of messages between agents

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 includes a description; such as the form of the message, data types of elements of the message and message structure information.

The architecture describes Web services support for MEPs that group basic messages into higher-level interactions.

[EN:] I'm not sure an MEP is a core concept, maybe it's more of a quality, capability, or constraint? Also not sure an MEP has an identifier?

Message Header

Summary

A message header is the part of the message that is available to any potential intermediaries and contains information about the message, such as its structure and the identity of the service provider.

[EN:] Not just intermediaries, but also the ultimate receiver.

Relationships to other elements
a message header
is part of a message
a message header
may contain message routing information
a message header
may contain message security information
a message header
may contain message orchestration information
a message header
may contain a transaction context
Description

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.

[EN:] Good question as to whether messages have headers, or whether messages include headers...are headers also maybe an attribute of the transport?

Message description language

Summary
Relationships to other elements
Description

A service

Summary

A service is a set of actions that form a coherent whole from the point of view of a service provider

Relationships to other elements
a service
is a set of actions
a service
hasa service provider
a service
has a service description
a service
has an identifier
a service
has a service semantics
a service
may be invoked by a service requestor
Description

A service is a collection of actions, each action is typically accessed via messages sent from the service requestor to the service provider. A service [does] may have a service description, which includes a description of the messages, their types [the rest optional part of description] any implied ordering of messages and the intended effects of those messages.

[EN:] To me, the basic abstraction of a service is that it includes a service name, the description of the data to be sent to (and optionally received from) the service, and the network location of the service. I am not sure a service includes multiple interfaces, for simplicity I think we have to model them as unique interfaces -- multiple interfaces = multiple services.

A service provider

Summary
Relationships to other elements
a service provider
provides a set of services
a service provider
has a provider name
a service provider
is a role of an agent
Description

From a business perspective, this is the owner of the service. From an architectural perspective, this is the platform [EN: agent?] 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 [EN: are these MEPs defined or part of the architecture?] is that of a server.

[EN:] I think it would definitely simplify things to describe them in terms of SOA, so a service provider is the instance of a service, or the agent that hosts the instance of the service that can be invoked by the requester? more like that...

A Service requestor

Summary

A service requestor is the entity that is responsible for requesting a service from a service provider.

Relationships to other elements
a service requestor
requests a set of services
a service requestor
may have a requestor name
a service requestor
is a role of an agent
Description

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.

[EN:] Also not sure it makes sense to talk about the business perspective here.

Service description

Summary
Relationships to other elements
a service description
is a description of a service
a service description
contains a description of the service's interface
a service description
may contain a description of the service's semantics
a service description
may be published in a discovery agency
a service description
may be retrieved from a discovery agency
a service description
is epxressed in a service description language
Description

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

[EN:] I don't see the difference between description and service description, especially if we move to SOA. Let's combine them.

Service semantics

Summary

The semantics of a service is the contract between the service provider and the service requestor that expresses the effect of invoking the service. A service semantics may be formally described in a machine readable form, identified but not formally defined or informally defined via an `out of band' agreement between the provider and the requestor.

Relationships to other elements
a service semantics
is the contract between the service provider and the service requestor concerning the effects and requirements pertaining to the use of a service
a service semantics
may be identified in a service description
a service semantics
may be expressed in a service description language
a service semantics
is about the intended effects of using a service
a service semantics
is about the requirements for using a service
a service semantics
is about notable events involved in using a service
a service semantics
is about the relationship between the service provider and the service requestor
a service semantics
may identify the quality of service expectations of a service
a service semantics
may contain a description of the message types in a service
Description

Types are not enough to understand the intent and meaning of data. For example, deposit and withdraw from an account typically have the same type signature, but with a different effect. Semantics in web services provide formal documentation of meaning. Contracts describing semantics may be used in other web service features such as choreography.

[EN:] Not sure this is part of the architecture, at least not the core concepts, this seems to be the next level up. I think the core concepts do not include interpreting the content of the message.

Service Description language

Summary

A Service Description language is a language which is used to describe a service.

Relationships to other elements
Description

[EN:] Not sure this is part of the core concepts, other than as an instance of a service description, or as an example implementation of a service description. We could say that service descriptions have a language, but we could also constrain it to a Web language, and that could be an implicit constraint within the Web architecture constraint.

SOAP

Summary

SOAP is a simple and lightweight XML-based mechanism for creating structured data packages that can exchanged between network applications.

Relationships to other elements
SOAP
is a language for expressing the structure of messages
a SOAP package
has an envelope
a SOAP package
has a set of encoding rules for expressing instances of application-defined data types.
a SOAP package
has a convention for representing the exchange of messages and responses.
SOAP
has a set of rules for using SOAP with HTML.
SOAP
may be used with other message delivery protocols.
Description

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.

[EN:] Let's not define SOAP but reference it as an example of a technology that implements messaging.

Transaction

Summary

The fundamental characteristic of a transaction is the ability to join multiple actions into the same unit of work, such that the actions either succeed or fail as a unit. Transaction is a feature of the architecture that supports the coordination of results or operations on state in a multi-step interaction.

Relationships to other elements
a transaction
is a feature

[EN:] Transactions may be a core concept but they also need a service to manage them.

Description

[EN: the following are not really core concepts I don't think -- the first is a key definition, perhaps for the glossary or introduction, and the WSDL definition is again something for use as an example technology not a core part of the architecture.]

A Web service

Summary
Relationships to other elements
a Web service
is a service
a Web service
has an identifier which is in the form of a URI identifier
a Web service
has a description
Description

A Web service is [EN: instantiated or provided via a software agent] a software system identified by a URI, whose public interfaces [EN- delete this: and bindings are defined and] [is] 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. [EN: need to include service accessed via transport upon request, returning any results]

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. [EN: not really sure about this either since these are more along the lines of example technologies.]

WSDL

Summary
Relationships to other elements
Description

Relationships

The relationships between concepts in the architecture are laid out in this section. These relationships represent the core modeling concepts used in the architecture itself.

is a

Summary

The X is a Y relationship denotes the relationship between concepts X and Y, such that every X is also a Y.

Relationships to other elements

Assuming that X is a Y, then:

true of
if P is true of Y then P is true of X
contains
if Y has a P then X has a Q such that Q is a P.
transitive
if U is a X then U is a Y
Description

Essentially, when we say that concept X is a Y we mean that every feature of Y is also a feature of X. Note, however, that since X is presumably a more specific concept than Y, the features of X may also be more specific variants of the features of Y.

For example, in the service concept, we state that every service has an identifier. In the more specific Web service concept, we note that a Web service has an identifier in the form of a URI identifier.

is expressed in

Summary

The concept X is expressed in L relationship denotes that instances of X are values of the language L.

Relationships to other elements

Assuming that X is expressed in L, then:

valid
if E a valid expression in L then E is an instance of concept X
Description

Essentially, when we say that concept X is expressed in L we use the language L to express instances of X.

For example, in the service description concept, we state that service descriptions are expressed in a service description language. That means that we can expect legal expressions of the service description language to be instances of the service description concept.

is realized as

Summary

The concept X is realized as Y relationship denotes that the concept X is an abstraction of, or view of the concept Y. An equivalent view is that the concept X is implemented using Y.

Relationships to other elements

Assuming that X is realized as Y, then:

implemented
if Y is present, or true of a system, then the concept X applies to the system
Description

Essentially, when we say that the concept or feature X is realized as Y we mean that one of implementing concept X is to ensure that the concepts Y are valid.

For example, in the correlation feature, we state that message correlation requires that we associate identifiers with messages. This can be realized in a number of ways — including the identifier in the message header, message body, in a service binding and so on. The message identifier is a key to the realization of message correlation.

[EN: Not sure "relationship" has to be formally defined, might be better to document the rubric as manuals do instead of defining "relationship" as if it were a core architectural concept on a par with service, choreography, and transport.

Also need to:

[EN: Basically delete the following sections in Chapter 3, replacing Chapter 3 with the core concepts.]

3 Architecture Overview

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 architecture. 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. Components and technologies that extend the basic architecture are represented within the extended architecture.

The basic architecture includes Web services technologies capable of:

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 agents performing any of three roles: the service provider, service discovery agency, and service requestor. The interactions involve the publish, find, and bind operations. In a typical scenario a service provider hosts an instance of a network accessible software agent. 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:

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

Basic Web services architecture components are typically defined using applications of XML, 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, an envelope, data within the envelope and data external to the envelope. 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.

The previous figure also 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 provider that contains the result of the request or operation. The service provider receives the request, processes the message and sends a response. The technologies typically used for this type of Web services interaction include SOAP, WSDL, and HTTP.

Note:

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 agents, roles, and operations in Web services architecture.

3.1.2 Roles

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:

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

Here is a partial list of Features:

3.2.1.1 Packaging

For some applications, a purely XML-based representation of the payload is awkward or inefficient. Examples of such cases include payloads which contain binary data, recursively structured envelopes, syntactically ill-formed XML fragments, etc.

The most common packaging tactic in such cases is to introduce a multipart representation which carries the SOAP envelope and its related data (commonly referred to as "attachments"). "SOAP Messages with Attachments", published as a W3C note [http://www.w3.org/TR/SOAP-attachments], is one proposed scheme; "Direct Internet Message Encapsulation (DIME)" [http://www.ietf.org/internet-drafts/draft-nielsen-dime-02.txt] is another. An abstract model for the SOAP 1.2 attachment feature [http://www.w3.org/TR/soap12-af/] specifies how SOAP 1.2 bindings use attachments and how those attachments are referenced from the envelope.

Some of the controversies surrounding the feature include:

3.2.1.2 Transactions

The fundamental characteristic of a transaction is the ability to join multiple actions into the same unit of work, such that the actions either succeed or fail as a unit. A transaction is an infrastructure element that can support the coordination of results or operations on state in a multi-step interaction.

A Web services transaction is generally defined as the ability to join two or more Web services into a transactional unit of work. The transactional unit of work is responsible for ensuring that any state changes performed by participating Web services are either made permanent or undone.

A long running transaction is defined as a special case of a transaction, in which one or more of the joined Web services either depend upon the completion of an external event, or upon the completion of a lengthy interaction. A "normal" transaction can run to completion without external dependencies; a long running transaction may depend upon the completion of an asynchronous event, human intervention, or other time-based activity that must first run to completion on a schedule unrelated to the Web service execution. A motivating factor for this type of transaction might be the multiple calls, long lead times, and cumbersome manual processes typically involved in interacting with numerous parties across the Web.

Long running transactions are implemented using a shared context that tracks the state of the execution. The context remains active until all web services within the transactional unit run to completion. Completion can be successful or unsuccessful, and the result of the overall transactional unit is determined by the success or failure of the individual web services.

The overall result of the transactional unit (i.e. the ultimate disposition of the related state changes) depends upon the results of the participating Web services, interpreted according to a set of predetermined rules. For example, if all participating Web services complete successfully, the transactional unit completes successfully and the state changes are made permanent. If one or more of the participating Web services fails, the transactional unit may also fail and the state changes are undone. Other rules may allow the state changes to be made permanent of undone for a subset of participants.

The state changes can be undone using logging associated with persistent stores or by using compensation actions. Logging mechanisms typically either implement undo or redo algorithms for replacing unmodified data, restoring the state to what it was before the execution of the transaction. Compensation actions typically execute programs that back out the changes by restoring the original values.

Web services can join a transaction by including information that registers them into the same, shared unit of work. If only two Web services are included, they can manage the shared context themselves. If more than two Web services register, an independent coordinator may be needed to track the context and maintain a list of registered Web services (and propagate context).

Two major cases of context management need to be addressed:

  1. Where communication sessions (or conversations) are available to maintain shared state

  2. Where communication sessions (or conversations) are not available to maintain shared state

In the first case, context can be shared using the session or conversation, and multiple Web services can be joined using the shared session of conversation. Automatic recovery may be possible for some actions because it can be triggered on a failure condition for the session (or conversation).

In the second case, context must be maintained in a central place, and information about the completion of the participants must be coordinated. The coordinator responsible for maintaining the context is at the same place where the web service is offered, and to which requests are sent for executing the initial Web service.

A context needs a unique identifier to identify it on the network, and could be a Web resource for example.

A coordinator can be used to track participating web services that register to join a transaction, and coordinators themselves can become participants that represent other web services.

Candidate technologies in this area include BTP, WS-Transactions, WS-Coord, and the OMG Activity Spec.

Editorial note 
EN: Improve definition of long-running transaction. Link the concepts to specific architecture elements, such as SOAP and WSDL. Incorporate the section better into the overall context of transactionality.
3.2.1.4 Choreography

A single web service is limited to accepting a request for information or the execution of a process and providing the information or process results in return. Richer functionality can be provided when multiple web services are used together.

Choreographies define how multiple web services are used together, specifying the linkages and usage patterns involved. The linkages between Web Services consist of interactions between those services implemented by sending messages between those Web Services, for example by invoking operations as defined in WSDL.

A choreography definition describes the sequence and conditions which control how the interactions occur. Successful execution of a choreography should result in the completion of some useful function, for example: the placement of an order, information about its delivery and eventual payment.

Example uses of choreography definitions include:

A standard choreography definition language provides significant benefits:

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.

4 Web Services Stacks


[EN: Is this the place for David Booth's text? Some of the explanation of stacks seems to pertain to MEPs, but others pertains to how discovery works. Perhaps a combination of these two would be a good basis for a chapter. Perhaps push to Chapter 5 to make room for the qualities chapter? Some of the material in this chapter, the "overarching concerns" would be a good fit for the qualities chapter.]

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.

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

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

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.

4.3 Description "Stack"

Description

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.

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

4.3.2 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 ‘agent’, 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.

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

Discovery

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.

4.4.1 Service Publication

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

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?

4.4.2 Service Discovery

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

4.5 Overarching Concerns

Overarching concerns

4.5.1 Security Concern

Editorial note 
CBF: To be further developed...

High-level application interactions may require trust between partners, confidence in the data exchanged, or confidentiality. (The Web services architecture provides support for traditional security artifacts. @@@)

The Web services architecture defines a certain number of roles (@@@ see roles section) and data exchanges (messages, description documents, etc).

First, an agent acting in a defined role and therefore taking part into a Web service interaction may authenticate itself to the other agents it is interacting with.

Second, any interaction may need to be authorized. Authorization can be done in a variety of ways: using a username/password combination, using tokens, etc.

Third, the data exchanged, in the form of a message or any other document (e.g. service description), may have its authorship identified and its integrity guaranteed. Integrity guarantees can be enabled at different layers.

Finally, any of the data used may need to be kept confidential and be accessible only to interested parties. This can be done at the transport layer level, as well as at the message level.

Candidate technologies:

Editorial note 
(@@@ need list to be made more open: non-repudiation, etc.)

4.5.2 Quality of Service Concern

Editorial note 
CBF: To be developed...

@@@

4.5.3 Management Concern

As Web services become pervasive and critical to business operations, the task of managing Web services and the Web services architecture will be imperative to the success of such operations. Management in this case is defined as a set of capabilities for; discovering the existence, availability, health, and usage, as well the control and configuration of resources, where resources are defined as Web services, agents of the Web services architecture, and roles undertaken in the architecture.

4.5.3.4 Manager Role
Manager Role

As a result of these definitions it is useful to introduce the role of the Manager which uses the manageability information provided by the manageable resources. Since, the manager needs to be able to manage all of the agents of the Web services architecture, it needs to be able to ‘discover’ manageable resources and access management information of the resource, as well as utilise the control and configuration mechanisms exposed. The Web service Architecture will define the basic set of management information, and control mechanisms supported by each resource identified in the architecture The definition of the ‘Manager’ role, beyond the information model offered to it and how it interacts with the existing roles of the Web services architecture, is outside the scope of this architecture document, which will neither define how the Manager is implemented or how an implementaion is to use the manageability information.

The management concern is satisfied by defining the architecture necessary to make a Web service architecture implementation and a Web service implementation manageable. This architecture must define the minimum, basic information, metrics, configuration, operations, events, and behaviors that a Web services agent must implement in order to be called a ‘manageable Web services agent’. Not all agents must be manageable. Not all Web services architecture implementations must be manageable. Support of this manageable Web services architecture by implementations of the Web services architeture is higly recommended, but not required.

To summarize, the Web Services Architecture does not specify how management concept should to be implemented and does not prescribe any specific management systems. It defines:

  • Extensible Management Information Schema that directly correlates with the WS Architecture roles

  • Base set of Management Operations/Events (Manageability) that WS Architecture roles need to provide

  • Access to Management Information/Operations/Events (Manageability)

  • Discovery of Access to Management Information

Essentially, it defines an extensible information set and information flow that enable various interested parties to realize management of implementations of Web Services and Web Services Architectures.

4.5.3.9 Realization in Web Services Architecture
Management Pattern

Since the Web services architecture defines how to define information, operations, and notifications through WSDL portTypes, access through bindings, and locateability through ports, it is consistent to use the Web services architecture to describe as well as provide access to and discoverability of the manageable agents of the Web services architecture itself.

A Web service can define its manageability information in a portType and service that is available to the manager or environment. A manageability service WSDL document can be defined that a web service implements to provide access to a web service’s management information by management systems. This interface would include the ability to get configuration and metric data, update configurations, and receive events from manageable web service that the manageability service represents. Other agents of the Web services architecture can provide their own manageability portTypes and ports as well.

The management interface, or service port, of a Web Service, Execution Environment, or Discovery Agency is identified by a URI. This URI will be bound directly to a port type described by WSDL. The WSDL document may contain multiple bindings, including a SOAP over HTTP and an HTTP binding, which allows direct HTTP Get of manageability data items via a URL. The manageability WSDL should be published or advertised to a discovery agency. This provides for the following variation of the Web services oriented architecture triangle:

Editorial note 
This probably should be added to Usage Scenarios doc
Management Use Case

In this scenario we take the Web services architectural triangle, we can decorate it with the artifacts and roles for management activities. In this example we add the following artifacts

  1. A service environment that the service runs in. The service environment is part of the service provider

  2. A management portType for the execution environment which it advertises (grey oval).

  3. Management portTypes for the Discovery Agencies which they advertise (yellow oval).

  4. A management portType for the service which the service provider advertises (green oval)

  5. A business portType and for the service which the service provider advertises

  6. A discovery agency for management portTypes. The management portType is advertised with a different discovery agency than the busines portType. This is for illustration purposes only and certainly the both portTypes could be available from the same discovery agency.

  7. A business service requester (i.e. stockquote requester) which has access to the business operations.

  8. A separate management service requester which has access to the management operations. Certainly, these requesters could be one and the same.

In this scenario, a manageable service is advertised by the service provider in a management discovery agency. The management service requester discovers the existence and interface of a manageable Web service. It then interacts with the management portType to access the management data of the service.

This same scenario works for management requesters who want to interact with the management PortTypes of the discovery agencies and execution environment. The management service requester can discover the managability portType for the discovery agencies, service environment, and service and interace with any of these agent just like the example of their interaction with a service.

This scenario is not meant to be exclusive of all other ways to advertise and pass manageability information to managers.

5 Web Service Architecture


[EN: This seems like a good place to insert the "stakeholders perspective" information Frank developed, meaning once we get through the qualities and the Web services stack, then we can go through the stakeholders' perspective and validate that the requirements are met.]

Stakeholders' viewpoints

In this section we examine how the architecture meets the Web services requirements. We present this as a series of stakeholders' viewpoints; the objective being that, for example, security represents a major stakeholder's viewpoint of the architecture itself.

Editorial note
When developing a particular stakeholder's viewpoint, one should make sure that the concepts discussed are properly documented in the architecture.

Scalability and extensibility

According to the Web services Architecture requirements, it is a major goal of the architecture that any implementations are inherently scalable and extensible.

This goal is broken down into five critical success factors: modularity, extensibility, simplicity, migration from EDI and peer to peer.

Modularity

The critical success factor AC002 focuses on the modularity of the architecture; with appropriate granularity. This is reduced to an overall conceptual integrity with appropriate decomposition and easy comprehension.

Our architecture is laid out using the simple style of concepts and relationships. This modeling technique is simple, and yet allows us to expose the critical properties of Web services. A major design goal of the architecture has been the appropriate separation of concerns. In general, this is achieved by rigorous minimalism associated with each concept: only associating those properties of a concept that are truly necessary to meet the requirements.

The overall themes in this architecture can be summarized as:

Extensibility

Peer to peer interaction

To support Web services interacting in a peer to peer style, the architecture must support peer to peer message exchange patterns, must permit Web services to have persistent identity, must permit descriptions of the capabilities of peers and must support flexibility in the discovery of peers by each other.

In the message exchange pattern concept we allow for Web services to communicate with each other using a very general concept of message exchange. Furthermore, we allow for the fact that a message exchange pattern can itself be identified -- this permits interacting Web service agents to explicitly reference a particular message pattern in their interactions.

A Web service wishing to use a peer-to-peer style interaction may use, for example, a publish-subscribe form of message exchange pattern. This kind of message exchange is just one of the possible message exchange patterns possible when the pattern is explicitly identifiable.

In the agent concept we note that agents have identifiers. The primary role of an agent identifier is to permit long running interactions spanning multiple messages. Much like correlation, an agent's identifier can be used to link messages together. For example, in a publish and subscribe scenario, a publishing Web service may include references to the Web service that requested the subscription, separately from and additionaly to, the actual recipient of the service.

The agent concept also clarifies that a given agent may adopt the role of a service provider and/or a service requestor. I.e., these are roles of an agent, not necessarily intrinsic to the agent itself. Such flexibility is a key part of the peer to peer mode of interaction between Web services.

In the service concept we state that services have a semantics that may be identified in a service description and that may be expressed in a service description language. This identification of the semantics of a service, and for more advanced agents the description of the service contract itself, permits agents implementing Web services to determine the capabilities of other peer agents. This is turn, is a critical success factor in the architecture supporting peer-to-peer interaction of Web services.

Finally, the fact that services have descriptions means that these descriptions may be published in discovery agencies and also retrieved from such agencies. In effect, the availability of explicit descriptions enables Web services and agents to discover each other automatically as well as having these hard-coded.

Long running transactions

In CSF AC017 are identified two requirements that support applications in a similar manner to traditional EDI systems: reliable messaging and support for long-running stateful choreographed interactions. This architecture supports transactions by allowing messages to be part of message exchanges and extended choreographies. It also permits support for message reliability.

Conversations

Conversations are supported in this architecture at two levels: the single use of a Web service and the combination of Web services.

A message exchange pattern is defined to be the set of messages that makes a single use of a service. Typical examples of message exchange pattern are request-response, publish-subscribe and event notification.

The details of the message exchange pattern may be documented in a service description — expressed in a service description language such as WSDL.

In addition, the architecture supports the correlation of messages by permitting messages to have identifiers.

Web services may be combined into larger scale conversations by means of choreographies. A choreography is the documentation of the combination of Web services, leaving out the details of the actual messages involved in each service invokation and focusing on the dependencies between the Web services.

Of particular importance, both to individual message exchange patterns and combined services, is the handling of exceptions.

Message reliability


The Web services architecture consists of:

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

5.2 Formats

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

...

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

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

5.2.3.1 SOAP Extensibility

SOAP provides a simple messaging framework whose core functionality is concerned with providing extensibility. Extensions to the base messaging framework defined by SOAP are modeled and specified as abstract features. Example features include "reliability", "security", "correlation", and "routing". The Web services architecture describes a number of these features (see section 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 5.2.3.3 Process Model).

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.

5.2.3.1.1 SOAP Module

A SOAP Module is a formally specified expression of a SOAP Feature as one or more SOAP header blocks. Refer to the SOAP specification for the detailed requirements of a SOAP Module. A SOAP Module is typically used to express a feature that is not provided for either directly or indirectly through mechanisms of the bound transport, or transfer, protocol. They are also used for the expression of end-to-end SOAP Features that might span multiple, disparate transport, or transfer, protocols as the message is conveyed from original sender to ultimate receiver.

5.2.3.3 Process Model

...

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

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

5.2.4.1 WSDL harvesting material

Overview
WSDL plays a descriptor role in the overall Web Services
architecture.  WSDL is static as it does not define dynamic interactions
between
Web Services.


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

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


Namespaces

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
http://www.w3.org/2002/07/wsdl. 
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
message
format. A message consists of a collection of typed data items. An exchange
of
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
each
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
http://www.w3.org/TR/2002/WD-wsdl12-20020709/#eii-binding
"A binding defines message format and protocol details for operations and
messages defined by a particular portType. There may be any number of
bindings
for a given portType."

WSDL SOAP 1.1 bindings 
http://www.w3.org/TR/2002/WD-wsdl12-bindings-20020709/#_soap-b

"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

http://www.w3.org/TR/2002/WD-wsdl12-bindings-20020709/#_http

"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
http://www.w3.org/TR/2002/WD-wsdl12-bindings-20020709/#_mime
"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

http://www.w3.org/TR/2002/WD-wsdl12-20020709/#language-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
'http://www.w3.org/2002/07/wsdl'"

WSDL issues:

1. Link handling
http://mail.python.org/pipermail/xml-sig/2002-February/007184.html

2. Does not support description of dynamic interactions.
				

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

5.3 Protocols

Now provide description of Web service protocols

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

6 Processing Model

Now provide description of SOAP and WSDL Processing models

				Processing model
----------------
http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#msgexchngmdl
 SOAP provides a distributed processing model that assumes a
 SOAP message originates at an initial SOAP sender and is sent to
 an ultimate SOAP receiver via zero or more SOAP intermediaries.

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#soapnodes
 A SOAP node can be the initial SOAP sender, an ultimate SOAP
 receiver, or a SOAP intermediary.  A SOAP node receiving a SOAP
 message MUST perform processing according to the SOAP processing
 model.

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#soaproles
 In processing a SOAP message, a SOAP node is said to act in one or more
 SOAP roles, each of which is identified by a URI known as the SOAP
 role name.

 This specification defines the following SOAP roles:
  http://www.w3.org/2002/06/soap-envelope/role/next
  http://www.w3.org/2002/06/soap-envelope/role/none
  http://www.w3.org/2002/06/soap-envelope/role/ultimateReceiver

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#targettingblocks
 A SOAP header block MAY carry a role attribute information item that
 is used to target the header block at SOAP nodes operating in the
 specified role.

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#muprocessing
 A SOAP header block is said to be understood by a SOAP node if the
 software at that SOAP node has been written to fully conform to and
 implement the semantics conveyed by the combination of local name and
 namespace name of the outer-most element information item of that
 header block.

 ... for every mandatory SOAP header block targeted to a node, that
 node MUST either process the header block or not process the SOAP
 message at all, and instead generate a fault

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#structinterpbodies
 An ultimate SOAP receiver MUST correctly process the immediate
 children of the SOAP body

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#procsoapmsgs
 Rules for SOAP processing and the kinds of faults that must be
 generated.

http://www.w3.org/TR/2002/WD-soap12-part1-20020626/#envvermodel
 A SOAP Version 1.2 message has a child element information item
 of the document information item with a local name of Envelope and a
 namespace name of "http://www.w3.org/2002/06/soap-envelope".

 If a SOAP node receives a message whose version is not supported it
 MUST generate a fault with a Value of Code set to
 "env:VersionMismatch". Any other malformation of the message
 construct MUST result in the generation of a fault with a
 Value of Code set to "env:Sender".

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

6
Web Services Architecture Charter (See http://www.w3.org/2002/01/ws-arch-charter.)
7
DRAFT: Architecture Principles of the World-Wide Web; Ian Jacobs, 30 August 2002 (See http://www.w3.org/TR/2002/WD-webarch-20020830/.)
8
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/.)
9
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/.)
10
SOAP 1.2 Part 0 (See http://www.w3.org/TR/2002/WD-soap12-part0-20020626/.)
11
SOAP 1.2 Part 0 (See http://www.w3.org/TR/soap12-af.)
12
SOAP Messages with Attachments (See http://www.w3.org/TR/SOAP-attachments.)
13
XML Protocol (SOAP) Requirements (See http://www.w3.org/TR/2001/WD-SOAP-reqs-20010319/#N2082.)
14
XML Protocol Usage Scenarios (See http://www.w3.org/TR/2001/WD-xmlp-scenarios-20011217/.)
15
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/.)
16
Web Services Architecture Requirements Working Draft, eds. D. Austin, A. Barbir, C. Ferris, S. Garg (See http://www.w3.org/tr/wsa-reqs.)
17
Web Services Glossary Working Draft, eds. H. Haas (See http://www.w3.org/tr/ws-gloss.)
18
Web Services Architecture Usage Scenarios Working Draft, eds. H. Haas, D. Orchard (See http://www.w3.org/TR/2002/WD-ws-arch-scenarios-20020730/.)
18
Message Service Specification, ebXML Message Service Specification Version 2.0 (See http://www.ebxml.org/specs/ebMS.pdf.)
19
Web Services Routing Protocol (WS-Routing) (See http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsrvspev/html/ws-routing.asp.)
20
XML Key Management Specification (XKMS 2.0) W3C Working Draft 18 March 2002, eds. Phillip Hallam-Baker, VeriSign (See http://www.w3.org/TR/2002/WD-xkms2-20020318/.)
21
XML-Signature Syntax and Processing, W3C Recommendation 12 February 2002, eds. D. Eastlake, J. R., D. Solo, M. Bartel, J. Boyer , B. Fox , E. Simon. (See http://www.w3.org/TR/2002/REC-xmldsig-core-20020212/.)
22
XML Encryption Syntax and Processing W3C Proposed Recommendation 03 October 2002, eds. D. Eastlake J. Reagle (See http://www.w3.org/TR/2002/PR-xmlenc-core-20021003/.)
23
Web Services Security Specification, Working Draft 03 November 2002 (See http://www.oasis-open.org/committees/wss/documents/WSS-Core-03-1103.pdf.)

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 processing

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.

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

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:
http://www.oasis-open.org/committees/ebxml-msg/
-	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
processing.

Implementation independent Service specification - ebCPPA:
http://www.oasis-open.org/committees/ebxml-cppa/
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
(http://www.oasis-open.org/committees/ebxml-cppa/documents/presentations/ind
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:
http://www.ebtwg.org/projects/documentation/core/CoreComponentsTS1.80.pdf
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)

20021202DBOIncorporated f2f changes from the first morning - use of agents, duplicate diagrams, document overview - and the correlation/reliability feature summary
20021114CBFincorporate MTF overview proposal. merged with daveo's changes based on 11/13/2002 f2f session.
20021029CBFtweaked intro per Hugo's suggestion/comment.
20021028CBFincorporated Jean-Jacques' and Hugo's comments on description. amended status and abstract. some restructuring of the references and appendicies.
20021025CBFincorporated Heather's description prose. Incorporated Hugo's comments
20021024CBFincorporated feedback from Joel Munter and some from Jean-Jacques Moreau.
20021022CBFincorporated revised graphics
20021020CBFincorporated Eric's section 1.2 updates. Converted to xmlspec-v2.2.
20020720CBFincorporated SOAP harvest, weaved into the revised flow. added normative biblio.
20020604DBOInitial Rev