Copyright © 2004 W3C® (MIT, ERCIM, 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 [WSARCH].
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 and 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 a public W3C Working Group Note 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. This Working Draft represents the Working Group's consensus agreement as to the current set of requirements for the Web Services Architecture. The Working Group considers this document to be a living document and may add or change the requirements as the analysis of the architecture proceeds through the Working Group's deliberations.
In this new version, requirements that the Working Group ruled as being application-specific and therefore out-of-scope out-of-scope.
Comments on this document should be sent to the public [email protected] mailing list (public archive).
Patent disclosures relevant to this specification may be found on the Working Group's patent disclosure page.
This is a public W3C Working Group Note 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 Conventions Used
in This Document
2. Requirements Analysis Method
2.1 Understanding
Critical Success Factors Analysis
3. The Analysis Hierarchy
3.1 Mission
Statement
3.1.1 Mission
3.1.2 Users of Web Services Architecture
3.2 Goals
3.2.1 Top-level Goals
3.2.2 Critical Success Factors and Requirements
4. Acknowledgments
5. References
5.1 Normative
References
5.2 Informative
References
6. Change Log
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 excerpted from [WS Glossary]:
Web service
[Definition: A Web service is a software system identified by a URI [RFC 2396], whose public interfaces and bindings are defined and described using XML. Its definition can be discovered by other software systems. These systems may then interact with the Web service in a manner prescribed by its definition, using XML based messages conveyed by Internet protocols.]
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.
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.
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.
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.
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:
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
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:
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.
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.
does not preclude any programming model.
AR004.2 is comprised of loosely-coupled components and their interrelationships.
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
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 of the parties participating to an exchange.
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.
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.
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.
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].
is consistent with the architectural principles and design goals of the Web. These principles and design goals are generally outlined in [WebArch], [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
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.
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.
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.
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.
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.
The WSA must enable the management and provisioning of Web Services
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.
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.
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).
conforms to the internationalized character model defined in "Character Model for the World Wide Web" Recommendation [CHARMOD]
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 prior knowledge of the service.
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
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.
Members of the Working Group are (at the time of writing, and by alphabetical order): Geoff Arnold (Sun Microsystems, Inc.), Mukund Balasubramanian (Infravio, Inc.), Mike Ballantyne (EDS), Abbie Barbir (Nortel Networks), David Booth (W3C), Mike Brumbelow (Apple), Doug Bunting (Sun Microsystems, Inc.), Greg Carpenter (Nokia), Tom Carroll (W. W. Grainger, Inc.), Alex Cheng (Ipedo), Michael Champion (Software AG), Martin Chapman (Oracle Corporation), Ugo Corda (SeeBeyond Technology Corporation), Roger Cutler (ChevronTexaco), Jonathan Dale (Fujitsu), Suresh Damodaran (Sterling Commerce(SBC)), James Davenport (MITRE Corporation), Paul Denning (MITRE Corporation), Gerald Edgar (The Boeing Company), Shishir Garg (France Telecom), Hugo Haas (W3C), Hao He (The Thomson Corporation), Dave Hollander (Contivo), Yin-Leng Husband (Hewlett-Packard Company), Mario Jeckle (DaimlerChrysler Research and Technology), Heather Kreger (IBM), Sandeep Kumar (Cisco Systems Inc), Hal Lockhart (OASIS), Michael Mahan (Nokia), Francis McCabe (Fujitsu), Michael Mealling (VeriSign, Inc.), Jeff Mischkinsky (Oracle Corporation), Eric Newcomer (IONA), Mark Nottingham (BEA Systems), David Orchard (BEA Systems), Bijan Parsia (MIND Lab), Adinarayana Sakala (IO 0K ..NA), Waqar Sadiq (EDS), Igor Sedukhin (Computer Associates), Hans-Peter Steiert (DaimlerChrysler Research and Technology), Katia Sycara (Carnegie Mellon University), Bryan Thompson (Hicks & Associates, Inc.), Sinisa Zimek (SAP).
Previous members of the Working Group were: Assaf Arkin (Intalio, Inc.), Daniel Austin (W. W. Grainger, Inc.), Mark Baker (Idokorro Mobile, Inc. / Planetfred, Inc.), Tom Bradford (XQRL, Inc.), Allen Brown (Microsoft Corporation), Dipto Chakravarty (Artesia Technologies), Jun Chen (MartSoft Corp.), Alan Davies (SeeBeyond Technology Corporation), Glen Daniels (Macromedia), Ayse Dilber (AT&T), Zulah Eckert (Hewlett-Packard Company), Colleen Evans (Sonic Software), Chris Ferris (IBM), Daniela Florescu (XQRL Inc.), Sharad Garg (Intel), Mark Hapner (Sun Microsystems, Inc.), Joseph Hui (Exodus/Digital Island), Michael Hui (Computer Associates), Nigel Hutchison (Software AG), Marcel Jemio (DISA), Mark Jones (AT&T), Timothy Jones (CrossWeave, Inc.), Tom Jordahl (Macromedia), Jim Knutson (IBM), Steve Lind (AT&T), Mark Little (Arjuna), Bob Lojek (Intalio, Inc.), Anne Thomas Manes (Systinet), Jens Meinkoehn (T-Nova Deutsche Telekom Innovationsgesellschaft), Nilo Mitra (Ericsson), Don Mullen (TIBCO Softwar.e, Inc.), Himagiri Mukkamala (Sybase, Inc.), Joel Munter (Intel), Henrik Frystyk Nielsen (Microsoft Corporation), Duane Nickull (XML Global Technologies), David Noor (Rogue Wave Software), Srinivas Pandrangi (Ipedo), Kevin Perkins (Compaq), Mark Potts (Talking Blocks, Inc), Fabio Riccardi (XQRL, Inc.), Don Robertson (Documentum), Darran Rolls (Waveset Technologies, Inc.), Krishna Sankar (Cisco Systems Inc), Jim Shur (Rogue Wave Software), Patrick Thompson (Rogue Wave Software), Steve Vinoski (IONA), Scott Vorthmann (TIBCO Software, Inc.), Jim Webber (Arjuna), Prasad Yendluri (webMethods, Inc.), Jin Yu (MartSoft Corp.) .