You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1648 lines
48 KiB
1648 lines
48 KiB
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
|
|
<html lang="en">
|
|
<head>
|
|
<meta name="generator" content=
|
|
"HTML Tidy for Linux/x86 (vers 1st March 2002), see www.w3.org">
|
|
<meta content="text/html; charset=ISO-8859-1" http-equiv=
|
|
"Content-Type">
|
|
<title>Web Services Architecture Requirements</title>
|
|
<style type="text/css">
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
dt.label { display: run-in; }
|
|
|
|
li, p { margin-top: 0.3em;
|
|
margin-bottom: 0.3em; }
|
|
|
|
p.diff-chg,
|
|
li.diff-chg,
|
|
h1.diff-chg,
|
|
h2.diff-chg,
|
|
h3.diff-chg,
|
|
h4.diff-chg,
|
|
h5.diff-chg,
|
|
h6.diff-chg,
|
|
td.diff-chg,
|
|
p.diff-del,
|
|
li.diff-del,
|
|
h1.diff-del,
|
|
h2.diff-del,
|
|
h3.diff-del,
|
|
h4.diff-del,
|
|
h5.diff-del,
|
|
h6.diff-del,
|
|
td.diff-del,
|
|
tr.diff-del { background-color: red; text-decoration: line-through;}
|
|
p.diff-add,
|
|
p.diff-add,
|
|
h1.diff-add,
|
|
h2.diff-add,
|
|
h3.diff-add,
|
|
h4.diff-add,
|
|
h5.diff-add,
|
|
h6.diff-add,
|
|
td.diff-add,
|
|
tr.diff-add { background-color: lime; }
|
|
|
|
|
|
div.exampleInner pre { margin-left: 1em;
|
|
margin-top: 0em; margin-bottom: 0em}
|
|
div.exampleOuter {border: 4px double gray;
|
|
margin: 0em; padding: 0em}
|
|
div.exampleInner { background-color: #d5dee3;
|
|
border-top-width: 4px;
|
|
border-top-style: double;
|
|
border-top-color: #d3d3d3;
|
|
border-bottom-width: 4px;
|
|
border-bottom-style: double;
|
|
border-bottom-color: #d3d3d3;
|
|
padding: 4px; margin: 0em }
|
|
div.exampleWrapper { margin: 4px }
|
|
div.exampleHeader { font-weight: bold;
|
|
margin: 4px}
|
|
</style>
|
|
|
|
<link rel="stylesheet" type="text/css" href=
|
|
"http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css">
|
|
</head>
|
|
<body>
|
|
<div class="head">
|
|
<p><a href="http://www.w3.org/"><img src=
|
|
"http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width=
|
|
"72"></a></p>
|
|
<h1>Web Services Architecture Requirements</h1>
|
|
|
|
<h2>W3C Working Group Note 11 February 2004</h2>
|
|
|
|
<dl>
|
|
<dt>This version:</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/2004/NOTE-wsa-reqs-20040211">http://www.w3.org/TR/2004/NOTE-wsa-reqs-20040211</a></dd>
|
|
|
|
<dt>Latest version:</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/wsa-reqs">http://www.w3.org/TR/wsa-reqs</a></dd>
|
|
|
|
<dt>Previous versions:</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/2002/WD-wsa-reqs-20021114">http://www.w3.org/TR/2002/WD-wsa-reqs-20021114</a></dd>
|
|
|
|
<dt>Editors:</dt>
|
|
|
|
<dd>Daniel Austin, W. W. Grainger, Inc. <a href=
|
|
"mailto:austin.d@ic.grainger.com"><austin.d@ic.grainger.com></a></dd>
|
|
|
|
<dd>Abbie Barbir, Nortel Networks, Inc. <a href=
|
|
"mailto:abbieb@nortelnetworks.com"><abbieb@nortelnetworks.com></a></dd>
|
|
|
|
<dd>Christopher Ferris, IBM <a href=
|
|
"mailto:chrisfer@us.ibm.com"><chrisfer@us.ibm.com></a></dd>
|
|
|
|
<dd>Sharad Garg, The Intel Corporation <a href=
|
|
"mailto:sharad.garg@intel.com"><sharad.garg@intel.com></a></dd>
|
|
</dl>
|
|
|
|
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2004 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p>
|
|
|
|
</div>
|
|
|
|
<hr>
|
|
<div>
|
|
<h2><a name="abstract">Abstract</a></h2>
|
|
|
|
<p>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 <a href='#wsarch'>[WSARCH]</a>.</p>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
|
|
<div>
|
|
<h2><a name="status">Status of this Document</a></h2>
|
|
|
|
<p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>
|
|
|
|
<p>This is a public <a href=
|
|
"http://www.w3.org/2003/06/Process-20030618/tr.html#q71">W3C
|
|
Working Group Note</a> of the Web Services Architecture Requirements
|
|
document. It is a <a href="/2002/01/ws-arch-charter">chartered</a>
|
|
deliverable of the <a href="/2002/ws/arch/">Web Services
|
|
Architecture Working Group</a>, which is part of the <a href=
|
|
"/2002/ws/Activity">Web Services Activity</a>. This Working Group Note
|
|
represents the Working Group's consensus agreement as to the
|
|
current set of requirements for the Web Services Architecture.</p>
|
|
|
|
<p>In this new version, requirements that the Working Group ruled as being application-specific and therefore out-of-scope.</p>
|
|
|
|
<p>Discussion of this document is invited on the public mailing list
|
|
<a href="mailto:www-ws-arch@w3.org">www-ws-arch@w3.org</a> (<a href=
|
|
"http://lists.w3.org/Archives/Public/www-ws-arch/">public
|
|
archives</a>).</p>
|
|
|
|
<p>Patent disclosures relevant to this specification may be found
|
|
on the Working Group's <a href=
|
|
"http://www.w3.org/2002/ws/arch/2/04/24-IPR-statements">patent
|
|
disclosure page</a>.</p>
|
|
|
|
<p>Publication as a Working Group Note does not imply endorsement by the
|
|
W3C Membership. This is a draft document and may be updated, replaced
|
|
or obsoleted by other documents at any time. It is inappropriate to
|
|
cite this document as other than work in progress. Other documents may supersede this document.</p>
|
|
</div>
|
|
|
|
<hr>
|
|
<div class="toc">
|
|
<h2><a name="shortcontents">Short Table of Contents</a></h2>
|
|
|
|
<p class="toc">1. <a href="#id2604787">Introduction</a><br>
|
|
2. <a href="#id2605016">Requirements Analysis Method</a><br>
|
|
3. <a href="#id2605167">The Analysis Hierarchy</a><br>
|
|
4. <a href="#acknowledgments">Acknowledgments</a><br>
|
|
5. <a href="#references">References</a><br>
|
|
</p>
|
|
</div>
|
|
|
|
<hr>
|
|
<div class="toc">
|
|
<h2><a name="contents">Table of Contents</a></h2>
|
|
|
|
<p class="toc">1. <a href="#id2604787">Introduction</a><br>
|
|
1.1 <a href="#id2604831">What is a Web
|
|
service?</a><br>
|
|
1.2 <a href="#id2604911">Conventions Used
|
|
in This Document</a><br>
|
|
2. <a href="#id2605016">Requirements Analysis Method</a><br>
|
|
2.1 <a href="#id2605084">Understanding
|
|
Critical Success Factors Analysis</a><br>
|
|
3. <a href="#id2605167">The Analysis Hierarchy</a><br>
|
|
3.1 <a href="#mission">Mission
|
|
Statement</a><br>
|
|
3.1.1 <a href=
|
|
"#id2605190">Mission</a><br>
|
|
3.1.2 <a href=
|
|
"#id2605205">Users of Web Services Architecture</a><br>
|
|
3.2 <a href="#goals">Goals</a><br>
|
|
3.2.1 <a href=
|
|
"#id2605249">Top-level Goals</a><br>
|
|
3.2.2 <a href=
|
|
"#csfsreqs">Critical Success Factors and Requirements</a><br>
|
|
4. <a href="#acknowledgments">Acknowledgments</a><br>
|
|
5. <a href="#references">References</a><br>
|
|
5.1 <a href="#normrefs">Normative
|
|
References</a><br>
|
|
5.2 <a href="#informrefs">Informative
|
|
References</a><br>
|
|
</p>
|
|
</div>
|
|
|
|
<hr>
|
|
<div class="body">
|
|
<div class="div1">
|
|
<h2><a name="id2604787"></a>1. Introduction</h2>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<div class="div2">
|
|
<h3><a name="id2604831"></a>1.1 What is a Web service?</h3>
|
|
|
|
<p>The Working Group has jointly come to agreement on the following
|
|
working definition excerpted from <a href="#ws-gloss">[WS
|
|
Glossary]</a>:</p>
|
|
|
|
<p><b>Web service</b></p>
|
|
|
|
<p>[<a name="WebService" title="Web service">Definition</a>: A Web
|
|
service is a software system identified by a URI <a href=
|
|
"#RFC2396">[RFC 2396]</a>, 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.]</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="id2604911"></a>1.2 Conventions Used in This
|
|
Document</h3>
|
|
|
|
<p>The key words <em>"must"</em>, <em>"must not"</em>,
|
|
<em>"required"</em>, <em>"shall"</em>, <em>"shall not"</em>,
|
|
<em>"should"</em>, <em>"should not"</em>, <em>"required"</em>,
|
|
<em>"may"</em>, and <em>"optional"</em> in this document are to be
|
|
interpreted as described in <a href=
|
|
"http://www.ietf.org/rfc/rfc2119.txt">RFC 2119</a>.</p>
|
|
|
|
<div class="note">
|
|
<p class="prefix"><b>Note:</b></p>
|
|
|
|
<p>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:</p>
|
|
|
|
<p>[D-]A(G|F|R|UC)nnn.n.n</p>
|
|
|
|
<p>[D-] indicates that the item is in a draft state</p>
|
|
|
|
<p>A indicates that this is an architectural item.</p>
|
|
|
|
<p>[G|F|R|UC] is one of Goal|Critical Success
|
|
Factor|Requirement|Use Case.</p>
|
|
|
|
<p>nnn.n.n indicates the sequence number of the item.</p>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="id2605016"></a>2. Requirements Analysis Method</h2>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<div class="div2">
|
|
<h3><a name="id2605084"></a>2.1 Understanding Critical Success
|
|
Factors Analysis</h3>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="id2605167"></a>3. The Analysis Hierarchy</h2>
|
|
|
|
<div class="div2">
|
|
<h3><a name="mission"></a>3.1 Mission Statement</h3>
|
|
|
|
<div class="div3">
|
|
<h4><a name="id2605190"></a>3.1.1 Mission</h4>
|
|
|
|
<p>The mission of the Web Services Architecture Working Group is to
|
|
develop and maintain a standard reference architecture for Web
|
|
services.</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="id2605205"></a>3.1.2 Users of Web Services
|
|
Architecture</h4>
|
|
|
|
<p>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.</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="goals"></a>3.2 Goals</h3>
|
|
|
|
<div class="div3">
|
|
<h4><a name="id2605249"></a>3.2.1 Top-level Goals</h4>
|
|
|
|
<p>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 <a href=
|
|
"#csfsreqs">section 3.2.2</a> 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.</p>
|
|
|
|
<p>Top-level Goals for the Web Services Architecture (WSA):</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><em>AG001 Interoperability</em></p>
|
|
|
|
<p>The WSA <em>should</em> enable the development of interoperable
|
|
Web services across a wide array of environments.</p>
|
|
|
|
<p>Critical success factors and requirements for this goal:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><a href="#AC004">AC004</a> does not preclude any programming
|
|
model.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><a href="#AC023">AC023</a> is comprised of loosely-coupled
|
|
components and their interrelationships.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>In addition, the Web Services Architecture Working Group
|
|
will:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><a href="#AC016">AC016</a> examine architectural issues that
|
|
might pose an impediment to interoperability of implementations,
|
|
and between components of the architecture.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</li>
|
|
|
|
<li>
|
|
<p><em>AG002 Reliability</em></p>
|
|
|
|
<p>The WSA <em>must</em> be reliable and stable over time.</p>
|
|
|
|
<p>Critical success factors and requirements for this goal:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><a href="#AC019">AC019</a> enables conforming Web services to be
|
|
reliable, stable, and evolvable over time.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</li>
|
|
|
|
<li>
|
|
<p><em>AG003 Integration with the World Wide Web</em></p>
|
|
|
|
<p>The WSA <em>must</em> be consistent with the current and future
|
|
evolution of the World Wide Web.</p>
|
|
|
|
<p>Critical success factors and requirements for this goal:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><a href="#AC009">AC009</a> <em>should</em> avoid any unnecessary
|
|
misalignment with the Semantic Web.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><a href="#AC011">AC011</a> is consistent with the architectural
|
|
principles and design goals of the existing Web.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><a href="#AC021">AC021</a> ensures device independence of Web
|
|
services.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><a href="#AC022">AC022</a> conforms to the internationalized
|
|
character model defined in "Character Model for the World Wide Web"
|
|
Recommendation <a href="#CHARMOD">[CHARMOD]</a></p>
|
|
</li>
|
|
</ul>
|
|
|
|
</li>
|
|
|
|
<li>
|
|
<p><em>AG004 Security</em></p>
|
|
|
|
<p>The WSA <em>must</em> provide a secure environment for online
|
|
processes.</p>
|
|
|
|
<p>Critical success factors and requirements for this goal:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><a href="#AC006">AC006</a> addresses the security of Web
|
|
services across distributed domains and platforms.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><a href="#AC020">AC020</a> enables privacy protection for the
|
|
consumer of a Web service across multiple domains and services.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</li>
|
|
|
|
<li>
|
|
<p><em>AG005 Scalability and Extensibility</em></p>
|
|
|
|
<p>The WSA <em>must</em> enable implementations that are scalable
|
|
and extensible.</p>
|
|
|
|
<p>Critical success factors and requirements for this goal:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><a href="#AC002">AC002</a> provides for modular web services
|
|
architecture components, with each at a level of granularity
|
|
appropriate to meet the other goals.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><a href="#AC003">AC003</a> is sufficiently extensible to allow
|
|
for future evolution of technology and of business goals.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><a href="#AC005">AC005</a> applies the principle of simplicity
|
|
and is defined such that it does not impose high barriers to entry
|
|
for its intended audience.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><a href="#AC017">AC017</a> <em>must</em> satisfy the
|
|
requirements of enterprises wishing to transition from traditional
|
|
EDI.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><a href="#AC024">AC024</a> <em>must</em> enable peer to peer
|
|
interacting web services</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</li>
|
|
|
|
<li>
|
|
<p><em>AG006 Team Goals</em></p>
|
|
|
|
<p>The Web Services Architecture Working Group will work to ensure
|
|
that the Architecture will meet the needs of the user
|
|
community.</p>
|
|
|
|
<p>Critical success factors and requirements for this goal:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><a href="#AC007">AC007</a> is reliable, stable, and evolves over
|
|
time.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><a href="#AC008">AC008</a> is consistent and coherent. This
|
|
applies to both the reference architecture itself and the document
|
|
that contains its definition.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
|
|
|
|
<p>In addition, the Web Services Architecture Working Group
|
|
will:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><a href="#AC012">AC012</a> identify or create user scenarios and
|
|
use cases that support and illustrate the requirements and web
|
|
services architecture.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><a href="#AC013">AC013</a> 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.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p><a href="#AC015">AC015</a> 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.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</li>
|
|
|
|
<li>
|
|
<p><em>AG007 Management and Provisioning</em></p>
|
|
|
|
<p>The standard reference architecture for Web Services
|
|
<em>must</em> provide for a manageable, accountable environment for
|
|
Web Services operations.</p>
|
|
|
|
<p>Critical success factors and requirements for this goal:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p><a href="#AC018">AC018</a> <em>must</em> enable the management
|
|
and provisioning of Web Services</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</li>
|
|
</ul>
|
|
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="csfsreqs"></a>3.2.2 Critical Success Factors and
|
|
Requirements</h4>
|
|
|
|
<p>The Web Services Architecture Working Group has identified the
|
|
following CSFs and requirements for the WSA.</p>
|
|
|
|
<p>Each of the following CSFs is stated as a predicate to the
|
|
following statement except where noted.</p>
|
|
|
|
<p><em>To develop a standard reference architecture for Web
|
|
services that:</em></p>
|
|
|
|
<dl>
|
|
<dt class="label"><a name="AC002"></a>AC002</dt>
|
|
|
|
<dd>
|
|
<p>provides for modular web services architecture components, with
|
|
each at a level of granularity appropriate to meet the other
|
|
goals.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>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.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>AC002.1.1 reduces complexity by decomposition of the component's
|
|
functionality and its position within the architecture</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>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.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</li>
|
|
</ul>
|
|
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC003"></a>AC003</dt>
|
|
|
|
<dd>
|
|
<p>is sufficiently extensible to allow for future evolution of
|
|
technology and of business goals</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR003.1">AR003.1 separates the transport of data or means of
|
|
access to Web services from the Web services themselves.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR003.3">AR003.3 technologies following this architecture
|
|
<em>should not</em> impede the development of complex interaction
|
|
scenarios</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR003.4">AR003.4 components of the architecture that are
|
|
orthogonal <em>must</em> be allowed to evolve independently of each
|
|
other and still work within the architecture</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR003.5">AR003.5 systems <em>must not</em> be precluded from
|
|
quoting, either unmodified or modified, messages within other
|
|
messages, to an arbitrary depth.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC004"></a>AC004</dt>
|
|
|
|
<dd>
|
|
<p>does not preclude any programming model.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR004.2">AR004.2 is comprised of loosely-coupled components
|
|
and their interrelationships.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC005"></a>AC005</dt>
|
|
|
|
<dd>
|
|
<p>applies the principle of simplicity and is defined such that it
|
|
does not impose high barriers to entry for its intended
|
|
audience</p>
|
|
|
|
<p>The reference architecture <em>should</em> be easily
|
|
understandable by the target audience.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AC005.2">AC005.2 the WSA is stated in simple, declarative
|
|
sentences</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AC005.3">AC005.3 the WSA identifies and defines all of its
|
|
components precisely and unambiguously.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AC005.3.1">AC005.3.1. there is a unique identification
|
|
scheme for identifying each component, and all components are
|
|
identified using this identification scheme.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AC005.3.2">AC005.3.2 the terms and language used to describe
|
|
the WSA and its components are unambiguously defined.</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AC005.4">AC005.4 the WSA uses illustrations to visually
|
|
describe key components and relationships</p>
|
|
</li>
|
|
</ul>
|
|
|
|
|
|
|
|
<p>The reference architecture defined by the WSA <em>should</em> be
|
|
as minimal as possible</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AC005.5">AC005.5 the WSA will use the minimum number of
|
|
components required for a coherent and complete description of the
|
|
web service architecture.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AC005.6">AC005.6 the WSA will avoid redundancies when
|
|
describing relationships between components.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
|
|
|
|
<p>The WSA <em>should</em> simplify the task of a programmer
|
|
writing interoperable implementations of specifications of
|
|
components described by the architecture.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AC005.9">AC005.9 the role played by each component in the
|
|
overall architecture is clearly stated</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AC005.10">AC005.10 the interdependencies among components
|
|
are noted explicitly</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AC005.11">AC005.11 existing specs that fulfill the role of a
|
|
given component are referenced</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC006"></a>AC006</dt>
|
|
|
|
<dd>
|
|
<p>addresses the security of Web services across distributed
|
|
domains and platforms</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AC006.1">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.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AC006.2">AC006.2 the establishment of a set of Web Services
|
|
Security Policies to counter and mitigate the security hazards
|
|
identified in the threat model.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AC006.3">AC006.3 the construction of a Web Services Security
|
|
Model that captures the security policies.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AC006.4">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.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>Requirements:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR006.1">AR006.1 the WG <em>should</em> consider the threat
|
|
of Accessibility attacks ([D]DOS, DNS spoofing, etc.) in the
|
|
security framework.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR006.2.1">AR006.2.1 the WS security framework <em>must</em>
|
|
enable Authentication of the parties participating to an
|
|
exchange.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR006.2.2">AR006.2.2 the WS security framework <em>must</em>
|
|
enable persistent and transient authentication of authorship of
|
|
data.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR006.3">AR006.3 the WS security framework <em>must</em>
|
|
enable Authorization</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR006.4">AR006.4 the WS security framework <em>must</em>
|
|
enable Confidentiality.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR006.5">AR006.5 the WS security framework <em>must</em>
|
|
enable (data) Integrity.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR006.6">AR006.6 the WS security framework <em>must</em>
|
|
enable non-repudiation of origin and receipt between transacting
|
|
parties</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR006.10.1 the WS security framework <em>must</em> provide a
|
|
means of expressing security policy.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR006.10.2 the WS security framework <em>must</em> provide a
|
|
means to access a web service's security policy.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR006.12 the WS security framework <em>must</em> enable
|
|
Auditing.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR006.13 where a Web service provides security features in line
|
|
with AR006, it <em>should</em> provide the ability to administer
|
|
that security.</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC007"></a>AC007</dt>
|
|
|
|
<dd>
|
|
<p>The WSA is reliable, stable, and evolves over time.</p>
|
|
|
|
<p id="AC007.1">AC007.1 the WSA is reliable.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AC007.1.1">AC007.1.1 the WSA is precisely defined without
|
|
ambiguity,</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR007.1.1.1">AR007.1.1.1 using standard definition languages
|
|
whenever applicable and available,</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR007.1.1.2">AR007.1.1.2 using standard terms, and clearly
|
|
defined new terms.</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
<p id="AC007.2">AC007.2 the WSA is stable and evolves over
|
|
time.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR007.2.1">AR007.2.1 the WSA has stable conceptual models,
|
|
definitions, assumptions, and scopes.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR007.2">AR007.2.2 the WSA is governed by a well defined
|
|
versioning policy.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR007.2.3">AC007.2 .3 newer versions of WSA <em>should</em>
|
|
be compatible with older versions.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR007.2.3.1">AR007.2.3.1 when a component within the Web
|
|
Service Architecture changes, the change is precisely identified,
|
|
and the changed WSA is reliable.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR007.2.3.2">AR007.2.3.2 the assumptions behind a change in
|
|
the component, and its scope <em>must</em> be clearly stated.</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC008"></a>AC008</dt>
|
|
|
|
<dd>
|
|
<p>is consistent and coherent. This applies to both the reference
|
|
architecture itself and the document that contains its
|
|
definition.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>AC008.1 the WSA provides simple visualization of architecture in
|
|
the form of a two-dimensional diagram</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AC008.4 the WSA does not do the same or similar things in
|
|
mutually incompatible ways; it is not self-contradictory.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AC008.6">AC008.6 the definition and use of the components is
|
|
consistent within the WSA and the architecture document itself.</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC009"></a>AC009</dt>
|
|
|
|
<dd>
|
|
<p><em>should</em> avoid any unnecessary misalignment with the
|
|
Semantic Web</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR009.2">AR009.2 new Web services technologies, developed by
|
|
W3C Web Services WGs, <em>should</em> be capable of being mapped to
|
|
RDF/XML.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR009.3">AR009.3 all conceptual elements <em>should</em> be
|
|
addressable directly via a URI.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR009.4">AR009.4 the WSA <em>must not</em> 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.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR009.5">AR009.5 Web service descriptions <em>should</em> be
|
|
capable of referencing concepts identified by a URI in an ontology,
|
|
such as W3C OWL <a href="#OWL">[OWL]</a>.</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
</dl>
|
|
|
|
<dl>
|
|
<dt class="label"><a name="AC011"></a>AC011</dt>
|
|
|
|
<dd>
|
|
<p>is consistent with the architectural principles and design goals
|
|
of the Web. These principles and design goals are generally
|
|
outlined in <a href="#WebArch">[WebArch]</a>, <a href=
|
|
"#AXIOMS">[AXIOMS]</a>, <a href="#WEBAT50K">[WEBAT50K]</a>, and in
|
|
<a href="#REST">[REST]</a>.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AC010">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.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AC010.1">AC010.1 each new architectural area that has a
|
|
representation <em>should</em> be normatively defined using XML
|
|
Schema.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>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.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>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.</p>
|
|
|
|
<p>Derived requirements:</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR011.1 the Web Services Architecture Working Group
|
|
<em>must</em> closely monitor the deliverables of the TAG as they
|
|
further refine and or document the architecture and design
|
|
principles of the Web</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
</dl>
|
|
|
|
<dl>
|
|
<dt class="label"><a name="AC012"></a>AC012</dt>
|
|
|
|
<dd>
|
|
<p>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</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>AR012.1 - terms <em>must</em> be well defined and used
|
|
consistently</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR012.2 - use cases organized around usage scenarios, usage
|
|
scenarios <em>should</em> reflect common usage patterns for
|
|
architecture</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR012.3 - target audience for architectural deliverables
|
|
<em>must</em> be defined</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR012.5 - architecture <em>should</em> support use cases for all
|
|
aspects of Web services.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AC012.7">AC012.7 the WSA <em>must</em> be validated against
|
|
WSA use cases.</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC013"></a>AC013</dt>
|
|
|
|
<dd>
|
|
<p>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</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>AR013.2 the documents produced are used as input to charter new
|
|
Web services Working Groups.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR013.3 the Working Group will maintain liaisons with relevant
|
|
external groups, such as those listed in the charter and possibly
|
|
others.</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC015"></a>AC015</dt>
|
|
|
|
<dd>
|
|
<p>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.</p>
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC016"></a>AC016</dt>
|
|
|
|
<dd>
|
|
<p>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.</p>
|
|
|
|
<p>The Web Services Architecture WG <em>should</em>:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>AR016.1 explore architectural relationships between components
|
|
of the architecture.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR016.2. identify architectural gaps or disconnects between
|
|
components of the architecture.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR016.3. recommend or solicit proposals for addressing any
|
|
identified gaps and/or disconnects.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR016.4 identify architectural principles and constraints that
|
|
enable interoperability of implementations, and between components
|
|
of the architecture.</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC017"></a>AC017</dt>
|
|
|
|
<dd>
|
|
<p>The WSA <em>must</em> satisfy the requirements of enterprises
|
|
wishing to transition from traditional EDI.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>AR017.2 the WSA <em>must</em> support reliable messaging.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR017.4 the WSA <em>must</em> support long running, stateful and
|
|
choreographed interactions, both within and across trust
|
|
boundaries.</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC018"></a>AC018</dt>
|
|
|
|
<dd>
|
|
<p>The WSA <em>must</em> enable the management and provisioning of
|
|
Web Services</p>
|
|
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC019"></a>AC019</dt>
|
|
|
|
<dd>
|
|
<p>enables conforming Web services to be reliable, stable, and
|
|
evolvable over time.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR019.1">AR019.1 Web services conforming to WSA can be
|
|
reliably discovered, accessed, and executed.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR019.1.2">AR019.1.2 WSA will enable the availability
|
|
constraints of a Web service to be known to its clients.</p>
|
|
|
|
<table border="1" summary="Editorial note">
|
|
<tr>
|
|
<td align="left" valign="top" width="50%"><b>Editorial
|
|
note</b></td>
|
|
<td align="right" valign="top" width="50%"> </td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td colspan="2" align="left" valign="top">there has been some
|
|
discussion as to whether consumers is the most appropriate term
|
|
used in this context.</td>
|
|
</tr>
|
|
</table>
|
|
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR019.2">AR019.2 the WSA <em>must</em> enable a conforming
|
|
Web service implementation to be stable with respect to its
|
|
definition.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR019.2.1">AR019.2.1 a Web service can be defined
|
|
independent of its implementation.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR019.2.2">AR019.2.2 the WSA <em>must</em> enable a Web
|
|
service implementation to be stable based on service
|
|
agreements.</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR019.3">AR019.3 the WSA <em>must</em> 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.</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC020"></a>AC020</dt>
|
|
|
|
<dd>
|
|
<p>enables privacy protection for the consumer of a Web service
|
|
across multiple domains and services.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>AR020.1 the WSA <em>must</em> enable privacy policy statements
|
|
to be expressed about Web services.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR020.2 advertised Web service privacy policies <em>must</em> be
|
|
expressed in P3P <a href="#P3P">[P3P]</a>.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR020.3 the WSA <em>must</em> enable a consumer to access a Web
|
|
service's advertised privacy policy statement.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR020.5 the WSA <em>must</em> enable delegation and propagation
|
|
of privacy policy.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>AR020.6: Web Services <em>must not</em> be precluded from
|
|
supporting interactions where one or more parties of the
|
|
interaction are anonymous.</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC021"></a>AC021</dt>
|
|
|
|
<dd>
|
|
<p>ensures device independence of Web services.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR021.1">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.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR021.2">AR021.2 makes no assumptions about the utility or
|
|
visibility of services based on user locality.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR021.3">AR021.3 assumes a spectrum of device capabilities
|
|
(from high end servers to handheld devices).</p>
|
|
</li>
|
|
</ul>
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC022"></a>AC022</dt>
|
|
|
|
<dd>
|
|
<p>conforms to the internationalized character model defined in
|
|
"Character Model for the World Wide Web" Recommendation <a href=
|
|
"#CHARMOD">[CHARMOD]</a></p>
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC023"></a>AC023</dt>
|
|
|
|
<dd>
|
|
<p>is comprised of loosely-coupled components and their
|
|
interrelationships.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR023.1">AR023.1 components are defined in terms of
|
|
unambiguous, well-defined interfaces.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR023.2">AR023.2 components are described by their
|
|
functional roles and responsibilities.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR023.3">AR023.3 component interfaces define their inputs
|
|
and outputs and also the format and constraints on those inputs and
|
|
outputs.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR023.4">AR023.4 component relationships are described in
|
|
terms of messages and message exchange patterns.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR023.5">AR023.5 messages are transmitted and consumed by
|
|
the component interfaces that make up the architecture.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR023.6">AR023.6 support XML based techniques for defining
|
|
messages/protocols for invoking web resources.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR023.7">AR023.7 support both early and late client binding
|
|
to web services.</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR023.7.1">AR023.7.1 defines or identifies a base interface
|
|
that all Web services can implement, that permits communication
|
|
without prior knowledge of the service.</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
</ul>
|
|
|
|
</dd>
|
|
|
|
<dt class="label"><a name="AC024"></a>AC024</dt>
|
|
|
|
<dd>
|
|
<p>The WSA <em>must</em> enable peer to peer interacting web
|
|
services</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR024.1">AR024.1 the WSA <em>must</em> support atleast the
|
|
following peer to peer message exchange patterns:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p id="AR024.1.1">AR024.1.1 request-response</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR024.1.2">AR024.1.2 publish-subscribe</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR024.1.3">AR024.1.3 events and event notification</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR024.2">AR024.2 the WSA <em>must not</em> preclude
|
|
persistent identities for peers</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR024.3">AR024.3 the WSA <em>must not</em> preclude
|
|
determining capabilities for peers</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR024.4">AR024.4 the WSA <em>must</em> enable direct peer to
|
|
peer interactions without the use of third party intermediaries</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR024.5">AR024.5 the WSA <em>must not</em> preclude the use
|
|
of third party intermediaries (e.g. forwarding)</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p id="AR024.6">AR024.6 it <em>must</em> be possible for peers to
|
|
discover each other</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="acknowledgments"></a>4. Acknowledgments</h2>
|
|
|
|
<p>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</p>
|
|
|
|
<p>This document is a product of the <a href=
|
|
"http://www.w3.org/2002/ws/arch/">Web Services Architecture Working
|
|
Group</a>.</p>
|
|
|
|
<p>
|
|
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
|
|
(IONA), 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).</p>
|
|
|
|
|
|
<p>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.) .</p>
|
|
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="references"></a>5. References</h2>
|
|
|
|
<div class="div2">
|
|
<h3><a name="normrefs"></a>5.1 Normative References</h3>
|
|
|
|
<dl>
|
|
<dt class="label"><a name="P3P"></a>[P3P]</dt>
|
|
|
|
<dd>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
|
|
<a href=
|
|
"http://www.w3.org/TR/P3P/">http://www.w3.org/TR/P3P/</a>.)</dd>
|
|
|
|
<dt class="label"><a name="RFC2396"></a>[RFC 2396]</dt>
|
|
|
|
<dd><cite>Uniform Resource Identifiers (URI): Generic
|
|
Syntax</cite>, IETF RFC 2396, T. Berners-Lee, R. Fielding, L.
|
|
Masinter, August 1998 (See <a href=
|
|
"http://www.ietf.org/rfc/rfc2396.txt">http://www.ietf.org/rfc/rfc2396.txt</a>.)</dd>
|
|
</dl>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="informrefs"></a>5.2 Informative References</h3>
|
|
|
|
<dl>
|
|
<dt class="label"><a name="wsarch"></a>[WSARCH]</dt>
|
|
|
|
<dd><a href='http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/'>Web Services Architecture, W3C Working Group Note, D. Booth, H.
|
|
Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, D.
|
|
Orchard, 11 February 2004</a> (See
|
|
http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/.)</dd>
|
|
|
|
|
|
<dt class="label"><a name="ws-gloss"></a>[WS Glossary]</dt>
|
|
|
|
<dd><a href=
|
|
"http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/">Web Services Glossary, H. Haas, A. Brown, W3C Working Group Note, 11
|
|
February 2004</a> (See http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/.)</dd>
|
|
|
|
<dt class="label"><a name="CSF-Primer"></a>[CSF-Primer]</dt>
|
|
|
|
<dd>A Primer on Critical Success Factors, MIT Sloan School of
|
|
Management Working Paper, Bullen, C. and J. Rockart, 1220-81</dd>
|
|
|
|
<dt class="label"><a name="WebArch"></a>[WebArch]</dt>
|
|
|
|
<dd>Architecture of the World Wide Web, First Edition (See <a href=
|
|
"http://www.w3.org/TR/2003/WD-webarch-20031001/">http://www.w3.org/TR/2003/WD-webarch-20031209/</a>.)</dd>
|
|
|
|
<dt class="label"><a name="AXIOMS"></a>[AXIOMS]</dt>
|
|
|
|
<dd>Universal Resource Identifiers -- Axioms of Web Architecture,
|
|
Berners-Lee, T. , 1996 (See <a href=
|
|
"http://www.w3.org/DesignIssues/Axioms.html">http://www.w3.org/DesignIssues/Axioms.html</a>.)</dd>
|
|
|
|
<dt class="label"><a name="WEBAT50K"></a>[WEBAT50K]</dt>
|
|
|
|
<dd>Web Architecture at 50,000 Feet, Berners-Lee, T., 1998 (See <a
|
|
href=
|
|
"http://www.w3.org/DesignIssues/Architecture.html">http://www.w3.org/DesignIssues/Architecture.html</a>.)</dd>
|
|
|
|
<dt class="label"><a name="REST"></a>[REST]</dt>
|
|
|
|
<dd>Architectural Styles and the Design of Network-based Software
|
|
Architectures, Fielding, R., 2000 (See <a href=
|
|
"http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm">http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm</a>.)</dd>
|
|
|
|
<dt class="label"><a name="CHARMOD"></a>[CHARMOD]</dt>
|
|
|
|
<dd>Character Model for the World Wide Web 1.0, M. Dürst, F.
|
|
Yergeau, R. Ishida, M. Wolf, T. Texin, W3C Working
|
|
Draft 22 August 2003 (See <a href=
|
|
"http://www.w3.org/TR/2003/WD-charmod-20030822/">http://www.w3.org/TR/2003/WD-charmod-20030822/</a>.)</dd>
|
|
|
|
<dt class="label"><a name="OWL"></a>[OWL]</dt>
|
|
|
|
<dd>OWL Web Ontology Language Reference, M. Dean, G. Schreiber,
|
|
W3C Recommendation 10 February 2003 (See <a
|
|
href=
|
|
"http://www.w3.org/TR/2004/REC-owl-ref-20040210/">http://www.w3.org/TR/2004/REC-owl-ref-20040210/.)</a></dd>
|
|
</dl>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
</body>
|
|
</html>
|
|
|