W3C

Web Services Architecture Requirements

W3C Working Draft 19 August 2002

This version:
http://www.w3.org/TR/2002/WD-wsa-reqs-20020819
Latest version:
http://www.w3.org/TR/wsa-reqs
Previous version:
http://www.w3.org/TR/2002/WD-wsa-reqs-20020429
Editors:
Daniel Austin, W. W. Grainger, Inc. <austin.d@ic.grainger.com>
Abbie Barbir, Nortel Networks, Inc. <abbieb@nortelnetworks.com>
Christopher Ferris, IBM <chrisfer@us.ibm.com>
Sharad Garg, The Intel Corporation <sharad.garg@intel.com>

Abstract

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 reference 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 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 W3C Working Draft of the Web Services Architecture Requirements document. It is a chartered deliverable of the Web Services Architecture Working Group, which is part of the Web Services Activity. Although the Working Group agreed to request publication of this document, this document does not represent consensus within the Working Group about Web services architecture requirements.

While a few critical success factors and requirements still need to be agreed upon (draft items are prefixed with "D-"), most of the text in this document is stable and feedback on this document is sought by the Working Group.

Comments on this document should be sent to www-wsa-comments@w3.org (public archive). It is inappropriate to send discussion emails to this address.

Discussion of this document takes place on the public www-ws-arch@w3.org mailing list (public archive) 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 public W3C Working Draft for review by W3C members and other interested parties. It 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". A list of all W3C technical reports can be found at http://www.w3.org/TR/.

Table of Contents

1 Introduction
    1.1 What is a Web service?
    1.2 Conventions Used in This Document
2 Requirements Analysis Method
    2.1 Understanding Critical Success Factors Analysis
3 The Analysis Hierarchy
    3.1 Mission Statement
        3.1.1 Mission
        3.1.2 Users of Web Services Architecture
    3.2 Goals
        3.2.1 Top-level Goals
        3.2.2 Critical Success Factors and Requirements
4 Acknowledgments
5 References
    5.1 Normative References
    5.2 Informative References
6 Change Log


1 Introduction

The use of Web services on the World Wide Web is expanding rapidly as the need for application-to-application communication and interoperability grows. These 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 reference 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.

1.1 What is a Web service?

The Working Group has jointly come to agreement on the following working definition:

Web service

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

1.2 Conventions Used in This Document

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.

Note:

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

[D-]A(G|F|R|UC)nnn.n.n

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

nnn.n.n indicates the sequence number of the item.

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 Architecture Working Group directly, and those only in response to perceived gaps or omissions in the work of other Working Groups. Usage scenarios will be published separately.

2.1 Understanding Critical Success Factors Analysis

The Critical Success Factors Analysis methodology for determining requirements is a top-down means of determining requirements based on the needs of the organization. For this reason it is well-suited for requirements analysis for large systems with many stakeholders and an audience with multiple and sometimes conflicting interests. The CSF analysis method begins with a mission statement and then begins to divide the mission statement into a set of very high-level goals. These high-level goals are then further divided into Critical Success Factors, which themselves are then further broken down into multiple levels of a hierarchy, becoming more concrete. At the lowest level, each CSF becomes a requirement for the system; a single, well-defined task that must be accomplished in order to be successful. Along the way, problems to be solved and assumptions made are recorded.

Once the CSF hierarchy is established and a set of requirements has been derived, these can then be arranged into a matrix for comparison with the problems identified. In order to be considered complete, each problem must be fully addressed by one or more requirements.

By analyzing the steps necessary to achieve success, and cross-referencing them against problems to be solved, a complete set of requirements can be determined that can then be correlated with specific user scenarios. Each of the requirements should apply to at least one user scenario, and generally more than one.

This methodology allows requirements to be determined that satisfy the needs of the organization and those of the user. Since architectural frameworks are built and maintained by organizations, this method allows us to create a well-defined and reasonably complete set of requirements.

3 The Analysis Hierarchy

3.1 Mission Statement

3.1.1 Mission

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

