Web Services Architecture Requirements

26 March 2002

This version:
Previous version:
Daniel Austin, W. W. Grainger, Inc. <austin.d@ic.grainger.com>
Abbie Barbir, Nortel Networks, Inc. <abbieb@nortelnetworks.com>
Sharad Garg, The Intel Corporation <sharad.garg@intel.com>


This draft is provided to the working group for discussion only and represents a very early version of this document. Readers may well expect significant changes in content and organization over time.


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.


The use of Web Services on the World Wide Web is expanding rapidly as the need for application-to-application communication and interoperability grows. These services provide a standard means of communication among different software applications involved in presenting dynamic context-driven information to the user. In order to promote interoperability and extensibility among these applications, as well as to allow them to be combined in order to perform more complex operations, a standard referernce architecture is needed. The Web Services Architecture Working Group at W3C is tasked with producing this reference architecture.

This document describes a set of requirements for a standard reference architecture for Web Services developed by the Web Services Architecture Working Group. These requirements are intended to guide the development of the reference architecture and provide a set of measurable constraints on Web Services implementations by which conformance can be determined..

Status of this Document

This document is an editors' copy that has no official standing.

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

This document is a preliminary editor's draft of the Web Services Architecture Working Group which is part of the Web Services Activity.

The Working Group intends that this document will at some point become a Working Draft.

The Web Services Architecture Working Group will not allow early implementation to constrain its ability to make changes to this document prior to final release. Publication as a Working Draft does not imply endorsement by the W3C Membership. It is inappropriate to use W3C Working Drafts as reference material or to cite them as other than "work in progress". A list of current W3C Recommendations and other technical documents can be found at http://www.w3.org/TR/.

Comments on, and discussions of this draft can be sent on the (archived) public mailing list www-ws-arch@w3.org.

This document may be available in translations in the future. The English version of this specification is the only normative version.

Due to the architectural nature of this document, it affects not only a large number of W3C Working Groups, but also software developers, content developers, and writers and users of specifications outside the W3C that have to interface with W3C specifications.

Table of Contents

1 Introduction
    1.1 What is a Web Service?
2 Requirements Analysis Method
    2.1 Understanding Critical Success Factors Analysis
    2.2 The Analysis Heirarchy
        2.2.1 Mission, Vision, and Values
        2.2.2 Goals
        2.2.3 Assumptions and Information Needs
        2.2.4 Problems and Gap Analysis
        2.2.5 Critical Success Factors
        2.2.6 Analysis Matrix: Problems v. CSFs
3 Requirements
4 User Scenarios
5 Glossary
6 Acknowledgements
7 References
    7.1 Normative References
    7.2 Informative References

1 Introduction

1.1 What is a Web Service?

The group has jointly come to agreement on the following definition:

Web Service

[Definition: A web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols]

2 Requirements Analysis Method

Many methods of analyzing requirements for software systems are available. While each of them has strengths and weaknesses, the Web Services Architecture Working Group has decided to make use of two methods concurrently, in the hope that together each of these methods will produce a well-defined set of requirements for Web Services Architecture. The two methods chosen are the Critical Success Factor Analysis method, which will be supplemented through the use of gathering Usage Scenarios. Both of these methods are useful but represent different approaches to the problem of gathering requirements.

The Working Groups intends to use these methods together and to cross-reference the results of each approach to ensure consistency of the overall architectural direction. By ensuring that the requirements each serve to meet the goals of the Working Group through the CSF analysis, and also ensuring that the architecture is consistent with the envisioned Usage Scenarios of the Working Groups in the Web Services activity, we can develop a set of architectural requirements that will provide an architectural model that meets the needs of all of those involved.

Note that in the case of Usage Scenarios, the vast majority of these are taken from the work of other W3C Working Groups in the Web Services Activity domain. Few individual Usage Scenarios will be developed by the Web Services Architecure Working Group directly, and those only in response to perceived gaps or omissions in the work of other Working Groups.

2.1 Understanding Critical Success Factors Analysis

2.2 The Analysis Heirarchy

2.2.1 Mission, Vision, and Values Mission

The mission of the Web Services Architecture Working Group is to develop and maintain a standard reference architecture for Web Services. Vision

The W3C Web Services Reference Architecture is intended primarily for the use of other working groups specifying the components identified in the architecture, secondarily for developers implementing the components, and incidentally for end users of those components. The exposition of the reference architecture must, to the greatest extent possible, be understandable by an experienced software designer or developer: it should use a minimum of specialized jargon, employ simple declarative sentences wherever possible, and be organized and illustrated in a way to minimize the amount of effort required to understand it. The reference architecture should specify as few components and relationships as are absolutely necessary. The reference architecture should contain examples intendedto clarify how an application programmer would use its components to build typical applications that utilize web services.

