W3C

Web Services Architecture

W3C Working Draft 14 May 2003

This version:
http://www.w3.org/TR/2003/WD-ws-arch-20030514/
Latest version:
http://www.w3.org/TR/ws-arch/
Previous version:
http://www.w3.org/TR/2002/WD-ws-arch-20021114/
Editors:
David Booth, W3C Fellow / Hewlett-Packard <dbooth@w3.org>
Michael Champion, Software AG <Mike.Champion@SoftwareAG-USA.com>
Chris Ferris, IBM <chrisfer@us.ibm.com>
Francis McCabe, Fujitsu Labs of America <fgm@fla.fujitsu.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 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 the Web Services Architecure specification. It has been produced by the W3C Web Services Architecture Working Group, which is part of the W3C Web Services Activity. Significant changes have been made to the structure and content of the document since the last publication. The Working Group expects to republish this document along with a new version of the Web Services Glossary in the near future as a result of its upcoming face-to-face meeting. At this point, the Web Services Architecture Working Group would like to request feedback mainly on the new structure.

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 Purpose of the Web Service Architecture
1.2 Intended Audience
1.3 Document Organization
1.4 Notational Conventions
1.5 What Is a Web Service?
1.5.1 Agents and Services
1.5.2 Requester and Provider
1.5.3 Service Description
1.5.4 Semantics
1.5.5 The Role of Humans
1.6 Architectural Style
1.6.1 Interoperability Architecture
1.6.2 Service Oriented Architecture
1.6.3 SOA and REST archictures
1.7 Web Service Technologies
2 Core Concepts and Relationships
2.1 Introduction
2.2 Alphabetical List of Core Concepts
2.2.1 Agent
2.2.1.1 Summary
2.2.1.2 Relationships to other elements
2.2.1.3 Description
2.2.2 Authentication
2.2.2.1 Summary
2.2.2.2 Relationships to other elements
2.2.2.3 Description
2.2.3 Choreography
2.2.3.1 Summary
2.2.3.2 Relationships to other elements
2.2.3.3 Description
2.2.4 Choreography Description Language
2.2.4.1 Summary
2.2.4.2 Relationships to other elements
2.2.4.3 Description
2.2.5 Correlation
2.2.5.1 Summary
2.2.5.2 Relationships to other elements
2.2.5.3 Description
2.2.6 Deployed element
2.2.6.1 Summary
2.2.6.2 Relationships to other elements
2.2.6.3 Description
2.2.7 Discovery
2.2.7.1 Summary
2.2.7.2 Relationships to other elements
2.2.7.3 Description
2.2.8 Discovery Service
2.2.8.1 Summary
2.2.8.2 Relationships to other elements
2.2.8.3 Description
2.2.9 Feature
2.2.9.1 Summary
2.2.9.2 Relationships to other elements
2.2.9.3 Description
2.2.10 Identifier
2.2.10.1 Summary
2.2.10.2 Relationships to other elements
2.2.10.3 Description
2.2.11 Intermediary
2.2.11.1 Summary
2.2.11.2 Relationships to other elements
2.2.11.3 Description
2.2.12 Legal Entity
2.2.12.1 Summary
2.2.12.2 Relationships to other elements
2.2.12.3 Description
2.2.13 Life cycle
2.2.13.1 Summary
2.2.13.2 Relationship to other elements
2.2.13.3 Description
2.2.14 Management capability
2.2.14.1 Summary
2.2.14.2 Relationship to other elements
2.2.14.3 Description
2.2.15 Management configuration
2.2.15.1 Summary
2.2.15.2 Relationship to other elements
2.2.15.3 Description
2.2.16 Management event
2.2.16.1 Summary
2.2.16.2 Relationship to other elements
2.2.16.3 Description
2.2.17 Manager
2.2.17.1 Summary
2.2.17.2 Relationship to other elements
2.2.17.3 Description
2.2.18 Manageable Element
2.2.18.1 Summary
2.2.18.2 Relationships to other elements
2.2.18.3 Description
2.2.19 Manageability Interface
2.2.19.1 Summary
2.2.19.2 Relationships to other elements
2.2.20 Management metric
2.2.20.1 Summary
2.2.20.2 Relationship to other elements
2.2.20.3 Description
2.2.21 Message
2.2.21.1 Summary
2.2.21.2 Relationships to other elements
2.2.21.3 Description
2.2.22 Message Exchange Pattern (MEP)
2.2.22.1 Summary
2.2.22.2 Relationships to other elements
2.2.22.3 Description
2.2.23 Message Header
2.2.23.1 Summary
2.2.23.2 Relationships to other elements
2.2.23.3 Description
2.2.24 Message description language
2.2.24.1 Summary
2.2.24.2 Relationships to other elements
2.2.24.3 Description
2.2.25 Message Identifier
2.2.25.1 Summary
2.2.25.2 Relationships to other elements
2.2.25.3 Description
2.2.26 Message recipient
2.2.26.1 Summary
2.2.26.2 Relationships to other elements
2.2.26.3 Description
2.2.27 Message sender
2.2.27.1 Summary
2.2.27.2 Relationships to other elements
2.2.27.3 Description
2.2.28 Reliable messaging
2.2.28.1 Summary
2.2.28.2 Relationships to other elements
2.2.28.3 Description
2.2.29 Representation
2.2.29.1 Summary
2.2.29.2 Relationships to other elements
2.2.29.3 Description
2.2.30 Resource
2.2.30.1 Summary
2.2.30.2 Relationships to other elements
2.2.30.3 Description
2.2.31 Service
2.2.31.1 Summary
2.2.31.2 Relationships to other elements
2.2.31.3 Description
2.2.32 Service description
2.2.32.1 Summary
2.2.32.2 Relationships to other elements
2.2.32.3 Description
2.2.33 Service provider
2.2.33.1 Summary
2.2.33.2 Relationships to other elements
2.2.33.3 Description
2.2.34 Service requester
2.2.34.1 Summary
2.2.34.2 Relationships to other elements
2.2.34.3 Description
2.2.35 Service semantics
2.2.35.1 Summary
2.2.35.2 Relationships to other elements
2.2.35.3 Description
2.2.36 Service Task
2.2.36.1 Summary
2.2.36.2 Relationships to other elements
2.2.36.3 Description
2.2.37 SOAP
2.2.37.1 Summary
2.2.37.2 Relationships to other elements
2.2.37.3 Description
2.2.38 WSDL
2.2.38.1 Summary
2.2.38.2 Relationships to other elements
2.2.38.3 Description
2.3 Relationships
2.3.1 The is a relationship
2.3.1.1 Summary
2.3.1.2 Relationships to other elements
2.3.1.3 Description
2.3.2 The describes relationship
2.3.2.1 Summary
2.3.2.2 Relationships to other elements
2.3.2.3 Description
2.3.3 The is expressed in relationship
2.3.3.1 Summary
2.3.3.2 Relationships to other elements
2.3.3.3 Description
2.3.4 The has a relationship
2.3.4.1 Summary
2.3.4.2 Relationships to other elements
2.3.4.3 Description
2.3.5 The realized relationship
2.3.5.1 Summary
2.3.5.2 Relationships to other elements
2.3.5.3 Description
3 Stakeholder's perspectives
3.1 Web integration
3.2 Information and service
3.3 Web service agents
3.4 Web Service Discovery
3.4.1 Scenarios Not Requiring Discovery
3.4.2 Scenarios Requiring Discovery
3.4.2.1 Human Discovery
3.4.2.2 Autonomous Selection
3.5 Web service semantics
3.6 Web services security
3.7 Scalability and extensibility
3.8 Modularity
3.9 Extensibility
3.10 Peer to peer interaction
3.11 Long running transactions
3.12 Conversations
3.13 Message reliability
3.14 Web service manageability
4 Constraints
4.1 Formats
4.1.1 XML Infoset
4.1.2 XML Schema

Appendices

A Acknowledgments (Non-Normative)
B References (Non-Normative)
B.1 Normative References
B.2 Informative References
C Architectural Use of Technologies (Non-Normative)
D Web Services Architecture Change Log (Non-Normative)


1 Introduction

[dbooth editing this section. The previous "Contract with the Reader" has been merged into this section.]

1.1 Purpose of the Web Service Architecture

Web services provide a standard means of interoperating between different software applications, running on a variety of platforms and/or frameworks. The Web service architecture (WSA) is intended to provide a common definition of a Web service, and define its place within a larger Web services framework to guide Web services product implementers, Web services specification authors, Web services application developers, and Web services students.

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 promotes interoperability through the definition of compatible protocols. The architecture does not impose any requirements on the implementation of services, and imposes no restriction on how services might be combined. The WSA describes both the minimal characteristics that are common to all Web services, and a number of characteristics that are needed by many, but not all, Web services.

1.2 Intended Audience

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.

1.3 Document Organization

This document provides introductory overview material followed by normative material.

