Web Services Architecture Requirements

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", "required", "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 (CSF) 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 7 categories. Each of these is associated with the CSFs and requirements listed in section 3.2.2 which further elaborate on each of the respective top-level goals. Of course, it is also important to recognize that an important motivation for the product of this Working Group is to support the needs of enterprises that use Web services for the purpose of engaging in e-business.

Top-level Goals for the Web Services Architecture (WSA):

AG001 Interoperability
The WSA should enable the development of interoperable Web services across a wide array of environments.
Critical success factors and requirements for this goal:
- 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:
- AC016 examine architectural issues that might pose an impediment to interoperability of implementations, and between components of the architecture.
AG002 Reliability
The WSA 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 WSA 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 [CHARMOD]
AG004 Security
The WSA 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 WSA must enable 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.
- AC017 must satisfy the requirements of enterprises wishing to transition from traditional EDI.
- AC024 must enable peer to peer interacting web services
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.
AG007 Management and Provisioning
The standard reference architecture for Web Services must provide for a manageable, accountable environment for Web Services operations.
Critical success factors and requirements for this goal:
- AC018 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 WSA.

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:

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

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.
AR003.3 technologies following this architecture should not impede the development of complex interaction scenarios
AR003.4 components of the architecture that are orthogonal must be allowed to evolve independently of each other and still work within the architecture
AR003.5 systems must not be precluded from quoting, either unmodified or modified, messages within other messages, to an arbitrary depth.

AC004

does not preclude any programming model.

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 the WSA is stated in simple, declarative sentences
AC005.3 the WSA 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 WSA and its components are unambiguously defined.
AC005.4 the WSA uses illustrations to visually describe key components and relationships

The reference architecture defined by the WSA should be as minimal as possible

AC005.5 the WSA will use the minimum number of components required for a coherent and complete description of the web service architecture.
AC005.6 the WSA will avoid redundancies when describing relationships between components.

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

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 WS security framework must enable Authentication for the identities of communicating parties.
AR006.2.2 the WS security framework must enable persistent and transient authentication of authorship of data.
AR006.3 the WS security framework must enable Authorization
AR006.4 the WS security framework must enable Confidentiality.
AR006.5 the WS security framework must enable (data) Integrity.
AR006.6 the WS security framework must enable non-repudiation of origin and receipt between transacting parties
AR006.10.1 the WS security framework must provide a means of expressing security policy.
AR006.10.2 the WS security framework must provide a means to access a web service's security policy.
AR006.12 the WS security framework must enable Auditing.
AR006.13 where a Web service provides security features in line with AR006, it should provide the ability to administer that security.

AC007

The WSA is reliable, stable, and evolves over time.

AC007.1 the WSA is reliable.

AC007.1.1 the WSA 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.

AC007.2 the WSA is stable and evolves over time.

AR007.2.1 the WSA has stable conceptual models, definitions, assumptions, and scopes.
AR007.2.2 the WSA is governed by a well defined versioning policy.
AC007.2 .3 newer versions of WSA 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 WSA 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 the WSA provides simple visualization of architecture in the form of a two-dimensional diagram
AC008.4 the WSA 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 consistent within the WSA and 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 the WSA must not preclude the characterization of a Web Service that attempts to make its semantics clear to an automatic system using technologies such as those adopted as part of the Semantic Web.
AR009.5 Web service descriptions should be capable of referencing concepts identified by a URI in an ontology, such as W3C OWL [OWL].

AC011

is consistent with the architectural principles and design goals of the 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 XML Schema.
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 the 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 WSA must be validated against WSA 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 the Working Group will maintain liaisons with relevant external groups, such as those 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.

AC016

The Web Services Architecture Working Group will examine architectural issues that might pose an impediment to interoperability of implementations, and between components of the architecture.

The Web Services Architecture WG should:

AR016.1 explore architectural relationships between components of the architecture.
AR016.2. identify architectural gaps or disconnects between components of the architecture.
AR016.3. recommend or solicit proposals for addressing any identified gaps and/or disconnects.
AR016.4 identify architectural principles and constraints that enable interoperability of implementations, and between components of the architecture.

AC017

The WSA must satisfy the requirements of enterprises wishing to transition from traditional EDI.

AR017.2 the WSA must support reliable messaging.
AR017.4 the WSA must support long running, stateful and choreographed interactions, both within and across trust boundaries.

AC018

The WSA must enable the management and provisioning of Web Services

AC018.1 ensure that implementations of the WSA 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 WSA 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 WSA 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 WSA can be reliably discovered, accessed, and executed.
- AR019.1.2 WSA will enable the availability constraints of a Web service to be known to its clients.
  Editorial note
  there has been some discussion as to whether consumers is the most appropriate term used in this context.
AR019.2 the WSA must enable 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 WSA must enable a Web service implementation to be stable based on service agreements.
AR019.3 the WSA must enable 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.

AR020.1 the WSA must enable privacy policy statements to be expressed about Web services.
AR020.2 advertised Web service privacy policies must be expressed in P3P [P3P].
AR020.3 the WSA must enable a consumer to access a Web service's advertised privacy policy statement.
AR020.5 the WSA must enable delegation and propagation of privacy policy.
AR020.6: Web Services must not be precluded from supporting interactions where one or more parties of the interaction are anonymous.

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]

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.
AR023.3 component interfaces define their inputs and outputs and also the format and constraints on those inputs and outputs.
AR023.4 component relationships are described in terms of messages and message exchange patterns.
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.

AC024

The WSA must enable peer to peer interacting web services