3.1.2 Users of Web Services Architecture

This document envisions three distinct groups of users of the standard reference architecture for Web Services. The primary audience for whom the reference architecture is intended is the IT community and developers who wish to deploy Web Services or to develop software that enables the use of Web Services. Another intended group of users is that of other W3C Working Groups who are developing the technologies identified for use within the reference architecture. The third intended audience is the Web Services Architecture Working Group itself, in order to fully realize the promise of Web Services.

3.2 Goals

3.2.1 Top-level Goals

The Working Group has determined that at the highest level, its goals can be divided into 6 categories. Each of these is associated with the CSFs and requirements listed in section 3.2.2

Top-level Goals for the Web Services Architecture

  • D-AG001 Interoperability

    The Web Services Architecture SHOULD enable the development of interoperable Web services across a wide array of environments.

    Critical success factors and requirements for this goal:

    • D-AC001 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.

    • AC004 does not preclude any programming model.

    • AC023 is comprised of loosely-coupled components and their interrelationships.



    In addition, the Web Services Architecture Working Group will:

    • D-AC016 examine architectural and technology issues that might prevent interoperability, and recommend existing standards and technologies where available.



  • AG002 Reliability

    The Web Services Architecture must be reliable and stable over time.

    Critical success factors and requirements for this goal:

    • AC019 enables conforming Web services to be reliable, stable, and evolvable over time.



  • AG003 Integration with the World Wide Web

    The Web Services Architecture must be consistent with the current and future evolution of the World Wide Web.

    Critical success factors and requirements for this goal:

    • AC009 SHOULD avoid any unnecessary misalignment with the Semantic Web.

    • AC011 is consistent with the architectural principles and design goals of the existing Web.

    • AC021 ensures device independence of Web services.

    • AC022 conforms to the internationalized character model defined in "Character Model for the World Wide Web" Recommendation



  • AG004 Security

    The Web Services Architecture must provide a secure environment for online processes.

    Critical success factors and requirements for this goal:

    • AC006 addresses the security of Web services across distributed domains and platforms.

    • AC020 enables privacy protection for the consumer of a Web service across multiple domains and services.



  • AG005 Scalability and Extensibility

    The web services architecture must promote implementations that are scalable and extensible.

    Critical success factors and requirements for this goal:

    • AC002 provides for modular web services architecture components, with each at a level of granularity appropriate to meet the other goals.

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

    • AC005 applies the principle of simplicity and is defined such that it does not impose high barriers to entry for its intended audience.

    • D-AC017 provides guidance for the development of the Web services infrastructure needed to implement common business functions in a standards-based environment.



  • AG006 Team Goals

    The Web Services Architecture Working Group will work to ensure that the Architecture will meet the needs of the user community.

    Critical success factors and requirements for this goal:

    • AC007 is reliable, stable, and evolves over time.

    • AC008 is consistent and coherent. This applies to both the reference architecture itself and the document that contains its definition.



    In addition, the Web Services Architecture Working Group will:

    • AC012 identify or create user scenarios and use cases that support and illustrate the requirements and web services architecture.

    • AC013 co-ordinate with other W3C Working Groups, the Technical Architecture Groups and other groups doing Web services related work in order to maintain a coherent architecture for Web services.

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



  • D-AG007 Management and Provisioning

    The standard reference architecture for Web Services must provide for a manageable, accountable and organized environment for Web Services operations..

    Critical success factors and requirements for this goal:

    • D-AC018 The Web Services Architecture must enable the management and provisioning of Web Services





3.2.2 Critical Success Factors and Requirements

The Web Services Architecture Working Group has identified the following CSFs and requirements for the Web Services Architecture.

Each of the following CSFs is stated as a predicate to the following statement except where noted.

To develop a standard reference architecture for Web services that:

D-AC001

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

  • D-AC001.1 - Encourage the development of interoperable software products.

    • D-AC001.1.1 - Ensure that no individual implementor is favored over others.

    • D-AC001.1.2 - Identify all interfaces and messaging protocols within the architecture in a standardized way.

  • D-AC001.2 -Ensures that the development of standards-based technologies identify conformance in such a way that testing software can be constructed..