The body of the architecture is presented as a set of core concepts and key relationships between them. A core concept is usually a noun, but does not have to be, and the relationships between conncepts are usually predicates, i.e., verbs. Both noun-style and verb-style concepts are present in the architecture, the latter playing a prominent role in the relationships between concepts.

A primary goal of the concepts section is to provide a basis for measuring conformance to the architecture. For example, the resource concept states that resources have identifiers (in fact they have URIs). Using this assertion as a basis, we can measure conformance to the architecture of a particular resource by looking for its identifier. If, in a given instance of this architecture, a resource has no identifier, then it is not a valid instance of the architecture.

While the concepts and relationships represent an enumeration of the architecture, the stakeholders' viewpoints approaches from a different perspective: how the architecture meets the goals and requirements. In this section we elucidate the more global properties of the architecture and demonstrate how the concepts actually achieve important objectives.

A primary goal of the Stakeholder's Perspectives section is to relate the actual architecture with the requirements of the architecture, especially as outlined in the Web services requirements document.

For example, in the 3.14 Web service manageability section we show how the management of Web services is modeled within the architecture. The aim here is to demonstrate that Web services are manageable and which key concepts and features of the architecture achieve that goal. In this case, manageability is realized by showing a link between the concept of a physically deployed resource and the abstract concept it realizes (such as a Web service). Management of such deployed resources then leads to management of Web services themselves.

The key stakeholder's viewpoints supported in this document reflect the major goals of the architecture itself: interopability, extensibility, security, Web integration, implementation and manageability.

Where appropriate, the WSA also identifies candidate technologies that have been determined to meet the functionality requirements defined within the architecture.

1.4 Notational Conventions

The key words "MUST", "MUST NOT", "REQUIRED", "SHALL", "SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY", and "OPTIONAL" in this document are to be interpreted as described in RFC 2119.

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

