Web Services Architecture Requirements

Editor's Draft 26 June 2002

This version:
http://www.w3.org/TR/2002/WD-wsa-reqs-20020605
Latest version:
http://www.w3.org/TR/wsa-reqs
Previous versions:
http://www.w3.org/TR/2002/WD-wsa-reqs-20020429http://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>
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 document is an editors' copy that has no official standing.

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

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

This first version of the requirements document is an early snapshot: it may contain conflicting and incomplete requirements and goals. The next version that the Working Group will publish will be more complete and polished.

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


Short Table of Contents

1. Introduction
2. Requirements Analysis Method
3. The Analysis Hierarchy
4. Acknowledgments
5. References
6. Change Log


Table of Contents

1. Introduction
1.1 What is a Web service?
1.2 Notational Conventions
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
3.3 Analysis Matrix: Problems vs. CSFs
3.4 Analysis Matrix: User Scenarios vs. CSFs
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 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]

1.2 Notational Conventions

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

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

The W3C Web Services Reference Architecture is intended primarily for the W3C Web Services Architecture Working Group to analyze, prioritize and characterize the technologies that are needed to fully realize an interoperable and extensible realization of the promise of Web Services. It is also intended for the use of other working groups specifying the technologies identified and described in the architecture. A secondary target audience for the architecture are the developers implementing the specified technologies, and the wider IT community that uses these technologies to deploy 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 for this goal:

  • D-AG002 Reliability

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

    Critical Success Factors for this goal:

  • D-AG003 Web-friendly

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

    Critical Success Factors for this goal:

  • AG004 Security

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

    Critical Success Factors for this goal:

  • AG005 Scalability and Extensibility

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

    Critical Success Factors for this goal:

  • 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 for this goal:

3.2.2 Critical Success Factors and Requirements

Proposed lower-level goals and CSFs 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:

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

D-AC002

provides modularity of Web Services components, allowing for a level of granularity sufficient to meet business goals

  • D-AC002.1 - Provide conceptual clarity to allow developers to share ideas and code

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

    • D-AC002.1.2 - Ease development, testing, and maintenance by providing a logical, easy to understand, and consistent organization

    • D-AC002.1.3 - Allow the creation of generic rules, methods, and procedures to aid in consistent development practices

  • D-AC002.2 - Support object-oriented design principles by encouraging encapsulation and information hiding by components of the architecture

    • D-AC002.2.1 - Encourage reuse by creating well-defined modules that perform a particular task

    • D-AC002.2.2 - Allow the creation and deployment of configurable objects that the end user can tailor for different purposes in a standard way.

  • 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

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

  • D-AR003.2 description of Web Services be clearly separated into abstract descriptions ("what") from their concrete realizations ("how"), or put another way, separate design time aspects from run-time aspects

  • 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

  • D-AR003.5 modularity must support common business functions such as reliability, security, transactions, etc.

  • D-AR003.6 defines or identifies a base interface that all Web services can implement, that permits communication without a priori knowledge of the service.

D-AC004

does not preclude any programming model

  • D-AC004.2 Interfaces to web resources must be properly defined and designed.

  • D-AC004.3 Focus on defining the architecture in terms of components and the relationships between them. Components are defined in terms of interfaces, that define their inputs and outputs and also the form and constraints on those inputs and outputs. The relationships between components are described in terms of messages and the protocols by means of which these messages are transmitted among the interfaces of the components that make up the architecture.

The Web Services Architecture should:

  • D-AR004.1 provide consistent definition of web resources

  • AR004.2 provide well-defined interfaces for Web Services

  • D-AR004.3 use XML based techniques for defining messages/protocols for invoking web resources

D-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. At this stage all this goal requirements are imperative.

  • D-AC005.1 it avoids specialized jargon not familiar to ordinary software designers

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

  • D-AC005.7 How do these figures compare to those of notable exemplars of good reference architectures?

  • D-AC005.8 Could any components or relationships be removed without significantly limiting the value of the architecture?

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

The reference architecture should simplify the task of an application programmer using the specifications it describes.

  • D-AC005.13 the reference architecture does not force a programmer to use exotic constructions

  • D-AC005.14 the architecture can be implemented without large amounts of code

  • D-AC005.15 it allows simple invocations as well as elaborations with more functionality when building Web Services or applications that employ web services

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

  • There are six aspects in the security framework for Web Services architecture: Accessibility, Authentication, Authorization, Confidentiality, Integrity, and Non-repudiation. Together they form the foundation for secure Web Services.

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

    Editorial note
    Feedback requested. The WG is seriously considering removing this requirement. If you would be opposed to its removal, please send comment to www-wsa-comments@w3.org.
  • D-AR006.8 The security framework document SHOULD provide some guidelines for securing private keys, though the methods for securing private keys is outside the scope of the architecture.

  • D-AR006.9 The security framework document SHOULD recommend a baseline for trust models.

  • 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.11 The architecture must provide an interface for Web Services to directly communicate with their underlying infrastructure.

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

    Editorial note
    glossary definition pending
  • 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.