AC002

provides for modular web services architecture components, with each at a level of granularity appropriate to meet the other goals.

  • AC002.1 - provides conceptual integrity, i.e. a unified theme rather than a set of disjoint ideas, which generally characterizes designs that are easy to understand and implement.

    • AC002.1.1 - Reduce complexity by decomposition of the component's functionality and its position within the architecture

    • AC002.1.2 - Eases development and maintenance of implementations of the architecture by defining architectural components that are logical, consistent, and thus easy to understand.



  • D-AC002.2 - removed

  • D-AC002.3 - Provide for Increased flexibility and maintainability because single components can be upgraded or replaced independently of others



AC003

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

  • AR003.1 separates the transport of data or means of access to Web services from the Web services themselves.

  • D-AR003.3 technologies following this architecture should not impede the development of complex interaction scenarios likely for future business interactions

  • AR003.4 modules that are orthogonal must be allowed to evolve independently of each other and still work within the architecture



AC004

does not preclude any programming model.

The Web Services Architecture should:

  • AR004.2 is comprised of loosely-coupled components and their interrelationships.



AC005

applies the principle of simplicity and is defined such that it does not impose high barriers to entry for its intended audience

The reference architecture should be easily understandable by the target audience.

  • AC005.2 it is stated in simple declarative sentences

  • AC005.3 The Web Service Architecture identifies and defines all of its components precisely and unambiguously.

    • AC005.3.1. There is a unique identification scheme for identifying each component, and all components are identified using this identification scheme.

    • AC005.3.2 The terms and language used to describe the Web Services Architecture and its components are unambiguously defined.

  • AC005.4 it uses illustrations to visually describe key components and relationships



The reference architecture should be as minimal as possible

  • AC005.5 The reference architecture will use the minimum number of components required for a coherent and complete description of the web service architecture.

  • AC005.6 The reference architecture will avoid redundancies when describing relationships between components.



The reference architecture should simplify the task of a programmer writing interoperable implementations of specifications of components described by the architecture.

  • AC005.9 the role played by each component in the overall architecture is clearly stated

  • AC005.10 the interdependencies among components are noted explicitly

  • AC005.11 existing specs that fulfill the role of a given component are referenced



AC006

addresses the security of Web services across distributed domains and platforms

  • AC006.1 The construction of a Web Services Threat Model based on thorough analysis of existing and foreseeable threats to Web service endpoints and their communication.

  • AC006.2 The establishment of a set of Web Services Security Policies to counter and mitigate the security hazards identified in the threat model.

  • AC006.3 The construction of a Web Services Security Model that captures the security policies.

  • AC006.4 The realization of the security model in the form of a Web Services Security Framework that is an integral part of the Web Services Architecture.

Requirements

  • AR006.1 The WG SHOULD consider the threat of Accessibility attacks ([D]DOS, DNS spoofing, etc.) in the security framework.

  • AR006.2.1 The security framework must enable Authentication for the identities of communicating parties.

  • AR006.2.2 The security framework MUST enable persistent and transient authentication of authorship of data.

  • AR006.3 The security framework must enable Authorization

  • AR006.4 The security framework must enable Confidentiality.

  • AR006.5 The security framework must enable (data) Integrity.

  • AR006.6 The security framework MUST enable non-repudiation of origin and receipt between transacting parties

  • D-AR006.7 The security framework SHOULD enable key management and key distribution.

  • AR006.10.1 WS security framework MUST provide a means of expressing security policy.

  • AR006.10.2 WS security framework MUST provide a means to access a web service's security policy.

  • D-AR006.12 The security framework must include Auditing.

  • D-AR006.13 Where a web service provides security features in line with AR006, it SHOULD provide the ability to manage that security in a meaningful way.

AC007

The Web Service Architecture is reliable, stable, and evolves over time.