AR024.1 the WSA must support atleast the following peer to peer message exchange patterns:
- AR024.1.1 request-response
- AR024.1.2 publish-subscribe
- AR024.1.3 events and event notification
AR024.2 the WSA must not preclude persistent identities for peers
AR024.3 the WSA must not preclude determining capabilities for peers
AR024.4 the WSA must enable direct peer to peer interactions without the use of third party intermediaries
AR024.5 the WSA must not preclude the use of third party intermediaries (e.g. forwarding)
AR024.6 it must be possible for peers to discover each other

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): Daniel Austin (W. W. Grainger, Inc.), Mark Baker (Idokorro Mobile, Inc. (formerly Planetfred, Inc.)), Mike Ballantyne (EDS), Abbie Barbir (Nortel Networks), David Booth (W3C), Allen Brown (Microsoft Corporation), Mike Brumbelow (Apple), Doug Bunting (Sun Microsystems, Inc.), Greg Carpenter (Nokia), Dipto Chakravarty (Artesia Technologies), Jun Chen (MartSoft Corp.), Alex Cheng (Ipedo), Tom Carroll (W. W. Grainger, Inc.), Michael Champion (Software AG), Martin Chapman (Oracle Corporation), Ugo Corda (SeeBeyond Technology Corporation), Roger Cutler (ChevronTexaco), Jonathan Dale (Fujitsu), Suresh Damodaran (Sterling Commerce(SBC)), Glen Daniels (Macromedia), James Davenport (MITRE Corporation), Alan Davies (SeeBeyond Technology Corporation), Paul Denning (MITRE Corporation), Ayse Dilber (AT&T), Zulah Eckert (Hewlett-Packard Company), Gerald Edgar (The Boeing Company), Colleen Evans (Progress Software Corp.), Chris Ferris (IBM), Daniela Florescu (XQRL Inc.), Sharad Garg (Intel Corporation), Shishir Garg (France Telecom), Hugo Haas (W3C), Mark Hapner (Sun Microsystems, Inc.), Hao He (The Thomson Corporation), Dave Hollander (Contivo), Yin-Leng Husband (Hewlett-Packard Company), Nigel Hutchison (Software AG), Mario Jeckle (DaimlerChrysler Research and Technology), Mark Jones (AT&T), Timothy Jones (CrossWeave, Inc.), Tom Jordahl (Macromedia), Heather Kreger (IBM), Sandeep Kumar (Cisco Systems Inc), Hal Lockhart (OASIS), Bob Lojek (Intalio Inc), Michael Mahan (Nokia), Anne Thomas Manes (Systinet), Francis McCabe (Fujitsu), Michael Mealling (VeriSign, Inc.), Jens Meinkoehn (T-Nova Deutsche Telekom Innovationsgesellschaft), Jeff Mischkinsky (Oracle Corporation), Nilo Mitra (Ericsson), Himagiri Mukkamala (Sybase, Inc.), Joel Munter (Intel Corporation), Eric Newcomer (IONA), Henrik Nielsen (Microsoft Corporation), Jim Shur (Rogue Wave Software), David Orchard (BEA Systems), Srinivas Pandrangi (Ipedo), Fabio Riccardi (XQRL Inc.), Don Robertson (Documentum), Waqar Sadiq (EDS), Krishna Sankar (Cisco Systems Inc), Igor Sedukhin (Computer Associates), Hans-Peter Steiert (DaimlerChrysler Research and Technology), Katia Sycara (Carnegie Mellon University), Patrick Thompson (Rogue Wave Software), Steve Vinoski (IONA), Scott Vorthmann (TIBCO Software, Inc.), Prasad Yendluri (webMethods, Inc.), Jin Yu (MartSoft Corp.), Sinisa Zimek (SAP).

Previous members of the Working Group were: Tom Bradford (XQRL, Inc.), Joseph Hui (Exodus/Digital Island), Marcel Jemio (DISA), Jim Knutson (IBM), David Noor (Rogue Wave Software), Kevin Perkins (Compaq), Darran Rolls (Waveset Technologies, Inc.).

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, M. Dürst, F. Yergeau, R. Ishida, M. Wolf, A. Freytag, T. Texin, W3C Working Draft 30 April 2002 (See http://www.w3.org/TR/charmod/.)
[P3P]: The Platform for Privacy Preferences 1.0 (P3P1.0) Specification, L. Cranor, M. Langheinrich, M. Marchiori, M. Presler-Marshall, J. Reagle, W3C Recommendation 16 April 2002 (See http://www.w3.org/TR/P3P/.)
[OWL]: OWL Web Ontology Language 1.0 Reference, M. Dean, D. Connolly, F. van Harmelen, J. Hendler, I. Horrocks, D. McGuinness, P. Patel-Schneider, L. Stein, W3C Working Draft 29 July 2002 (See http://www.w3.org/TR/2002/WD-owl-ref-20020729/.)

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
20020915	CBF	incorporate responses to comments received by Joseph Reagle: http://lists.w3.org/Archives/Public/www-wsa-comments/2002Aug/0000.html.
20020915	CBF	incorporate all resolutions and action items recorded in Sept 11-13 WSAWG f2f minutes, http://www.w3.org/2002/09/11-ws-arch-irc and http://www.w3.org/2002/09/12-ws-arch-irc and http://www.w3.org/2002/09/13-ws-arch-irc. Some additional editorial clean-up.
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	CBF	added bibref to CHARMOD, applied some missing resolutions from 18 July telcon
20020729	CBF	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	CBF	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.