NOTE-wsa-reqs-20040211 47.6 KB

Raw Blame History Permalink

<!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">&lt;austin.d@ic.grainger.com&gt;</a></dd>

<dd>Abbie Barbir, Nortel Networks, Inc. <a href=
"mailto:abbieb@nortelnetworks.com">&lt;abbieb@nortelnetworks.com&gt;</a></dd>

<dd>Christopher Ferris, IBM <a href=
"mailto:chrisfer@us.ibm.com">&lt;chrisfer@us.ibm.com&gt;</a></dd>

<dd>Sharad Garg, The Intel Corporation <a href=
"mailto:sharad.garg@intel.com">&lt;sharad.garg@intel.com&gt;</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>
&nbsp;&nbsp;&nbsp;&nbsp;1.1 <a href="#id2604831">What is a Web
service?</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;1.2 <a href="#id2604911">Conventions Used
in This Document</a><br>
2. <a href="#id2605016">Requirements Analysis Method</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#id2605084">Understanding
Critical Success Factors Analysis</a><br>
3. <a href="#id2605167">The Analysis Hierarchy</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#mission">Mission
Statement</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.1 <a href=
"#id2605190">Mission</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.1.2 <a href=
"#id2605205">Users of Web Services Architecture</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;3.2 <a href="#goals">Goals</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;3.2.1 <a href=
"#id2605249">Top-level Goals</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;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>
&nbsp;&nbsp;&nbsp;&nbsp;5.1 <a href="#normrefs">Normative
References</a><br>
&nbsp;&nbsp;&nbsp;&nbsp;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%">&nbsp;</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 &amp; 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&amp;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&amp;T),
Timothy Jones (CrossWeave, Inc.), Tom Jordahl (Macromedia), Jim Knutson
(IBM), Steve Lind (AT&amp;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&uuml;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>