AC007.1 The Web Service Architecture is reliable.

  • AC007.1.1 The Web Service Architecture is precisely defined without ambiguity,

    • AR007.1.1.1 using standard definition languages whenever applicable and available,

    • AR007.1.1.2 using standard terms, and clearly defined new terms.

  • D-AC007.1.2 Reliability of Web Service Architecture is enabled by AC008,AC011,AR012.5 and AR012

AC007.2 The Web Service Architecture is stable and evolves over time.

  • AR007.2.1 The Web Service Architecture has stable conceptual models, definitions, assumptions, and scopes.

  • AR007.2.2 The Web Service Architecture is governed by a well defined versioning policy.

  • AC007.2 .3 Newer versions of Web Service Architecture should be compatible with older versions.

    • AR007.2.3.1 When a component within the Web Service Architecture changes, the change is precisely identified, and the changed Web Service Architecture is reliable.

    • AR007.2.3.2 The assumptions behind a change in the component, and its scope must be clearly stated.

AC008

is consistent and coherent. This applies to both the reference architecture itself and the document that contains its definition.

  • AC008.1 Simple visualization of architecture in the form of a two-dimensional diagram

  • AC008.4 Architecture does not do the same or similar things in mutually incompatible ways; it is not self-contradictory.

  • AC008.6 The definition and use of the components is consistentwithin the Web Service Architectureand the architecture document itself.

AC009

SHOULD avoid any unnecessary misalignment with the Semantic Web

  • AR009.2 new Web services technologies, developed by W3C Web Services WGs, SHOULD be capable of being mapped to RDF/XML.

  • AR009.3 All conceptual elements should be addressable directly via a URI.

  • AR009.4 It should be possible to characterize the semantics of a web service using technologies adopted as part of the Semantic Web.

  • AR009.5 Web services should be capable of being represented as Concepts in W3C OWL

AC011

is consistent with the architectural principles and design goals of the existing(?) Web. These principles and design goals are generally outlined in [TAGTOC], [AXIOMS], [WEBAT50K], and in [REST].

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

  • AC010.1 Each new architectural area that has a representation SHOULD be normatively defined using XMLSchema.

  • AC011.2 recommends the use of existing Web technologies that adhere to the architectural and design principles of the Web and that provide clear functional coverage of the responsibilities and constraints for an identified architectural component.

  • AC011.3 recommends the design of new Web technologies that adhere to the architectural and design principles of the Web to provide functional coverage of the responsibilities and constraints for an identified architectural component.

    Derived requirements:

  • AR011.1 Web Services Architecture Working Group must closely monitor the deliverables of the TAG as they further refine and or document the architecture and design principles of the Web

AC012

The Web Services Architecture Working Group will identify, or create, usage scenarios and use cases that support and illustrate the requirements and Web services architecture

  • AR012.1 - terms must be well defined and used consistently

  • AR012.2 - use cases organized around usage scenarios, usage scenarios should reflect common usage patterns for architecture

  • AR012.3 - target audience for architectural deliverables must be defined

  • AR012.5 - architecture should support use cases for all aspects of Web services.

  • AC012.7 The Web Service Architecture must be validated against Web Service Architecture use cases.



AC013

The Web Services Architecture Working Group will co-ordinate with other W3C Working Groups, the Technical Architecture Groups and other groups doing Web services related work in order to maintain a coherent architecture for Web services

  • AR013.2 The documents produced are used as input to charter new Web services Working Groups.

  • AR013.3 Maintain liaisons with relevant external groups, such as the ones listed in the charter and possibly others.

AC015

The Web Services Architecture Working Group will organize its efforts in such a way as to address vital time-to-market issues for its products, including iterating over successive refinements of the overall requirements for the standard reference architecture.

D-AC016

The Web Services Architecture Working Group will examine architectural and technology issues that might prevent interoperability, and recommend existing standards and technologies where available. Also to recommend the formation of new Working Groups to develop areas of the Web Services Architecture where the need for standardization and specification has been identified.