D-AC007

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

D-AC007.1 The Web Service Architecture is reliable.

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

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

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

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

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

  • D-AC007.2.2 The Web Service Architecture is governed by a well defined versioning policy.

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

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

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

  • D-AC007.2.4 The evolution of identified technologies should be considered especially with reference to other industry standards.

D-AC007.3 Predictable Evolution of Architecture

  • D-AC007.3.1 The reference architecture must define a framework for growth of the architecture.

  • D-AC007.3.2 Non-normative extension guidelines to be specified for each standard

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

  • D-AC008.2 Architecture supports the concepts used in commonly accepted design patterns.

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

  • D-AC008.5 There shall not be wildly different means to achieve the same ends in the architecture.

  • D-AC008.6 The definition and use of the components is consistent within the Web Service Architecture.

AC009

SHOULD avoid any unnecessary misalignment with s/w

  • 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 representable as Concepts in W3C OWL

D-AC011

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

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

    Derived critical success factors:

    • D-AC011.2.1 Uses a standard identifier technology (URI)

    • D-AC011.2.2 Uses a standard transport/transfer technology

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

      • D-AC010.1Each new architectural area has its representation normatively defined in a syntactic schema language defined in a W3C Recommendation
        Editorial note
        proposal from chair

  • D-AR011.1 WSAWG must closely monitor the deliverables of the TAG as they further refine and or document the architecture and design principles of the Web

AC012

identify or create user 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

  • D-AR012.4 - usage scenarios and use cases must be referencable via URI(reference)

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

  • D-AR012.6 - usage scenarios and use cases shall be used as justification for recommending the formation of new WSA WGs

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

AC013 (subsumes D-AC014)

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

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-AC015.1 Is the Web Services Activity a center for Web Services standards specification, that is is the community able to start new working groups in a manner that is usable by the community?

  • AC015.2 Is the WSA perceived as a reliable forum for architectural guidance? Do other working groups ask for advice from the WSA, or do they not bother?

  • D-AC015.3 Is the WSA document perceived as usable and referenceable in time for products? New/revised products would be able to reference this WSArch doc if it was delivered in time for their products.

  • AC015.4 Does the WSA demonstrate a reasonable number of re-use decisions rather than re-inventing?

  • D-AC015.5 Is the architecture document regularly revised?

  • D-AC015.6 Is the architecture document regularly referenced by other specifications, including but not limited to W3C specifications?

  • D-AC015.7 Is there a lack of press/developer commentary that refers to time-to-market problems with WSA? To paraphrase, no press is good press on this issue.

D-AC016

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

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 measurement of these metrics and instrumentation for management of Web Services.

  • D-AC018.1 Develop a standard convention of measuring Web Services metrics so different service providers, implementors and consumers can reach service level agreements.

    • D-AC018.1.1 The standard should include definitions of metrics such as Quality of Service, Reliability of Service and other metrics.

    • D-AC018.1.2 The reference architecture should provide guidelines on measuring those metrics.

    • D-AC018.1.3 Metrics can be independently verified.

  • D-AC018.2 Define standard management instrumentations of Web Services.

    • D-AC018.2.1 The standard should define, but not limited to, instrumentations such as starting, suspending, and retiring services.

    • D-AC018.2.2 The instrumentations should conform to other goals of this working group.

    • D-AC018.2.3 The definition of management framework is out of scope. There are a number of such technologies available: www.dmtf.org.

    • D-AC018.2.4 The instrumentations may be exposed as Web Services.

  • D-AC018.3. Clearly define and publish reference architecture for implementors.

    • D-AC018.3.1 Clearly define and publish reference Web Services management model.

    • D-AC018.4 security policies, handling various QoS aspects, negotiation of service level agreements (SLAs) must be facilitated by technologies conforming to this architecture.

D-AC019

ensure reliable, stable, and predictably evolvable Web Services.

  • D-AC019.1 Web Services created using WSA can be reliably discovered, accessed, and executed.

  • D-AC019.2 Web Services created using WSA can be implemented such that they are stable with respect to their definitions.

  • D-AC019.3 Web Services created using WSA may be evolved/extended while maintaining their reliability and stability.

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.

  • 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.4 Private data acquisition during a Web service transaction MUST NOT exceed the consumer's consent.

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

D-AC021

ensures device independence of Web Services.

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

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

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

3.3 Analysis Matrix: Problems vs. CSFs

Editorial note
TBD

3.4 Analysis Matrix: User Scenarios vs. CSFs

Editorial note
TBD

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, Chris Ferris, Hugo Haas, Hao He, Dave Hollander, Joe Hui, Yin-Leng Husband, Mike Mahan, Nilo Mitra, Dave Orchard

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