[dbooth: Two problems with this definition: (1) What are "bindings"? (We haven't defined them.) Why are they relevant to the definition of a Web service? I think we could just omit "and bindings" from the definition. (2) Does a WS really need to have a "discoverable" WSD in order to be a WS? A WS certainly could have a private WSD or a WSD that is developed collaboratively rather than being "discovered". Also, it seems odd to define something X based on the existence of something else Y that is not a part of X. I suggest instead: "A Web service is a software system identified by a URI, whose public interfaces are defined and described using XML. Other systems may 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 architecture described in this document.

1.5.1 Agents and Services

A Web service is viewed as an abstract notion that must be implemented by a concrete agent. (See Figure 1.) The agent is the physical entity (a piece of software) that sends and receives messages, while the service is the abstract set of functionality that is provided. To illustrate this distinction, you might implement a particular Web service using one agent one day (perhaps written in one programming language), and a different agent the next day (perhaps written in a different programming language). Although the agent may have changed, the Web service remains the same.

1.5.2 Requester and Provider

The purpose of a Web service is to provide some functionality on behalf of its owner -- a legal entity, such as a business or an individual. The provider entity is the legal entity that provides an appropriate agent to implement a particular service. (See Figure 1: Basic Architectural Roles.)

A requester entity is a legal entity that wishes to make use of a provider entity's Web service. It will use a requester agent to exchange messages with the provider entity's provider agent. In order for this message exchange to be successful, the requester entity and the provider entity must first agree on both the semantics and the mechanics of the message exchange.

1.5.3 Service Description

The mechanics of the message exchange are (partially) documented in a Web service description (WSD). (See Figure 1.) The service description is a machine processable specification of the message formats, datatypes and protocols that should be used between the requester agent and the provider agent. It also specifies the network location of the provider agent, and may provide some information about the message exchange pattern that is expected.

1.5.4 Semantics

The semantics ("Sem" in Figure 1) of the message exchange represents the "contract" between the requester entity and the provider entity regarding the purpose and consequences of the interaction. It also includes any additional details on the mechanics of the message exchange that are not specified in the service description. Although this "contract" represents the overall agreement between the requester entity and the provider entity on how and why their respective agents will interact, it is not necessarily written or explicitly negotiated. It may be explicit or implicit, oral or written, machine processable or human oriented.

While the service description represents a "contract" governing the mechanics of interacting with a particular service, the semantics represents a "contract" governing the meaning and purpose of that interaction.

1.5.5 The Role of Humans

Although one of the main purposes of Web services is to automate processes that might otherwise be performed manually, humans still play a role in their architecture and use, notably in two ways:

  1. Humans need to agree on the semantics and the service description. Since a human (or organization) ultimately is the legal owner of any Web service, people must either implicitly or explicitly agree on the semantics and the service description that will govern the interaction.

    Often this agreement will be accomplished by the provider entitity publicizing and offering both the semantics and the service description as take-it-or-leave-it "contracts" that the requester entity must accept unmodified as conditions of use. However, nothing in this architecture prevents them from reaching agreement by other means. For example, in some situations, the service description (excepting the network address of the service) may be defined by an industry organization, and shared by many requester and provider entities. In other situations, it may originate from the requester entity (even if it is written from provider entity's perspective).

  2. Humans create the requester and provider agents (either directly or indirectly). Ultimately, humans must ensure that these agents implement the terms of the agreed-upon service description and semantics. There are many ways this can be achieved, and this architecture does not specify or care what means are used. For example:

    • an agent could be hard coded to implement a particular, fixed service description and semantics;

    • an agent could be coded in a more general way, and the desired service description and/or semantics could be input dynamically; or

    • an agent could be created first, and the service description and/or semantics could be produced from the agent code.

    Regardless of the approach used, from an information perspective both the semantics and the service description must be somehow be input to, or embodied in, both the requester agent and the provider agent before the two agents can interact.

Figure 1: Basic Architectural Roles.

[dbooth: Not sure how we should label the figures. Also, Figure 1 may need to be resized.]

Basic architecture roles

1.6 Architectural Style

1.6.1 Interoperability Architecture

The Web services architecture is an interoperability architecture — it identifies those global elements of the global Web services network that are required in order to ensure interoperability between Web services. It is not intended to be an architecture for individual Web services; the structure and implementation of these is inherently private and is left to the discretion of the developers of these. However, in order to ensure interoperability, certain concepts, relationships and constraints are important; and this architecture identifies those.

The major goals of the architecture are outlined in the Web Services Architecture Requirements document. These goals are to promote

  • interoperability between Web services,

  • integration with the World Wide Web,

  • reliability of Web services,

  • security of Web services,

  • Scalability and extensibility of Web services, and

  • Manageability of Web services.

The role of this architecture is to provide a global perspective on the networked service architecture. Other specifications, such as SOAP 1.2 and WSDL give detailed recommendations for specific requirements. This architecture is intended to show how these, and other related, technologies fit together to deliver the benefits of Web services.

Some non-goals of the architecture include:

  • to prescribe a specific programming model or programming technology

  • to constrain the internal architecture and implementation of specific Web services

  • to demonstrate how Web services are constructed

  • to be specific about how messages or other descriptions are formatted

  • to determine specific technologies for messaging, discovery, choreography etc.

1.6.2 Service Oriented Architecture

The Web architecture and the Web services Architecture (WSA) are instances of a Service Oriented Architecture (SOA). To understand how they relate to each other and to closely related technologies such as CORBA, it may be useful to look up yet another level and note that SOA is in turn a type of Distributed System. A distributed system, consists of discrete software agents that must work together to implement some intended functionality. Furthermore, the agents in a distibuted system do not operate in the same processing environment, so they must communicate by hardware/software protocol stacks that are intrinsically less reliable than direct code invocation and shared memory. This has important architectural implications because distributed systems require that developers (of infrastructure and applications) consider the unpredictable latency of remote access, and take into account issues of concurrency and the possibility of partial failure. [Samuel C. Kendall, Jim Waldo, Ann Wollrath and Geoff Wyant, "A Note On Distributed Computing"].

An SOA is a specific type of distributed system in which the agents are "services" For the purposes of this document, a service is a software agent that performs some well-defined operation (i.e., "provides a service") and can be invoked outside of the context of a larger application. That is, while a service might be implemented by exposing a feature of a larger application (e.g., the purchase order processing capability of an enterprise resource planning system might be exposed as a discrete service), the users of that server need be concerned only with the interface description of the service. Furthermore, most definitions of SOA stress that "services" have a network-addressable interface and communicate via standard protocols and data formats.

Figure 2, Generic Service Oriented Architecture Diagram Services interacting over transports through interfaces defined by service descriptions.

The description of a service in a SOA is essentially a description of the messages that are exchanged. This architecture adds the constraint of stateless connections, that is where the all the data for a given request must be in the request.

Editorial note
Put in a good word about the Semantic web and semantics in general here

In essence, the key components of a Service Oriented Architecture are the messages that are exchanged, agents that act as service requesters and service providers, and shared transport mechanisms that allow the flow of messages. In addition, in public SOAs, we include the public descriptions of these components: descriptions of the messages, descriptions of the services and so on. These descriptions may be machine processable, in which case they become potential messages themselves: for use in service discovery systems and in service management systems.

1.6.3 SOA and REST archictures

The World Wide Web is a SOA that operates as a networked information system that imposes some additional constraints: Agents identify objects in the system, called "resources," with Uniform Resource Identifiers (URIs). Agents represent, describe, and communicate resource state via "representations" of the resource in a variety of widely-understood data formats (e.g. XML, HTML, CSS, JPEG, PDF ). Agents exchange representations via protocols that use URIs to identify and directly or indirectly address the agents and resources. [W3C Technical Architecture Group, "Architecture of the World Wide Web"]

An even more constrained architectural style for reliable Web applications known as "Representation State Transfer" or REST has been proposed by Roy Fielding and has inspired both the TAG's Architecture document and many who see it as a model for how to build web services ["Architectural Styles and the Design of Network-based Software Architectures" ]. The REST Web is the subset of the WWW in which agents are constrained to, amongst other things, expose and use services via uniform interface semantics, manipulate resources only by the exchange of "representations", and thus use "hypermedia as the engine of application state."

The scope of "Web services" as that term is used by this working group is somewhat different. It encompasses not only the Web and REST Web services whose purpose is to create, retrieve, update, and delete information resources but extends the scope to consider services that perform an arbitrarily complex set of operations on resources that may not be "on the Web." Although the distrinctions here are murky and controversial, a "Web service" invocation may lead to services being performed by people, physical objects being moved around (e.g. books delivered).

We can identify two major classes of "Web services": REST-compliant or "direct resource manipulation" services in which in which the primary purpose of the service is to manipulate XML representations of Web resources using the a minimal, uniform set of operations operations, and "distributed object" or "Web-mediated operation" services in which the primary purpose of the service is to perform an arbitrarily complex set of operations on resources that may not be "on the Web", and the XML messages contain the data needed to invoke those operations. In other words, "direct" services are implemented by web servers that manipulate data directly, and "mediated" services are external code resources that are invoked via messages to web servers.

Editorial note
Lots of open terminology issues here, such as what we call these two types of services, and whether the "web service" is the interface to the external code or the external code itself.

Both classes of "Web services" use URIs to identify resources and use Web protocols and XML data formats for messaging. Where they fundamentally differ is that "distributed object" (editors' note: or "mediated services") use application specific vocabularies as the engine of application state, rather than hypermedia. Also, they achieve some of their benefits in a somewhat different way. The emphasis on messages, rather than on the actions that are caused by messages, means that SOAs have good "visibility": trusted third parties may inspect the flow of messages and have a good assurance as to the services being invoked and the roles of the various parties. This, in turn, means that intermediaries, such as fire- walls, are in a better situation for performing their functions. A fire- wall can look at the message traffic, and at the structure of the message, and make predictable and reasonable decisions about security.

In REST-compliant SOAs, the visibility comes from the uniform interface semantics, essentially those of the HTTP protocol: an intermediary can inspect the URI of the resource being manipulated, the TCP/IP address of the requester, and the interface operation requested (e.g. GET, PUT, DELETE) and determine whether the requested operation should be performed. The TCP/IP and HTTP protocols have a widely supported set of conventions (e.g. known ports) to support intermediaries, and firewalls, proxies, caches, etc. are almost universal today. In non-REST [Ed. note: or "distributed object" or "mediated" ] but XML-based services, the visibility comes from the fact that XML is the universal meta-format for the data. Intermediaries can be programmed or configured to use the specifics of the SOAP XML format, standardized SOAP headers (e.g. for encryption, digital signature exchange, access control, etc.), or even generic XPath expressions to make routing, filtering, and cacheing decisions. XML-aware firewall and other "edge appliance" products are just coming to market as of this writing.

1.7 Web Service Technologies

Web service architecture involves many layered and interrelated technologies. There are many ways to visualize these technologies, just as there are many ways to build and use Web services. Figure 3 provides one illustration of some of these technology families.

Figure 3: Stack Diagram.Technology Layers (Stack Diagram)

Marketing documents from Web services vendors often contain a three-part diagram to show how the different Web services "standards" relate to one another: WSDL describes the format SOAP messages, and UDDI serves as a discovery service for the WSDL descriptions. The problem with such diagrams is that they don't convey the multiple dimensions of the Web services standards "space" and can't easily be extended to handle new standards, e.g. for security, management, choreography, and so on. In order to show the big picture of the Web services architecture as we envision it, the picture needs to be somewhat more complex.

First and foremost, XML is the "backplane" of the WSA. One can imagine Web services that don't depend on the SOAP envelope framework or processing model, or that don't employ WSDL to describe the interaction between a service and its consumers, but XML is much more fundamental. It provides the extensibility and vendor, platform, and language neutrality that is the key to loosely-coupled, standards-based interoperability that are the essence of the Web services value proposition. Furthermore, XML helps blur the distinction between "payload" data and "protocol" data, allowing easier mapping and bridging across different communications protocols, which is necessary in many enterprise IT infrastructures that are built on industrial-strength but proprietary components. Thus, the "base technology" of the WSA consists of some key XML specifications, including XML 1.x, XML Schema Description Language and the xml:base specification. Note that we do not rely on all XML technologies; for example, we do not rely on XML DTDs, in the architecture.

This leads to the next key concept in the WSA: services are invoked and provide results via messages that must be exchanged over some communications medium. The WSA encompasses a wide, almost infinite variety of communications mechanisms: HTTP (the dominant protocol of "the Web"), other internet protocols such as SMTP and FTP, generic interface APIs such as JMS, earlier distributed object protocols such as IIOP, and so on. In principle, Web services invocation and result messages could be passed around by "sneakernet", RFC 1149-compliant carrier pigeons, or mechanisms that have not yet been invented. WSA says almost nothing about this communication layer other than it exists -- it does not specificy that it be at any particular level of the OSI reference architecture protocol stack, and allows Web services messages to be "tunnelled" over protocols designed for another purpose.

WSA does have quite a bit to say about the messages themselves, if not about the mechanism by which they are communicated. SOAP is the key messaging technology in the WSA: While very simple information transfer services can be implemented without SOAP, secure, reliable, multi-part, multi-party and/or multi-network applications are much easier to build if there is a standard way of packaging the messaging information in a protocol neutral way. This also allows the messaging infrastructure (which may be specialized hardware, SOAP intermediaries, or code libraries called by the ultimate recipient of a SOAP message) to provide authentication, encryption, access control, transaction processing, routing, delivery confirmation, etc. services. SOAP's envelope (and attachment) structure and header / processing model have proven to be a very robust and powerful framework within which to do this.

Interoperability across heterogenous systems requires a mechanism to allow the precise structure and data types of the messages to be commonly understood by Web services producers and consumers. WSDL is an obvious choice today as the means by which the precise description of Web services messages can be exchanged.

Editorial note
Obviously we have open issues with respect to whether description mechanisms such as shared code "qualify" here.

In the future, more sophisticated description languages that handle more of the *semantic* content of the messages are likely to become technologically viable, and such languages (perhaps based on RDF and OWL) will fit well in the WSA framework.

Beyond the description of individual messages such as WSDL provides, the WSA envisions a variety process descriptions: the process of discovering service descriptions that meet specified criteria, the process of describing multi-part and stateful sequences of messages, the aggregation of processes into higher-level processes, and so on. This area is much much clearly defined than other parts of the WSA, but there is much work going on and the WSA incorporates them at an abstract level.

In addition to specific messaging and description technologies, the architecture also provides for security and management. These are complex areas that touch on many of the different levels and technologies deployed in the service of Web services.

2 Core Concepts and Relationships

2.1 Introduction

The formal core of the architecture is this enumeration of the core concepts and relationships that are central to Web services' interoperability.

Each concept is presented in a stylized regular way: consisting of a short summary, an enumeration of the relationships with other concepts, and a slightly longer description. For example, the concept for agent includes as relating concepts the fact that an agent is a computational resource, has an identifier and an owner. The description part of the agent explains in more detail why agents are important to the archicture.

The ordering of the concepts in this section is alphabetical; this should not be understood to imply any relative importance. For a more focused viewpoint the reader is directed to the Stakeholder's perspectives section which examines the architecture from the perspective of key stakeholders of the architecture.

The reason for choosing an alphabetical ordering is that, inevitably, there is a large amount of cross-referencing between the concepts. As a result, it is very difficult, if not misleading, to choose a non-alphabetic ordering that reflects some sense of priority between the concepts. Furthermore, the `optimal ordering' depends very much on the point of view of the reader. Hence, we devote the Stakeholders perspectives section to a number of prioriterized readings of the architecture.

A primary function of this section is to give guidance as to conformance to the architecture. For example, the architecture notes that a message is a unit of interaction between software agents. This means that the architecture is not concerned about messages between objects that are within an implementation of a Web service. We also state that messages have a message sender; any realization of this architecture that does not permit a message to be associated with its sender is not in conformance with the architecture.

Unlike language specifications, or protocol specifications, conformance to an architecture is necessarily a somewhat imprecise art. However, the presence of a concept in this enumeration is a strong hint that, in any realization of the architecture, there should be a corresponding feature in the implementation. Furthermore, if a relationship is identified here, then there should be corresponding relationships in any realized architecture. The absence of such a concrete feature may not prevent interoperability; but it will certainly make such interoperability more difficult.

Figure 4, below, illustrates graphically many of the concepts and relationships enumerated below. This diagram will hopefully aid the reader in traversing the concepts and relationships' enumeration.

[Figure 4: Core Concepts and Relationships] Core concepts and relationships

2.2 Alphabetical List of Core Concepts

The architecture is enumerated as a set of conceptsand their relationships.

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

2.2.1 Agent

2.2.1.1 Summary

An agent is a program acting on behalf of another person, entity, or process [Web Arch].

2.2.1.2 Relationships to other elements
An agent is

a computational resource

An agent has

an identifier

An agent has

an owner that is a legal entity

An agent may provide

one or more services

An agent may request

zero or more services

2.2.1.3 Description

Agents are programs that engage in some set of actions as representatives of other entities. On the Web, for example, agents can seek information. Agents implement services.

Agents are the computational representatives of legal entities. This architecture specifically eschews any attempt to govern the implementation of agents; it is only concerned with ensuring interopability between systems.

2.2.2 Authentication

2.2.2.1 Summary

Authentication is the process of verifying that a potential partner in a conversation is capable of representing a principal or legal entity

2.2.2.2 Relationships to other elements
Authentication is

a feature of the architecture

Authentication may be realized

using a security authority

2.2.2.3 Description

2.2.3 Choreography

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

2.2.3.2 Relationships to other elements
A choreography is

the pattern of possible interactions between a set of services

A choreography may be expressed in

a choreography description language

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

Defining the possible patterns of interactions between services does not itself construe a composite service; however, a composite service requires a definition in terms of the choreography of a set of services.

A choreography is not to be confused with orchestration. Orchestration is a technique for realizing choreographies, but is not the only such method.

2.2.4 Choreography Description Language

2.2.4.1 Summary

A Choreography Description Language is a notation for describing the higher levels of interaction between a group of services. It may also permit the specification of a composite service in terms of component services.

2.2.4.2 Relationships to other elements
A choreography Description Language describes

the pattern of possible interactions between a set of services

A choreography Description Language may describe

the life cycle of a service invocation

A choreography Description Language describes

the conversations possible between service requesters and service providers.

2.2.4.3 Description

A Choreography description language is focussed on enabling the description of how to interact with services at a larger scale than the individual message exchange pattern. It permits the description of how Web services can be composed, how roles and associations in Web services can be established, and how the state, if any, of composed services is to be managed.

2.2.5 Correlation

2.2.5.1 Summary

Correlation [n.] is the association of matching messages. Correlation ensures that the agent requesting a service execution can match the reply with the request, especially when multiple replies may be possible.

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.

2.2.5.2 Relationships to other elements
Correlation is

a feature

Correlation is

a means of associating a message in a specific conversational context.

Message correlation may be realized

by including message identifiers to enable messagesto be identified.

2.2.5.3 Description

Correlation, specifically message correlation, refers to the ability to identify a given message as being the message for a particular purpose. In a conversation, it is important to be able to determine that an actual message that has been received is the expected message. Often this is implicit when conversations are relayed over stream-oriented message transports; but not all transports allow correlation to be established so implicitly.

For situations where correlation must be handled explicitly, one technique is to associate a message identifier with messages. The message identifier is an identifier that allows a received message 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 through 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.

2.2.6 Deployed element

2.2.6.1 Summary

A deployed resource is a resource that exists in the physical world. There are many kinds of deployed elements, including agents, services and descriptions.

2.2.6.2 Relationships to other elements
A deployed element is

a physically existing resource

A deployed element has

an owner

A deployed element has

a physical location, such as a file in a computer or a process executing on a computer.

A deployed element may realize

a service

A deployed element may be

a service description

A deployed element may be

a managed element

2.2.6.3 Description

Deployed elements are resources that exist physically and are potentially manageable. They are the realization of other elements of this architecture — the services, the agents and the descriptions that form the logical aspect of this architecture.

Deployed elements have locations and a physical presence in the real world — for example, as a set of files on a disk, or an executing process on a computer.

Deployed elements are the unit of manageability; they have owners and may have other properties that are subject to management.

2.2.7 Discovery

[dbooth should edit this one]

[EN: The diagram does not include this concept, maybe point to David Booth's text, instead of defining it here? Do we really need to define the act of discovery as a core concept, when we are defining registry and description as core concepts?]

2.2.7.1 Summary

Discovery is the act of locating a machine-processable description of a Web service that may have been previously unknown and that meets certain functional criteria. [17]

2.2.7.2 Relationships to other elements

discovery

is an abstract process

discovery

may be initiated by an end user or an agent

discovery

may be realizedas a discovery service

discovery

may be realizedas a direct interaction between service requesterand service provider

discovery

has inputs a set of functional criteria

discovery

has outputs a set of service descriptions that match the inputs

2.2.7.3 Description

There are varius means by which discovery can be performed. Various entities, e.g. human end users or agents may initiate discovery. Service requesters 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 requesters, using service discovery is optional, as a service provider can send the description directly to service requesters. Likewise, service requesters can obtain a service description from other sources besides a service registry, such as a local file system, FTP site, URL, or WSIL document.

2.2.8 Discovery Service

2.2.8.1 Summary

A discovery service is a service that performs discovery; of particular interest are discovery services that permit the discovery of Web services.

2.2.8.2 Relationships to other elements
A discovery service is

a service

A discovery service is used to

publish service descriptions

A discovery service is used to

search for service descriptions

A discovery service may be accessed

automatically or under human guidance

2.2.8.3 Description

A discovery service is used by agents and service owners to publish and search for service descriptions.

The discovery of a service takes place at different times in the overall life-cycle of a service. At one extreme, discovery is vestigial as a new service may be built directly in terms of an existing service; at the other extreme, a service requester dynamically searches for a service provider that may fulfil its requirements immediately prior to the actual service initiation.

2.2.9 Feature

2.2.9.1 Summary

A feature is a subset of the architecture that relates to a particular requirement or larger scale property. A key aspect of features is that they may have realizations, possibly within the architecture itself.

2.2.9.2 Relationships to other elements
A feature is

set of related concepts

A feature has

a realization

2.2.9.3 Description

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

For example, message correlation is a feature of the architecture. The requirement is to be able to associate a message with a particular context. Message correlation may be realized in one of several ways:

  • message identifier in message

  • message occurrence in a stream of messages

2.2.10 Identifier

2.2.10.1 Summary

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

2.2.10.2 Relationships to other elements
an identifier is

an opaque string of bits

an identifier may be realized

a URI

an identifier identifies

a resource that is relevant to the architecture

2.2.10.3 Description

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

We have a strong preference that any concrete realization of identifiers does not exhibit any structure. The reason is that an identifier's primary role is to permit multiple references to a resource to be viewed as equivalent.

An opaque string means, in this context, that identifies do not have a structure that is discernible to an outside observer. However, identifiers MAY have internal structure that is relevant to the originator of the identifier; for example, an identifier in a challenge-response interchange may be opaque to the responder but not to the challenger.

2.2.11 Intermediary

2.2.11.1 Summary

An intermediary is a message processing node that does not necessarily represent the message's intended recipient; but which, none-the-less processes some aspect of the message.

2.2.11.2 Relationships to other elements
an intermediary is

a agent

2.2.11.3 Description

Intermediaries process messages that are intended for other recipients. An intermediary may act as a gateway to bridge transport services, or may process specific aspects of messages (such as security information).

2.2.12 Legal Entity

2.2.12.1 Summary

A legal entity such as a person or a corporation may be the owner of agents that provide or request Web services.

2.2.12.2 Relationships to other elements
a legal entity may be

the owner of an agent

a legal entity has

a presence in the physical domain

a legal entity has

a physical address

a legal entity may agree to

to a legally binding contract

a legal entity has

a name

2.2.12.3 Description

Legal entities are represented by agents and Web services.

Legal entities are individuals (i.e., humans) and organizations. Both are legal entities in that they have the right to enter into contracts -- which is the critical property from the perspective of this architecture.

From a architectural perspective, the key difference between an individual and an organization is that the former has no owner or shareholders, and that all actions are ultimately rooted in the actions of humans.

2.2.13 Life cycle

2.2.13.1 Summary

A life cycle is a set of states and transition paths for an element.

2.2.13.2 Relationship to other elements
a life cycle is

the set of externally observable states that an entity can be in, together with the transitions between them.

a Web service may have

an explicit description of its life cycle

a life cycle of a service may be managed

by a manager

a life cycle of a service may be described

in a manageability interface

2.2.13.3 Description

The life cycle of a Web service is a key target for Web service management capabilities.

2.2.14 Management capability

2.2.14.1 Summary

Management capabilities are the capabilities required by a manager to be able to effectively manage.

2.2.14.2 Relationship to other elements
the status of a manageable element is

a management capability

the configuration of a manageable element is

a management capability

the events associated with a manageable element are

management capabilities

the operations on a manageable element are

a management capability

Management capabilities may be described

in a manageability interface description

2.2.14.3 Description

The key managability capabilities include the ability to identify a manageable element, the ability to acquire status information about a manageable element, the ability to configure it and the ability to control its life-cycle.

2.2.15 Management configuration

2.2.15.1 Summary

A management configuration is a collection of properties of a manageable elements which may be changed.

2.2.15.2 Relationship to other elements
a management configurationis

a set of property values that denotes a particular state of a manageable element

2.2.15.3 Description

Setting a property may influence the behavior of a manageable element. Configuration mechanisms that are common for each type of manageable element [e.g. Web service endpoint] should conform to the Web services architecture [e.g. description and interaction]. Configuration for a manageable element, beyond the common configuration, should be defined by an administrative interface.

2.2.16 Management event

2.2.16.1 Summary

Events are changes in the state of a manageable element that are relevant to the element's manager.

2.2.16.2 Relationship to other elements
a management event is

an event that denotes an event associated with a manageable element that is relevant to a manager.

a problem event is

a management event

a life-cycle event is

a management event

a state change event is

a management event

a request processing event is

a management event

2.2.16.3 Description

Event descriptions are messages that indicate a problem, a lifecycle state change, or a state change. For a manageable element there are two classes of events: State Changed and Request Processing events. State change events occur whenever lifecycle state transitions happen. A request processing event description indicates that the state of a request has been changed and should include the previous state and the transition time. The event may also include any context associated with the request, reply, or failure message and any part or the complete content of these messages. Event descriptions provide valuable information for managers and can be used to calculate many of the metrics.

2.2.17 Manager

2.2.17.1 Summary

A manager is an entity that is capable of and has an interest in managing manageable elements.

2.2.17.2 Relationship to other elements
a manager is

an agent

a manager manages

a manageable element

a manager uses

a manageability capabilities

2.2.17.3 Description

A manager is an agent that is able to manage a set of manageable elements and has the interest and authority in so doing. Managers use the manageability capabilities and interfaces to control the life cycle and other properties of manageable elements on behalf of the owners of those elements.

A manager may have additional capabilities than those within the scope of this architecture; for example, a manager may be able to directly control the computational resources that are used to offer Web services. This architecture focuses on those aspects of management that are central to Web services.

2.2.18 Manageable Element

2.2.18.1 Summary

A manageable element is a deployed element that is manageable. I.e., a physically existing resource that is capable of being managed. A key attribute of manageable elements is that they provide an interface to allow their management.

2.2.18.2 Relationships to other elements
a manageable element is

deployed element

a manageable element has

a life cycle

a manageable element has

a manageability interface

a manageable element has

a descriptionof its manageability interface

a manageable element is

discoverable

2.2.18.3 Description

Manageable elements expose an interface that permits their state — especially their life cycle state to be monitored and potentially modified. The simplest such modification being to delete the element.

There are many potentially manageable elements in this architecture, including services, agents and descriptions as well as discovery providers and service requesters and providers.

As with Web services themselves, manageable elements may also be discovered using similar mechanisms. It is expected that discovery of manageable elements would permit managers to determine if an element is manageable.

2.2.19 Manageability Interface

2.2.19.1 Summary

A manageability interface is a description of the means by which a management system can manage a manageable element.

2.2.19.2 Relationships to other elements
a manageability interface has

controls

a manageability interface has

identification information

a manageability interface has

events that correspond to the life cycle of a manageable element

a manageability interface has

metrics

a manageability interface has

status

a manageability interface has

configuration controls

2.2.20 Management metric

2.2.20.1 Summary

Management metrics are raw atomic unambiguous information. For manageability metrics, the information is for managmement purposes.

2.2.20.2 Relationship to other elements
a manageability metricis

a raw atomic point of data

2.2.20.3 Description

The value of the metric captures the information at a point in time. Generally these values are numeric, but may be strings as well. This can be contrasted with Measurements that are calculated with a formula based on metrics, e.g. Average response time during the last hour of execution. The metrics requirements do not enforce any implementation pattern. A managed element should allow any available metrics and measurements to be reported according to configurable time intervals, such as cumulative, sliding window, and interval. A managed element must declare which interval types are supported.

2.2.21 Message

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

2.2.21.2 Relationships to other elements
a message is

a unit of interaction between agents

a message may be part of

a message exchange pattern

a message may be described using

a message description language

a message has

a message sender

a message has

zero or more message recipients

a message may have

a message identifier

a message has

a message content

a message may have

zero or more message headers

a message may have

a message envelope

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

A message represents the data structure passed to a service during its request, and received from a service during its response (if any). The structure of messages are defined in service descriptions.

2.2.22 Message Exchange Pattern (MEP)

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

2.2.22.2 Relationships to other elements
a message exchange pattern is

set of messagesbetween agentsthat corresponds to a single instantiation of a service

a message exchange pattern is

a feature of the architecture

a message exchange pattern has

a unique identifier

a message exchange pattern is

the life cycle of a messageexchange

a message exchange pattern describes

the temporal and causal relationships, if any, of multiple messagesexchanged in conformance with the pattern.

a message exchange pattern describes

the normal and abnormal termination of any message exchange conforming to the pattern.

a message exchange pattern may be expressed

in a choreography description language.

a message exchange pattern may realize

message correlation

a message exchange pattern may describe

a service invokation.

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

2.2.23 Message Header

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

2.2.23.2 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

message transaction context

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

2.2.24 Message description language

2.2.24.1 Summary

A message description language allows the structure of messages to be described.

2.2.24.2 Relationships to other elements
a message description language describes

the structure of a message

2.2.24.3 Description

A message description language allows the formal structure of messages to be described, including the types of elements of the message, how recipients and senders are identified and which headers are associated with messages.

2.2.25 Message Identifier

2.2.25.1 Summary

A message identifier is an identifierthat uniquely identifies a message.

2.2.25.2 Relationships to other elements
a message identifier is

a unique identifier

a message identifier identifies

a message

2.2.25.3 Description

A message may have an identifier. In the context of Web services we use URIs to represent message identifiers. Message identifiers allow messages to be correlatedwithin an extended transaction; for example, an event message may reference the original subscription request message.

Message identifiers also support message reliabilityand management and accountabilityof services: by providing the means to uniquely identify messages in an audit trail.

2.2.26 Message recipient

2.2.26.1 Summary

A message recipient is an agent that is intended — by the message's sender — to consume the message.

2.2.26.2 Relationships to other elements
a message recipient is

a agent

2.2.26.3 Description

The message recipient is the agent that the sender intends the message to be consumed by. The message recipient of an agent may be represented as the agent's identifier in a message envelope; however, in the case of anonymous or broadcast-style interactions, the recipient of a message may not be available to the sender.

In general, a message may be intended for more than more than one recipient. Furthermore, in some cases, the sending agent may not have direct knowledge of the identity of the message recipient (for example, in multi-case situations or in the case anonymous interactions with a service provider.)

Messages may also be passed through intermediaries that process aspects of the message; typically by examining the message headers. The sending agent may or may not be aware of such intermediaries.

2.2.27 Message sender

2.2.27.1 Summary

A message sender is the agent that originates a message.

2.2.27.2 Relationships to other elements
a message sender is

a agent

2.2.27.3 Description

A message sender is the agent that originally caused a new message to be created and sent to an agent. The message sender of an agent may be represented as the agent's identifier in a message envelope; however, in the case of anonymous interactions the originator of a message may not be available.

2.2.28 Reliable messaging

2.2.28.1 Summary

Reliable messaging is a feature that represents a key infrastructure-level notion of reliability.

2.2.28.2 Relationships to other elements
reliable messaging is

a feature

reliable messaging may be realized by

a combination of message acknowledgement and correlation.

2.2.28.3 Description

Reliable messaging is an important contributory factor to the overall reliability of Web services. The goal of reliable messaging is to both reduce the the error frequency for interactions and, where errors occur, to provide a greater amount of information about either successful or unsuccessful attempts at message delivery.

Reliable messaging may be realized with a combination of message receipt acknowlegment and correlation. In the event that a message has not been properly received, the sender may attempt a resend, or some other compensating action. Note that in a distributed system, it theoretically not possible to guarantee correct notification of delivery; however, in practice, simple techniques can greatly increase the overall confidence in the message delivery.

Message correlation may be used by the receivers of messages to ensure that messages are only acted on once - with duplicate messages being ignored or treated as errors.

2.2.29 Representation

2.2.29.1 Summary

A representationis a data object that denotes a resource state, and is the vehicle for conveying the meaning of a resource. A resource is an abstraction for which there is a conceptual mapping to a (possibly empty) set of representations.

2.2.29.2 Relationships to other elements
a representation is

a data object

a representation denotes

the state of a resource

2.2.29.3 Description

Representations are data objects that denote the state of a resource. A resource has a unique identifier, whereas a representation is a data object that represents the resource itself. Note, that a representation of a resource need not be the same as the resource itself; for example the resource asociated with the booking state of a restaurant will have different representations depending on when the representation is retrieved.

Resources have identifiers but cannot be retrieved — representations of resources may be retrieved but are typically not themselves resources.

2.2.30 Resource

2.2.30.1 Summary

A resource is defined by [RFC2396] to be anything that has an identifier.

2.2.30.2 Relationships to other elements
a resource is

an entity

a resource has

an identifier

a resource may have

zero or more representations

2.2.30.3 Description

Resources form the heart of the Web architecture itself — the Web is a universe of resources that have URIs as identifiers, as defined in [RFC2396].

2.2.31 Service

2.2.31.1 Summary

A service is a set of actions that form a coherent whole from the point of view of service providers and service requesters.

2.2.31.2 Relationships to other elements
a service performs

one or more tasks

a service has

a service description

a service has

one or more service providers

a service has

zero or more service requesters

a service has

an identifier

a service has

a service semantics

a service has

a service interface

a service is realized

by one or more agents acting as service providers

a service is invoked by

exchanging messages

a service has

a service execution model

2.2.31.3 Description

A service is a collection of related tasks that form a coherent whole, from the point of view of service providers and requesters. Critically, services have descriptions that may be formally expressed in one or more service description languages.

The concept of a service is distinct from the software agent that provides the service (and the software agent that requests it). A service refers to the actions performed by the agents rather than the agents themselves.

In the case of atomic or simple services, a service is provided through the actions of a single (possibly federated) software agent. In the case of a composite service, the service is provided through the collaboration of a collection of agents. In this latter case, it may not be obvious which software agent is providing the service — either to the requester of a service or even to the agents providing the service.

A service has an identifier, which in this architecture is a URI. However, the service's identifier should not be construed as identifying any of the agents that perform the tasks offered by the service.

The service description defines the functionality of a service, the service semantics and the interface of the service, i.e how to interact with the service.

The semantics of a service is expressed in terms of the tasks that are performed by the service.

In a Service Oriented Architecture, the description of a service's interface is expressed in terms of the messages that may be exchanged between service providers and requesters.

Issue (service_uri):

What is identified with a service identifier?

Source:

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

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

However, it is not clear what is referenced by a service identifier; is it the service end-points, the service description, the agent?. None of these seems definitive.

Resolution:

None recorded.

2.2.32 Service description

2.2.32.1 Summary

A service description is a set of documents that describe the interface to and semantics of a service.

2.2.32.2 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 contains

a description of the messages that are exchanged by the service

a service description has

a identifier which is a URI.

a service description is expressedin

a service description language

2.2.32.3 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 requesters. The complete description may be realized as a set of XML description documents.

There are many potential uses of service descriptions, they may be used to facilitate the construction and deployment of services, they may be used by people to locate appropriate services and they may be used by service requesters to automatically discover appropriate providers in those case where requesters are able to may suitable choices.

2.2.33 Service provider

2.2.33.1 Summary
2.2.33.2 Relationships to other elements
a service provider is

a Web service agent

a service provider provides

one or more services

2.2.33.3 Description

The service provider is the agent, i.e., computational entity, that provides a service.

A given service may be offered by more than one agent, especially in the case of composite services, and a given service provider may offer more than one service.

2.2.34 Service requester

2.2.34.1 Summary

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

2.2.34.2 Relationships to other elements
a service requester is

a Web service agent

a service requeser requests

one or more services

2.2.34.3 Description

The service requester is the entity that requires a certain function to be satisfied. From an architectural perspective, this is the agentthat is looking for and invoking or initiating an interaction with a service.

2.2.35 Service semantics

2.2.35.1 Summary

The semantics of a service is the contract between the service providerand the service requesterthat 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 requester.

2.2.35.2 Relationships to other elements
a service semantics is

the contract between the service providerand the service requesterconcerning the effects and requirements pertaining to the use of a service

a service semantics is about

the service tasks that constitute the service.

a service semantics may be expressed

in a service description language

a service semantics may be identified

in a service description

a service semantics describes

the intended effects of using a service

a service semantics is describes

the relationship between the service providerand the service requester

2.2.35.3 Description

Knowing the type of a data structure is not enough to understand the intent and meaning behind its use. For example, methods to 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.

The semantics of a service is fundamentally about the tasks that are encapsulated in the service. A given service may encapsulate a number of different tasks, each task consists of a goal and a process or action for achieving the goal.

2.2.36 Service Task

2.2.36.1 Summary

A service task is a unit of activity associated with a service. It is denoted by a pair: a goal and an action; the goal denotes the intended effect of the task and the action denotes the process by which the goal is achieved.

2.2.36.2 Relationships to other elements
a service task has

a goal that represents the intended effect of the task

a service task has

one or more actions that should result in the goal being achieved.

2.2.36.3 Description

A task is an abstraction that encapsulates the intended effect of invoking a service.

A task is associated with a goal — a predicate that should be satisfied on successful completion of the task

A task is associated with a procedure (or action) that is used to achieve the task.

The actions associated with a task may be public, as in the exchange of messages between service providers and requesters; or it may be private, as in the calculation of a formula or in the update of a shared resource. In the case of a service oriented architecture only the public aspects of a task are important, and these are expressed entirely in terms of the messages exchanged.

2.2.37 SOAP

2.2.37.1 Summary

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

2.2.37.2 Relationships to other elements
SOAP is

An example of implementation technology for expressingthe structure of messages

a SOAP package has

an envelope

a SOAP package has

a set of encoding rules for expressinginstances of application-defined data types.

a SOAP package has

an envelope

a SOAP package has

a convention for representing the exchange of messagesand responses.

SOAP has

a set of rules for using SOAP with HTTP.

SOAP may be used with

other message delivery protocols.

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

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; it also provides a simple framework for extensible messages and message processing.

One special type of SOAP Feature is the Message Exchange Pattern (MEP). A SOAP 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.

2.2.38 WSDL

2.2.38.1 Summary
2.2.38.2 Relationships to other elements
WSDL is a

example of implementation technology for service descriptions

WSDL describes

the abstract functionality of a service

WSDL describes

the concrete binding details for SOAP 1.2, HTTP and MIME

2.2.38.3 Description

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

WSDL describes Web services starting with the messages that are exchanged between the service provider and requester. The messages themselves are described abstractly and then bound to a concrete network protocol and message format.

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.

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.

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.

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

2.3.1 The is a relationship

2.3.1.1 Summary

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

2.3.1.2 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 Qis a P.

transitive

if P is true of Y then P is true of X

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

2.3.2 The describes relationship

2.3.2.1 Summary

The concept X is described by Y relationship denotes that Y is an expression of some language L and that the value of Y is an instances of X.

2.3.2.2 Relationships to other elements

Assuming that X is described by Y, then:

valid

if Y a valid expression of L, then the value of Y is an instance of concept X

2.3.2.3 Description

Essentially, when we say that concept X is described by Y we are saying that the expression Y denotes 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.

2.3.3 The is expressed in relationship

2.3.3.1 Summary

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

2.3.3.2 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

2.3.3.3 Description

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.

2.3.4 The has a relationship

2.3.4.1 Summary

The concept X has a Y relationship denotes that every instance of X is associated with an instance of Y.

2.3.4.2 Relationships to other elements

Assuming that X has a Y, then:

valid

if E is an instance of X then Y is valid for E.

2.3.4.3 Description

When we say that concept X has a Y we mean that whenever we see an X we should also see a Y

For example, in the Web service concept, we state that Web services have URI identifiers. So, whenever we the Web service concept is found, we can assume that the Web service referenced has an identifier. This, in turn, allows implementations to use identifiers to reliably refer to Web services. If a given Web service does not have an identifier associated with it, then the architecture has been violated.

2.3.5 The realized relationship

2.3.5.1 Summary

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

2.3.5.2 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

reified

Y is a reification of the concept X.

2.3.5.3 Description

When we say that the concept or feature X is realized as Y, we mean that Y is an implementation or reification of the concept X. I.e., if Y is a valid concept of a system then we have also ensured that the concept X is valid of the same system.

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.

3 Stakeholder's perspectives

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.

3.1 Web integration

Goal AG003 of the requirements identifies Web services must be consistent with the current and evolving nature of the World Wide Web.

This goal can be divided into two sub-goals — relating to the architectural principles of the Weband, more pragmatically, relating the architecture to the various technologies in use.

Critical Success Factor AC011notes that the architecture should be consistent with the architectural principles and design goals of the Web. For our purposes we use the Architecture of the World Wide Webas our reference for the architecture of the Web.

This identifies the architecture of the Web to be founded on a few basic concepts: agents that are programs that represent people, identification of resources using URIs representations of resources as data objects and interaction via standard protocols — most notably of course HTTP.

3.2 Information and service

Unlike the World Wide Web in general, it is of the essence that Web services, like service oriented architectures in general, are essentially about the provision of action. I.e., whereas the World Wide Web is a networked information system, the Web service World Wide Web is a networked service system: information is exchanged between Web service agents for the purpose of requesting and provisioning service, not simply information.

This is a key specialization of the World Wide Webin general; and it drives a number of the specific features of this architecture. However, it is also the case that requests for action and the various possible responses are also information and have representations.

The key representational requirement of this architecture is that messages exchanged between Web service agents is encoded in XML. This is consistent with the general principles of the World Wide Web.

3.3 Web service agents

This architecture also uses the concept of an agentto identify the computational resource actually involved with Web services. The key properties of agents required to model Web services are that:

  1. It is a computational activity

  2. It has an owner

  3. It engages in message exchanges with other Web service agents, those messages counting as equivalent messages between the agents' owners.

  4. It uses standard protocols to:

    1. describe the form and semantics of messages

    2. describe the legal sequences of messages

  5. The distinction between a service requester and service provider is one of the agent's roles; i.e., it is not intrinsic to the concept of agent that it is bound to be solely a provider or requester of services. Of course, in many cases, particular agents will be bound to particular functions that will fix the role of the agent to be a service provider or requester.

However, it is clear that there is a strong correspondence between a Web service agent and a Web agent. Both are computational resources that represent people; our definition requires sufficient detail to be able to account for the greater degree of indirection expected between Web service agents and Web agents.

3.4 Web Service Discovery

Based on Web Services Architectural Roles

Before a requester agent and a provider agent can interact, the corresponding enties that own them must first agree on the service description and semantics that will govern the interaction, as depicted in Figure 1. There are many ways this can be achieved. Some require discovery, others don't.

3.4.1 Scenarios Not Requiring Discovery

If the requester and provider entities are already known to each other, then one common way for them to agree on the service description and semantics is for a requester human and a provider human to communicate directly. For example, the provider human might send the proposed service description and semantics directly to the requester human. Or the parties might develop them collaboratively. In these situations, there is no need for discovery.

If the provider entity is furnishing the service description unilaterally, then a variation on this approach is for the requester entity to retrieve the service description dynamically from the provider agent, at the start of their interaction, as depicted in Figure 4: Parties Known, Dynamically Getting WSD. This allows the requester agent to be assured of using the latest version that the provider agent supports, again without requiring discovery.

[Figure 5: Parties Known, Dynamically Getting WSD]

[dbooth: The label at the top of this diagram needs to be fixed. It should be "Figure 5" instead of "Figure 2".] Parties known; requester agent dynamically getting WSD from provider agent

3.4.2 Scenarios Requiring Discovery

On the other hand, if the requester entity does not already know what provider agent it wishes to engage, then it may need to "discover" a suitable candidate. Discovery is "the act of locating a machine-processable description of a Web service that may have been previously unknown and that meets certain functional criteria." [17] Two common ways to approach this are human discovery, and autonomous selection.

3.4.2.1 Human Discovery

With human discovery, a requester human uses some kind of discovery tool or agent to help locate a suitable service description, i.e., a description representing a service that meets the desired functional criteria, as shown in Figure 6: Human Discovery.

[Figure 6: Human Discovery]

[dbooth: The label at the top of this diagram needs to be fixed. It should be "Figure 6" instead of "Figure 3".] Human Discovery

There are several points to note about this situation.

  • Regardless of how the service description is obtained, somehow the requester and provider entities must agree on the semantics of the planned interaction. There are several ways this can be done, and the WSA does not specify or care what way is used. For example, the provider entity may publish both the service description and semantics on a take-it-or-leave-it basis, which the requester must accept unmodified as a condition of engaging the provider agent. Or the parties could negotiate the desired semantics. Or the semantics might be defined by an industry standards body that both parties have chosen to follow.

  • Somehow the discovery agent must obtain both the service description (or at least a reference to it), and sufficient information (labeled "SemanticsID" in Figure 6) to describe or identify the semantics of the service that the provider entity offers. The SemanticsID is necessary to allow the requester human to find a service having the desired semantics. In practice, the SemanticsID might be as simple as a few words or a URI, or it may be more complex, such as a TModel (in UDDI) or a collection of RDF, DAML-S or OWL statements.

    [dbooth: I'm still looking for a better term than "SemanticsID" in this section. Any ideas? "Semantic description"? "Semantic designator"? ...?]

  • The WSA also does not specify or care how the discovery agent obtains the service description and SemanticsID. For example, if the discovery agent is implemented as a search engine (such as Google), then it might crawl the Web, collecting service descriptions wherever it finds them, with the provider entity having no knowledge of it. Or, if the discovery agent is implemented as a registry (such as UDDI), then the provider entity could publish the service description and SemanticsID directly to the discovery agent.

  • [dbooth: Need to add mention of the trust decision.]

3.4.2.2 Autonomous Selection

With autonomous selection, the requester agent uses a selection agent to select a service description from among

@@ unfinished @@ [dbooth to fill in this section]

, as shown in Figure 7: Autonomous Selection.

[Figure 7: Autonomous Selection]

[dbooth: The label at the top of this diagram needs to be fixed. It should be "Figure 7" instead of "Figure 5".] Autonomous Selection

3.5 Web service semantics

A third major distinction between this architecture and the World Wide Webis that, for computer programs to be able to interact with other in a meaningful way, it is necessary to model the semanticsof the information exchanged.

So long as the primary purpose of an agent is to render information in a way that is immediately meaningful to human eyes, the semantics of the interactions between agents is essentially straightforward — as is ably captured in the generic HTTP protocol.

However, if an agent is expected to be able to act on information it receives, it becomes necessary to be much more precise as to the intended semantics of the information.

The semantics of the information exchanged between Web service agents is derived from the structure of the messages, the message exchange patterns and conversational patterns between agents. In addition, it is necessary to be precise about

  • the real-world entities referenced by terms in messages

  • the expected actions to be undertaken by service providers

  • the relationship between the owners of the agents acting as service provider and service requester

This architecture enables this precision by ensuring that the various aspects of the semantics of the information exchanged between agents can be properly identified. Where appropriate, and possible, it also identifies a number of description languages which can be used to describe different semantic aspects of this exchanged information.

An important technology for realizing the description of the semantics of Web services is the Semantic Web. "The Semantic Web is an extension of the current web in which information is given well-defined meaning, better enabling computers and people to work in cooperation." -- Tim Berners-Lee, James Hendler, Ora Lassila, The Semantic Web, Scientific American, May 2001.

Editorial note
More justice needs to be made to the technologies coming out of the Semantic Web effort.

In summary, Web services can be considered to be a specialization of World Wide Webin general; a specialization that reflects the intended purpose of the exchanged information — to be about services. Similarly, this architecture can be viewed as an elaboration of the general WWW architecture; albeit with a significant number of additional concepts.

3.6 Web services security

Editorial note
Please see input from Security Task Force

3.7 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 EDIand peer to peer.

3.8 Modularity

The critical success factor AC002focuses 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 conceptsand 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:

  • Web services are used and presented by agentsinteracting on behalf of real-world actors.

  • Message structures, service interfaces, conversationsare first of all explicitly identified and potentially describedusing using a variety of description languages. This has the effect of documenting the various aspects involved in two or more interacting Web services.

  • Minimal assumptions about required components. For example, although Web services may be documented, it is not required. Similarly, although descriptions may be published, that is also not required.

3.9 Extensibility

3.10 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 patternconcept 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 agentconcept 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 agentconcept also clarifies that a given agent may adopt the role of a service providerand/or a service requester. 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 serviceconcept we state that services havea semanticsthat may be identified in a service descriptionand that may be expressedin 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 serviceshave descriptionsmeans 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.

3.11 Long running transactions

In CSF AC017are 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.

3.12 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 patternis 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 languagesuch as WSDL.

In addition, the architecture supports the correlationof 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.

Editorial note
Please also consider Mark Jones's input and Geoff Arnold's stuff on synchronous/asynchronous

3.13 Message reliability

Critical Success Factor AC017 of the requirements notes that the architecture must satisfy the requirements of enterprises wishing to transition from traditional EDI and more specifically AR017.1 requires that the architecture must support reliable messaging.

The goal of reliability is to both reduce the the error frequency for interactions and, where errors occur, to provide a greater amount of information about either successful or unsuccessful attempts at service.

In the context of Web services, we can address the issues of reliability at three distinct levels: of reliable and predictable interactions between services, of the reliable and predictable delivery of infrastructure services and of the reliable and predictable behavior of individual service providers and requesters. This analysis is generally separate from concerns of fault tolerance, availability or security, but there may of course be overlapping issues.

The architecture addresses the requirements for the highest level of reliability identified here by accomodating the descriptions of the choreographies of the interactions between Web service requesters, providers. In effect, reliability at this level becomes a measurable property of the descriptions of choreographies: in effect, assuming that the infrastracture is reliable, and assuming that the services are reliable, do the descriptions of the choreographies describe situations which will behave in predictable ways?

The reliability of the individual service providers and requesters is out of scope of this architecture as we do not comment on the realization of Web services. However, reliability at this level is often enhanced by service providers adopting deployment platforms that have strong management capabilities.

The reliability of the infrastracture services refers to the reliability of the messaging infrastructure and the discovery infrastructure; the former is often referred to as reliable messaging. In general, this refers to a predictable quality of service related to the delivery of the messages involved with the Web service.

In more detail, we identify two properties of message sending that are important: the sender of the message would like to be able to determine whether a given message has been received by its intended receiver and that the message has been received exactly once.

Knowing if a message has been received correctly allows the sender to take compensating action in the event the message has not been received. At the very least, the sender may attempt to resend a message that has not been received.

The general goal of reliable messaging is to define mechanisms that make it possible to achieve these objectives with a high probability of success in the face of inevitable but unpredictable network, system and software failures.

The goals of reliable messaging can be made more explicit by considering the issues related to multiple receptions of a message and message intermediaries. If there is an intermediary, does the sender want to know whether the message got to the intermediary or to the intended end recipient? Does the receiver care whether it receives a message more than once? The following classification of reliable messaging expectations is taken from the ebXML Messaging Services.

Duplicate-EliminationAck Requested From End ReceiverAck Requested from Next ReceiverComment
1YYYOnce-And-Only-Once End-To-End, At Least Once to Intermediate
2YYNOnce-and-only-Once End-to-End based on end-to-end retransmission
3YNYAt-Least-Once at the intermediate level, Once-and-only-once end-to-end if all the intermediaries are reliable, no end-to-end notification
4YNNAt-Most-Once end-to-end, no retries at the intermediate level
5NYYAt-Least-Once with duplicates possible both end-to-end and at intermediate level
6NYNAt-Least-Once with duplicates possible both end-to-end and at intermediate level
7NNYAt-Least-Once to the intermediaries and the end. No end-to-end notification
8NNNBest Effort

The goals of reliable messaging may also be examined with respect to whether one wishes to confirm only the receipt of a message, or perhaps also to confirm the validity of that message. Three questions may be asked about message validity:

  1. Was the message received the same as the one sent? This may be determined by such techniques as byte counts, check sums, digital signatures.

  2. Does the message conform to the formats specified by the agreed upon protocol for the message? Typically determined by automatic systems using syntax constraints (eg xml well formed) and structural constraints (validate against one or more xml schemas or WSDL message definitions).

  3. Does the message conform to the business rules expected by the receiver? For this purpose additional constraints and validity checks related to the business process are typically checked by application logic and/or human process managers.

Of these, first and second are considered to be part of reliable messaging, the last is partly addressed by Web service choreography.

Message reliability is most often achieved via an acknoweldgement infrastructure, which is a set of rules defining how the parties to a message should communicate with each other concerning the receipt of that message and its validity. WS-Reliability and WS-ReliableMessaging are examples of specifications for an acknowledgement infrastructure that leverage the SOAP Extensibility Model. In cases where the underlying transport layer already provides reliable messaging support (e.g. a queue-based infrastructure), the same reliability Feature can be achieved in SOAP by defining a binding that relies on the underlying properties of the transport.

3.14 Web service manageability

Goal AG007 of the requirements identifies that manageability of Web services is an important goal of this architecture. Since the architecture defines how to define information, operations and discovery of Web services, it is consistent to use Web services to provide access to and manageability of Web services also.

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 manageable elements, where these are defined as Web services, descriptions, agents of the Web services architecture, and roles undertaken in the architecture.

This architecture does not attempt to specify completely how Web services are managed; that is be the role of a separate specification. The architecture does, however, identify the key concepts and relationships involved in modeling manageability. These key concepts include the manageable element, its management capabilities, the manageability interface and the manager.

For example, an executing Web services agent is a potentially managable element that may require management, as is an actually deployed Web service and the Web service's service description.

The manager is an agent that has the responsiblity for managing on behalf of its owner and the owners of the resources that it is managing. The manager uses the manageability interface to aquire metrics of managed elements and to manage the configuration, the life cycle, and to monitor the status of those elements. The manager is also a prime recipient of management events.

The key relationship that ensures that the architecture models management appropriately is the realizes relationship. The entities under management — the manageable elements — have a realizes relationship with other elements of the architecture. For example, a Web service is provided by an agent. Both the Web service itself and the agent are realized in some fashion; as are any descriptions of the service; as physically deployed resources, and those deployed resources are themselves potentially manageable.

As with Web services themselves, it may be important for scalability reasons for managers to be able to automatically discover both the manageable elements it may be responsible for and their manageability interfaces.

Editorial note
Discovery has a management aspect as well as a service aspect. This needs to be made clearer.

Of course, managers that are deployed in order to help the management of Web services are also potentially subject to management; however, to the extent that such managers are already modeled as Web services, their management will be handled as any other Web service.

4 Constraints

4.1 Formats

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

...

4.1.1 XML Infoset

Specifications for data formats used in the context of Web services SHOULD be based on XML Infoset [2]. XML Infoset is not a data format per se, but a formal set of information items and their associated properties that comprise an abstract description of an XML document [3]. The XML Infoset specification provides for a consistent and rigorous set of definitions for use in other specifications that need to refer to the information in a well-formed XML document.

Serialization of the XML Infoset definitions of information MAY be expressed using XML1.0 [3]. However, this is not a requirement. The flexibility in choice of serialization format(s) allows for broader interoperability between agents in the system.

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

4.1.2 XML Schema

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

Issue (otherschema):

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

Resolution:

None recorded.

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): Assaf Arkin (Intalio Inc.), Geoff Arnold (Sun Microsystems, Inc.), Daniel Austin (W. W. Grainger, Inc.), Mukund Balasubramanian (Infravio, Inc.), Mike Ballantyne (EDS), Abbie Barbir (Nortel Networks), David Booth (W3C), 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 (Sonic Software), Chris Ferris (IBM), Shishir Garg (France Telecom), Hugo Haas (W3C), 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.), Don Mullen (TIBCO Software, Inc.), Eric Newcomer (IONA), Duane Nickull (XML Global Technologies), Mark Nottingham (BEA Systems), David Orchard (BEA Systems), Srinivas Pandrangi (Ipedo), Mark Potts (Talking Blocks, Inc), Fabio Riccardi (XQRL Inc.), Don Robertson (Documentum), Waqar Sadiq (EDS), 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), 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.), Allen Brown (Microsoft Corporation), Daniela Florescu (XQRL Inc.), Sharad Garg (Intel), Joseph Hui (Exodus/Digital Island), Marcel Jemio (DISA), Timothy Jones (CrossWeave, Inc.), Jim Knutson (IBM), Mark Hapner (Sun Microsystems, Inc.), Bob Lojek (Intalio, Inc.), Anne Thomas Manes (Systinet), Joel Munter (Intel), Henrik Frystyk Nielsen (Microsoft Corporation), David Noor (Rogue Wave Software), Kevin Perkins (Compaq), Darran Rolls (Waveset Technologies, Inc.), Krishna Sankar (Cisco Systems Inc), Scott Vorthmann (TIBCO Software, 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, N. Mendelsohn, J. Moreau, H. Nielsen, 7 May 2003 (See http://www.w3.org/TR/2003/PR-soap12-part1-20030507/.)
9
SOAP Version 1.2 Part 2: Adjuncts Working Draft, eds. M. Gudgin, M. Hadley, J. Moreau, H. Nielsen, 7 May 2003 (See http://www.w3.org/TR/2003/PR-soap12-part1-20030507/.)
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 (XMLP) Requirements, W3C Working Draft 26 June 2002, eds V. Apparao et al. (See http://www.w3.org/TR/2002/WD-xmlp-reqs-20020626.)
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, W3C Working Draft, 14 May 2003, eds. A. Brown, H. Haas (See http://www.w3.org/TR/2003/WD-ws-gloss-20030514/.)
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 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.

D Web Services Architecture Change Log (Non-Normative)

20030419dbooth(Refactored document) Wrote/reworked Introduction
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