The Web Services Architecture WG should:

  • AR016.1 Identify what constitutes interoperability

    • D-AR016.1.1 in architectural realm.

    • D-AR016.1.2 in technological realm.

  • AR016.2. Identify existing

    • D-AR016.2.1 architecture that supports interoperability

    • AR016.2.2 technologies that support interoperability

  • AR016.3. Identify gaps

    • AR016.3.1 in architectural realm.

    • AR016.3.2 in technological realm.

  • D-AR016.4 Formation of WGs to address gaps

    • D-AR016.4.1 in architectural realm.

    • D-AR016.4.2 in technological realm.

D-AC017

provides guidance for the development of the Web services infrastructure needed to implement common business functions in a standards-based environment

  • D-AR017.1 The Web services Architecture must support common business functions, to the extent that those functions are defined in similar methodologies such as EDI.

  • D-AR017.2 The Web services Architecture must support reliable messaging and routing.

  • D-AR017.3 The Web services Architecture must support unique message IDs and message sequencing.

  • D-AR017.4 The Web services Architecture must support reliable transaction processing.

D-AC018

The Web Services Architecture must enable the management and provisioning of Web Services

  • AC018.1 Ensure that implementations of the Web Services Architecture are manageable.

    • AR018.1.1 Define a base set of standard metrics for architectural components and their interactions accompanied by guidelines for measurement.

    • AR018.1.2 Define a base set of standard management operations for Web Services Architecture implementations. Management operations includes, but is not limited to, support for configuration control and lifecycle control.

    • AR018.1.3 Define a base set of management events to be issued by the Web Services Architecture implementation.

    • AR018.1.4 Define a standard methodology for accessing management capabilities from the Web Services Architecture implementation.

  • AC018.2 Ensure that implementations of the Web Service instances are manageable.

    • AR018.2.1 Define how a web service should expose web service specific metrics, configuration, operations, and events.

    • AR018.2.2 Support the discovery of web service management capabilities.

    • AR018.2.3 Define a standard methodology for accessing management capabilities of a Web Service through the Web Services Architecture implementation.

  • AC018.3 Ensure that at least the following types of management aspects are supported: Resource Accounting, Usage Auditing and Tracking, Performance Monitoring, Availability, Configuration, Control, Security Auditing and Administration, and Service Level Agreements.

AC019

enables conforming Web services to be reliable, stable, and evolvable over time.

  • AR019.1 Web services conforming to Web Service Architecture can be reliably discovered, accessed, and executed.

    • AR019.1.2 Web Services Architecture will enable the availability constraints of a Web service to be known to its clients.



  • AR019.2 The Web services Architecture enables a conforming Web service implementation to be stable with respect to its definition.

    • AR019.2.1 A Web Service can be defined independent of its implementation.

    • AR019.2.2 The Web Service Architecture enables a Web Service implementation to be stable based on service agreements.

  • AC019.3 The Web Service Architecture enables a conforming Web Service definition to be evolvable by ensuring it is governed by a well defined versioning scheme for Web services that is made available independent of the service.

AC020

enables privacy protection for the consumer of a Web service across multiple domains and services.

  • AC020.1The Web Services Architecture MUST enable privacy policy statements to be expressed about Web services.

  • AC020.2 Advertised Web Service privacy policies MUST be expressed in P3P.

  • AC020.3 The Web Services Architecture MUST enable a consumer to access a Web Service's advertised privacy policy statement.

  • D-AC020.5 The Web Services Architecture MUST enable delegation and propagation of privacy policy.

AC021

ensures device independence of Web services.

  • AR021.1 Assumes no specific device or level of connectivity for clients or servers so that wireless, intermittently connected, mobile and strongly connected devices are supported.

  • AR021.2 Makes no assumptions about the utility or visibility of services based on user locality.

  • AR021.3 Assumes a spectrum of device capabilities (from high end servers to handheld devices).

AC022

conforms to the internationalized character model defined in "Character Model for the World Wide Web" Recommendation [CHARMOD]

D-AC023