2.2.2 Goals


A few words on the naming convention used here and throughout this document: all goals, critical success factors and requirements are labelled according to the following convention:


[D-] indicates that the item is in a draft state

A indicates that this is an architectural item.

[G|F|R|UC] is one of Goal|Critical Success Factor|Requirement|Use Case.

nnnn indicates the sequence number of the item.

Proposed Goals for the Web Services Architecture Working Group>

(Each of the following goals is stated as a predicate to the following statement.)

To develop a standard reference architecture for web services that:


provides a complete reference framework that encourages the development of interoperable software products from multiple vendors and provides a defensible basis for conformance and interoperability test suites


provides modularity of web services components, allowing for a level of granularity sufficient to meet business goals


is sufficiently extensible to allow for future evolution of technology and of business goals


ensures platform independence of web services components in a way that does not preclude any programming model nor assume any particular mode of communication between the individual components


provides simplicity and ease-of-use that does not impose high barriers to entry for users of web services


addresses the security of web services across distributed domains and platforms


is reliable, and stable, and whose evolution is predictable over time


is coherent and consistent in its definition


is aligned with the semantic web initiative at W3C and the overall existing web architecture


uses W3C XML technologies in the development of the web services architecture to the extent that this is compatible with the overall goals listed here.


is consistent with the existing web and its heterogenous environment and distributed architecture to the greatest extent possible

In addition, the Working Group will also act to:


identify or create the use cases that validate the requirements and the web services architecture and illustrate the benefits of web services


co-ordinate the development of web services within W3C, together with other W3C Working Groups where there is overlap among their problem domains


serve as liaison with groups outside W3C who are working on web 0services in order to achive interoperability and reduce duplication of effort


organize its efforts in such a way as to adress vital time-to-market issues for its products, including iterating over successive refinements of the overall requirements for the standard reference architecture.


identify current gaps in architectural interoperability and recommend standards -based remedies.




provide a standard set of metrics for measuring aspects of Web Services such as reliability, quality of service, and performance, and to define a standard means of instrumentation for measurement and management of these aspects of Web Services.




To develop a standard reference architecture for web services that enables privacy protection of the consumer of a Web service across multiple domains and services.

2.2.3 Assumptions and Information Needs

2.2.4 Problems and Gap Analysis

2.2.5 Critical Success Factors

2.2.6 Analysis Matrix: Problems v. CSFs

3 Requirements

4 User Scenarios

D-UC0001: Fire-and-forget

Definition: A one-way message with no delivery semantics guaranteed.

Scenario Description:

A metrics collection service exposes an interface for applications running in an environment to report their application usage metrics. Instead of reporting individual metrics, these applications report a computed sum that represents the summary of their usage. Therefore, the loss of a message is not important because the next update will again provide an updated summary. In the interest of efficiency, the client applications are not interested in receiving any faults, and just want to send a message and forget about it until the next time. Another example service could be sending a stock price update every 15 minutes.

D-UC0002: One-Way Message With Guaranteed Delivery

Definition: A one-way message with guaranteed delivery.

Scenario Description:

A web service that provides a messaging service could be a higher-level interface over enterprise messaging capabilities such as JMS. On the publisher side, it exposes an interface that allows applications to publish messages to a logical messaging channel. The publishing clients do not expect to receive a response to their invocation, however, it is important for them to know that the message has been delivered. So while they make a one-way request, they do want to receive faults if the message could not be successfully published, whether due to a system error on the server side or due to an application error on the server side.

D-UC0003: Document Centric Computing

Definition: Services whose operations support document centric computing.

Scenario Description:

In this scenario, a web service is ebXML based web service that requires document-oriented computing. The operations that its interface includes are all actually asynchronous messages with no parameters. All the data to the messages is sent as document attachments. Its description document will then describe the data expected by its operations in terms of the expected attachments and not in terms of its parameters.

D-UC0004: Remote Procedure Call

Definition: A service being invoked remotely by passing parameters.

Scenario Description:

The sender invokes the service by passing parameters that are serialized into a message for transmission to the receiving server.

D-UC0005: Request with acknowledgement

Definition: Data exchange with status acknowledgment between sender and receiver.

Scenario Description:

A sender wishes to reliably exchange data with a receiver. It wishes to be notified of the status of the data delivery to the receiver. The status may take the form of: 1. The data has been successfully delivered to the receiver, or 2. Some failure has occurred which prevents the successful delivery to the receiver.

D-UC0006: Third party intermediary

Definition: Services interacting with each other via a third party.

Scenario Description:

A blind auction marketplace serves as a broker between buyers and suppliers. Buyers submit their requirements to the marketplace hub, which broadcasts this information to multiple suppliers. Suppliers respond to the marketplace hub where the information is logged and ultimately delivered to the buyer.

