Copyright © 2002 W3C® (MIT, INRIA, Keio), All Rights Reserved. W3C liability, trademark, document use, and software licensing rules apply.
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.
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 [email protected] (public archive). It is inappropriate to send discussion emails to this address.
Discussion of this document takes place on the public [email protected] 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/.
1. Introduction
2. Requirements Analysis Method
3. The Analysis Hierarchy
4. Acknowledgments
5. References
6. Change Log
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
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.
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]
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.
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.
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.
The mission of the Web Services Architecture Working Group is to develop and maintain a standard reference architecture for Web Services.
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.
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:
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:
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..
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
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.
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
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
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 [email protected]. | |
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.
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
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.
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
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
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.
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.
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.
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.
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.
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.
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.
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.
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).
conforms to the internationalized character model defined in "Character Model for the World Wide Web" Recommendation
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 | |
| Apple | Mike Brumbelow |
| Artesia Technologies | Dipto Chakravarty |
| AT&T | Mark Jones |
| AT&T | Ayse Dilber |
| BEA Systems | David Orchard |
| Boeing Company | Gerald Edgar |
| Carnegie Mellon University | Katia Sycara |
| ChevronTexaco | Roger Cutler |
| Cisco Systems Inc | Sandeep Kumar |
| Cisco Systems Inc | Krishna Sankar |
| Hewlet Packard | Yin-Leng Husband |
| Computer Associates | Igor Sedukhin |
| Contivo | Dave Hollander |
| CrossWeave, Inc. | Timothy Jones |
| DaimlerChrysler Research and Technology | Mario Jeckle |
| DaimlerChrysler Research and Technology | Hans-Peter Steiert |
| DISA | Marcel Jemio |
| Documentum | Don Robertson |
| EDS | Mike Ballantyne |
| EDS | Waqar Sadiq |
| Ericsson | Nilo Mitra |
| Exodus/Digital Island | Joseph Hui |
| France Telecom | Shishir Garg |
| Fujitsu | Francis McCabe |
| Hewlett-Packard Company | Zulah Eckert |
| IBM | Heather Kreger |
| IBM | Jim Knutson |
| Intalio Inc | Bob Lojek |
| Intel Corporation | Sharad Garg |
| Intel Corporation | Joel Munter |
| IONA | Steve Vinoski |
| IONA | Eric Newcomer |
| Ipedo | Srinivas Pandrangi |
| Ipedo | Alex Cheng |
| Macromedia | Glen Daniels |
| Macromedia | Tom Jordahl |
| MartSoft Corp. | Jin Yu |
| MartSoft Corp. | Jun Chen |
| Microsoft Corporation | Allen Brown |
| Microsoft Corporation | Henrik Nielsen |
| MITRE Corporation | James Davenport |
| MITRE Corporation | Paul Denning |
| Nokia | Michael Mahan |
| Nortel Networks | Abbie Barbir |
| Oracle Corporation | Martin Chapman |
| Oracle Corporation | Jeff Mischkinsky |
| Planetfred, Inc. | Mark Baker |
| Rogue Wave Software | Patrick Thompson |
| Rogue Wave Software | David Noor |
| SAP | Sinisa Zimek |
| SeeBeyond Technology Corp | Alan Davies |
| Software AG | Michael Champion |
| Software AG | Nigel 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 |
| Systinet | Anne Thomas Manes |
| The Thomson Corporation | Hao He |
| TIBCO Software, Inc. | Scott Vorthmann |
| T-Nova Deutsche Telekom Innovationsgesellschaft | Jens Meinkoehn |
| VeriSign, Inc. | Michael Mealling |
| W. W. Grainger, Inc. | Tom Carroll |
| W. W. Grainger, Inc. | Daniel Austin |
| W3C | Hugo Haas |
| W3C | David Booth |
| Waveset Technologies | Darran Rolls |
| webMethods, Inc. | Prasad Yendluri |
| XQRL Inc. | Tom Bradford |
| XQRL Inc. | Daniela Florescu |
Former members of the WG:
| Compaq | Kevin Perkins |
| Date | Editor | Description |
|---|---|---|
| 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. |