is comprised of loosely-coupled components and their interrelationships.

  • AR023.1 components are defined in terms of unambiguous, well-defined interfaces.

  • AR023.2 components are described by their functional roles and responsibilities.

  • D-AR023.3 component interfaces define their inputs and outputs and also the form and constraints on those inputs and outputs.

  • D-AR023.4 component relationships are described in terms of messages and message transmission protocols.

  • AR023.5 messages are transmitted and consumed by the component interfaces that make up the architecture.

  • AR023.6 support XML based techniques for defining messages/protocols for invoking web resources.

  • AR023.7 support both early and late client binding to web services.

    • AR023.7.1 defines or identifies a base interface that all Web services can implement, that permits communication without a priori knowledge of the service.



4 Acknowledgments

The editors would like to thank the following Working Group members for their contributions to this document: Mark Baker, Doug Bunting, Mike Champion, Roger Cutler, Suresh Damodaran, Paul Denning, Zulah Eckert, Chris Ferris, Hugo Haas, Hao He, Dave Hollander, Joe Hui, Yin-Leng Husband, Mike Mahan, Francis McCabe, Nilo Mitra, Dave Orchard

This document is a product of the Web Services Architecture Working Group whose members are:

Members of the Working Group are (at the time of writing, and by alphabetical order):



Previous members of the Working Group were:

5 References

5.1 Normative References