Editorial note
todo: re-sort list by last name
AppleMike Brumbelow
Artesia TechnologiesDipto Chakravarty
AT&TMark Jones
AT&TAyse Dilber
BEA SystemsDavid Orchard
Boeing CompanyGerald Edgar
Carnegie Mellon UniversityKatia Sycara
ChevronTexacoRoger Cutler
Cisco Systems IncSandeep Kumar
Cisco Systems IncKrishna Sankar
Hewlet PackardYin-Leng Husband
Computer AssociatesIgor Sedukhin
ContivoDave Hollander
CrossWeave, Inc.Timothy Jones
DaimlerChrysler Research and TechnologyMario Jeckle
DaimlerChrysler Research and TechnologyHans-Peter Steiert
DISAMarcel Jemio
DocumentumDon Robertson
EDSMike Ballantyne
EDSWaqar Sadiq
EricssonNilo Mitra
Exodus/Digital IslandJoseph Hui
France TelecomShishir Garg
FujitsuFrancis McCabe
Hewlett-Packard CompanyZulah Eckert
IBMHeather Kreger
IBMJim Knutson
Intalio IncBob Lojek
Intel CorporationSharad Garg
Intel CorporationJoel Munter
IONASteve Vinoski
IONAEric Newcomer
IpedoSrinivas Pandrangi
IpedoAlex Cheng
MacromediaGlen Daniels
MacromediaTom Jordahl
MartSoft Corp.Jin Yu
MartSoft Corp.Jun Chen
Microsoft CorporationAllen Brown
Microsoft CorporationHenrik Nielsen
MITRE CorporationJames Davenport
MITRE CorporationPaul Denning
NokiaMichael Mahan
Nortel NetworksAbbie Barbir
Oracle CorporationMartin Chapman
Oracle CorporationJeff Mischkinsky
Planetfred, Inc.Mark Baker
Rogue Wave SoftwarePatrick Thompson
Rogue Wave SoftwareDavid Noor
SAPSinisa Zimek
SeeBeyond Technology CorpAlan Davies
Software AGMichael Champion
Software AGNigel Hutchison
Sterling Commerce(SBC)Suresh Damodaran
Sun Microsystems, Inc.Chris Ferris
Sun Microsystems, Inc.Doug Bunting
Sun Microsystems, Inc.Mark Hapner
Sybase, Inc.Himagiri Mukkamala
SystinetAnne Thomas Manes
The Thomson CorporationHao He
TIBCO Software, Inc.Scott Vorthmann
T-Nova Deutsche Telekom InnovationsgesellschaftJens Meinkoehn
VeriSign, Inc.Michael Mealling
W. W. Grainger, Inc.Tom Carroll
W. W. Grainger, Inc.Daniel Austin
W3CHugo Haas
W3CDavid Booth
Waveset TechnologiesDarran Rolls
webMethods, Inc.Prasad Yendluri
XQRL Inc.Tom Bradford
XQRL Inc.Daniela Florescu

Former members of the WG:

CompaqKevin Perkins

5. References

5.1 Normative References

[TAGTOC]
TAG Architecture Categorization (See http://www.w3.org/2001/tag/doc/toc.)
[AXIOMS]
Berners-Lee, T. Universal Resource Identifiers -- Axioms of Web Architecture, 1996 (See http://www.w3.org/DesignIssues/Axioms.html.)
[WEBAT50K]
Berners-Lee, T. Web Architecture at 50,000 Feet, 1998 (See http://www.w3.org/DesignIssues/Architecture.html.)
[REST]
Fielding, R. Architectural Styles and the Design of Network-based Software Architectures, 2000 (See http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.)
[BASS98]
Bass, L., Clements, P., and Kazman, R. Software Architecture in Practice. Reading, Mass.: Addison Wesley, 1998.
[Gallagher2000]
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.html.)

5.2 Informative References

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

6. Change Log

DateEditorDescription
20020626CFapplied all resolutions from 20-Jun TC as outlined in http://www.w3.org/2002/ws/arch/2/06/20-minutes#new-ai
20020614CFapplied all resolutions from f2f as outlined in http://lists.w3.org/Archives/Member/w3c-ws-arch/2002Jun/0053.html
20020605CFIncorporated 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
20020605DA Modified text based on meeting notes. Changed # 6, 9, 11, 21, 16,12,20,10. Corrected spelling and typography. Changes tracked since last draft.
20020605abbie1) 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.
20020531SG1) 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]).
20020426HHFixed typos
20020426CBFRemoved duplicate entry for D-AC006.2, 6.3 and 6.11, fixed typos
20020425HHAdded D-AR006.10, fixed typo
20020425CBFfixed links that link checker complained about
20020425HHAccessibility tweaks, removed prevloc, specified status, pubrules compliance
20020425CBFtweaked curr, latest uri for candidate WD
20020424DBAmade changes based on suggestions to the list, also changed wording of 16
20020423DBAtried to clean up each goal, modified top-level goal text, general document repair, relettering, status section, publishing details.
20020422DBAintegrated many changes, modified document structure
20020422abbiechanged goal 11 and renumbered the sub gaols
20020418CBFRelocated 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.