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

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

The use of Web Services on the World Wide Web is expanding rapidly as the need for application-to-application
communication and interoperability grows. These services provide a standard means of communication among different software applications involved in presenting dynamic context-driven information to the user. In order to promote interoperability and extensibility among these applications, as well as to allow them to be combined in order to perform more complex operations, a standard reference architecture is needed. The Web Services Architecture Working Group at W3C is tasked with producing this reference architecture.

This document describes a set of requirements for a standard reference architecture for Web Services
developed by the Web Services Architecture Working Group. These requirements are intended to guide the
development of the reference architecture and provide a set of measurable constraints on Web Services
implementations by which conformance can be determined.

1.1 What is a Web service?

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

Web service

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

1.2 Notational Conventions

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

Note:

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

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

[D-] indicates that the item is in a draft state

A indicates that this is an architectural item.

[G|F|R|UC] is one of Goal|Critical Success Factor|Requirement|Use Case.

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

2. Requirements Analysis Method

Many methods of analyzing requirements for software systems are available. While each of them has
strengths and weaknesses, the Web Services Architecture Working Group has decided to make use of
two methods concurrently, in the hope that together each of these methods will produce a well-defined
set of requirements for Web Services Architecture. The two methods chosen are the Critical Success
Factor Analysis method, which will be supplemented through the use of gathering Usage Scenarios. Both
of these methods are useful but represent different approaches to the problem of gathering requirements.

The Working Groups intends to use these methods together and to cross-reference the results of each
approach to ensure consistency of the overall architectural direction. By ensuring that the requirements each
serve to meet the goals of the Working Group through the CSF analysis, and also ensuring that the architecture
is consistent with the envisioned Usage Scenarios of the Working Groups in the Web Services activity, we can
develop a set of architectural requirements that will provide an architectural model that meets the needs of all of
those involved.

Note that in the case of Usage Scenarios, the vast majority of these are taken from the work of other
W3C Working Groups in the Web Services Activity domain. Few individual Usage Scenarios will be
developed by the Web Services Architecture Working Group directly, and those only in response to perceived
gaps or omissions in the work of other Working Groups. Usage scenarios will be published separately.

2.1 Understanding Critical Success Factors Analysis

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

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

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

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

3. The Analysis Hierarchy

3.1 Mission Statement

3.1.1 Mission

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

3.1.2 Users of Web Services Architecture

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

3.2 Goals

3.2.1 Top-level Goals

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

Top-level Goals for the Web Services Architecture

D-AG001 Interoperability

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

3.2.2 Critical Success Factors and Requirements

Proposed lower-level goals and CSFs for the Web Services Architecture Working Group

(Each of the following goals is stated as a predicate to the following statement.)

To develop a standard reference architecture for Web Services that:

D-AC001

provides a complete reference framework that encourages the
development of interoperable software products from multiple vendors
and provides a defensible basis for conformance and interoperability test suites

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

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

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

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

D-AC002

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

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

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

AC003

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

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

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

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

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

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

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

D-AC004

does not preclude any programming model

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

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

The Web Services Architecture should:

D-AR004.1 provide consistent definition of web resources

AR004.2 provide well-defined interfaces for Web Services

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

D-AC005

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

The reference architecture should be easily understandable by the
target audience. At this stage all this goal requirements are imperative.

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

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

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

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

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

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

AC005.10 the interdependencies among components are noted explicitly

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

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

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

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

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

AC006

addresses the security of Web Services across distributed domains and
platforms

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

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

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

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

Requirements

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

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

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

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

AR006.3
The security framework must enable Authorization

AR006.4
The security framework must enable Confidentiality.

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

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

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

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

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

AC009

SHOULD avoid any unnecessary misalignment with s/w

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

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

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

AR009.5 Web services should be representable as Concepts in W3C OWL

D-AC011

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

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

Derived critical success factors:

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

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

AC010 uses W3C XML technologies in the development of the Web Services
architecture to the extent that this is compatible with the overall goals listed
here.

D-AC010.1Each new architectural area has its representation normatively
defined in a syntactic schema language defined in a W3C Recommendation

Editorial note

proposal from chair

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

AC012

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

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

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

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

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

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

AC013 (subsumes D-AC014)

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

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

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

AC015

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

D-AC015.1 Is the Web Services Activity a center for Web Services standards
specification, that is is the community able to start new working groups in
a manner that is usable by the community?

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

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

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

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

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

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

D-AC016

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

The Web Services Architecture WG should:

AR016.1 Identify what constitutes interoperability

D-AR016.1.1 in architectural realm.

D-AR016.1.2 in technological realm.

AR016.2. Identify existing

D-AR016.2.1 architecture that supports interoperability

AR016.2.2 technologies that support interoperability

AR016.3. Identify gaps

AR016.3.1 in architectural realm.

AR016.3.2 in technological realm.

D-AR016.4 Formation of WGs to address gaps

D-AR016.4.1 in architectural realm.

D-AR016.4.2 in technological realm.

D-AC017

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

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

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

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

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

D-AC018

provide a standard set of metrics for measuring aspects of Web Services
such as reliability, quality of service, and performance, and to define a
standard means of measurement of these metrics and instrumentation for
management of Web Services.

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

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

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

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