TAGTOC
TAG Architecture Categorization (See http://www.w3.org/2001/tag/doc/toc.)
AXIOMS
Universal Resource Identifiers -- Axioms of Web Architecture, Berners-Lee, T. , 1996 (See http://www.w3.org/DesignIssues/Axioms.html.)
WEBAT50K
Web Architecture at 50,000 Feet, Berners-Lee, T., 1998 (See http://www.w3.org/DesignIssues/Architecture.html.)
REST
Architectural Styles and the Design of Network-based Software Architectures, Fielding, R., 2000 (See http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.)
CHARMOD
Character Model for the World Wide Web 1.0 (See http://www.w3.org/TR/charmod/.)

5.2 Informative References

CSF-Primer
A Primer on Critical Success Factors, MIT Sloan School of Management Working Paper, Bullen, C. and J. Rockart, 1220-81

6 Change Log

Date Editor Description
20020818 DBA * changed dates * changed stylesheet
20020805 DBA * made updates as per Working Group resolution thru 0805: * changed heading of section 1.2 * modified text in section 3.2.1 * added D-AG007 * moved D-AC018 under D-AG007 * replaced entire text of D-AC018 * added D-AR007.1.2 * modified text of AR019.1.2 * reformatted acknowledgements list
20020731 CF added bibref to CHARMOD, applied some missing resolutions from 18 July telcon
20020729 CF applied all resolutions from 18-Jul and 25-Jul TCs as outlined in @@@
20020715 SG applied all resolutions from 27-Jun and 11-Jul TCs as outlined in http://lists.w3.org/Archives/Member/w3c-wsa-editors/2002Jul/0013.html
20020626 CF applied all resolutions from 20-Jun TC as outlined in http://www.w3.org/2002/ws/arch/2/06/20-minutes#new-ai
20020614 CF applied all resolutions from f2f as outlined in http://lists.w3.org/Archives/Member/w3c-ws-arch/2002Jun/0053.html
20020605 CF Incorporated changes from editor's todo list as generated from WG decisions. Remove 'D-' designator for: AG004, AC006, D-AR006.2.1, D-AR006.4, D-AR006.5 D-AR006.3 - strike ", with allowance for the coexistence of dissimilar authorization models." and remove 'D-' status designator D-AG001 new wording: "The Web Services Architecture SHOULD enable the development of interoperable Web services across a wide array of environments." remove D-AC001.3 and D-AC001.3.1 D-AR006.11 remove bulleted text D-AR006.12 add Auditing as requirement [13] D-AR006.13 -- guidelines for ws sec admin[14] add Mark B's a priori requirement as D-AR003.6[15] [13] http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0217.html [14] http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0248.html [15] http://lists.w3.org/Archives/Public/www-ws-arch/2002May/0243.html
20020605 DA Modified text based on meeting notes. Changed # 6, 9, 11, 21, 16,12,20,10. Corrected spelling and typography. Changes tracked since last draft.
20020605 abbie 1) Remove draft designation from following items: D-AC003, D-AR003.4, D-AG006, D-AC008, D-AC008.1, D-AC008.4, D-AC0012, D-AR012.1, D-AR012.2, D-AR012.3, D-AC013, D-AR013.2, D-AR013.3, D-AC015 2) remove draft designation from D-AG005 and adopt revised wording: the web services architecture must promote implementations that are scalable and extensible 3) D-AC002.1.1 - rearrange the text. Approved with that proviso - draft status should be removed. 4) D-AC012.5 clarify around "level" - remove draft status with this proviso. 5) D-AC012.6 - remove from spec. 6) Rephrase all sect D-AC005 requirements as imperatives, in particular 5.1 through 5.12. Remove draft designation from: D-AC005.2, D-AC005.3, D-AC005.4, D-AC005.9, D-AC005.11, D-AC015.2, D-AC015.4 7) remove D-AC008.3, D-AR013.1 8) remove items: D-AC002.1.2.1, D-AC002.3.1, D-AR003.6, D-AC005.12 9) replace D-AC020 and subordinates with following: D-AC020 To develop a standard reference architecture for Web services that enables privacy protection for the consumer of a Web service across multiple domains and services. D-AC020.1 A Web service provider SHOULD make its privacy policy available to the Web service's consumers. D-AC020.2 A Web service's advertised privacy policy MUST be expressed in P3P. D-AC020.3 a Web service consumer MUST be capable of accessing a Web service's P3P policy statement. D-AC020.4 Private data acquisition during a Web service transaction MUST NOT exceed the consumer's consent.
20020531 SG 1) D-AG001 new wording: "The Web Services Architecture SHOULD enable the development of interoperable Web services across a wide array of environments." 2) Remove D-AC001.3 and D-AC001.3.1 3) Remove D-AC004.1 (decided in May 23 concall see minutes [1]). Should I change D-AC004.2 to D-AC004.1, and D-AC004.3 D-AC004.2? 4) Updated D-AC004 as follows: (as decided in May 23 concall see minutes [1]). D-AC004 does not preclude any programming model Note that I have commented the original D-AC004 in this version, just in case if we need it. 5) Added a new CSF D-AC021 (as decided in May 23 concall see minutes [1]). D-AC021 ensures device independence of Web services D-AC021.1 Assumes no specific device or level of connectivity for clients or servers so that wireless, intermittently connected, mobile and strongly connected devices are supported. D-AC0021.2 Makes no assumptions about the utility or visibility of services based on user locality. D-AC0021.3 Assumes a spectrum of device capabilities (from high end servers to handheld devices). 6) Added one more CSF D-AC021 to D-AG003 Web-friendly (as decided in May 23 concall see minutes [1]).
20020426 HH Fixed typos
20020426 CBF Removed duplicate entry for D-AC006.2, 6.3 and 6.11, fixed typos
20020425 HH Added D-AR006.10, fixed typo
20020425 CBF fixed links that link checker complained about
20020425 HH Accessibility tweaks, removed prevloc, specified status, pubrules compliance
20020425 CBF tweaked curr, latest uri for candidate WD
20020424 DBA made changes based on suggestions to the list, also changed wording of 16
20020423 DBA tried to clean up each goal, modified top-level goal text, general document repair, relettering, status section, publishing details.
20020422 DBA integrated many changes, modified document structure
20020422 abbie changed goal 11 and renumbered the sub gaols
20020418 CBF Relocated RFC2119 section. Incorporated abstract into introduction. Revised vision, fixed a few typos, assigned numbering scheme to CSFs and Requirements, updated D-AG0003 - D-AG0008. Releveled things a bit. Removed Usage Scenarios (now separate document). References tweaked. Incorporated Hugo's revised Status section.