D-UC0007: Communication via multiple intermediaries

Definition: Services interacting with each other via multiple intermediaries.

Scenario Description:

An intermediary forwards a message to the ultimate receiver on behalf of an initial sender. The initial sender wishes to enforce the non-repudiation property of the route. Any intermediate message service handler that appends a routing message must log the routing header information. Signed routing headers and the message readers must be logged at the message handler that passes the message to the ultimate receiver to provide the evidence of non-repudiation.

D-UC0008: Asynchronous messaging

Definition: Services interacting with asynchronous messaging.

Scenario Description:

A sender sends a message asynchronously to a receiver expecting some response at a later time. The sender tags the request with an identifier allowing the response to be correlated with the originating request. The sender may also tag the message with an identifier for another service (other than the originating sender) that will be the recipient of the response.

D-UC0009: Multiple asynchronous responses

Definition: Services interaction requiring multiple asynchronous messaging

Scenario Description:

An application requests some information from a server, which is returned at a later time in multiple responses. This can be because the requested information was not available all at once (e.g., distributed web searches).

D-UC0010: Events and Event notification

Definition: Service provider notifies events, or consumer subscribes to events.

Scenario Description:

A WS provider can describe events generated by a service, and WS client may subscribe to events The underlying WS framework would take care of the event by either polling (sending a SOAP request) with a specified interval or registering a SOAP listener (endpoint) with the target WS (according to the event definition in WSDL). For example, an application can subscribe to notification of various aspects of a printer's status (e.g., running out of paper, ink etc.).

D-UC0011: Versioning

Definition: Services providing different versions of its interfaces.

Scenario Description:

A WS provider can describe versions of interfaces implemented by a service. WS client can bind to the necessary interface version. This way there is no ambiguity when WS provider changes service interfaces and client has created a static proxy that uses previous version of interfaces. WS provider can deprecate and remove interfaces as desired, and the client would know that. Client would send a SOAP request that would not be accepted (as namespaces do not match), as opposed to client trying to send a SOAP request that could be accepted, but improperly executed.

5 Glossary


The software architecture of a program or computing system is the structure or structures of the system, which comprise software components, the externally visible properties of those components, and the relationships among them." [BASS98]


An association between an Interface, a concrete protocol and a data format. A Binding specifies the protocol and data format to be used in transmitting messages defined by the associated Interface.


A logical grouping of operations. An Interface represents an abstract Service type, independent of transmission protocol and data format.


The basic unit of communication between a Web Service and a Client: data to be communicated to or from a Web Service as a single logical transmission.


A set of messages related to a single Web Service action.


An association between a Binding and a network address, specified by a URI, that may be used to communicate with an instance of a Service. A Port indicates a specific location for accessing a Service using a specific protocol and data format.

Reference Architecture

A reference architecture is the generalized architecture of several end systems that share one or more common domains. The reference architecture defines the infrastructure common to the end systems and the interfaces of components that will be included in the end systems. The reference architecture is then instantiated to create a software architecture of a specific system. The definition of the reference architecture facilitates deriving and extending new software architectures for classes of systems. A reference architecture, therefore, plays a dual role with regard to specific target software architectures. First, it generalizes and extracts common functions and configurations. Second, it provides a base for instantiating target systems that use that common base more reliably and cost effectively.[Gallagher2000]

Web Service

A web service is a software application identified by a URI, whose interfaces and binding are capable of being defined, described and discovered by XML artifacts and supports direct interactions with other software applications using XML based messages via internet-based protocols

6 Acknowledgements

7 References

7.1 Normative References

Bass, L., Clements, P., and Kazman, R. Software Architecture in Practice. Reading, Mass.: Addison Wesley, 1998.
Gallagher, Brian P. Using the Architecture Tradeoff Analysis Method to Evaluate a Reference Architecture: A Case Study CMU/SEI-2000-TN-007 June 2000 (See http://www.sei.cmu.edu/publications/documents/00.reports/00tn007/00tn007.htm.)
Sadiq, W, Web Service Usage Scenarios, W3C Working Draft March 2002, Work in Progress (See http://lists.w3.org/Archives/Public/www-ws-desc/2002Mar/att-0043/01-ws-desc-usecases.html.)
Ibbotson, J. XML Protocol Usage Scenarios, W3C Working Draft, Work in Progress (See http://www.w3.org/TR/2001/WD-xmlp-scenarios-20011217/.)
Bullen, C. and J. Rockart -- A Primer on Critical Success Factors, MIT Sloan School of Management Working Paper 1220-81

7.2 Informative References

Yin, Kevin "A Refrence Architecture for Smart Web Services" Sun Developer Connection, August 2001 (See http://dcb.sun.com/practices/devnotebook/webserv_refarch.js.)