index.html 275 KB

Raw Blame History Permalink

<?xml version="1.0" encoding="iso-8859-1"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.0 Transitional//EN" "http://www.w3.org/TR/xhtml1/DTD/xhtml1-transitional.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" lang="en" xml:lang="en"><head><meta http-equiv="Content-Type" content="text/html; charset=iso-8859-1" /><title>Web Services Architecture</title><style type="text/css">
code           { font-family: monospace; }

div.constraint,
div.issue,
div.note,
div.notice     { margin-left: 2em; }

li p           { margin-top: 0.3em;
                 margin-bottom: 0.3em; }

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}
div.figure { text-align: center; }
</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><a name="title" id="title"></a>Web Services Architecture</h1>
<h2><a name="w3c-doctype" id="w3c-doctype"></a>W3C Working Group Note 11 February 2004</h2><dl><dt>This version:</dt><dd>
      <a href="http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/">http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/</a>
    </dd><dt>Latest version:</dt><dd>
      <a href="http://www.w3.org/TR/ws-arch/"> http://www.w3.org/TR/ws-arch/</a>
    </dd><dt>Previous version:</dt><dd>
      <a href="http://www.w3.org/TR/2003/WD-ws-arch-20030808/">
	http://www.w3.org/TR/2003/WD-ws-arch-20030808/
      </a>
    </dd><dt>Editors:</dt><dd>David Booth, W3C Fellow / Hewlett-Packard </dd><dd>Hugo Haas, W3C</dd><dd>Francis McCabe, Fujitsu Labs of America </dd><dd>Eric Newcomer (until October 2003), Iona </dd><dd>Michael Champion (until March 2003), Software AG</dd><dd>Chris Ferris (until March 2003), IBM</dd><dd>David Orchard (until March 2003), BEA Systems</dd></dl><p>This document is also available in these non-normative formats: <a href="wsa.ps">PostScript version</a> and <a href="wsa.pdf">PDF version</a>.</p><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" id="abstract"></a>Abstract</h2><p>This document defines the Web Services Architecture. It identifies the
        functional components and defines the relationships among those components to effect the desired properties of the overall architecture.</p></div><div>
<h2><a name="status" id="status"></a>Status of this Document</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">Working
          Group Note</a> produced by the <a href="http://www.w3.org/2002/ws/arch/">W3C Web Services Architecture Working Group</a>,
        which is part of the <a href="http://www.w3.org/2002/ws/Activity">W3C Web Services Activity</a>.
 This publication as a Working Group Note coincides
      with
the end of the Working Group's charter period, and
represents the culmination of the group's work.</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>).  A list of remaining open issues is included in  <a href="#conclusions"><b>4 Conclusions</b></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><div class="toc">
<h2><a name="contents" id="contents"></a>Table of Contents</h2><p class="toc">1 <a href="#introduction">Introduction</a><br />
    1.1 <a href="#id2260892">Purpose of the Web Service Architecture</a><br />
    1.2 <a href="#docoverview">Intended Audience</a><br />
    1.3 <a href="#id2259932">Document Organization</a><br />
    1.4 <a href="#whatis">What is a Web service?</a><br />
        1.4.1 <a href="#id2260073">Agents and Services</a><br />
        1.4.2 <a href="#reqpro">Requesters and Providers</a><br />
        1.4.3 <a href="#id2263315">Service Description</a><br />
        1.4.4 <a href="#id2263364">Semantics</a><br />
        1.4.5 <a href="#engaging">Overview of Engaging a Web Service</a><br />
    1.5 <a href="#id2268685">Related Documents</a><br />
2 <a href="#concepts_and_relationships"> Concepts and Relationships</a><br />
    2.1 <a href="#id2268743">Introduction</a><br />
    2.2 <a href="#meta_model">How to read this section</a><br />
        2.2.1 <a href="#meta_concept">Concepts</a><br />
        2.2.2 <a href="#meta_relationship">Relationships</a><br />
        2.2.3 <a href="#id2268989">Concept Maps</a><br />
        2.2.4 <a href="#model">Model</a><br />
        2.2.5 <a href="#conformance">Conformance</a><br />
    2.3 <a href="#concepts">The Architectural Models</a><br />
        2.3.1 <a href="#message_oriented_model">Message Oriented Model</a><br />
            2.3.1.1 <a href="#address">Address</a><br />
            2.3.1.2 <a href="#delivery_policy">Delivery Policy</a><br />
            2.3.1.3 <a href="#message">Message</a><br />
            2.3.1.4 <a href="#message_body">Message Body</a><br />
            2.3.1.5 <a href="#correlation">Message Correlation</a><br />
            2.3.1.6 <a href="#envelope">Message Envelope</a><br />
            2.3.1.7 <a href="#mep">Message Exchange Pattern (MEP)</a><br />
            2.3.1.8 <a href="#message_header">Message Header</a><br />
            2.3.1.9 <a href="#message_recipient">Message Receiver</a><br />
            2.3.1.10 <a href="#reliable_messaging">Message Reliability</a><br />
            2.3.1.11 <a href="#message_sender">Message Sender</a><br />
            2.3.1.12 <a href="#ms">Message Sequence</a><br />
            2.3.1.13 <a href="#message_transport">Message Transport</a><br />
        2.3.2 <a href="#service_oriented_model">The Service Oriented Model</a><br />
            2.3.2.1 <a href="#action">Action</a><br />
            2.3.2.2 <a href="#agent">Agent</a><br />
            2.3.2.3 <a href="#choreography">Choreography</a><br />
            2.3.2.4 <a href="#capability">Capability</a><br />
            2.3.2.5 <a href="#goal_state">Goal State</a><br />
            2.3.2.6 <a href="#provider_agent">Provider Agent</a><br />
            2.3.2.7 <a href="#provider_entity">Provider Entity</a><br />
            2.3.2.8 <a href="#requester_agent">Requester Agent</a><br />
            2.3.2.9 <a href="#requester_entity">Requester Entity</a><br />
            2.3.2.10 <a href="#service">Service</a><br />
            2.3.2.11 <a href="#service_description">Service Description</a><br />
            2.3.2.12 <a href="#service_interface">Service Interface</a><br />
            2.3.2.13 <a href="#intermediary">Service Intermediary</a><br />
            2.3.2.14 <a href="#service_role">Service Role</a><br />
            2.3.2.15 <a href="#service_semantics">Service Semantics</a><br />
            2.3.2.16 <a href="#service_task">Service Task</a><br />
        2.3.3 <a href="#resource_oriented_model">The Resource Oriented Model</a><br />
            2.3.3.1 <a href="#discovery">Discovery</a><br />
            2.3.3.2 <a href="#discovery_service">Discovery Service</a><br />
            2.3.3.3 <a href="#identifier">Identifier</a><br />
            2.3.3.4 <a href="#representation">Representation</a><br />
            2.3.3.5 <a href="#resource">Resource</a><br />
            2.3.3.6 <a href="#resource_description">Resource description</a><br />
        2.3.4 <a href="#policy_model">The Policy Model</a><br />
            2.3.4.1 <a href="#audit_guard">Audit Guard</a><br />
            2.3.4.2 <a href="#domain">Domain</a><br />
            2.3.4.3 <a href="#obligation">Obligation</a><br />
            2.3.4.4 <a href="#permission">Permission</a><br />
            2.3.4.5 <a href="#permission_guard">Permission Guard</a><br />
            2.3.4.6 <a href="#poo">Person or Organization</a><br />
            2.3.4.7 <a href="#policy">Policy</a><br />
            2.3.4.8 <a href="#policy_description">Policy Description</a><br />
            2.3.4.9 <a href="#policy_guard">Policy Guard</a><br />
    2.4 <a href="#relationships">Relationships</a><br />
        2.4.1 <a href="#isa">The is a relationship</a><br />
            2.4.1.1 <a href="#id2277502">Definition</a><br />
            2.4.1.2 <a href="#id2277533">Relationships to other elements</a><br />
            2.4.1.3 <a href="#id2277661">Explanation</a><br />
        2.4.2 <a href="#describes">The describes relationship</a><br />
            2.4.2.1 <a href="#id2277737">Definition</a><br />
            2.4.2.2 <a href="#id2277769">Relationships to other elements</a><br />
            2.4.2.3 <a href="#id2277802">Explanation</a><br />
        2.4.3 <a href="#hasa">The has a relationship</a><br />
            2.4.3.1 <a href="#id2277857">Definition</a><br />
            2.4.3.2 <a href="#id2277882">Relationships to other elements</a><br />
            2.4.3.3 <a href="#id2277914">Explanation</a><br />
        2.4.4 <a href="#owns">The owns relationship</a><br />
            2.4.4.1 <a href="#id2277970">Definition</a><br />
            2.4.4.2 <a href="#id2278004">Relationships to other elements</a><br />
            2.4.4.3 <a href="#id2278099">Explanation</a><br />
        2.4.5 <a href="#realized">The realized relationship</a><br />
            2.4.5.1 <a href="#id2278146">Definition</a><br />
            2.4.5.2 <a href="#id2278179">Relationships to other elements</a><br />
            2.4.5.3 <a href="#id2278242">Explanation</a><br />
3 <a href="#stakeholder">Stakeholder's Perspectives</a><br />
    3.1 <a href="#service_oriented_architecture">Service Oriented Architecture</a><br />
        3.1.1 <a href="#soadefs">Distributed Systems</a><br />
        3.1.2 <a href="#wsdossoa">Web Services and Architectural Styles</a><br />
        3.1.3 <a href="#relwwwrest">Relationship to the World Wide Web and REST Architectures</a><br />
    3.2 <a href="#technology">Web Services Technologies</a><br />
        3.2.1 <a href="#XML-infoset">XML</a><br />
        3.2.2 <a href="#SOAP">SOAP</a><br />
        3.2.3 <a href="#WSDL">WSDL</a><br />
    3.3 <a href="#stakeholder_using">Using Web Services</a><br />
    3.4 <a href="#wsdisc">Web Service Discovery</a><br />
        3.4.1 <a href="#id2279776">Manual Versus Autonomous Discovery</a><br />
        3.4.2 <a href="#discovery_approaches">Discovery: Registry, Index or Peer-to-Peer?</a><br />
            3.4.2.1 <a href="#id2279875">The Registry Approach</a><br />
            3.4.2.2 <a href="#id2279923">The Index Approach</a><br />
            3.4.2.3 <a href="#id2280003">Peer-to-Peer (P2P) Discovery</a><br />
            3.4.2.4 <a href="#id2280045">Discovery Service Trade-Offs</a><br />
        3.4.3 <a href="#id2280061">Federated Discovery Services</a><br />
        3.4.4 <a href="#id2280135">Functional Descriptions and Discovery</a><br />
    3.5 <a href="#id2280201">Web Service Semantics</a><br />
        3.5.1 <a href="#id2280311">Message semantics and visibility</a><br />
        3.5.2 <a href="#id2280404">Semantics of the Architectural Models</a><br />
        3.5.3 <a href="#id2280504">The Role of Metadata</a><br />
    3.6 <a href="#security">Web Services Security</a><br />
        3.6.1 <a href="#security_policies">Security policies</a><br />
        3.6.2 <a href="#id2280826">Message Level Security Threats</a><br />
            3.6.2.1 <a href="#id2280892">Message Alteration</a><br />
            3.6.2.2 <a href="#id2280916">Confidentiality</a><br />
            3.6.2.3 <a href="#id2280930">Man-in-the-middle</a><br />
            3.6.2.4 <a href="#id2280949">Spoofing</a><br />
            3.6.2.5 <a href="#id2280967">Denial of Service</a><br />
            3.6.2.6 <a href="#id2280993">Replay Attacks</a><br />
        3.6.3 <a href="#wssreqs">Web Services Security Requirements</a><br />
            3.6.3.1 <a href="#id2281040">Authentication Mechanisms</a><br />
            3.6.3.2 <a href="#id2281072">Authorization</a><br />
            3.6.3.3 <a href="#id2281089">Data Integrity and Data Confidentiality</a><br />
            3.6.3.4 <a href="#id2281105">Integrity of Transactions and Communications</a><br />
            3.6.3.5 <a href="#id2281118">Non-Repudiation</a><br />
            3.6.3.6 <a href="#id2281134">End-to-End Integrity and Confidentiality of Messages</a><br />
            3.6.3.7 <a href="#id2281146">Audit Trails</a><br />
            3.6.3.8 <a href="#id2281168">Distributed Enforcement of Security Policies</a><br />
        3.6.4 <a href="#id2281182">Security Consideration of This Architecture</a><br />
            3.6.4.1 <a href="#id2281208">Cross-Domain Identities</a><br />
            3.6.4.2 <a href="#id2281240">Distributed Policies</a><br />
            3.6.4.3 <a href="#id2281256">Trust Policies</a><br />
            3.6.4.4 <a href="#id2281308">Secure Discovery Mechanism</a><br />
            3.6.4.5 <a href="#trust">Trust and Discovery</a><br />
            3.6.4.6 <a href="#id2281395">Secure Messaging</a><br />
        3.6.5 <a href="#privacy">Privacy Considerations</a><br />
    3.7 <a href="#id2281505">Peer-to-Peer Interaction</a><br />
    3.8 <a href="#reliability">Web Services Reliability</a><br />
        3.8.1 <a href="#message_reliability">Message reliability</a><br />
        3.8.2 <a href="#service_reliability">Service reliability</a><br />
        3.8.3 <a href="#management">Reliability and management</a><br />
    3.9 <a href="#service_management">Web Service Management</a><br />
    3.10 <a href="#edi">Web Services and EDI: Transaction Tracking</a><br />
        3.10.1 <a href="#edi-tracking-problem">When Something Goes Wrong</a><br />
        3.10.2 <a href="#edi-tracking-need">The Need for Tracking</a><br />
        3.10.3 <a href="#edi-tracking-examples">Examples of Tracking</a><br />
        3.10.4 <a href="#edi-tracking-requirements">Requirements for Effective Tracking</a><br />
        3.10.5 <a href="#edi-tracking-and-uris">Tracking and URIs</a><br />
4 <a href="#conclusions">Conclusions</a><br />
    4.1 <a href="#id2282493">Requirements
    Analysis</a><br />
    4.2 <a href="#id2282511">Value of This
    Work</a><br />
    4.3 <a href="#unresolved_issues">Significant Unresolved
    Issues</a><br />
</p>
<h3><a name="appendices" id="appendices"></a>Appendices</h3><p class="toc">A <a href="#id2282689">Overview of Web Services Specifications</a> (Non-Normative)<br />
B <a href="#wsstechno">An Overview of Web Services Security Technologies</a> (Non-Normative)<br />
    B.1 <a href="#dsigenc">XML-Signature and XML-Encryption</a><br />
    B.2 <a href="#wss">Web Services Security</a><br />
    B.3 <a href="#xkms">XML Key Management Specification (XKMS) 2.0</a><br />
    B.4 <a href="#saml">Security Assertion Markup Language (SAML)</a><br />
    B.5 <a href="#id2282920">XACML: Communicating Policy Information</a><br />
    B.6 <a href="#id2282942">Identity Federation</a><br />
C <a href="#id2282999">References</a> (Non-Normative)<br />
D <a href="#id2283417">Acknowledgments</a> (Non-Normative)<br />
</p></div><hr /><div class="body"><div class="div1">
<h2><a name="introduction" id="introduction"></a>1 Introduction</h2><div class="div2">
<h3><a name="id2260892" id="id2260892"></a>1.1 Purpose of the Web Service Architecture</h3><p>Web services provide a standard means of interoperating between different software
          applications, running on a variety of platforms and/or frameworks. This document (WSA) is
          intended to provide a common definition of a Web service, and define its place within a
          larger Web services framework to guide the community.  The WSA provides a conceptual model and a context for understanding Web services and the
          relationships between the components of this model.
           </p><p>The
          architecture does not attempt to specify how Web services are implemented, and imposes no
          restriction on how Web services might be combined. The WSA describes both the minimal
          characteristics that are common to all Web services, and a number of characteristics that
          are needed by many, but not all, Web services. </p><p>The Web services architecture is an <em>interoperability</em> architecture: it
            identifies those global elements of the global Web services network that are required in
            order to ensure interoperability between Web services. </p></div><div class="div2">
<h3><a name="docoverview" id="docoverview"></a>1.2 Intended Audience</h3><p>This document is intended for a diverse audience. Expected readers include
          Web service specification authors, creators of Web service software, people making decisions about Web service technologies, and others.</p></div><div class="div2">
<h3><a name="id2259932" id="id2259932"></a>1.3 Document Organization</h3><p>This document has two main sections: a core concepts section (<a href="#concepts_and_relationships"><b>2  Concepts and Relationships</b></a> )
	and a stakeholder's perspectives section (<a href="#stakeholder"><b>3 Stakeholder's Perspectives</b></a>).  </p><p><a href="#concepts_and_relationships"><b>2  Concepts and Relationships</b></a>  provides the bulk of the conceptual model on which conformance constraints could be based. For example, the <a title="" href="#resource">resource</a> concept states
          that resources have identifiers (in fact they have URIs). Using this assertion as a basis,
          we can assess conformance to the architecture of a particular resource by looking for its
          identifier. If, in a given instance of this architecture, a resource has no identifier,
          then it is not a valid instance of the architecture.</p><p>While the <a title="" href="#concepts_and_relationships">concepts and relationships</a>
          represent an enumeration of the architecture, the <a title="" href="#stakeholder">stakeholders'
          perspectives</a> approaches from a different viewpoint: how the architecture meets
          the goals and requirements. In this section we elucidate the more global properties of the
          architecture and demonstrate how the <a title="" href="#concepts">concepts</a> actually
          achieve important objectives.</p><p>A primary goal of the <a title="" href="#stakeholder">Stakeholder's Perspectives</a>
          section is to provide a top-down view of the architecture from various perspectives.  For example, in the <a href="#security"><b>3.6 Web Services Security</b></a> section we show how the
          security of Web services is addressed within the architecture. The aim here is to
          demonstrate that Web services can be made secure and indicate which key concepts and features of the
          architecture achieve that goal.</p><p>The key stakeholder's perspectives supported in this document reflect the major goals of
          the architecture itself: interopability, extensibility, security, Web integration,
          implementation and manageability.</p></div><div class="div2">
<h3><a name="whatis" id="whatis"></a>1.4 What is a Web service?</h3><p>For the purpose of this Working Group and this architecture, and without prejudice toward
	  other definitions, we will use the following definition:</p><p>
          [<a name="wsdef" id="wsdef" title="Web service">Definition</a>: A Web service is a software system designed to
          support interoperable machine-to-machine interaction over a network. It has an interface
          described in a machine-processable format (specifically WSDL). Other systems interact with
          the Web service in a manner prescribed by its description using SOAP messages, typically
          conveyed using HTTP with an XML serialization in conjunction with other Web-related
          standards.]</p><div class="div3">
<h4><a name="id2260073" id="id2260073"></a>1.4.1 Agents and Services</h4><p>A Web <a title="" href="#service">service</a> is an abstract notion that must be implemented by
            a concrete <a title="" href="#agent">agent</a>. (See
	    <a href="#gengag">Figure 1-1</a>) The agent is the concrete piece
            of software or hardware that sends and receives <a title="" href="#message">messages</a>, while the service is the resource characterized by the abstract set of
            functionality that is provided. To illustrate this distinction, you might implement a
            particular Web service using one agent one day (perhaps written in one programming
            language), and a different agent the next day (perhaps written in a different
            programming language) with the same functionality. Although the agent may have changed, the Web service remains the same.</p></div><div class="div3">
<h4><a name="reqpro" id="reqpro"></a>1.4.2 Requesters and Providers</h4><p>The purpose of a Web service is to provide some functionality on behalf of its owner --
            a <a title="" href="#poo">person or organization</a>, such as a business or an individual. The <em>provider
            entity</em> is the <a title="" href="#poo">person or organization</a> that provides an appropriate agent to implement a
            particular service. (See <a href="#gengag">Figure 1-1</a>: Basic Architectural Roles.) </p><p>A <em>requester entity</em> is a <a title="" href="#poo">person or organization</a> that wishes to make use of a provider
            entity's Web service. It will use a <em>requester agent</em> to exchange messages
            with the provider entity's <em>provider
	    agent</em>.</p><p> (In most cases, the requester agent is the one to initiate this message exchange, though not always.  Nonetheless, for consistency we still use the term "requester agent" for the agent that interacts with the provider agent, even in cases when the provider agent actually initiates the exchange.)  </p><div class="note"><p class="prefix"><b>Note:</b></p><p id="wordonspr">A word on terminology: Many documents use the term service provider to refer to the provider entity and/or provider agent.  Similarly, they may use the term service requester to refer to the requester entity and/or requester agent.  However, since these terms are ambiguous -- sometimes referring to the <a title="" href="#agent">agent</a> and sometimes to the <a title="" href="#poo">person or organization</a> that owns the agent -- this document prefers the terms <em>requester entity</em>, <em>provider entity</em>, <em>requester agent</em> and <em>provider agent</em>.</p></div><p>In order for this message
            exchange to be successful, the requester entity and the provider entity must first <a title="" href="#agree">agree</a>
            on both the semantics and the mechanics of the message exchange.  (This is a slight simplification that will be explained further in <a href="#stakeholder_using"><b>3.3 Using Web Services</b></a>.) </p></div><div class="div3">
<h4><a name="id2263315" id="id2263315"></a>1.4.3 Service Description</h4><p>The mechanics of the message exchange are documented in a Web service
            <a title="" href="#service_description">description</a>
	    (WSD). (See <a href="#gengag">Figure 1-1</a>) The WSD is a machine-processable
            specification of the Web service's interface, written in WSDL.  It defines the message formats, datatypes,
            transport protocols, and transport serialization formats that should be used between the
            requester agent and the provider agent. It also specifies one or more network locations at which a provider agent can be invoked, and may provide some
            information about the message exchange pattern that is expected. In essence, the service description represents an <a title="" href="#agree">agreement</a> governing the mechanics
            of interacting with that service.     (Again this is a slight simplification that will be explained further in <a href="#stakeholder_using"><b>3.3 Using Web Services</b></a>.)</p></div><div class="div3">
<h4><a name="id2263364" id="id2263364"></a>1.4.4 Semantics</h4><p>The <a title="" href="#service_semantics">semantics</a> of a Web service is the shared
            expectation about the behavior of the service, in particular in response to messages
            that are sent to it. In effect, this is the "contract" between the requester
            entity and the provider entity regarding the purpose and consequences of the
            interaction.  Although this contract represents the overall agreement between the
            requester entity and the provider entity on how and why their respective agents will
            interact, it is not necessarily written or explicitly negotiated.  It may be explicit or
            implicit, oral or written, machine processable or human oriented, and it may be a legal agreement or an informal (non-legal) <a title="" href="#agree">agreement</a>.       (Once again this is a slight simplification that will be explained further in <a href="#stakeholder_using"><b>3.3 Using Web Services</b></a>.)</p><p>While the service description represents a contract governing the mechanics of
            interacting with a particular service, the semantics represents a contract governing the
            meaning and purpose of that interaction.  The dividing line between these two is not
            necessarily rigid.  As more semantically rich languages are used to describe the
            mechanics of the interaction, more of the essential information may migrate from the
            informal semantics to the service description.  As this migration occurs, more of the work
            required to achieve successful interaction can be automated.  </p></div><div class="div3">
<h4><a name="engaging" id="engaging"></a>1.4.5 Overview of Engaging a Web Service</h4><p>There are many ways that a requester entity might engage and use a Web service.  In general, the following broad steps are required, as illustrated in <a href="#gengag">Figure 1-1</a>:  (1) the requester and provider entities become known to each other (or at least one becomes know to the other); (2) the requester and provider entities somehow <a title="" href="#agree">agree</a> on the service description and semantics that will govern the interaction between the requester and provider agents; (3) the service description and semantics are realized by the requester and provider agents; and (4) the requester and provider agents exchange messages, thus performing some task on behalf of the requester and provider entities.  (I.e., the exchange of messages with the provider agent represents the concrete manifestation of interacting with the provider entity's Web service.)  These steps are explained in more detail in <a href="#wsdisc"><b>3.4 Web Service Discovery</b></a>.  Some of these steps may be automated, others may be performed manually.</p><div class="figure"><a name="gengag" id="gengag"></a><br /><img src="images/intro_ws_roles.gif" alt="The General Process of Engaging a Web        Service" /><p><i><span>Figure 1-1. </span>The General Process of Engaging a Web        Service</i></p><br /></div></div></div><div class="div2">
<h3><a name="id2268685" id="id2268685"></a>1.5 Related Documents</h3><p>The Working Group produced the following companion documents in the process of defining this architecture:</p><ul><li><p>Requirements Document <a href="#WSAREQ">[WSA Reqs]</a></p></li><li><p>Usage
Scenarios <a href="#WSUS">[WSAUS]</a></p></li><li><p>Glossary <a href="#WSAGLOSS">[WS Glossary]</a></p></li><li><p>OWL
Ontology <a href="#OWLO">[OWLO]</a></p></li></ul></div></div><div class="div1">
<h2><a name="concepts_and_relationships" id="concepts_and_relationships"></a>2  Concepts and Relationships</h2><div class="div2">
<h3><a name="id2268743" id="id2268743"></a>2.1 Introduction</h3><p>The formal core of the architecture is this enumeration of the concepts and
          relationships that are central to Web services' interoperability.</p></div><div class="div2">
<h3><a name="meta_model" id="meta_model"></a>2.2 How to read this section</h3><p>The architecture is described in terms of a few simple elements: concepts, relationships and models. Concepts are often noun-like in that they identify things or
	  properties that we expect to see in realizations of the architecture, similarly
	  relationships are normally linguistically verbs.</p><p>As with any large-scale effort, it is often necessary to structure the architecture
	  itself. We do this with the larger-scale meta-concept of <a title="" href="#model">model</a>. A model is a coherent portion of the architecture
	  that focuses on a particular theme or aspect of the architecture. </p><div class="div3">
<h4><a name="meta_concept" id="meta_concept"></a>2.2.1 Concepts</h4><p>A concept is expected to have some correspondence with any realizations of the
	    architecture. For example, the <a title="" href="#message">message</a> concept
	    identifies a class of object (not to be confused with Objects and Classes as are found
	    in Object Oriented Programming languages) that we expect to be able to identify in any
	    Web services context. The precise form of a message may be different in different
	    realizations, but the <a title="" href="#message">message</a> concept tells us what
	    to look for in a given concrete system rather than prescribing its precise form.</p><p>Not all concepts will have a realization in terms of data objects or structures
	    occurring in computers or communications devices; for example the <a title="" href="#poo">person or organization</a> refers to people and human
	    organizations. Other concepts are more abstract still; for example, <a title="" href="#message_reliability">message reliability</a> denotes a property of the
	    message transport service &#8212; a property that cannot be touched but nonetheless is
	    important to Web services.</p><p>Each concept is presented in a regular, stylized way consisting of a short definition,
            an enumeration of the relationships with other concepts, and a slightly longer
            explanatory description.  For example, the concept of <a title="" href="#agent">agent</a> includes as relating concepts the fact that an
            agent <a title="" href="#isa">is a</a> computational resource, <a title="" href="#hasa">has
            an identifier</a> and an owner. The description part of the <a title="" href="#agent">agent</a> explains in more detail why agents are important to the
            archicture.</p></div><div class="div3">
<h4><a name="meta_relationship" id="meta_relationship"></a>2.2.2 Relationships</h4><p>Relationships denote associations between concepts. Grammatically, relationships are
	  verbs; or more accurately, predicates.   A statement of a relationship typically takes the form: concept predicate concept. For
	  example, in <a title="" href="#agent">agent</a>, we state that:</p><dl><dt class="label"> An agent <a title="" href="#isa">is</a>
              </dt><dd><p>a computational resource</p></dd></dl><p>This statement makes an assertion, in this case about the nature of agents. Many such
	  statements are descriptive, others are definitive:</p><dl><dt class="label"> A message <a title="" href="#hasa">has</a>
              </dt><dd><p>a <a title="" href="#message_sender">message sender</a></p></dd></dl><p>Such a statement makes an assertion about valid instances of the architecture: we
	    expect to be able to identify the message sender in any realization of the
	    architecture. Conversely, any system for which we cannot identify the sender of a
	    message is not conformant to the architecture.  Even if a service is used anonymously, the sender has an identifier but it is not possible to associate this identifier with an actual person or organization.</p></div><div class="div3">
<h4><a name="id2268989" id="id2268989"></a>2.2.3 Concept Maps</h4><p>Many of the concepts in the architecture are illustrated with <em>concept maps</em>. A concept
            map is an informal, graphical way to illustrate key concepts and
            relationships. For example the diagram:</p><div class="figure"><br /><img src="images/mindmap.png" alt="Concept Map" /><p><i><span>Figure 2-1. </span>Concept Map</i></p><br /></div><p>shows three concepts which are related in various ways. Each box represents a concept, and each arrow (or labeled arc) represents a relationship.   </p><p>The merit of a concept map is that it allows rapid navigation of the key concepts and illustrates how
            they relate to each other. It should be stressed however that these diagrams are
            primarily navigational aids; the written text is the definitive source.</p></div><div class="div3">
<h4><a name="model" id="model"></a>2.2.4 Model</h4><p>A model is a coherent subset of the architecture that typically revolves around a
	    particular aspect of the overall architecture. Although different models share concepts,
	    it is usually from different points of view; the major role of a model is to explain and
	    encapsulate a significant theme within the overall Web services architecture.</p><p>For example, the <a title="" href="#message_oriented_model">Message Oriented Model</a>
            focuses and explains Web services strictly from a message passing perspective. In
            particular, it does not attempt to relate messages to services provided. The <a title="" href="#service_oriented_model">Service Oriented Model</a>, however, lays on
            top of and extends the Message Oriented Model in order to explain the fundamental
            concepts involved in service - in effect to explain the purpose of the messages in the Message
            Oriented Model.</p><p>Each model is described separately below, in terms of the concepts and relationships
            inherent to the model. The ordering of the concepts in each model section is
            alphabetical; this should not be understood to imply any relative importance. For a more
            focused viewpoint the reader is directed to the <a title="" href="#stakeholder">Stakeholder's
            perspectives</a> section which examines the architecture from the perspective of
            key stakeholders of the architecture.</p><p>The reason for choosing an alphabetical ordering is that there is a large
            amount of cross-referencing between the concepts. As a result, it is very difficult, if
            not misleading, to choose a non-alphabetic ordering that reflects some sense of priority
            between the concepts. Furthermore, the optimal ordering depends very much on the point
            of view of the reader. Hence, we devote the <a title="" href="#stakeholder">Stakeholders
            perspectives</a> section to a number of prioriterized readings of the
            architecture.</p></div><div class="div3">
<h4><a name="conformance" id="conformance"></a>2.2.5 Conformance</h4><p>Unlike language specifications, or protocol specifications, conformance to an
            architecture is necessarily a somewhat imprecise art. However, the presence of a concept
            in this enumeration is a strong hint that, in any realization of the architecture, there
            should be a corresponding feature in the implementation. Furthermore, if a relationship
            is identified here, then there should be corresponding relationships in any realized
            architecture. The consequence of non-conformance is likely to be reduced interoperability: The absence of such a concrete feature may not prevent interoperability,
            but it is likely to make such interoperability more difficult.</p><p>A primary function of the Architecture's enumeration in terms of models, concepts and
            relationships is to give guidance about conformance to the architecture. For example,
            the architecture notes that a <a title="" href="#message">message</a> <a title="" href="#hasa">has</a> a <a title="" href="#message_sender">message sender</a>; any
            realization of this architecture that does not permit a message to be associated with
            its sender is not in conformance with the architecture.  For example, SMTP could be used to transmit messages.  However, since SMTP (at present) allows forgery of the sender's identity, SMTP by itself is not sufficient to discharge this responsibility.</p></div></div><div class="div2">
<h3><a name="concepts" id="concepts"></a>2.3 The Architectural Models</h3><p>This architecture has four models, illustrated in <a href="#gmm">Figure 2-2</a>.  Each model in <a href="#gmm">Figure 2-2</a> is labeled with what may be viewed as the key
	  concept of that model.</p><div class="figure"><a name="gmm" id="gmm"></a><br /><img src="images/meta.png" alt="Meta Model of the Architecture" /><p><i><span>Figure 2-2. </span>Meta Model of the Architecture</i></p><br /></div><p>The four models are:</p><ul><li><p>The <a title="" href="#message_oriented_model">Message Oriented Model</a>
	      focuses on messages, message structure, message transport and so on &#8212; without
	      particular reference as to the reasons for the messages, nor to their
	      significance.</p><div class="figure"><br /><img src="images/message101.png" alt="Simplified Message Oriented Model" /><p><i><span>Figure 2-3. </span>Simplified Message Oriented Model</i></p><br /></div><p>
              The essence of the message model revolves around a few key concepts illustrated above: the <a title="" href="#agent">agent</a> that sends and receives <a title="" href="#message">messages</a>, the structure of the message in terms of <a title="" href="#message_header">message headers</a> and <a title="" href="#message_body">bodies</a> and the mechanisms used to deliver messages. Of
              course, there are additional details to consider: the role of policies and
              how they govern the message level model.
            The abridged diagram shows the key concepts; the detailed diagram expands on this to include many more concepts and relationships.</p></li><li><p>The <a title="" href="#service_oriented_model">Service Oriented Model</a>
	      focuses on aspects of <a title="" href="#service">service</a>, action and so
	      on. While clearly, in any distributed system, services cannot be adequately realized
	      without some means of messaging, the converse is not the case: messages do not need to
	      relate to services.</p><div class="figure"><br /><img src="images/service101.png" alt="Simplified Service Oriented Model" /><p><i><span>Figure 2-4. </span>Simplified Service Oriented Model</i></p><br /></div><p>
              The Service Oriented Model is the most complex of all the models in the
              architecture. However, it too revolves around a few key ideas. A service is realized
              by an agent and used by another agent. Services are mediated by means of the messages exchanged
              between requester agents and provider agents. </p><p>A very important
              aspect of services is their relationship to the real world: services are mostly
              deployed to offer functionality in the real world. We model this by elaborating on the
              concept of a service's owner &#8212; which, whether it is a person or an organization,
              has a real world responsibility for the service.
            </p><p>
              Finally, the Service Oriented Model makes use of meta-data, which, as described in <a href="#service_oriented_architecture"><b>3.1 Service Oriented Architecture</b></a>, is a key property of Service Oriented Architectures. This meta-data is used to document many aspects of services: from the
              details of the interface and transport binding to the semantics of the service and
              what policy restrictions there may be on the service. Providing rich descriptions is
              key to successful deployment and use of services across the Internet.
            </p></li><li><p>The <a title="" href="#resource_oriented_model">Resource Oriented Model</a> focuses
	      on <a title="" href="#resource">resources</a> that exist and have owners.</p><div class="figure"><br /><img src="images/resource101.png" alt="Simplified Resource Oriented Model" /><p><i><span>Figure 2-5. </span>Simplified Resource Oriented Model</i></p><br /></div><p>The resource model is adopted from the <a href="http://www.w3.org/TR/webarch/">Web Architecture</a> concept of resource.  We expand on this to
            incorporate the relationships between resources and owners.</p></li><li><p>The <a title="" href="#policy_model">Policy Model</a> focuses on constraints on the behavior of
	      agents and services. We generalize this to <a title="" href="#resource">resources</a>
	      since policies can apply equally to documents (such as descriptions of services) as
	      well as active computational resources.
            </p><div class="figure"><br /><img src="images/policy101.png" alt="Simplified Policy Model" /><p><i><span>Figure 2-6. </span>Simplified Policy Model</i></p><br /></div><p>
              Policies are about <a title="" href="#resource">resources</a>.  They are applied to <a title="" href="#agent">agents</a> that may attempt to access those resources, and are put
              in place, or established, by <a title="" href="#poo">people</a> who have
              responsibility for the resource.
            </p><p>
              Policies may be enacted to represent security concerns, quality of service concerns,
              management concerns and application concerns.
            </p></li></ul><div class="div3">
<h4><a name="message_oriented_model" id="message_oriented_model"></a>2.3.1 Message Oriented Model</h4><p>The Message Oriented Model focuses on those aspects of the architecture that relate
	  to <a title="" href="#message">messages</a> and the processing of them. Specifically, in
	  this model, we are not concerned with any semantic significance of the content of a
	  message or its relationship to other messages. However, the MOM does focus on the
	  structure of messages, on the relationship between message senders and receivers and how
	  messages are transmitted.</p><p>The MOM is illustrated in the <a href="#gmom">Figure 2-7</a>:</p><div class="figure"><a name="gmom" id="gmom"></a><br /><img src="images/MOM.png" alt="Message Oriented Model" /><p><i><span>Figure 2-7. </span>Message Oriented Model</i></p><br /></div><div class="div4">
<h5><a name="address" id="address"></a>2.3.1.1 Address</h5><div class="div5">
<h6><a name="id2269615" id="id2269615"></a>2.3.1.1.1 Definition</h6><p>An address is that information required by a message transport mechanism in order
              to deliver a message appropriately.</p></div><div class="div5">
<h6><a name="id2269627" id="id2269627"></a>2.3.1.1.2 Relationships to other elements</h6><dl><dt class="label">An address <a title="" href="#isa">is</a> </dt><dd><p>information used to describe how and where to deliver <a title="" href="#message">messages</a>.
                    </p></dd><dt class="label">An address <a title="" href="#isa">may be</a> </dt><dd><p>a URI.
                    </p></dd><dt class="label">An address <a title="" href="#isa">is</a> </dt><dd><p>typically <a title="" href="#message_transport">transport mechanism</a>
                    specific.
                    </p></dd><dt class="label">An address may be contained</dt><dd><p>in the <a title="" href="#envelope">message envelope</a>.
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2269738" id="id2269738"></a>2.3.1.1.3 Explanation</h6><p>In order for <a title="" href="#message_transport">message transport</a>
                mechanisms to function, it is normally necessary to provide information that
                allows messages to be delivered. This is called the address of the message
                receiver.</p><p>Typically, the form of the address information will depend of the particular
                message transport. In the case of an HTTP message transport, the address information
                will take the form of a URL.</p><p>The precise method that a <a title="" href="#message_sender">message sender</a>
                uses to convey address information will also depend on the transport mechanism
                used. On occasion, the address information may be provided as additional arguments
                to the invoking procedure. Or the address information may be located within the
                message itself; typically in the message envelope.</p></div></div><div class="div4">
<h5><a name="delivery_policy" id="delivery_policy"></a>2.3.1.2 Delivery Policy</h5><div class="div5">
<h6><a name="id2269793" id="id2269793"></a>2.3.1.2.1 Definition</h6><p>A delivery policy is a policy that constrains the methods by which messages are
              delivered by the message transport.</p></div><div class="div5">
<h6><a name="id2269805" id="id2269805"></a>2.3.1.2.2 Relationships to other elements</h6><dl><dt class="label">Delivery policy <a title="" href="#isa">is</a> </dt><dd><p>a <a title="" href="#policy">policy</a>
                    </p></dd><dt class="label">Delivery policy constrains</dt><dd><p><a title="" href="#message_transport">message transport</a>
                    </p></dd><dt class="label">Delivery policy may be expressed</dt><dd><p>in a policy description language
                    </p></dd><dt class="label">Delivery policy may express</dt><dd><p>the quality of service associated with delivering a <a title="" href="#message">message</a> by a <a title="" href="#message_transport">message
                    transport</a> mechanism</p></dd></dl></div><div class="div5">
<h6><a name="id2269905" id="id2269905"></a>2.3.1.2.3 Explanation</h6><p>Delivery policies are those <a title="" href="#policy">policies</a> that relate to
                the delivery of messages.</p><p>Typically, a delivery policy applies to the combination of a particular message and
                a particular <a title="" href="#message_transport">message transport</a>
                mechanism. The policies that apply, however, may originate from descriptions in the
                message itself, or be intrinsic to the transport mechanism, or both.</p><p>Examples of delivery policies include quality of service assurances &#8212; such as
                reliable versus best effort message delivery &#8212; and security assurances &#8212; such as
                encrypted versus unencrypted message transport. Another kind of delivery policy
                could take the form of assertions about recording an audit of how the message was
                delivered.</p></div></div><div class="div4">
<h5><a name="message" id="message"></a>2.3.1.3 Message</h5><div class="div5">
<h6><a name="id2269964" id="id2269964"></a>2.3.1.3.1 Definition</h6><p>A message is the basic unit of data sent from one Web services agent to another in
		the context of Web services.</p></div><div class="div5">
<h6><a name="id2269976" id="id2269976"></a>2.3.1.3.2 Relationships to other elements</h6><dl><dt class="label">a message <a title="" href="#isa">is</a>
                  </dt><dd><p>a unit of data sent from one <a title="" href="#agent">agent</a> to another</p></dd><dt class="label">a message may <a title="" href="#isa">be</a> part of</dt><dd><p>a <a title="" href="#ms">message sequence</a>
                    </p></dd><dt class="label">a message may be <a title="" href="#describes">described</a> using</dt><dd><p>a service description
                    language
                    </p></dd><dt class="label">a message <a title="" href="#hasa">has</a>
                  </dt><dd><p>a <a title="" href="#message_sender">message sender</a>
                    </p></dd><dt class="label">a message <a title="" href="#hasa">has</a>
                  </dt><dd><p>one or more <a title="" href="#message_recipient">message recipients</a>
                    </p></dd><dt class="label">a message may <a title="" href="#hasa">have</a>
                  </dt><dd><p>an <a title="" href="#identifier">identifier</a></p></dd><dt class="label">a message <a title="" href="#hasa">has</a>
                  </dt><dd><p>a message body</p></dd><dt class="label">a message <a title="" href="#hasa">has</a>
                  </dt><dd><p>zero or more <a title="" href="#message_header">message headers</a>
                    </p></dd><dt class="label">a message  <a title="" href="#hasa">has</a>
                  </dt><dd><p>a <a title="" href="#envelope">message envelope</a></p></dd><dt class="label">a message  is delivered by
                  </dt><dd><p>a <a title="" href="#message_transport">message transport</a> system</p></dd><dt class="label">a message may <a title="" href="#hasa">have</a>
                  </dt><dd><p>a <a title="" href="#delivery_policy">delivery policy</a> associated with it
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2270264" id="id2270264"></a>2.3.1.3.3 Explanation</h6><p>A message represents the data structure passed from its sender to its recipients.
		The structure of a message is defined in a service description.</p><p>The main parts of a message are its envelope, a set of zero or more headers, and
                the message body. The envelope serves to encapsulate the component parts of the
                message and it serves as a well-known location for message transport services to locate
                necessary addressing information.  The header holds ancillary information about the message and  facilitates modular processing.  The body of the message contains the message content or URIs to the actual data
	        resource.</p><p>A message can be as simple as an HTTP GET request, in which the HTTP headers are
		the headers and the parameters encoded in the URL are the content. Note that
		extended Web services functionality in this architecture is not supported in HTTP
		headers.</p><p>A message can also simply be a plain XML document.  However, such messages do not support
		extended Web services functionality defined in this architecture.</p><p>A message can be a SOAP XML, in which the SOAP headers are the headers.  Extended
		Web services functionality are supported in SOAP headers.</p></div></div><div class="div4">
<h5><a name="message_body" id="message_body"></a>2.3.1.4 Message Body</h5><div class="div5">
<h6><a name="id2270320" id="id2270320"></a>2.3.1.4.1 Definition</h6><p>A message body is the structure that represents the primary application-specific content that the
	        message sender intends to deliver to the message recipient.</p></div><div class="div5">
<h6><a name="id2270332" id="id2270332"></a>2.3.1.4.2 Relationships to other elements</h6><dl><dt class="label">a message body is <a title="" href="#hasa">contained by</a>
                  </dt><dd><p>the <a title="" href="#envelope">message envelope</a>.</p></dd><dt class="label">a message body <a title="" href="#isa">is</a>
                  </dt><dd><p>the application-specific content intended for the message recipient.</p></dd></dl></div><div class="div5">
<h6><a name="id2270391" id="id2270391"></a>2.3.1.4.3 Explanation</h6><p>The message body provides a mechanism for transmitting information to the recipient
	        of the message. The form of the message body, and other constraints on the body, may
	        be expressed as part of the service description.</p><p>In many cases, the precise interpretation of the message body will depend on
                the <a title="" href="#message_header">message headers</a> that are in the
                message.</p></div></div><div class="div4">
<h5><a name="correlation" id="correlation"></a>2.3.1.5 Message Correlation</h5><div class="div5">
<h6><a name="id2270428" id="id2270428"></a>2.3.1.5.1 Definition</h6><p>Message correlation is the association of a message with a context. Message correlation
              ensures that a <a title="" href="#requester_agent">requester agent</a> can match the reply with the
              request, especially when multiple replies may be possible.</p></div><div class="div5">
<h6><a name="id2270449" id="id2270449"></a>2.3.1.5.2 Relationships to other elements</h6><dl><dt class="label">Message Correlation <a title="" href="#isa">is</a>
                  </dt><dd><p>a means of associating a <a title="" href="#message">message</a> within a specific conversational context.</p></dd><dt class="label">Message correlation may be <a title="" href="#realized">realized</a>
                  </dt><dd><p>by including message identifiers to enable
		      <a title="" href="#message">messages</a> to be identified.</p></dd></dl></div><div class="div5">
<h6><a name="id2270516" id="id2270516"></a>2.3.1.5.3 Explanation</h6><p>Message correlation allows a message to be associated with  a particular purpose or context. In a
		conversation, it is important to be able to determine that an actual message that
		has been received is the expected message. Often this is implicit when conversations
		are relayed over stream-oriented message transports; but not all transports allow
		correlation to be established so implicitly.</p><p>For situations where correlation must be handled explicitly, one technique is to
		associate a message identifier with messages. The message identifier is an
		identifier that allows a received message to be correlated with the originating
		request. The sender may also add an identifier for a service, not necessarily the
		originating sender, who will be the recipient of the message (see asynchronous
		messaging).</p><p>Correlation may also be realized by the underlying protocol. For example, HTTP/1.1
                allows one to correlate a request with its response.</p></div></div><div class="div4">
<h5><a name="envelope" id="envelope"></a>2.3.1.6 Message Envelope</h5><div class="div5">
<h6><a name="id2270570" id="id2270570"></a>2.3.1.6.1 Definition</h6><p>A message envelope is the structure that encapsulates the component parts of a
	      message: the message body and the message headers.</p></div><div class="div5">
<h6><a name="id2270582" id="id2270582"></a>2.3.1.6.2 Relationships to other elements</h6><dl><dt class="label">a message envelope may <a title="" href="#hasa">contain</a>
                  </dt><dd><p>address information about the intended <a title="" href="#message_recipient">recipients</a> of its associated <a title="" href="#message">message</a></p></dd><dt class="label">a message envelope <a title="" href="#hasa">contains</a>
                  </dt><dd><p>the <a title="" href="#message_body">message body</a>.</p></dd><dt class="label">a message envelope <a title="" href="#hasa">contains</a>
                  </dt><dd><p>the <a title="" href="#message_header">message headers</a>.</p></dd></dl></div><div class="div5">
<h6><a name="issue_message_with_address" id="issue_message_with_address"></a>2.3.1.6.3 Explanation</h6><div class="issue"><p class="prefix"><a name="message_with_address" id="message_with_address"></a><b>Issue (message_with_address):</b></p><p class="prefix"><b>How is a message associated with its destination address?</b></p><p>There is an unresolved issue here.  A message somehow must be associated with its destination address.  This combination of the message with its destination address seems to be a significant architectural concept, yet SOAP does not require that the address be included in the message header.</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><p>The message envelope may contain information needed to actually deliver messages. If so, it
	        must at least contain sufficient address information so that the <a title="" href="#message_transport">message transport</a> can deliver the
	        message. Typically this information is part of the service <em>binding</em>
	        information found in a WSDL document.</p><p>Other metadata that may be present in an envelope includes security information to
	        allow the message to be authenticated and quality of service information.</p><p>A correctly design message transport mechanism should be able to deliver a message
	        based purely on the information in the envelope. For example, an encrypted message
	        that fully protects the identities of the sender, recipient as well as the message
	        content, may still be delivered using only the address information (and
	        the encrypted data stream itself).</p></div></div><div class="div4">
<h5><a name="mep" id="mep"></a>2.3.1.7 Message Exchange Pattern (MEP)</h5><div class="div5">
<h6><a name="id2270754" id="id2270754"></a>2.3.1.7.1 Definition</h6><p>A Message Exchanage Pattern (MEP) is a template, devoid of application semantics,
	      that describes a generic pattern for the exchange of messages between agents. It describes relationships (e.g., temporal, causal, sequential, etc.) of multiple messages exchanged in conformance with the pattern, as well as the normal and abnormal termination of any message exchange conforming to the pattern.</p></div><div class="div5">
<h6><a name="id2270771" id="id2270771"></a>2.3.1.7.2 Relationships to other elements</h6><dl><dt class="label">a message exchange pattern <a title="" href="#describes">describes</a>
                  </dt><dd><p>a generic pattern for the exchange of <a title="" href="#message">messages</a> between <a title="" href="#agent">agents</a>. </p></dd><dt class="label">a message exchange pattern <a title="" href="#isa">should have</a>
                  </dt><dd><p>a unique <a title="" href="#identifier">identifier</a>
                    </p></dd><dt class="label">a message exchange pattern may <a title="" href="#realized">realize</a>
                  </dt><dd><p>
                      <a title="" href="#correlation">message correlation</a>
                    </p></dd><dt class="label">a message exchange pattern may <a title="" href="#describes">describe</a>
                  </dt><dd><p>a <a title="" href="#service">service</a> invocation</p></dd></dl></div><div class="div5">
<h6><a name="issue_mep_vs_chor" id="issue_mep_vs_chor"></a>2.3.1.7.3 Explanation</h6><p>Distributed applications in a Web services architecture communicate via message
                exchanges. These message exchanges are logically factored
                into patterns that may be composed at different levels to form larger patterns.  A Message Exchange Pattern (MEP) is a template, devoid of application
                semantics, that describes a generic pattern for the exchange of
                (one-way) messages between agents. The patterns can be described
                by state machines that define the flow of the messages, including the
                handling of faults that may arise, and the correlation of messages.</p><div class="issue"><p class="prefix"><a name="mep_vs_chor" id="mep_vs_chor"></a><b>Issue (mep_vs_chor):</b></p><p class="prefix"><b>What is the difference between an MEP and a Choreography?</b></p><p>The precise difference between an MEP and a choreography is unresolved.  Some view MEPs as being atomic patterns, and a choreography as including composition of patterns.  Also, a choreography generally describes patterns that include application semantics (choreography = MEPs + application
                semantics), whereas an MEP is devoid of application semantics.  Finally, there is usually a difference in scale between an MEP and a choregraphy: A choreography often makes use of MEPs as building blocks.</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><p>Messages that are instances of an MEP are correlated, either explicitly or implicitly.  The
                exchanges may be synchronous or asynchronous.  </p><p>In order to promote interoperability, it is useful to define common MEPs that are
                broadly adopted and unambiguously identified. When a MEP is described for the
                purpose of interoperability, it should be associated with a URI that will identify
                that MEP.</p><p>Some protocols may natively
                support certain MEPs, e.g., HTTP natively supports request-response.  In other cases there is
                may be additional glue needed to map MEPs onto a protocol.</p><p>Web service description languages at the level of WSDL view MEPs from the
                perspective of a particular service actor. A simple request-reponse MEP, for
                example, appears as an incoming message which invokes an operation and an associated
                outgoing message with a reply. </p><p>An MEP is not necessarily limited to capturing only the inputs and outputs of a single service.  Consider the pattern:</p><ol type="1"><li><p>agent A uses an instance of an MEP (possibly request-response) to
		  communicate initially with B.</p></li><li><p>agent B then uses a separate, but related instance of an MEP to
		  communicate with C.</p></li><li><p>agent A uses another instance of an MEP to communicate with C but gets a
		  reply only after C has processed (2).</p></li></ol><p>This example makes it clear that the overall pattern cannot be described in terms of
		the inputs and outputs of any single interaction.  The pattern involves constraints
		and relationships among the messages in the various MEP instances.  It also
		illuminates the fact that exchange (1) is in in-out MEP from the perspective of
		actor B, and mirrored by an out-in MEP from the perspective of actor A.  Finally, an
		actual application instantiates this communication pattern and completes the picture
		by adding computation at A, B and C to carry out application-specific
		operations.</p><p>It is instructive to consider the kinds of fault reporting that occur
		in such a layering.  Consider a fault at the transport protocol level.  This
		transport level may itself be able to manage certain faults (e.g., re-tries), but it
		may also simply report the fault to the binding level.  Similarly the binding level
		may manage the fault (e.g., by re-initiating the underlying protocol) or may report
		a SOAP fault.  The choreography and application layers may be intertwined or
		separated depending on how they are architected.  There is also no rigid distinction
		between the choreography and binding layers; binding-level MEPs are essentially
		simple choreographies.  Conceptually, the choreographic level can enforce
		constraints on message order, maintain state consistency, communicate choreographic
		faults to the application, etc. in ways that transcend particular bindings and
		transports.</p></div></div><div class="div4">
<h5><a name="message_header" id="message_header"></a>2.3.1.8 Message Header</h5><div class="div5">
<h6><a name="id2271058" id="id2271058"></a>2.3.1.8.1 Definition</h6><p>A message header is the part of the message that contains information about a
		specific aspect of the message. </p></div><div class="div5">
<h6><a name="id2271070" id="id2271070"></a>2.3.1.8.2 Relationships to other elements</h6><dl><dt class="label">a message header is contained in</dt><dd><p>a <a title="" href="#envelope">message envelope</a>
                    </p></dd><dt class="label">a message header  <a title="" href="#isa">may be</a>
                  </dt><dd><p>
                      a specific well known types</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">The "is-a" relationship here is used in a different
way than elsewhere in the document.</td></tr></table></dd><dt class="label">a message header may identify
                  </dt><dd><p>
                      a <a title="" href="#service_role">service role</a>, which denotes the kind of processing expected for the header.</p></dd><dt class="label">a message header may be processed
                  </dt><dd><p>
                      independently of the <a title="" href="#message_body">message body</a></p></dd></dl></div><div class="div5">
<h6><a name="id2271171" id="id2271171"></a>2.3.1.8.3 Explanation</h6><p>Message headers represent information about messages that is independently
                standardized (such as WS-Security) &#8212; and may have separate semantics -- from the message body.    For example,
                there may be standard forms of message header that describe authentication of
                messages. The form of such headers is defined for all messages; although, of course,
                a given authentication header will be specific to the particular message.</p><p>The primary function of headers is to facilitate the modular processing of the
                message, although they can also be used to support routing and related aspects of
                message processing. The header part of a message can include information pertinent
                to extended Web services functionality, such as security, transaction context,
                orchestration information, message routing information, or management
                information.</p><p>Message headers may be processed independently of the message body, each message
                header may have an identifying service role that indicates the kind of processing that should be
                performed on messages with that header.  Each message may have several headers, each potentially identifying a different service role.</p><p>Although many headers will relate to infrastructure facilities, such as security,
                routing, load balancing and so on; it is also possible that headers will be
                application specific. For example, a purchase order processing Web service may be
                structured into layers; corresponding to different functions within the
                organization. These stakeholders may process headers of different messages in
                standardized ways: the customer information may be captured in one standardized
                header, the stock items by a different standardized header and so on.</p></div></div><div class="div4">
<h5><a name="message_recipient" id="message_recipient"></a>2.3.1.9 Message Receiver</h5><div class="div5">
<h6><a name="id2271251" id="id2271251"></a>2.3.1.9.1 Definition</h6><p>A message receiver is an <a title="" href="#agent">agent</a> that receives
	      a <a title="" href="#message">message</a>.</p></div><div class="div5">
<h6><a name="id2271275" id="id2271275"></a>2.3.1.9.2 Relationships to other elements</h6><dl><dt class="label">a message receiver <a title="" href="#isa">is</a>
                  </dt><dd><p>a <a title="" href="#agent">agent</a>
                    </p></dd><dt class="label">a message receiver <a title="" href="#isa">is</a>
                  </dt><dd><p>the recipient of a <a title="" href="#message">message</a>
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2271338" id="id2271338"></a>2.3.1.9.3 Explanation</h6><p>The message receiver is an <a title="" href="#agent">agent</a>  that is intended to receive  a message from the <a title="" href="#message_sender">message sender</a>. </p><p>Messages may be passed through <a title="" href="#intermediary">intermediaries</a> that process aspects of the message,
                typically by examining the <a title="" href="#message_header">message
                headers</a>. The message recipient may or may not be aware of processing by
                such intermediaries.</p><p>Often a specific message receiver, the ultimate recipient, is identified as the
                final recipient of a message. The ultimate recipient will be responsible for
                completing the processing of the message.</p></div></div><div class="div4">
<h5><a name="reliable_messaging" id="reliable_messaging"></a>2.3.1.10 Message Reliability</h5><div class="div5">
<h6><a name="id2271404" id="id2271404"></a>2.3.1.10.1 Definition</h6><p>Message reliability is the degree of certainty that a message will be delivered and
                that sender and receiver will both have the same understanding of the delivery
                status.</p></div><div class="div5">
<h6><a name="id2271417" id="id2271417"></a>2.3.1.10.2 Relationships to other elements</h6><dl><dt class="label">message reliability <a title="" href="#isa">is</a>
                  </dt><dd><p>a property of message delivery.
                    </p></dd><dt class="label">message reliability may be <a title="" href="#realized">realized</a>
                  by</dt><dd><p>a combination of message acknowledgement and <a title="" href="#correlation">correlation</a>.</p></dd><dt class="label">message reliability may be <a title="" href="#realized">realized</a>
                  by</dt><dd><p>a <a title="" href="#message_transport">transport mechanism</a></p></dd></dl></div><div class="div5">
<h6><a name="id2271503" id="id2271503"></a>2.3.1.10.3 Explanation</h6><p>The goal of reliable messaging is to both reduce the error frequency for messaging
                and to provide sufficient information about the status of a message delivery. Such
                information enables a participating agent to make a compensating decision when
                errors or less than desired results occur.  High level correlation such as  "two-phase
                commit" is needed if more than two agents are involved. Note that in a distributed
                system, it is theoretically not possible to guarantee correct notification of
                delivery; however, in practice, simple techniques can greatly increase the overall
                confidence in the message delivery.</p><p>It is important to note that a guarantee of the delivery of messages alone may not
                improve the overall reliability of a Web service due to the need for end-to-end reliability.  (See  "<a href="http://www.reed.com/Papers/EndtoEnd.html">End-to-End Arguments in System Design</a>".)  It may,
                however, reduce the overall cost of a Web service.  </p><p>Message reliability may be realized with a combination of message receipt
                acknowledgement and correlation. In the event that a message has not been properly
                received and acted upon, the sender may attempt a resend, or some other compensating
                action at the application level.</p></div></div><div class="div4">
<h5><a name="message_sender" id="message_sender"></a>2.3.1.11 Message Sender</h5><div class="div5">
<h6><a name="id2271579" id="id2271579"></a>2.3.1.11.1 Definition</h6><p>A message sender is the agent that transmits a <a title="" href="#message">message</a>.</p></div><div class="div5">
<h6><a name="id2271596" id="id2271596"></a>2.3.1.11.2 Relationships to other elements</h6><dl><dt class="label">a message sender <a title="" href="#isa">is</a>
                  </dt><dd><p>an <a title="" href="#agent">agent</a>
                    </p></dd><dt class="label">a message sender <a title="" href="#isa">is</a>
                  </dt><dd><p>the originator of a <a title="" href="#message">message</a>
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2271659" id="id2271659"></a>2.3.1.11.3 Explanation</h6><p>
                A message sender is an <a title="" href="#agent">agent</a> that transmits a
                <a title="" href="#message">message</a> to another agent.  Although every message has a sender, the identity of the sender may not be available to others in the case of anonymous interactions.  </p><p>Messages may also be passed through intermediaries that process aspects of the
                message; typically by examining the <a title="" href="#message_header">message
                headers</a>. The sending agent may or may not be aware of such <a title="" href="#intermediary">intermediaries</a>.</p></div></div><div class="div4">
<h5><a name="ms" id="ms"></a>2.3.1.12 Message Sequence</h5><div class="div5">
<h6><a name="id2271719" id="id2271719"></a>2.3.1.12.1 Definition</h6><p>A message sequence is a sequence of related messages.</p></div><div class="div5">
<h6><a name="id2271730" id="id2271730"></a>2.3.1.12.2 Relationships to other elements</h6><dl><dt class="label">a message sequence <a title="" href="#isa">is</a></dt><dd><p>a sequence of related <a title="" href="#message">messages</a>
                    </p></dd><dt class="label">a message sequence may <a title="" href="#realized">realize</a></dt><dd><p>a documented <a title="" href="#message">message exchange pattern</a>
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2271792" id="id2271792"></a>2.3.1.12.3 Explanation</h6><p>A requester agent and a provider agent exchange a number of messages during an interaction. The ordered set of messages exchanged is a message sequence.</p><p>This sequence may be realizing a well-defined <a title="" href="#mep">MEP</a>, usually identified by a URI.</p></div></div><div class="div4">
<h5><a name="message_transport" id="message_transport"></a>2.3.1.13 Message Transport</h5><div class="div5">
<h6><a name="id2271828" id="id2271828"></a>2.3.1.13.1 Definition</h6><p>A Message Transport is a mechanism that may be used by agents to deliver messages.</p></div><div class="div5">
<h6><a name="id2271839" id="id2271839"></a>2.3.1.13.2 Relationships to other elements</h6><dl><dt class="label">a message transport <a title="" href="#isa">is</a></dt><dd><p>a mechanism that delivers <a title="" href="#message">messages</a>
                    </p></dd><dt class="label">a message transport <a title="" href="#hasa">has</a></dt><dd><p>zero or more <a title="" href="#capability">capabilities</a>
                    </p></dd><dt class="label">a message transport is constrained
                  by</dt><dd><p>various delivery <a title="" href="#policy">policies</a>
                    </p></dd><dt class="label">a message transport must know</dt><dd><p>sufficient <a title="" href="#address">address</a> information in order to
                    deliver a message.
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2271946" id="id2271946"></a>2.3.1.13.3 Explanation</h6><p>The message transport is the actual mechanism used to deliver messages. Examples of
		message transport include HTTP over TCP, SMTP, message oriented
		middleware, and so on.</p><p>The responsibility of the message transport is to deliver a message from a sender
                to one or more recipient, i.e. transport a SOAP Infoset from one agent to another,
                possibly with some implied semantics (e.g. HTTP methods semantics).</p><p>Message transports may provide different features (e.g. message integrity, quality
                of service guaranties, etc.).</p><p>For a message transport to function, the sending agent must provide the <a title="" href="#address">address</a> of the recipient.</p></div></div></div><div class="div3">
<h4><a name="service_oriented_model" id="service_oriented_model"></a>2.3.2 The Service Oriented Model</h4><p>The Service Oriented Model (SOM) focuses on those aspects of the architecture that relate to
          <a title="" href="#service">service</a> and <a title="" href="#action">action</a>.</p><p>The primary purpose of the SOM is to explicate the relationships between an <a title="" href="#agent">agent</a> and the <a title="" href="#service">services</a> it provides and
          requests.   The SOM builds on the MOM, but its focus is on <a title="" href="#action">action</a> rather than message.</p><p>The concepts and relationships in the SOM are illustrated
	  in <a href="#gsom">Figure 2-8</a>:</p><div class="figure"><a name="gsom" id="gsom"></a><br /><img src="images/ServiceModel.png" alt="Service Oriented Model" /><p><i><span>Figure 2-8. </span>Service Oriented Model</i></p><br /></div><div class="div4">
<h5><a name="action" id="action"></a>2.3.2.1 Action</h5><div class="div5">
<h6><a name="id2272081" id="id2272081"></a>2.3.2.1.1 Definition</h6><p>An action, for the purposes of this architecture, is any action that may be
              performed by an <a title="" href="#agent">agent</a>, possibly as a result of
              receiving a <a title="" href="#message">message</a>, or which results in sending a
              <a title="" href="#message">message</a> or another observable state change.</p></div><div class="div5">
<h6><a name="id2272116" id="id2272116"></a>2.3.2.1.2 Relationships to other elements</h6><dl><dt class="label"> An action may <a title="" href="#realized">result in</a>
                  </dt><dd><p>a desired <a title="" href="#goal_state">goal state</a></p></dd><dt class="label">An action may <a title="" href="#isa">be</a>
                  </dt><dd><p>the sending of a <a title="" href="#message">message</a></p></dd><dt class="label">An action may <a title="" href="#isa">be</a>
                  </dt><dd><p>the processing of a received <a title="" href="#message">message</a></p></dd></dl></div><div class="div5">
<h6><a name="id2272204" id="id2272204"></a>2.3.2.1.3 Explanation</h6><p>At the core of the concept of <a title="" href="#service">service</a> is the
	      notion of one party performing action(s) at the behest of another party.  From the
	      perspective of requester and provider agents, an action is typically performed by executing some fragment of a program.</p><p>In the WSA, the actions performed by requester and provider agents are largely
		out of scope, except in so far as they are the result of messages being sent or
		received. In effect, the programs that are executed by agents are not in scope of
		the architecture, however the resulting messages are in scope.</p></div></div><div class="div4">
<h5><a name="agent" id="agent"></a>2.3.2.2 Agent</h5><div class="div5">
<h6><a name="id2272244" id="id2272244"></a>2.3.2.2.1 Definition</h6><p>An <a title="" href="#agent">agent</a> is a program acting on behalf of
		<a title="" href="#poo">person or organization</a>.  (This definition is a specialization of the definition in  <a href="#webarch">[Web Arch]</a>.  It corresponds to the notion of <em>software agent</em> in <a href="#webarch">[Web Arch]</a>.)</p></div><div class="div5">
<h6><a name="id2272285" id="id2272285"></a>2.3.2.2.2 Relationships to other elements</h6><dl><dt class="label"> An agent <a title="" href="#isa">is</a>
                  </dt><dd><p>a computational <a title="" href="#resource">resource</a></p></dd><dt class="label"> An agent <a title="" href="#hasa">has</a> </dt><dd><p>an owner that is a <a title="" href="#poo">person or organization</a>
                    </p></dd><dt class="label"> An agent may <a title="" href="#realized">realize</a>
                  </dt><dd><p>zero or more <a title="" href="#service">services</a>
                    </p></dd><dt class="label">An agent may <a title="" href="#requester_agent">request</a>
                  </dt><dd><p>zero or more <a title="" href="#service">services</a>
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2272401" id="id2272401"></a>2.3.2.2.3 Explanation</h6><p>Agents are programs that engage in actions on behalf of someone or something else. For our purposes, agents realize
              and request Web services. In effect, software agents are the running programs that
              <em>drive</em> Web services &#8212; both to implement them and to access them.</p><p>Software agents are also <em>proxies</em> for the <a title="" href="#poo">entities</a> that own them. This is important as many services involve
              the use of resources which also have owners with a definite interest in their
              disposition. For example, <a title="" href="#service">services</a> may involve the
              transfer of money and the incurring of legal obligations as a result.</p><p>We specifically avoid any attempt to govern the implementation of agents; we are
              only concerned with ensuring interopability between systems.</p></div></div><div class="div4">
<h5><a name="choreography" id="choreography"></a>2.3.2.3 Choreography</h5><div class="div5">
<h6><a name="id2272463" id="id2272463"></a>2.3.2.3.1 Definition</h6><p>A choreography defines the sequence and conditions under which multiple cooperating
              independent agents exchange messages in order to perform a task to achieve a goal state.</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">This is a different level of abstraction from the definition used by the <a href="http://www.w3.org/2002/ws/chor/">W3C Web Services Choreography Working Group</a>.</td></tr></table></div><div class="div5">
<h6><a name="id2272495" id="id2272495"></a>2.3.2.3.2 Relationships to other elements</h6><dl><dt class="label">A choreography uses </dt><dd><p>one or more <a title="" href="#service_interface">service interfaces</a>
                  .
                    </p></dd><dt class="label">A choreography defines</dt><dd><p>the pattern of possible interactions between a set of
		      <a title="" href="#agent">agents</a> .
                    </p></dd><dt class="label">A choreography may be expressed in</dt><dd><p>a choreography description language
                    </p></dd><dt class="label">A choreography pertains to</dt><dd><p> a given <a title="" href="#service_task">task</a></p></dd><dt class="label">A choreography defines</dt><dd><p>the relationship between exchanged <a title="" href="#message">messages</a>
                    and <a title="" href="#service_task">tasks</a> of a <a title="" href="#service">service</a>.
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2272618" id="id2272618"></a>2.3.2.3.3 Explanation</h6><p>A choreography is a model of the sequence of operations, states, and conditions that
		control the interactions involved in the participating services. The interaction prescribed by a choreography results in the completion
		of some useful function.  Examples include the placement of an order, information about
		its delivery and eventual payment, or putting the system into a well-defined error
		state.</p><p>A choreography can be distinguished from an  orchestration. An orchestration defines
		the sequence and conditions in which <em>one</em> Web service invokes other Web services in
		order to realize some useful function. </p><p>A choreography may be described using a choreography description language.   A choreography description language permits the description of how Web services can be composed, how service roles
		and associations in Web services can be established, and how the state, if any, of
		composed services is to be managed.  </p></div></div><div class="div4">
<h5><a name="capability" id="capability"></a>2.3.2.4 Capability</h5><div class="div5">
<h6><a name="id2272664" id="id2272664"></a>2.3.2.4.1 Definition</h6><p>A capability is a named piece of functionality (or feature) that is declared as
	      supported or requested by an <a title="" href="#agent">agent</a>.  </p></div><div class="div5">
<h6><a name="id2272682" id="id2272682"></a>2.3.2.4.2 Relationships to other elements</h6><dl><dt class="label">a capability <a title="" href="#hasa">has a</a></dt><dd><p>
		      <a title="" href="#identifier">identifier</a> which is a URI
                    </p></dd><dt class="label">a capability <a title="" href="#hasa">has a
                  </a></dt><dd><p>
		      a description of its semantics</p></dd><dt class="label">a capability can be </dt><dd><p>advertised
		      by an <a title="" href="#agent">agent</a> that supports it </p></dd><dt class="label">a capability can be </dt><dd><p>required
		      by <a title="" href="#agent">agent</a> that wishes to use it</p></dd><dt class="label">a capability may be
		  referenced by
                  </dt><dd><p>
		      a <a title="" href="#service_description">service description</a>
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2272799" id="id2272799"></a>2.3.2.4.3 Explanation</h6><p>Agents participating in an exchange
	      may implement a wide variety of features.   For
	      example, there may be different ways to achieve the
	      reliable delivery of a message, or there may be several mechanisms available to support security.  A Web service may advertise that it supports a particular capability, and an agent requiring that capability might select the service on that basis.  Or a Web service may indicate that it requires a particular capability of any requester agent that uses it, and a requester agent may select it or avoid it on that basis.   There may also be a negotiation -- either manual or automatic -- about which capabilities to select. </p><p> The concept of
	      capability encompasses SOAP features, but is
	      broader.</p></div></div><div class="div4">
<h5><a name="goal_state" id="goal_state"></a>2.3.2.5 Goal State</h5><div class="div5">
<h6><a name="id2272836" id="id2272836"></a>2.3.2.5.1 Definition</h6><p>A goal state is a state of some service or resource that is desireable from some
              <a title="" href="#poo">person or organization's</a> point of view.
              </p></div><div class="div5">
<h6><a name="id2272855" id="id2272855"></a>2.3.2.5.2 Relationships to other elements</h6><dl><dt class="label">a goal state <a title="" href="#isa">is</a>
                  </dt><dd><p>a state of the real world, which includes the state of relevant resources</p></dd><dt class="label">a goal state <a title="" href="#isa">is</a>
                  </dt><dd><p>desired by some <a title="" href="#poo">person or organization</a> which has
		    an interest in defining it.
                    </p></dd><dt class="label">a goal state may be characterized
                  </dt><dd><p>informally, or formally with a formal expression.
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2272929" id="id2272929"></a>2.3.2.5.3 Explanation</h6><p>
                Goal states are associated with tasks. Tasks are the unit of action associated
                with <a title="" href="#service">services</a> that have a measurable meaning. Typically measured
                from the perspective of the owner of a service, a goal state is characterized by a
                predicate that is true of that state &#8212; for example, a book selling service may
                have as its goal state that a book has been purchased by a legitimate customer.
              </p><p>
                It is difficult to be formal about vague properties such as desireable, however, it
                is also clear that services are deployed and used with an intention. An e-commerce
                service is oriented towards buying and selling, a stock ticker service is oriented
                towards giving timely information. A goal state is simply a way of being able to
                declare success when a task has completed sucessfully.
              </p></div></div><div class="div4">
<h5><a name="provider_agent" id="provider_agent"></a>2.3.2.6 Provider Agent</h5><div class="div5">
<h6><a name="id2272981" id="id2272981"></a>2.3.2.6.1 Definition</h6><p>A provider agent is an agent that is capable of and empowered to perform the
	      actions associated with a service on behalf of its owner &#8212; the <a title="" href="#provider_entity">provider entity</a>.</p></div><div class="div5">
<h6><a name="id2273004" id="id2273004"></a>2.3.2.6.2 Relationships to other elements</h6><dl><dt class="label">a provider agent <a title="" href="#isa">is</a>
                  </dt><dd><p>a <a title="" href="#service">Web service</a> software
                      <a title="" href="#agent">agent</a>
                    </p></dd><dt class="label">a provider agent <a title="" href="#realized">realizes</a></dt><dd><p>one or more <a title="" href="#service">services</a>
                    </p></dd><dt class="label">a provider agent performs, or causes to perform</dt><dd><p>the <a title="" href="#action">actions</a> associated with a <a title="" href="#service_task">task</a></p></dd><dt class="label">a provider agent acts on behalf of</dt><dd><p>a <a title="" href="#provider_entity">provider entity</a></p></dd></dl></div><div class="div5">
<h6><a name="id2273115" id="id2273115"></a>2.3.2.6.3 Explanation</h6><p>The provider agent is the software agent that realizes a Web service by performing tasks on behalf of its owner &#8212; the <a title="" href="#provider_entity">provider entity</a>.</p><p>A given service may be offered by more than one agent, especially in the case of
		composite services, and a given provider agent may realize more than one
		Web service.</p></div></div><div class="div4">
<h5><a name="provider_entity" id="provider_entity"></a>2.3.2.7 Provider Entity</h5><div class="div5">
<h6><a name="id2273153" id="id2273153"></a>2.3.2.7.1 Definition</h6><p>The provider entity is the <a title="" href="#poo">person or organization</a> that is providing a Web service.</p></div><div class="div5">
<h6><a name="id2273171" id="id2273171"></a>2.3.2.7.2 Relationships to other elements</h6><dl><dt class="label"> a provider entity</dt><dd><p><a title="" href="#isa">is a</a> <a title="" href="#poo">person or organization</a></p></dd><dt class="label"> a provider entity</dt><dd><p>offers a  <a title="" href="#service">Web service</a></p></dd><dt class="label"> a provider entity <a title="" href="#owns">owns</a></dt><dd><p>a <a title="" href="#provider_agent">provider agent</a></p></dd></dl></div><div class="div5">
<h6><a name="id2273233" id="id2273233"></a>2.3.2.7.3 Explanation</h6><p>The provider entity is the <a title="" href="#poo">person or organization</a> that is offering a Web service.  The provider agent acts on behalf of the provider entity that owns it.</p></div></div><div class="div4">
<h5><a name="requester_agent" id="requester_agent"></a>2.3.2.8 Requester Agent</h5><div class="div5">
<h6><a name="id2273262" id="id2273262"></a>2.3.2.8.1 Definition</h6><p>A requester agent is a software <a title="" href="#agent">agent</a> that wishes to interact with a
                <a title="" href="#provider_agent">provider agent</a> in order to request that  a task be performed on behalf of its owner &#8212; the <a title="" href="#requester_entity">requester entity</a>.</p></div><div class="div5">
<h6><a name="id2273298" id="id2273298"></a>2.3.2.8.2 Relationships to other elements</h6><dl><dt class="label">a requester agent <a title="" href="#isa">is</a>
                  </dt><dd><p>an
                      <a title="" href="#agent">agent</a>
                    </p></dd><dt class="label">a requester agent uses</dt><dd><p>a <a title="" href="#service">service</a>
                    </p></dd><dt class="label">a requester agent acts on behalf of</dt><dd><p>a <a title="" href="#requester_entity">requester entity</a></p></dd></dl></div><div class="div5">
<h6><a name="id2273371" id="id2273371"></a>2.3.2.8.3 Explanation</h6><p>The requester agent is the software agent that requires a certain function to be
              performed on behalf of its owner &#8212; the requester entity.  From an architectural perspective, this is the <a title="" href="#agent">agent</a> that is looking for and invoking or initiating an
              interaction with a provider agent.</p></div></div><div class="div4">
<h5><a name="requester_entity" id="requester_entity"></a>2.3.2.9 Requester Entity</h5><div class="div5">
<h6><a name="id2273407" id="id2273407"></a>2.3.2.9.1 Definition</h6><p>The requester entity is the person or organization that wishes to  use a <a title="" href="#provider_entity">provider entity</a>'s Web service.</p></div><div class="div5">
<h6><a name="id2273425" id="id2273425"></a>2.3.2.9.2 Relationships to other elements</h6><dl><dt class="label"> a requester entity</dt><dd><p><a title="" href="#isa">is a</a> <a title="" href="#poo">person or organization</a></p></dd><dt class="label"> a requester entity <a title="" href="#owns">owns</a></dt><dd><p>a <a title="" href="#requester_agent">requester agent</a></p></dd></dl></div><div class="div5">
<h6><a name="id2273473" id="id2273473"></a>2.3.2.9.3 Explanation</h6><p>The requester entity is the <a title="" href="#poo">person or organization</a> that wishes to make use of a Web service.  The requester entity is the counterpart to the <a title="" href="#provider_entity">provider entity</a>.</p></div></div><div class="div4">
<h5><a name="service" id="service"></a>2.3.2.10 Service</h5><div class="div5">
<h6><a name="id2273508" id="id2273508"></a>2.3.2.10.1 Definition</h6><p>A service is an abstract resource that represents a capability of
              performing tasks that represents a coherent functionality from the point of view of
              <a title="" href="#provider_entity">provider entities</a> and <a title="" href="#requester_entity">requester entities</a>.  To be used, a  service must be realized by a concrete <a title="" href="#provider_agent">provider agent</a>. </p></div><div class="div5">
<h6><a name="id2273543" id="id2273543"></a>2.3.2.10.2 Relationships to other elements</h6><dl><dt class="label">a service <a title="" href="#isa">is a</a></dt><dd><p><a title="" href="#resource">resource</a>
                    </p></dd><dt class="label">a service performs</dt><dd><p>one or more <a title="" href="#service_task">tasks</a>
                    </p></dd><dt class="label">a service <a title="" href="#hasa">has</a>
                  </dt><dd><p>a <a title="" href="#service_description">service description</a>
                    </p></dd><dt class="label">a service <a title="" href="#hasa">has a</a>
                  </dt><dd><p><a title="" href="#service_interface">service interface</a>
                    </p></dd><dt class="label">a service <a title="" href="#hasa">has</a>
                  </dt><dd><p><a title="" href="#service_semantics">service semantics</a>
                    </p></dd><dt class="label">a service <a title="" href="#hasa">has</a>
                  </dt><dd><p>an <a title="" href="#identifier">identifier</a>
                    </p></dd><dt class="label">a service <a title="" href="#hasa">has</a>
                  </dt><dd><p>a <a title="" href="#service_semantics">service semantics</a>
                    </p></dd><dt class="label">a service <a title="" href="#hasa">has</a>
                  </dt><dd><p>one or more <a title="" href="#service_role">service roles</a> in relation
                    to the service's owner</p></dd><dt class="label">a service may <a title="" href="#hasa">have</a>
                  </dt><dd><p>one or more <a title="" href="#policy">policies</a> applied to it.</p></dd><dt class="label">a service is <a title="" href="#owns">owned by</a>
                  </dt><dd><p>a <a title="" href="#poo">person or organization</a>.</p></dd><dt class="label">a service is provided by
                  </dt><dd><p>a <a title="" href="#poo">person or organization</a>.</p></dd><dt class="label">a service is <a title="" href="#realized">realized by</a>
                  </dt><dd><p>a <a title="" href="#provider_agent">provider agent</a>.</p></dd><dt class="label">a service is used by </dt><dd><p>a <a title="" href="#requester_agent">requester agent</a>.</p></dd></dl></div><div class="div5">
<h6><a name="issue_ws_get" id="issue_ws_get"></a>2.3.2.10.3 Explanation</h6><p>A service is an abstract <a title="" href="#resource">resource</a> that represents a
              <a title="" href="#poo">person or organization</a> in some collection
              of related <a title="" href="#service_task">tasks</a> as having specific <a title="" href="#service_role">service roles</a>.  The service may be realized by one or more <a title="" href="#provider_agent">provider agents</a> that act on behalf of the person or organization &#8212; the provider entity.</p><p>The critical distinction of a Web service, compared to other Web resources, is that Web services do not necessarily have a <a title="" href="#representation">representation</a>; however, they
              <em>are</em> associated with <a title="" href="#action">actions</a>.</p><div class="issue"><p class="prefix"><a name="ws_get" id="ws_get"></a><b>Issue (ws_get):</b></p><p class="prefix"><b>What should be the representation returned by an HTTP "GET" on a Web service URI?</b></p><p>What should be the representation of a Web service?  Should a service description be available at the service URI?</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><p>For a Web service to be compliant with this architecture there must be sufficient
              <a title="" href="#service_description">service descriptions</a> associated with the service
              to enable its use by other parties. Ideally, a service description will give
              sufficient information so that an automatic agent may not only use the service but
              also decide if the service is appropriate; that in turn implies a description of the
              semantics of the service.</p><p>We distinguish a number of things in their relation to a service: a service has an owner; a service must be realized by a (software) provider agent; a requester agent may interact with a provider agent; and a provider agent has an owner (the <a title="" href="#provider_entity">provider entity</a>). Web services are
              inherently <em>about</em> computer-to-computer interactions between requester and provider agents; yet they are also
              ultimately deployed in human service because the requester and provider agents act on behalf of their owners.</p><p>Web services are focused on <a title="" href="#action">actions</a>. It is
              convenient, for the purposes of characterizing their semantics, to capture this in
              terms of <a title="" href="#service_task">tasks</a>. The semantics of any
              computational system is bound with the behavior of the system: and the intended
              semantics is bound with some desired behavior. Tasks combine the concept of action
              with intention: i.e., Web services are conventionally invoked with a given purpose in
              mind. The purpose can be expressed as an intended goal state: such as a book being
              delivered or a temperature reading being taken.</p><p>There is <em>no</em> requirement for there to be a one-to-one correspondence
              between <a title="" href="#message">messages</a> and services. A given message may be
              processed by more than one service, especially in the situation where there are
              service intermediaries, and a given service may, of course, process more than one kind
              of message. We formalize this by asserting that a service adopts one or more <a title="" href="#service_role">service roles</a>. The service role identifies the intended
              role as determined by the <a title="" href="#poo">owner</a> of the
              service. A given role is characterized by the aspects of messages it is concerned
              with.</p></div></div><div class="div4">
<h5><a name="service_description" id="service_description"></a>2.3.2.11 Service Description</h5><div class="div5">
<h6><a name="id2274089" id="id2274089"></a>2.3.2.11.1 Definition</h6><p>A service description is a set of documents that describe the interface to and
		semantics of a <a title="" href="#service">service</a>.</p></div><div class="div5">
<h6><a name="id2274107" id="id2274107"></a>2.3.2.11.2 Relationships to other elements</h6><dl><dt class="label">a service description <a title="" href="#isa">is</a>
                  </dt><dd><p>a machine-processable description of a <a title="" href="#service">service</a>
                    </p></dd><dt class="label">a service description <a title="" href="#isa">is</a></dt><dd><p>a machine-processable description of the <a title="" href="#service_interface">service's interface</a></p></dd><dt class="label">a service description contains</dt><dd><p>a machine-processable description of the <a title="" href="#message">messages</a> that are exchanged by the <a title="" href="#service">service</a>
                    </p></dd><dt class="label">a service description may include</dt><dd><p>a description of the <a title="" href="#service_semantics">service's semantics</a>
                    </p></dd><dt class="label">a service description is expressed
                  in</dt><dd><p>a service description language
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2274232" id="id2274232"></a>2.3.2.11.3 Explanation</h6><p>A service description contains the details of the interface and, potentially, the
              expected behavior of the service. This includes its data types, operations, transport protocol
              information, and <a title="" href="#address">address</a>. It could also include categorization and other
              metadata to facilitate discovery and utilization. The complete
              description may be realized as a set of XML description documents.</p><p>There are many potential uses of service descriptions: they may be used to
		facilitate the construction and deployment of services, they may be used by people
		to locate appropriate services, and they may be used by requester agents to
		automatically discover appropriate provider agents in those case where requester agents are able
		to make suitable choices.</p></div></div><div class="div4">
<h5><a name="service_interface" id="service_interface"></a>2.3.2.12 Service Interface</h5><div class="div5">
<h6><a name="id2274276" id="id2274276"></a>2.3.2.12.1 Definition</h6><p>A service interface is the abstract boundary that a service exposes. It defines the types of messages and the message exchange patterns that are involved in interacting with the service, together
	      with any conditions implied by those messages.</p></div><div class="div5">
<h6><a name="id2274291" id="id2274291"></a>2.3.2.12.2 Relationships to other elements</h6><dl><dt class="label">a service interface defines
                  </dt><dd><p>the <a title="" href="#message">messages</a> relevant to the service</p></dd></dl></div><div class="div5">
<h6><a name="id2274322" id="id2274322"></a>2.3.2.12.3 Explanation</h6><p>A service interface defines the different types of messages that a service sends and
	      receives, along with the message exchange patterns that may be used.</p></div></div><div class="div4">
<h5><a name="intermediary" id="intermediary"></a>2.3.2.13 Service Intermediary</h5><div class="div5">
<h6><a name="id2274346" id="id2274346"></a>2.3.2.13.1 Definition</h6><p>A service intermediary is a Web service whose main role is to transform
              messages in a value-added way. (From a messaging point
	      of view, an intermediary processes messages en route
	      from one agent to another.) Specifically, we say that a
	      service intermediary is a service whose outgoing
              messages are equivalent to its incoming messages in some application-defined sense.
              </p></div><div class="div5">
<h6><a name="id2274363" id="id2274363"></a>2.3.2.13.2 Relationships to other elements</h6><dl><dt class="label">A service intermediary <a title="" href="#isa">is</a>
                  </dt><dd><p>a <a title="" href="#service">service</a>.
                    </p></dd><dt class="label">A service intermediary adopts
                  </dt><dd><p>a specific <a title="" href="#service_role">service role</a>.
                    </p></dd><dt class="label">A service intermediary preserves
                  </dt><dd><p>the semantics of messages it receives and sends.
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2274436" id="id2274436"></a>2.3.2.13.3 Explanation</h6><p>
                A service intermediary is a specific kind of service which typically acts as a kind of
                filter on messages it handles. Normally, intermediaries do not consume messages but
                rather forward them to other services. Of course, intermediaries do often
                <em>modify</em> messages but, it is of the essence that <em>from some
                application specific perspective</em> they do not modify the meaning of the
                message.
              </p><p>
                Of course, if a message is altered in any way, then from some perspectives it is no
                longer the same message. However, just as a paper document is altered whenever
                anyone writes a comment on the document, and yet it is still the same document, so
                an intermediary modifies the messages that it receives, forwarding the same message
                with some changes.
              </p><p>
                Coupled with the concept of service intermediary is the <a title="" href="#service_role">service
                role</a> is adopts. Typically, this involves one or more of the messages'
                headers rather than the bodies of messages. The specification of the header is
                coupled with the permissable semantics of the intermediary should make it clear to
                what extent the messages forwarded by an itnermediary are the same message and what
                modifications are permitted.
              </p><p>
                There are a number of situations where additional processing of messages is
                required. For example, messages that are exchanged between agents within an
                enterprise may not need encryption; however, if a message has to leave the
                enterprise then good security may suggest that it be encrypted. Rather than burden
                every software agent with the means of encrypting and decrypting messages, this
                functionality can be realized by means of an intermediary. The main responsiblity of
                the software agents then becomes ensuring that the messages are routed appropriately
                and have the right headers targetted at the appropriate intermediaries.
              </p></div></div><div class="div4">
<h5><a name="service_role" id="service_role"></a>2.3.2.14 Service Role</h5><div class="div5">
<h6><a name="id2274518" id="id2274518"></a>2.3.2.14.1 Definition</h6><p>A service role is an abstract set of tasks which is identified to be relevant by a
              <a title="" href="#poo">person or organization</a> offering a service. Service roles
              are also associated with particular aspects of messages exchanged with a <a title="" href="#service">service</a>.</p></div><div class="div5">
<h6><a name="id2274545" id="id2274545"></a>2.3.2.14.2 Relationships to other elements</h6><dl><dt class="label">a service role <a title="" href="#isa">is</a>
                  </dt><dd><p>a set of <a title="" href="#service_task">service tasks</a>
                    </p></dd><dt class="label">a service role may be defined
                  </dt><dd><p>in terms of particular properties of <a title="" href="#message">messages</a>.
                    </p></dd><dt class="label">a service role may be established by
                  </dt><dd><p>a service <a title="" href="#poo">owner</a>.
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2274625" id="id2274625"></a>2.3.2.14.3 Explanation</h6><p>A service role is an intermediate abstraction between <a title="" href="#service">service</a> and <a title="" href="#service_task">task</a>. A given
              message that is received by a service may involve processing associated with several
              service roles. Similarly, messages emitted may also involve more than one service
              role.</p><p>We can formalize the distinction by noting that a service role is typically
              associated with a particular property of messages. For <em>ultimate</em>
              processing, the service role may be to determine some final disposition of messages
              received. However, other service roles may be associated with more generic properties
              of messages &#8212; such as their encryption, or whether they reference a customer or
              inventory item.</p><p>Service roles identify the points of interest that a service owner has in the
              processing of messages. As such, they are established by the <a title="" href="#poo">party that offers</a> in the service.</p></div></div><div class="div4">
<h5><a name="service_semantics" id="service_semantics"></a>2.3.2.15 Service Semantics</h5><div class="div5">
<h6><a name="id2274697" id="id2274697"></a>2.3.2.15.1 Definition</h6><p>The semantics of a service is the behavior expected when interacting with the
              service. The semantics expresses a contract (not necessarily a legal contract) between the
              <a title="" href="#provider_entity">provider entity</a> and the <a title="" href="#requester_entity">requester entity</a>.  It  expresses the intended real-world effect of
              invoking the service. A service semantics may be formally described in a machine
              readable form, identified but not formally defined, or informally defined via an "out
              of band" agreement between the provider entity and the requester entity.</p></div><div class="div5">
<h6><a name="id2274730" id="id2274730"></a>2.3.2.15.2 Relationships to other elements</h6><dl><dt class="label">a service semantics <a title="" href="#isa">is</a>
                  </dt><dd><p>the contract between the <a title="" href="#provider_entity">provider entity</a> and the <a title="" href="#requester_entity">requester entity</a> concerning the effects and requirements pertaining to the
                    use of a <a title="" href="#service">service</a>
                  </p></dd><dt class="label">a service semantics <a title="" href="#describes">describes</a>
                  </dt><dd><p>the intended effects of using a <a title="" href="#service">service</a>
                    </p></dd><dt class="label">a service semantics <a title="" href="#isa">is about</a>
                  </dt><dd><p>the <a title="" href="#service_task">service tasks</a> that constitute the
                    service.</p></dd><dt class="label">a service semantics should be identified</dt><dd><p>in a <a title="" href="#service_description">service description</a>
                    </p></dd><dt class="label">a service semantics may be described</dt><dd><p>in a  formal, machine-processable language
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2274872" id="id2274872"></a>2.3.2.15.3 Explanation</h6><p>Knowing the type of a data structure is not enough to understand the intent and
              meaning behind its use. For example, methods to deposit and withdraw from an account
              typically have the same type signature, but with a different effect. The effects of
              the operations are the semantics of the operation. It is good practice to be
              <em>explicit</em> about the intended effects of using a Web service; perhaps even
              to the point of constructing a machine readable description of the semantics of a
              service.</p><p>Machine processable semantic descriptions provide the potential for sophisticated
              usage of Web services.  For example, by accessing such descriptions, a requester agent may autonomously choose which provider agent to use.</p><p>Apart from the expected behavior of a service, other semantic aspects of a service
              include any policy restrictions on the service, the relationship between the provider entity and the requester entity, and what manageability features are associated with
              the service.</p></div></div><div class="div4">
<h5><a name="service_task" id="service_task"></a>2.3.2.16 Service Task</h5><div class="div5">
<h6><a name="id2274921" id="id2274921"></a>2.3.2.16.1 Definition</h6><p>A service task is an action or combination of actions that is associated with a desired
              goal state. Performing the task involves executing the actions, and is intended to
              achieve a particular goal state.</p></div><div class="div5">
<h6><a name="id2274935" id="id2274935"></a>2.3.2.16.2 Relationships to other elements</h6><dl><dt class="label">a service task <a title="" href="#isa">is</a>
                  </dt><dd><p>an <a title="" href="#action">action</a> or combination of actions.</p></dd><dt class="label">a service task <a title="" href="#hasa">is associated with</a>
                  </dt><dd><p>one or more intended <a title="" href="#goal_state">goal states</a>.</p></dd><dt class="label">a service task is <a title="" href="#action">performed</a> by
                  </dt><dd><p>executing the <a title="" href="#action">actions</a> associated with the task.</p></dd><dt class="label">a service task <a title="" href="#hasa">has a</a>
                  </dt><dd><p><a title="" href="#service_interface">service interface</a></p></dd></dl></div><div class="div5">
<h6><a name="id2275052" id="id2275052"></a>2.3.2.16.3 Explanation</h6><p>A service task is an abstraction that encapsulates some intended effect of invoking
              a service.</p><p>Tasks are associated with goal states &#8212; characterized by predicates that are
               satisfied on successful completion.</p><p>The performance of a task is made observable by the exchange of
              messages between the <a title="" href="#requester_agent">requester
              agent</a> and the <a title="" href="#provider_agent">provider
              agent</a>. The specific pattern of messages is what defines the choreography
              associated with the task.</p><p>In addition to exchanged messages, there may be other private actions associated
              with a task. For example, in a database update task, the task may be signaled by an
              initiating message and a completion message, which are public, and the actual database
              update, which is typically private.</p><p>In the case of a <a title="" href="#service_oriented_architecture">service oriented
		architecture</a> only the public aspects of a task are important, and these
		are expressed entirely in terms of the messages exchanged.</p><p>Tasks represent a useful unit in modeling the semantics of a <a title="" href="#service">service</a> and indeed of a <a title="" href="#service_role">service
              role</a> &#8212; a given service may consist of a number of tasks.</p></div></div></div><div class="div3">
<h4><a name="resource_oriented_model" id="resource_oriented_model"></a>2.3.3 The Resource Oriented Model</h4><p>The Resource Oriented Model focuses on those aspects of the architecture that relate to
	  <a title="" href="#resource">resources</a>. Resources are a fundamental concept that
	  underpins much of the Web and much of Web services; for example, a Web service is a
	  particular kind of resource that is important to this architecture.</p><p>The ROM focuses
          on the key features of resources that are relevant to the concept of resource, independent
          of the role the resource has in the context of Web services. Thus we focus on issues
          such as the ownership of resources, policies associated with resources and so on. Then, by
          virtue of the fact that Web services are resources, these properties are inherited by Web
          services.</p><p>We illustrate the basic concepts and relationships in the
	  ROM in <a href="#grom">Figure 2-9</a>:</p><div class="figure"><a name="grom" id="grom"></a><br /><img src="images/ROM.png" alt="Resource Oriented Model" /><p><i><span>Figure 2-9. </span>Resource Oriented Model</i></p><br /></div><div class="div4">
<h5><a name="discovery" id="discovery"></a>2.3.3.1 Discovery</h5><div class="div5">
<h6><a name="id2275212" id="id2275212"></a>2.3.3.1.1 Definition</h6><p>Discovery is the act of locating a machine-processable description of a Web service-related resource that may have been previously unknown and that meets certain functional criteria.  It involves matching a set of functional and other criteria with a set of resource  descriptions. The goal is to find an appropriate Web service-related resource.<a href="#WSAGLOSS">[WS Glossary]</a>
              </p></div><div class="div5">
<h6><a name="id2275234" id="id2275234"></a>2.3.3.1.2 Relationships to other elements</h6><dl><dt class="label">Discovery is</dt><dd><p>the act of locating a <a title="" href="#resource_description">resource description</a></p></dd><dt class="label">Discovery involves </dt><dd><p>matching a set of functional and other criteria with a set of
		  resource descriptions.</p></dd><dt class="label">Discovery may be <a title="" href="#action">performed</a> </dt><dd><p>by an <a title="" href="#agent">agent</a>, or by an end-user</p></dd><dt class="label">Discovery may be <a title="" href="#realized">realized</a> </dt><dd><p>using a <a title="" href="#discovery_service">discovery service</a></p></dd></dl></div><div class="div5">
<h6><a name="id2275328" id="id2275328"></a>2.3.3.1.3 Explanation</h6><p>In the context of Web services, the resources being discovered are usually service descriptions.  If a requester entity does not already know what service it wishes to engage, the
              requester entity must discover one.  There are various means by which discovery can be
              performed. Various things &#8212;   human end users or agents &#8212; may initiate
              discovery. Requester entities may find service descriptions during development for
              static binding, or during execution for dynamic binding. For statically bound requester agents, using discovery is optional, as the service description might be
              obtained in other ways, such as being sent directly from the provider entity to the
              requester entity, developed collaboratively, or provided by a third party, such as a standards body.</p></div></div><div class="div4">
<h5><a name="discovery_service" id="discovery_service"></a>2.3.3.2 Discovery Service</h5><div class="div5">
<h6><a name="id2275369" id="id2275369"></a>2.3.3.2.1 Definition</h6><p>A discovery service is a service that enables agents to retrieve Web service-related resource descriptions.</p></div><div class="div5">
<h6><a name="id2275381" id="id2275381"></a>2.3.3.2.2 Relationships to other elements</h6><dl><dt class="label">A discovery service <a title="" href="#isa">is</a>
                  </dt><dd><p>a <a title="" href="#service">service</a>
                    </p></dd><dt class="label">A discovery service is used to</dt><dd><p>publish <a title="" href="#resource_description">descriptions</a>
                    </p></dd><dt class="label">A discovery service is used to</dt><dd><p>search for <a title="" href="#resource_description">resource descriptions</a>
                    </p></dd><dt class="label">A discovery service may be used  </dt><dd><p>by an <a title="" href="#agent">agent</a></p></dd></dl></div><div class="div5">
<h6><a name="id2275479" id="id2275479"></a>2.3.3.2.3 Explanation</h6><p>A discovery service is used to publish and search for
              descriptions meeting certain functional or semantic criteria.  It is primarily
              intended for use by requester entities, to facilitate the process of finding an
              appropiate provider agent for a particular task.
	      However, depending on the implementation and
	      policy of the discovery service (<a href="#discovery_approaches"><b>3.4.2 Discovery: Registry, Index or Peer-to-Peer?</b></a>), it may also be used by provider entities to actively publish their service descriptions.</p><p>Although the resource model is general purpose, the most important resource for our
              purposes is the Web service. Furthermore, the primary role of a discovery service is
              to facilitate the discovery of Web services.</p><p>For dynamic discovery, the requester agent may interact directly
		with the discovery service to find an appropriate provider agent to engage.  For
		static discovery, a human may interact with the discovery service through an
		appropriate software agent, such as a browser.</p><p>The use of an automated discovery service is optional, since other means can be
                used to enable a requester entity and provider entity to <a title="" href="#agree">agree</a> on the service
                description that will govern the interaction.  For example, the requester entity
                might obtain the service description directly from the provider entity, the two
                parties might develop the service description collaboratively, or, in some
                circumstances, the service description may be created by the <em>requester</em> entity and
                dictated to the provider entity. (For example, a large company may require its
                suppliers to provide Web services that conform to a particular service description.)
                Likewise, a requester entity can obtain a service description from other sources
                besides a discovery service, such as a local file system, FTP site, URL, or WSIL
                document.</p></div></div><div class="div4">
<h5><a name="identifier" id="identifier"></a>2.3.3.3 Identifier</h5><div class="div5">
<h6><a name="id2275559" id="id2275559"></a>2.3.3.3.1 Definition</h6><p>An identifier is an unambiguous name for  a resource.</p></div><div class="div5">
<h6><a name="id2275570" id="id2275570"></a>2.3.3.3.2 Relationships to other elements</h6><dl><dt class="label">an identifier should be <a title="" href="#realized">realized</a>
                  </dt><dd><p>a URI</p></dd><dt class="label">an identifier identifies</dt><dd><p>a resource that is relevant to the architecture</p></dd></dl></div><div class="div5">
<h6><a name="issue_urivsqname" id="issue_urivsqname"></a>2.3.3.3.3 Explanation</h6><p>Identifiers are used to identify resources. In the architecture we use Uniform
		Resource Identifiers <a href="#RFC2396">[RFC 2396]</a> to identify resources.</p><div class="issue"><p class="prefix"><a name="urivsqname" id="urivsqname"></a><b>Issue (urivsqname):</b></p><p class="prefix"><b>Should URIs be used to identify Web services components, rather than QNames?</b></p><p>Some specifications use QNames to identify things.    However, QNames may be ambiguous, because the same QName may be used to identify things of different types.  (In effect, specifications having this practice have different symbol spaces to distinguish the different uses of a QName.)  Should URIs be preferred instead of QNames for Web services?  A significant majority of this Working Group believes the answer is yes.</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div></div></div><div class="div4">
<h5><a name="representation" id="representation"></a>2.3.3.4 Representation</h5><div class="div5">
<h6><a name="id2275670" id="id2275670"></a>2.3.3.4.1 Definition</h6><p>A <a href="http://www.w3.org/TR/2003/WD-webarch-20031209/#msg-representation">representation</a> is a
		piece of data that describes a resource state.

                 </p></div><div class="div5">
<h6><a name="id2275696" id="id2275696"></a>2.3.3.4.2 Relationships to other elements</h6><dl><dt class="label">a resource may <a title="" href="#hasa">have a</a></dt><dd><p>representation</p></dd></dl></div><div class="div5">
<h6><a name="id2275725" id="id2275725"></a>2.3.3.4.3 Explanation</h6><p>Representations are data objects that reflect the state of a resource. A resource
		has a unique identifier (a URI). Note that a representation of a resource need not be the same
		as the resource itself; for example the resource asociated with the booking state of
		a restaurant will have different representations depending on when the
		representation is retrieved.  A representation is usually retrieved by performing an HTTP "GET" on a URI.</p></div></div><div class="div4">
<h5><a name="resource" id="resource"></a>2.3.3.5 Resource</h5><div class="div5">
<h6><a name="id2275753" id="id2275753"></a>2.3.3.5.1 Definition</h6><p>A resource is defined by <a href="#RFC2396">[RFC 2396]</a> to be anything that can have an
              <a title="" href="#identifier">identifier</a>. Although resources in general can be anything, this architecture is only concerned with those resources that are relevant to Web services and therefore have some additional characteristics.  In particular, they incorporate the concepts of ownership and control: a resource that appears in this architecture is a
              <em>thing</em> that has a name, may have reasonable representations and which can
              be said to be owned. The ownership of a resource is critically connected with the
              right to set policy on the resource.</p></div><div class="div5">
<h6><a name="id2275789" id="id2275789"></a>2.3.3.5.2 Relationships to other elements</h6><dl><dt class="label">a resource <a title="" href="#hasa">has</a>
                  </dt><dd><p>an <a title="" href="#identifier">identifier</a>
                    </p></dd><dt class="label">a resource may <a title="" href="#hasa">have</a>
                  </dt><dd><p>zero or more <a href="http://www.w3.org/TR/2003/WD-webarch-20031209/#msg-representation">representations</a>
                    </p></dd><dt class="label">a resource may <a title="" href="#hasa">have</a>
                  </dt><dd><p>zero or more <a title="" href="#resource_description">resource
                    descriptions</a>
                    </p></dd><dt class="label">a resource is <a title="" href="#owns">owned by</a>
                  </dt><dd><p>a <a title="" href="#poo">person or organization</a>
                    </p></dd><dt class="label">a resource may be governed by
                  </dt><dd><p>zero or more <a title="" href="#policy">policies</a>
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2275936" id="id2275936"></a>2.3.3.5.3 Explanation</h6><p>Resources form the heart of the Web architecture itself.  The Web is a universe of
		resources that have URIs as <a href="http://www.w3.org/TR/2003/WD-webarch-20031209/#identification">identifiers</a>, as defined in <a href="#RFC2396">[RFC 2396]</a>.</p><p>From a real-world perspective, a most interesting aspect of a resource is its
              ownership: a resource is something that can be owned, and therefore have policies
              applied to it. Policies applying to resources are relevant to the management of Web
              services, security of access to Web services and many other aspects of the role that a
              resource has in the world.</p></div></div><div class="div4">
<h5><a name="resource_description" id="resource_description"></a>2.3.3.6 Resource description</h5><div class="div5">
<h6><a name="id2275990" id="id2275990"></a>2.3.3.6.1 Definition</h6><p>A resource description is any machine readable data that may permit resources
              to be discovered. Resource descriptions may be of many different forms, tailored for
              specific purposes, but all resource descriptions must contain the resource's
              identifier.</p></div><div class="div5">
<h6><a name="id2276004" id="id2276004"></a>2.3.3.6.2 Relationships to other elements</h6><dl><dt class="label">A resource description <a title="" href="#hasa">contains</a>
                  </dt><dd><p>the <a title="" href="#resource">resource</a>'s <a title="" href="#identifier">identifier</a>
                    </p></dd><dt class="label">A resource description may reference
                  </dt><dd><p>the <a title="" href="#policy">policies</a> applicable to the resource
                    </p></dd><dt class="label">A resource description may reference
                  </dt><dd><p>the <a title="" href="#service_semantics">semantics</a> applicable to the resource
                    </p></dd></dl></div><div class="div5">
<h6><a name="id2276092" id="id2276092"></a>2.3.3.6.3 Explanation</h6><p>A resource description is a machine-processable description of a resource. Resource
              descriptions are used by and within <a title="" href="#discovery_service">discovery
              services</a> to permit agents to discover the resource.</p><p>The precise contents of a resource description will vary, depending on the
              resource, on the purpose of the description and on the accessibility of the
              resource. However, for our purposes it is important to note that the description must
              contain the resource's identifier. I.e., a description of the form: "the new
              resource that is owned by XYZ co." is not regarded as a valid resource description because it does not mention the resource's identifier.</p><p>A primary purpose of resource descriptions is to facilitate the discovery of the
              resource. To aid that purpose, the description is likely to contain information about
              the location of the resource, how to access it and potentially any policies that
              govern the policy. Where the resource is a Web service, the description may also
              contain machine-processable information about how to invoke the Web service and the
              expected effect of using the Web service.</p><p>Note that a resource description is fundamentally distinct from the <a title="" href="#representation">resource representation</a>. The latter is a snapshot reflecting  the state of
              resource, the description is meta-level information about the resource.</p></div></div></div><div class="div3">
<h4><a name="policy_model" id="policy_model"></a>2.3.4 The Policy Model</h4><p>The Policy Model focuses on those aspects of the architecture that relate to <a title="" href="#policy">policies</a> and, by extension, security and quality of service.</p><p>Security is fundamentally about constraints; about constraints on the behavior on
	  action and on accessing resources. Similarly, quality of service is also about constraints
	  on service. In the PM, these constraints are modeled around the core concept of <a title="" href="#policy">policy</a>; and the relationships with other elements of the
	  architecture. Thus the PM is a framework in which security can be realized.</p><p>However, there are many other kinds of constraints, and policies that are relevant to
	  Web services, including various application-level constraints.</p><p>The concepts and relationships in the PM are illustrated in <a href="#gpm">Figure 2-10</a>:</p><div class="figure"><a name="gpm" id="gpm"></a><br /><img src="images/policy.png" alt="Policy Model" /><p><i><span>Figure 2-10. </span>Policy Model</i></p><br /></div><div class="div4">
<h5><a name="audit_guard" id="audit_guard"></a>2.3.4.1 Audit Guard</h5><div class="div5">
<h6><a name="id2276237" id="id2276237"></a>2.3.4.1.1 Definition</h6><p>An audit guard is a mechanism used on behalf of an owner that monitors
              actions and agents to verify the satisfaction of obligations.</p></div><div class="div5">
<h6><a name="id2276250" id="id2276250"></a>2.3.4.1.2 Relationships to other elements</h6><dl><dt class="label">a audit guard <a title="" href="#isa">is a</a> </dt><dd><p>a <a title="" href="#policy_guard">policy guard</a></p></dd><dt class="label">an audit guard may monitor</dt><dd><p>one or more <a title="" href="#resource">resources.</a></p></dd><dt class="label">an audit guard may monitor</dt><dd><p><a title="" href="#action">actions</a> relative to one or more <a title="" href="#service">services</a>.</p></dd><dt class="label">an audit guard may determine</dt><dd><p>if an <a title="" href="#agent">agent</a>'s obligations have been
                    discharged.</p></dd></dl></div><div class="div5">
<h6><a name="id2276353" id="id2276353"></a>2.3.4.1.3 Explanation</h6><p>An audit guard is an enforcement mechanism.  It is used to monitor the discharge of
              obligations. The role of the audit guard
              is to monitor that agents, resources and services are consistent with any associated
              obligations established by the service's owner or manager.</p><p>Typically, an audit guard monitors the state of a resource or a service,
	      ensuring that the obligation is satisfied.   It determines whether the associated obligations are
	      satisfied.</p><p>By their nature, it is not possible to proactively enforce obligations; hence, an
	      obligation violation may result in some kind of retribution after the fact of the
	      violation.</p></div></div><div class="div4">
<h5><a name="domain" id="domain"></a>2.3.4.2 Domain</h5><div class="div5">
<h6><a name="id2276392" id="id2276392"></a>2.3.4.2.1 Definition</h6><p>A domain is an identified set of agents and/or resources that is subject to the constraints of one of more <a title="" href="#policy">policies.</a>
            </p></div><div class="div5">
<h6><a name="id2276410" id="id2276410"></a>2.3.4.2.2 Relationships to other elements</h6><dl><dt class="label">A domain <a title="" href="#isa">is</a></dt><dd><p>a collection of <a title="" href="#agent">agents</a> and/or <a title="" href="#resource">resources.</a></p></dd><dt class="label">A domain defines</dt><dd><p>the scope of application of one or more <a title="" href="#policy">policies</a></p></dd></dl></div><div class="div5">
<h6><a name="id2276469" id="id2276469"></a>2.3.4.2.3 Explanation</h6><p>A domain defines the scope of applicability of <a title="" href="#policy">policies</a>. A domain may be defined explicitly or implicitly. Members of an explicitly defined domain are enumerated by a central authority; members of an implicitly defined domain are not.  For example, membership in an implicitly defined domain may depend on the state of the agent or something it possesses, and thus may be dynamic.</p></div></div><div class="div4">
<h5><a name="obligation" id="obligation"></a>2.3.4.3 Obligation</h5><div class="div5">
<h6><a name="id2276502" id="id2276502"></a>2.3.4.3.1 Definition</h6><p>An obligation is a kind of policy that prescribes actions and/or states of
              an agent and/or resource.</p></div><div class="div5">
<h6><a name="id2276514" id="id2276514"></a>2.3.4.3.2 Relationships to other elements</h6><dl><dt class="label">an obligation <a title="" href="#isa">is a</a> </dt><dd><p>kind of <a title="" href="#policy">policy</a></p></dd><dt class="label">an obligation may require</dt><dd><p>an <a title="" href="#agent">agent</a> to perform one or more <a title="" href="#action">actions</a></p></dd><dt class="label">an obligation may require</dt><dd><p>an agent or service to be in one or more allowable states</p></dd><dt class="label">an obligation may be discharged</dt><dd><p>by the performance of an <a title="" href="#action">action</a> or other
                    event.</p></dd></dl></div><div class="div5">
<h6><a name="id2276612" id="id2276612"></a>2.3.4.3.3 Explanation</h6><p>An obligation is one of two fundamental types of <a title="" href="#policy">policies</a>. When an agent has an obligation to perform some
              action, then it is required to do so. When the action is performed, then the agent can
              be said to have satisfied its obligations.</p><p>Not all obligations relate to actions.  For example, an agent providing a service
	      may have an obligation to maintain a certain state of readiness.  (Quality of service
	      policies are often expressed in terms of obligations.) Such an obligation is typically
	      not discharged by any of the obligee's actions; although an event (such as a certain
	      time period expiring) may discharge the obligation.</p><p>Obligations, by their nature, cannot be proactively enforced. However, obligations
	      are associated with enforcement mechanisms: <a title="" href="#audit_guard">audit
	      guards</a>. These monitor controlled resources and agents and may result in some
	      kind of <em>retribution</em>; retributions are not modeled by this
	      architecture.</p><p>An obligation may continue to exist after its requirements have been met (for example, an obligation to maintain a particular credit card balance), or it may be discharged by some action or event.</p></div></div><div class="div4">
<h5><a name="permission" id="permission"></a>2.3.4.4 Permission</h5><div class="div5">
<h6><a name="id2276678" id="id2276678"></a>2.3.4.4.1 Definition</h6><p>A permission is a kind of policy that prescribes the allowed actions and states of
              an agent and/or resource.</p></div><div class="div5">
<h6><a name="id2276690" id="id2276690"></a>2.3.4.4.2 Relationships to other elements</h6><dl><dt class="label">a permission <a title="" href="#isa">is a</a> </dt><dd><p>type of <a title="" href="#policy">policy</a></p></dd><dt class="label">a permission may enable</dt><dd><p>one or more <a title="" href="#action">actions</a></p></dd><dt class="label">a permission may enable</dt><dd><p>one or more allowable states</p></dd></dl></div><div class="div5">
<h6><a name="id2276759" id="id2276759"></a>2.3.4.4.3 Explanation</h6><p>A permission is one of two fundamental types of <a title="" href="#policy">policies</a>. When an agent has permission to perform some action,
              to access some resource, or to achieve a certain state, then it is expected that any
              attempt to perform the action etc., will be successful. Conversely, if an <a title="" href="#agent">agent</a> does <em>not</em> have the required permission, then
              the action should fail even if it would otherwise have succeeded.</p><p>Permissions are enforced by guards, in particular <a title="" href="#permission_guard">permission guards</a>, whose function is to ensure that
	      permission policies are honored.</p></div></div><div class="div4">
<h5><a name="permission_guard" id="permission_guard"></a>2.3.4.5 Permission Guard</h5><div class="div5">
<h6><a name="id2276817" id="id2276817"></a>2.3.4.5.1 Definition</h6><p>A permission guard is a mechanism deployed on behalf of an owner to enforce permission policies.</p></div><div class="div5">
<h6><a name="id2276829" id="id2276829"></a>2.3.4.5.2 Relationships to other elements</h6><dl><dt class="label">a permission guard <a title="" href="#isa">is a</a> </dt><dd><p>a <a title="" href="#policy_guard">policy guard</a></p></dd><dt class="label">a permission guard <a title="" href="#isa">is a</a></dt><dd><p>a mechanism that enforces <a title="" href="#permission">permission
                    policies</a></p></dd><dt class="label">a permission guard may control</dt><dd><p>one or more <a title="" href="#resource">resources.</a></p></dd><dt class="label">a permission guard enables</dt><dd><p><a title="" href="#action">actions</a> relative to one or more <a title="" href="#service">services.</a></p></dd></dl></div><div class="div5">
<h6><a name="id2276935" id="id2276935"></a>2.3.4.5.3 Explanation</h6><p>A permission guard is an enforcement mechanism that is used to enforce permission
              <a title="" href="#policy">policies</a>. The role of the permission guard is to
              ensure that any uses of a service or resource are consistent with the policies
              established by the service's owner or manager.</p><p>Typically, a permission guard sits between a resource or service and the requester
	      of that resource or service. In many situations, it is not necessary for a service to
	      be aware of the permission guard. For example, one possible role of a <a title="" href="#intermediary">message intermediary</a> is to act as a permission guard for
	      the final intended recipient of messages.</p><p>A permission guard acts by either enabling a requested action or access, or by
	      denying it. Thus, it is normally possible for <a title="" href="#permission">permission</a> policies to be proactively enforced.</p></div></div><div class="div4">
<h5><a name="poo" id="poo"></a>2.3.4.6 Person or Organization</h5><div class="div5">
<h6><a name="id2276996" id="id2276996"></a>2.3.4.6.1 Definition</h6><p>A person or organization may be the owner of agents that
		provide or request Web services.</p></div><div class="div5">
<h6><a name="id2277008" id="id2277008"></a>2.3.4.6.2 Relationships to other elements</h6><dl><dt class="label">a person or organization may <a title="" href="#owns">own</a>  </dt><dd><p> an <a title="" href="#agent">agent</a> </p></dd><dt class="label">a person or organization may belong to</dt><dd><p>a <a title="" href="#domain">domain</a></p></dd><dt class="label">a person or organization may establish</dt><dd><p> <a title="" href="#policy">policies</a> governing resources that they own</p></dd></dl></div><div class="div5">
<h6><a name="id2277086" id="id2277086"></a>2.3.4.6.3 Explanation</h6><p>The WSA concept of <a title="" href="#poo">person or organization</a> is intended to refer to the real-world people
		that are represented by agents that perform actions on their behalf.  All actions considered in this architecture
		are ultimately rooted in the actions of humans.</p></div></div><div class="div4">
<h5><a name="policy" id="policy"></a>2.3.4.7 Policy</h5><div class="div5">
<h6><a name="id2277116" id="id2277116"></a>2.3.4.7.1 Definition</h6><p>A policy is a constraint on the behavior of agents or people or organizations.</p></div><div class="div5">
<h6><a name="id2277128" id="id2277128"></a>2.3.4.7.2 Relationships to other elements</h6><dl><dt class="label">a policy <a title="" href="#isa">is a</a> </dt><dd><p>constraint on the allowable actions or states of an <a title="" href="#agent">agent</a> or <a title="" href="#poo">person or organization</a></p></dd><dt class="label">a policy may <a title="" href="#hasa">have</a> </dt><dd><p>an <a title="" href="#identifier">identifier</a></p></dd><dt class="label">a policy may <a title="" href="#describes">be described</a> </dt><dd><p>in a <a title="" href="#policy_description">policy description</a></p></dd><dt class="label">a policy may define</dt><dd><p>a <a title="" href="#capability">capability</a></p></dd></dl></div><div class="div5">
<h6><a name="id2277242" id="id2277242"></a>2.3.4.7.3 Explanation</h6><p>A policy is a constraint on the behavior of
              agents as they perform actions or access resources.</p><p>There are many kinds of policies, some relate to accessing resources in particular
	      ways, others relate more generally to the allowable actions an agent may perform: both
	      as provider agents and as requester agents.</p><p>Logically, we identify two types of policy: <a title="" href="#permission">permissions</a> and <a title="" href="#obligation">obligations</a>.</p><p>Although most policies relate to actions of various kinds, it is not exclusively
	      so. For example, there may be a policy that an agent must be in a certain state (or
	      conversely may not be in a particular state) in relation to the services it is
	      requesting or providing.</p><p>Closely associated with policies are the mechanisms for establishing policies and
	      for enforcing them. This architecture does not model the former.</p><p>Policies have applications for defining security properties, quality of service
	      properties, management properties and even application properties.</p></div></div><div class="div4">
<h5><a name="policy_description" id="policy_description"></a>2.3.4.8 Policy Description</h5><div class="div5">
<h6><a name="id2277308" id="id2277308"></a>2.3.4.8.1 Definition</h6><p>A policy description is a machine-processable description of a policy or set of
              policies.</p></div><div class="div5">
<h6><a name="id2277318" id="id2277318"></a>2.3.4.8.2 Relationships to other elements</h6><dl><dt class="label">a policy description <a title="" href="#describes">describes</a> </dt><dd><p>a <a title="" href="#policy">policy</a>
                  </p></dd></dl></div><div class="div5">
<h6><a name="id2277352" id="id2277352"></a>2.3.4.8.3 Explanation</h6><p>A policy description is a machine processable description of some constraint on the behavior of
              agents as they perform actions, access resources.</p><p>The policy description itself is not the policy, but it may define the policy and it may be used to determine if the policy <em>applies</em> in a given situation.</p><p>Policy descriptions may include specific conditions, such as "agents of XXX
              Co. may access files in directory FFF". They may also include more general rules,
              such as "if an entity has the right to access files in the directory FFF, it also
              has the obligation to close them after 20 seconds.".
              </p></div></div><div class="div4">
<h5><a name="policy_guard" id="policy_guard"></a>2.3.4.9 Policy Guard</h5><div class="div5">
<h6><a name="id2277393" id="id2277393"></a>2.3.4.9.1 Definition</h6><p>A policy guard is a mechanism that enforces one or more policies.  It is deployed on behalf of an owner.</p></div><div class="div5">
<h6><a name="id2277404" id="id2277404"></a>2.3.4.9.2 Relationships to other elements</h6><dl><dt class="label">a policy guard <a title="" href="#hasa">has </a> </dt><dd><p>an owner responsible for establishing the guard</p></dd></dl></div><div class="div5">
<h6><a name="id2277436" id="id2277436"></a>2.3.4.9.3 Explanation</h6><p>A policy guard is an abstraction that denotes a mechanism that is used by owners of
              resources to enforce policies.</p><p>The architecture identifies two kinds of policy guards:
		<a title="" href="#audit_guard">audit guards</a> and
		<a title="" href="#permission_guard">permission guards</a>. These relate to the
		core kinds of policies (obligation and permission policies respectively).</p></div></div></div></div><div class="div2">
<h3><a name="relationships" id="relationships"></a>2.4 Relationships</h3><p>This section defines terms that appear in our architectural models but are not specific to Web services or Web services architecture.  However, they are defined here to help clarify our use of these terms in this document. </p><div class="div3">
<h4><a name="isa" id="isa"></a>2.4.1 The <em>is a</em> relationship</h4><div class="div4">
<h5><a name="id2277502" id="id2277502"></a>2.4.1.1 Definition</h5><p>The <em>X</em> is a <em>Y</em> relationship denotes the relationship between
              concepts <em>X</em> and <em>Y</em>, such that every <em>X</em> is also a <em>Y</em>.</p></div><div class="div4">
<h5><a name="id2277533" id="id2277533"></a>2.4.1.2 Relationships to other elements</h5><p>Assuming that <em>X</em> is a <em>Y</em>, then:</p><dl><dt class="label">true of</dt><dd><p>if <em>P</em> is true of <em>Y</em> then <em>P</em> is true of <em>X</em>
                  </p></dd><dt class="label">contains</dt><dd><p>if <em>Y</em>
                    <a title="" href="#hasa">has a</a>
                    <em>P</em> then <em>X</em>
                    <a title="" href="#hasa">has a</a>
                    <em>Q</em> such that <em>Q</em>
                    <a title="" href="#isa">is a</a>
                    <em>P</em>.</p></dd><dt class="label">transitive</dt><dd><p>if <em>P</em> is true of <em>Y</em> then <em>P</em> is true of <em>X</em>
                  </p></dd></dl></div><div class="div4">
<h5><a name="id2277661" id="id2277661"></a>2.4.1.3 Explanation</h5><p>Essentially, when we say that concept <em>X</em> is a <em>Y</em> we mean that
              every feature of <em>Y</em> is also a feature of <em>X</em>. Note, however,
              that since <em>X</em> is presumably a more specific concept than <em>Y</em>,
              the features of <em>X</em> may also be more specific variants of the features of <em>Y</em>.</p><p>For example, in the <a title="" href="#service">service</a> concept, we state that
              every service has an identifier. In the more specific <a title="" href="#service">Web
              service</a> concept, we note that a Web service has an identifier in the form of
              a URI identifier.</p></div></div><div class="div3">
<h4><a name="describes" id="describes"></a>2.4.2 The <em>describes</em> relationship</h4><div class="div4">
<h5><a name="id2277737" id="id2277737"></a>2.4.2.1 Definition</h5><p>The concept <em>Y</em> describes <em>X</em> if and only if
              <em>Y</em> is an expression of some language <em>L</em> and that the values of
              <em>Y</em> are instances of <em>X</em>.</p></div><div class="div4">
<h5><a name="id2277769" id="id2277769"></a>2.4.2.2 Relationships to other elements</h5><p>Assuming that <em>Y</em> describes <em>X</em>, then: if <em>Y</em> is a valid expression of <em>L</em>, then the values of
                    <em>Y</em> are instances of concept <em>X</em>
                  </p></div><div class="div4">
<h5><a name="id2277802" id="id2277802"></a>2.4.2.3 Explanation</h5><p>Essentially, when we say that <em>Y</em> describes concept <em>X</em> we are saying that the expression <em>Y</em> denotes instances of <em>X</em>.</p><p>For example, in the <a title="" href="#service_description">service description</a>
              concept, we state that service descriptions are expressed in a service description
              language. That means that we can expect legal expressions of the service description
              language to be instances of the service description concept.</p></div></div><div class="div3">
<h4><a name="hasa" id="hasa"></a>2.4.3 The <em>has a</em> relationship</h4><div class="div4">
<h5><a name="id2277857" id="id2277857"></a>2.4.3.1 Definition</h5><p>Saying that "the concept <em>X</em> has a <em>Y</em> relationship" denotes that every
              instance of <em>X</em> is associated with an instance of <em>Y</em>.</p></div><div class="div4">
<h5><a name="id2277882" id="id2277882"></a>2.4.3.2 Relationships to other elements</h5><p>Assuming that <em>X</em> has a <em>Y</em>, then: if <em>E</em> is an instance of <em>X</em> then <em>Y</em> is valid
                    for <em>E</em>.</p></div><div class="div4">
<h5><a name="id2277914" id="id2277914"></a>2.4.3.3 Explanation</h5><p>When we say that "concept <em>X</em> has a <em>Y</em>" we mean that whenever we
              see an <em>X</em> we should also see a <em>Y</em>
            </p><p>For example, in the <a title="" href="#service">Web service</a> concept, we state
              that Web services have URI identifiers. So, whenever the Web service concept is
              found, we can assume that the Web service referenced has an identifier. This, in turn,
              allows implementations to use identifiers to reliably refer to Web services. If a
              given Web service does not have an identifier associated with it, then the
              architecture has been violated.</p></div></div><div class="div3">
<h4><a name="owns" id="owns"></a>2.4.4 The <em>owns</em> relationship</h4><div class="div4">
<h5><a name="id2277970" id="id2277970"></a>2.4.4.1 Definition</h5><p>The relationship "<em>X</em> owns <em>Y</em>"  denotes the relationship between
              concepts <em>X</em> and <em>Y</em>, such that every <em>X</em> has the right and authority to control, utilize and dispose of <em>Y</em>.
            </p></div><div class="div4">
<h5><a name="id2278004" id="id2278004"></a>2.4.4.2 Relationships to other elements</h5><p>Assuming that <em>X</em> owns <em>Y</em>, then:</p><dl><dt class="label">policy</dt><dd><p><em>X</em> has the right to establish policies that constrain <a title="" href="#agent">agents</a> and other entities in their use of <em>Y</em>
                  </p></dd><dt class="label">disposal</dt><dd><p><em>X</em> has the right to transfer some or all of his rights with respect
                  to <em>Y</em> to another entity.
                  </p></dd><dt class="label">transitive</dt><dd><p>if <em>P</em> is true of <em>Y</em> then <em>P</em> is true of <em>X</em>
                  </p></dd></dl></div><div class="div4">
<h5><a name="id2278099" id="id2278099"></a>2.4.4.3 Explanation</h5><p>
              Essentially, when we say that <em>X</em> owns <em>Y</em> we mean that
              <em>X</em> has a significant set of rights with respect to <em>Y</em>, and
              that those rights are transferrable.
            </p><p>
              In general, ownership is partial, and there may be many entities that have rights with
              respect to some service or resource. </p></div></div><div class="div3">
<h4><a name="realized" id="realized"></a>2.4.5 The <em>realized</em> relationship</h4><div class="div4">
<h5><a name="id2278146" id="id2278146"></a>2.4.5.1 Definition</h5><p>The statement "concept <em>X</em> is realized as <em>Y</em>"  denotes that
              the concept <em>X</em> is an abstraction of the concept <em>Y</em>. An
              equivalent view is that the concept <em>X</em> is implemented using <em>Y</em>.</p></div><div class="div4">
<h5><a name="id2278179" id="id2278179"></a>2.4.5.2 Relationships to other elements</h5><p>Assuming that <em>X</em> is realized as <em>Y</em>, then:</p><dl><dt class="label">implemented</dt><dd><p>if <em>Y</em> is present, or true of a system, then the concept
                    <em>X</em> applies to the system</p></dd><dt class="label">reified</dt><dd><p>
                    <em>Y</em> is a reification of the concept <em>X</em>.</p></dd></dl></div><div class="div4">
<h5><a name="id2278242" id="id2278242"></a>2.4.5.3 Explanation</h5><p>When we say that the concept or feature <em>X</em> is realized as <em>Y</em>,
              we mean that <em>Y</em> is an implementation or reification of the concept
              <em>X</em>. I.e., if <em>Y</em> is a valid concept of a system then we have
              also ensured that the concept <em>X</em> is valid of the same system.</p><p>For example, in the <a title="" href="#correlation">correlation</a> feature, we
              state that message correlation requires that we associate identifiers with messages.
              This can be realized in a number of ways &#8212; including the identifier in the message
              header, message body, in a service binding and so on. The message identifier is a key
              to the realization of message correlation.</p></div></div></div></div><div class="div1">
<h2><a name="stakeholder" id="stakeholder"></a>3 Stakeholder's Perspectives</h2><p></p><p>This section examines the architecture from various perspectives, each perspective representing one coherent view of the architecture.
        For
        example, security represents one major stakeholder's perspective of the architecture itself.</p><div class="div2">
<h3><a name="service_oriented_architecture" id="service_oriented_architecture"></a>3.1 Service Oriented Architecture</h3><div class="div3">
<h4><a name="soadefs" id="soadefs"></a>3.1.1 Distributed Systems</h4><p>A <em>distributed system</em> consists of diverse, discrete software agents that must work
together to perform some tasks. Furthermore, the agents in a distributed
system do not operate in the same processing environment, so they must
communicate by hardware/software protocol stacks over a network.  This means
that communications with a distributed system are intrinsically less fast
and reliable than those using direct code invocation and shared memory. This
has important architectural implications because distributed systems require
that developers (of infrastructure and applications) consider the
unpredictable latency of remote access, and take into account issues of
concurrency and the possibility of partial failure <a href="#ANODC">[Dist Comp]</a>.</p><p>Distributed <em>object</em> systems are distributed systems in which the semantics of
object initialization and method invocation are exposed to remote systems
by means of a proprietary or standardized mechanism to broker requests
across system boundaries, marshall and unmarshall method argument data, etc.
Distributed objects systems typically (albeit not necessarily) are
characterized by objects maintaining a fairly complex internal state
required to support their methods, a fine grained or "chatty" interaction
between an object and a program using it, and a focus on a shared
implementation type
system and interface hierarchy between the object and the program that uses
it.</p><p>A Service Oriented Architecture (SOA) is a form of distributed
systems architecture that is typically characterized by the following
properties:</p><ul><li><p>
Logical view: The service is an abstracted, <em>logical</em> view of actual
programs, databases, business processes, etc., defined in terms of what it
<em>does</em>, typically carrying out a business-level operation.
</p></li><li><p>
Message orientation: The service is formally defined in terms of the
messages exchanged between provider agents and requester agents, and not the
properties of the agents themselves. The internal structure of an agent,
including features such as its implementation language, process structure
and even database structure, are deliberately abstracted away in the SOA:
using the SOA discipline one does not and should not need to know how an
agent implementing a service is constructed. A key benefit of this concerns
so-called legacy systems. By avoiding  any knowledge of the internal
structure of an agent, one can incorporate any software component or
application that can be "wrapped" in message handling code that allows it to
adhere to the formal service definition.
</p></li><li><p>Description orientation: A service is described by machine-processable meta data.  The description supports the public nature of the SOA: only those details that are exposed to the public and important for the use of the service should be included in the description.  The semantics of a service should be documented, either directly or indirectly, by its description.</p></li><li><p>Granularity: Services tend to use a small number of operations with relatively large and complex messages.</p></li><li><p>Network orientation: Services tend to be oriented toward use over a network, though this is not an absolute requirement.</p></li><li><p>Platform neutral: Messages are sent in a platform-neutral, standardized format delivered
 through the interfaces.  XML is the most obvious format that meets this
 constraint.</p></li></ul></div><div class="div3">
<h4><a name="wsdossoa" id="wsdossoa"></a>3.1.2 Web Services and Architectural Styles</h4><p>Distributed object systems have a number of architectural
challenges. <a href="#ANODC">[Dist Comp]</a> and others point out:</p><ul><li><p>
Problems introduced by latency and unreliability of the underlying
transport.
</p></li><li><p>
The lack of shared memory between the caller and object.
</p></li><li><p>
The numerous problems introduced by partial failure scenarios.
</p></li><li><p>
The challenges of concurrent access to remote resources.
</p></li><li><p>
The fragility of distributed systems if incompatible updates are
introduced to any participant.
</p></li></ul><p>These challenges apply irrespective of whether the distributed
object system is implemented
using COM/CORBA or Web services technologies.  Web services are no less
appropriate than the alternatives if the fundamental criteria for successful
distributed object architectures are met.  If these criteria are met, Web
services technologies may be appropriate if the benefits they offer in terms
of platform/vendor neutrality offset the performance and implementation
immaturity issues they may introduce.</p><p>Conversely, using Web services technologies to implement a distributed
system doesn't magically turn a distributed object architecture into an SOA.
Nor are Web services technologies <em>necessarily</em> the best choice for
implementing SOAs -- if the necessary infrastructure and expertise are in
place to use COM or CORBA as the implementation technology and there is no
requirement for platform neutrality, using SOAP/WSDL may not add enough
benefits to justify their costs in performance, etc.</p><p>In general SOA and Web services are most appropriate for
applications:</p><ul><li><p>That must operate over the Internet where reliability and
speed cannot be guaranteed;</p></li><li><p>Where there is no ability to manage
deployment so that all requesters and providers are upgraded at once;</p></li><li><p>Where components of the distributed system run on different platforms and vendor
products;</p></li><li><p>Where an existing application needs to be exposed for use over a network, and can be wrapped as a Web service.</p></li></ul></div><div class="div3">
<h4><a name="relwwwrest" id="relwwwrest"></a>3.1.3 Relationship to the World Wide Web and REST Architectures</h4><p>The World Wide Web operates as a networked information system that
            imposes several constraints: Agents identify objects in the system, called
            <em>resources</em>, with Uniform Resource Identifiers (URIs). Agents represent,
            describe, and communicate resource state via <em>representations</em> of the resource
            in a variety of widely-understood data formats (e.g. XML, HTML, CSS, JPEG, PNG). Agents
            exchange representations via protocols that use URIs to identify and directly or
            indirectly address the agents and resources. <a href="#webarch">[Web Arch]</a>
          </p><p>An even more constrained architectural style for reliable Web applications known as
            <em>Representation State Transfer</em> (REST) has been proposed by Roy Fielding and
            has inspired both the W3C Technical Architecture Group's
	    architecture document <a href="#webarch">[Web Arch]</a> and many who see it as a model for how
            to build Web services <a href="#fielding">[Fielding]</a>. The REST Web is the subset of the WWW (based on HTTP) in
            which agents provide
            <em>uniform interface semantics</em> -- essentially create, retrieve, update and delete -- rather than arbitrary or application-specific interfaces, and manipulate resources only by the exchange of
            <em>representations</em>.  Furthermore, the REST interactions are "stateless" in the sense that the meaning of a message does not depend on the state of the conversation.</p><p>We can identify two major classes of Web services:</p><ul><li><p>
<em>REST-compliant Web services,</em>  in which the primary purpose
            of the service is to manipulate XML representations of Web resources using a
            uniform set of "stateless" operations; and</p></li><li><p><em>arbitrary Web services,</em> in which the service may expose an arbitrary set of operations.
		</p></li></ul><p>Both classes of Web services use URIs to identify resources and use Web
            protocols (such as HTTP and SOAP 1.2) and XML data formats for messaging.  (It should be noted that SOAP 1.2 <em>can</em> be used in a manner consistent with REST.  However, SOAP 1.2 can also be used in a manner that is <em>not</em> consistent with REST.)</p></div></div><div class="div2">
<h3><a name="technology" id="technology"></a>3.2 Web Services Technologies</h3><p>Web service architecture involves many layered and interrelated technologies. There are
          many ways to visualize these technologies, just as there are many ways to build and use
          Web services. <a href="#gwsasd">Figure 3-1</a> below provides one illustration of some of these technology
          families.</p><div class="figure"><a name="gwsasd" id="gwsasd"></a><br /><img src="images/WSA_STACK.png" alt="Web Services Architecture Stack" /><p><i><span>Figure 3-1. </span>Web Services Architecture Stack</i></p><br /></div><p>In this section we describe some of those technologies that seem critical and the role
          they fill in relation to this architecture. This is a necessarily bottom-up perspective,
          since, in this section, we are looking at Web services from the perspective of tools which
          can be used to design, build and deploy Web serivces.</p><p>The technologies that we consider here, in relation to the Architecture, are XML, SOAP,
	  WSDL.  However, there are many other technologies that may be useful.  (For example, see the <a href="http://lists.w3.org/Archives/Public/www-ws-arch/2004Feb/0022.html">list of Web services specifications compiled by Roger Cutler and Paul Denning</a>.)  See also <a href="#wsstechno"><b>B An Overview of Web Services Security Technologies</b></a></p><div class="div3">
<h4><a name="XML-infoset" id="XML-infoset"></a>3.2.1 XML</h4><p>XML solves a key technology requirement
	    that appears in many places.  By offering a standard, flexible and inherently extensible
	    data format, XML significantly reduces the burden of deploying the many technologies
	    needed to ensure the success of Web services.</p><p>The important aspects of XML, for the purposes of this Architecture, are the core
            syntax itself, the concepts of the XML Infoset <a href="#infoset">[XML Infoset]</a>, XML Schema and
            XML Namespaces.</p><p>XML Infoset is not a data format per se, but a
            formal set of information items and their associated properties that comprise an
            abstract description of an XML document <a href="#xml10">[XML 1.0]</a>. The XML Infoset
            specification provides for a consistent and rigorous set of definitions for use in other
            specifications that need to refer to the information in a well-formed XML document.</p><p>Serialization of the XML Infoset definitions of information may be expressed using XML
            1.0 <a href="#xml10">[XML 1.0]</a>. However, this is not an inherent requirement of the
            architecture. The flexibility in choice of serialization format(s) allows for broader
            interoperability between agents in the system. In the future, a binary encoding of the XML infoset
            may be a suitable replacement for the textual serialization.  Such a binary
            encoding may be more efficient and more suitable for machine-to-machine
            interactions. </p></div><div class="div3">
<h4><a name="SOAP" id="SOAP"></a>3.2.2 SOAP</h4><p>SOAP 1.2  provides a standard, extensible,
            composable framework for packaging and exchanging XML messages. In the context of this architecture, SOAP 1.2 also provides a convenient mechanism for referencing <a title="" href="#capability">capabilities</a> (typically by use of headers).</p><p><a href="#soappart1">[SOAP 1.2 Part 1]</a> defines an XML-based messaging framework: a processing model and an exensibility model. SOAP messages can be carried by a variety of network protocols; such as HTTP, SMTP, FTP, RMI/IIOP, or a
            proprietary messaging protocol.</p><p><a href="#soappart2">[SOAP 1.2 Part 2]</a> defines three optional components: a set of encoding rules for expressing instances of
            application-defined data types, a convention for representing remote procedure calls
            (RPC) and responses, and a set of rules for using SOAP with HTTP/1.1.</p><p>While SOAP
Version 1.2 <a href="#soappart1">[SOAP 1.2 Part 1]</a> doesn't define "SOAP" as an acronym anymore, there are two expansions of the term that reflect these
different ways in which the technology can be interpreted:</p><ol type="1"><li><p>
Service Oriented Architecture Protocol: In the general case, a SOAP message represents the
information needed to invoke a service or reflect the results of a service
invocation, and contains the information specified in the service interface
definition.
</p></li><li><p>
Simple Object Access Protocol: When using the optional SOAP RPC Representation,
a SOAP message represents a method
invocation on a remote object, and the serialization of in the argument list
of that method that must be moved from the local environment to the remote
environment.
</p></li></ol></div><div class="div3">
<h4><a name="WSDL" id="WSDL"></a>3.2.3 WSDL</h4><p>WSDL 2.0<a href="#wsdl12">[WSDL 2.0 Part 1]</a> is a language for
                      describing <a title="" href="#service_description">Web services</a>.</p><p>WSDL describes Web services starting with the messages that are exchanged between the
            requester and provider agents. The messages themselves are described abstractly and
            then bound to a concrete network protocol and message format.</p><p>Web service definitions can be mapped to any implementation language, platform, object model, or messaging
            system. Simple extensions to existing Internet infrastructure can implement Web services
            for interaction via browsers or directly within an application. The application could be
            implemented using COM, JMS, CORBA, COBOL, or any number of proprietary integration
            solutions. As long as both the sender and receiver <a title="" href="#agree">agree</a> on the service description, (e.g. WSDL
            file), the implementations behind the Web services can be anything. </p></div></div><div class="div2">
<h3><a name="stakeholder_using" id="stakeholder_using"></a>3.3 Using Web Services</h3><p>The introduction outlined and illustrated (in <a href="#gengag">Figure 1-1</a>) the four broad steps involved in the process
	of engaging a Web service (see <a href="#engaging"><b>1.4.5 Overview of Engaging a Web Service</b></a>).  This section expands on these steps.  Although these steps are <em>necessary</em>, they may not be <em>sufficient</em>: many scenarios will require additional steps, or significant refinements of these fundamental steps.  Furthermore, the order in which the steps are performed may vary from situation to situation.</p><ol type="1"><li><p>  The requester and provider entities "become known to each other", in the sense that whichever party  initiates the interaction must become aware of the other party.  There are two cases.</p><ol type="a"><li><p>In a typical case, the <em>requester</em> agent will be the initiator.  In this case, we would say that the requester entity must become aware of the provider entity, i.e., the requester agent must somehow obtain the address of the provider agent.  There are two ways this may typically occur: (1) the requester entity may obtain the provider agent's address directly from the provider entity; or  (2) the requester entity may use a discovery service to locate a suitable service description (which contains the provider agent's invocation address) via an associated functional description, either through manual discovery or autonomous selection.   These cases are described more fully in <a href="#wsdisc"><b>3.4 Web Service Discovery</b></a>.</p></li><li><p>In other cases, the <em>provider</em> agent may initiate the exchange of messages between the requester and provider agents.  In this case, saying that the requester and provider entities become known to each other actually means that the <em>provider</em> entity becomes aware of the <em>requester</em> entity, i.e., the provider agent somehow obtains the address of the requester agent.  How this occurs is application dependent and irrelevant to this architecture.  Although this case is expected to be less common than when the requester agent is the initiator, it is important in some "push" or subscription scenarios.</p></li></ol></li><li><p> The requester entity and provider entity <a title="" href="#agree">agree</a> on the service description (a WSDL document) and semantics that will govern the interaction between the requester agent and the provider agent.  (See the note below on <a title="" href="#agree">"Agreeing on the Same Semantics and Service Description</a> for further explanation of what is meant here by "agree".)</p><p>This does not necessarily mean that the requester and provider entities must communicate or negotiate with each other.  It simply means that both parties must have the same (or compatible) understandings of the service description and semantics, and intend to uphold them.  There are many ways this can be achieved, such as:</p><ul><li><p>The requester and provider entities may communicate directly with each other, to explicitly agree on the service description and semantics.</p></li><li><p>The provider entity may publish and offer both the service description and semantics as take-it-or-leave-it
                "contracts" that the requester entity must accept unmodified as conditions
                of use.</p></li><li><p>The service description and semantics (excepting
                the network address of the particular service) may be defined as a standard by an industry organization, and
                used by many requester and provider entities. In this case, the act of the requester and provider entities reaching agreement is accomplished by both parties independently conforming to the same standard.</p></li><li><p>The service description and semantics (perhaps excepting the network address of the service) may
                be defined and published by the <em>requester</em> entity (even if they are written from provider entity's
                perspective), and offered to provider entities on a take-it-or-leave-it basis.    This may occur, for example, if a large company requires its suppliers to provide Web services that conform to a particular service description and semantics.  In this case, agreement is achieved by the provider entity adopting the service description and semantics that the requester entity has published.</p></li></ul><p>Depending on the scenario, Step 2 (or portions of Step 2) may be performed prior to Step 1.</p></li><li><p>  The service description and semantics are input to, or embodied in, both the requester agent and the provider agent as appropriate.  In other words, the information in them must either be input to, or implemented in, the requester and provider agents.  There are many ways this can be achieved, and this architecture does not specify or care what means are used. For
                example:</p><ul><li><p>An agent could be hard coded to implement a particular, fixed service
                    description and semantics.</p></li><li><p>An agent could be coded in a more general way, and the desired service
                    description and/or semantics could be input dynamically.</p></li><li><p>An agent could be created first, and the service description and/or semantics
                    could be generated or deduced from the agent code.  For example, a tool could examine a set of existing class files to generate a service description.</p></li></ul><p>Regardless of the approach used, from an information perspective both the semantics
                and the service description must somehow be input to, or implemented in, both the
                requester agent and the provider agent before the two agents can interact.  (This is a slight simplification; see the note below on <a title="" href="#agree">"Agreeing" on the Same Semantics and Service Description</a> for further explanation.)</p></li><li><p> The requester agent and provider agent exchange SOAP messages on behalf of their owners.</p></li></ol><div class="note"><p class="prefix"><b>Note:</b></p><p id="agree"><em>"Agreeing" on the Same Semantics and Service Description.</em>     Although it is convenient to say that the requester and provider entities must "agree" on the semantics and the service description, it is a slight simplification (and perhaps slightly misleading) to say that the parties <em>must</em> agree on the <em>same</em> semantics and service description:</p><ul><li><p>The word "agree" often connotes an active communication between the parties and an explicit act (such as signing a contract) to cause the agreement to become binding on the two parties, yet neither of these is required in the case of step 2 above.   </p></li><li><p>It is a slight simplification to say that the requester and provider agents must implement the <em>same</em> semantics and WSD, for two reasons: (1) the requester agent implements them from the perspective of the requester entity, while the provider agent implements them from the perspective of the provider entity (for example, one party's input is the other party's output); and (2) the requester and provider agents only need to implement those aspects of the service description and semantics that are <em>relevant</em> to their respective roles.  </p></li></ul><p>In summary, it is convenient (and evocative) to say that the requester and provider entities must <em>agree</em> on the semantics and the service description that will govern the interaction between the requester and provider agents, but it would be more accurate to say that they simply need to have a <em>congruent</em> or <em>non-conflicting view</em> of the semantics and service description of the interaction.</p></div></div><div class="div2">
<h3><a name="wsdisc" id="wsdisc"></a>3.4 Web Service Discovery</h3><p>If the requester entity wishes to initiate an interaction with a provider entity and it does not already know what provider agent it
            wishes to engage, then the requester entity may need to "discover" a suitable candidate.
            Discovery is "the act of locating a machine-processable description of a Web service that may have been previously unknown and that meets certain functional criteria. " <a href="#WSAGLOSS">[WS Glossary]</a>   The goal is to find an appropriate Web service.</p><p>A <a title="" href="#discovery_service">discovery service</a> is a service that facilitates the process of performing discovery.  It is a logical role, and could be performed by either the requester agent, the provider agent or some other agent.  </p><p><a href="#gdp">Figure 3-2</a> ("Discovery Process") expands on <a href="#gengag">Figure 1-1</a> to describe the process of engaging a Web service when a discovery service is used.</p><div class="figure"><a name="gdp" id="gdp"></a><br /><img src="images/discovery_process.gif" alt="Discovery Process" /><p><i><span>Figure 3-2. </span>Discovery Process</i></p><br /></div><p>Service engagement using a discovery service proceeds in roughly the following steps.</p><ol type="1"><li><p>The requester and provider entities "become known to each other":</p><ol type="a"><li><p>The discovery service somehow obtains both the Web service description ("WSD" in <a href="#gdp">Figure 3-2</a>) and an associated functional description ("FD") of the service.</p><p>The functional description ("FD" in <a href="#gdp">Figure 3-2</a>) is a machine-processable description of the functionality (or partial semantics) of the service that the provider entity is offering.  It could be as
                  simple as a few words of meta data or  a URI, or it may be more complex, such as a TModel (in
                  UDDI) or a collection of RDF, DAML-S or OWL-S statements.</p><p>This architecture does not specify or care how the discovery service obtains the service
                  description or functional description. For example, if the discovery service is implemented as
                  a search engine, then it might crawl the Web, collecting service
                  descriptions wherever it finds them, with the provider entity having no knowledge
                  of it. Or, if the discovery service is implemented as a registry (such as UDDI),
                  then the provider entity may need to actively publish the service description and functional description
                  directly to the discovery service.</p></li><li><p>The requester entity supplies criteria to the discovery service to select a Web service description based on its associated functional description, <a title="" href="#capability">capabilities</a> and potentially other characteristics.  One might locate a service having certain desired functionality or semantics; however, it may be possible to specify "non-functional" criteria related to the provider agent, such as the name of the provider entity, performance or reliability criteria, or criteria related to the provider entity, such as the provider entity's vendor rating.</p></li><li><p>The discovery service returns one or more Web service descriptions (or references to them) that meet the specified criteria.   If multiple service descriptions are returned, the requester entity selects one, perhaps using additional  criteria.</p></li></ol></li><li><p>The requester and provider entities <a title="" href="#agree">agree</a> on the semantics ("Sem" in <a href="#gdp">Figure 3-2</a>) of the desired interaction. Although this may commonly be achieved by the provider entity defining the semantics and offering them on a take-it-or-leave-it basis to the requester entity, it could be achieved in other ways.  For example, both parties may adopt certain standard service semantics that are defined by some industry standards body.  Or in some circumstances the requester could define the semantics.  The important point is that the parties must <em>agree</em> (in the sense described in <a href="#stakeholder_using"><b>3.3 Using Web Services</b></a>) on the semantics, regardless of how that is achieved.  </p><p>Step 2 also requires that the parties <a title="" href="#agree">agree</a> (in the sense described in <a href="#stakeholder_using"><b>3.3 Using Web Services</b></a>) on the service description that is to be used.  However, since the requester entity obtained the Web service description in Step 1.c, in effect the requester and provider entities have already done so.</p></li><li><p>The service description and semantics are input to, or embodied in, both the requester agent and the provider agent, as appropriate.  </p></li><li><p>The requester agent and provider agent exchange SOAP messages on behalf of their owners.</p></li></ol><div class="div3">
<h4><a name="id2279776" id="id2279776"></a>3.4.1 Manual Versus Autonomous Discovery</h4><p>The discovery process described above is not specific about who or what within the requester entity actually performs the discovery.  Under <em>manual discovery</em>, a requester <em>human</em> uses a discovery service (typically at design time) to
              locate and select a service description
              that meets the desired functional and other criteria.  Under <em>autonomous discovery</em>, the requester  <em>agent</em> performs this task, either at design time or run time.  Although the steps are similar in either case, the constraints and needs are significantly different, such as:</p><ul><li><p><em>Interface requirements.</em>  The requirements for something that is intended for human interaction are very different from the requirements for something that is intended for machine interaction.</p></li><li><p><em>Need for standardization.</em>  There is far less need to standardize an interface or protocol that humans use than those that machines are intended to use.

</p></li><li><p><em>Trust.</em>   People do not necessarily
trust machines to make decisions that may have significant
consequences.  This is explained more fully in <a href="#trust"><b>3.6.4.5 Trust and Discovery</b></a>.</p></li></ul><p>In the case of autonomous discovery, the need for machine-processable semantics is greatly increased.  </p><p>One situation in which autonomous discovery is often needed is when the requester agent has been interacting with a particular provider agent, but for some reason needs to refresh its choice of provider agent, either because the previous provider agent is no longer available, or other reasons.</p></div><div class="div3">
<h4><a name="discovery_approaches" id="discovery_approaches"></a>3.4.2 Discovery: Registry, Index or Peer-to-Peer?</h4><p>At present, there are three leading viewpoints on how a discovery service should be conceived: as a <em>registry</em>, as an <em>index</em>, or as a <em>peer-to-peer</em> system.   What are the differences?  For what purpose is one better than the other?</p><div class="div4">
<h5><a name="id2279875" id="id2279875"></a>3.4.2.1 The Registry Approach</h5><p>A <em>registry</em> is an authoritative, centrally controlled store of information.</p><ul><li><p>Publishing a service description requires an active step by the provider entity: it must explicitly place the information into the registry before that information is available to others.  In the case of a registry:</p></li><li><p>The registry owner decides <em>who</em> has authority to place information into, or update, the registry.  Although the owner of registry R may delegate permission to approved provider entities that wish to publish their own service descriptions, an arbitrary third party could not publish a description of someone else's service in registry R.  This means, for example, that company X would not be able to register a functional description of company Y's service, even if that description would be valuable to others and may be superior in some ways to Y's own description.</p></li><li><p>The registry owner decides <em>what</em> information is placed in the registry.   Others cannot independently augment that information.</p></li></ul><p>UDDI is often seen as an example of the registry approach, but it can also be used as an index.</p></div><div class="div4">
<h5><a name="id2279923" id="id2279923"></a>3.4.2.2 The Index Approach</h5><p>In contrast with a registry, an <em>index</em> is a compilation or guide to information that exists elsewhere.  It is not authorative and does not centrally control the information that it references.   In the case of an index:</p><ul><li><p>Publishing is passive: the provider entity exposes the service and functional descriptions on the Web, and those who are interested (the index owners) collect them without the provider entity's specific knowledge.</p></li><li><p>Anyone can create their own index.  When descriptions
are exposed, they can be harvested using spiders and arranged into an index.  Multiple
organizations may have such indexes.</p></li><li><p>The information contained in an index could be out of date.  However, since the index contains pointers to the authoritative information, the information can be verified before use.</p></li><li><p>

An index could include third-party information.</p></li><li><p>Different indexes could provide different kinds of information &#8212; some richer, some sparser.</p></li><li><p>Free-market forces determine
which index people will use to discover the information that they seek.

</p></li></ul><p>Google is often cited as an example of the index approach.</p><p>It is important to note that the key difference between the registry approach and the index approach is not merely the difference between a registry itself and an index <em>in isolation</em>.   Indeed, UDDI could be used as a means to implement an individual index: just spider the Web, and put the results into a UDDI registry.  Rather, the key difference is one of <em>control</em>: Who controls <em>what</em> and <em>how</em>  service descriptions get discovered?  In the registry model, it is the owner of the registry who controls this.  In the index model, since anyone can create an index, market forces determine which indexes become popular.  Hence, it is effectively the market that controls what and how service descriptions get discovered. </p></div><div class="div4">
<h5><a name="id2280003" id="id2280003"></a>3.4.2.3 Peer-to-Peer (P2P) Discovery</h5><p>Peer-to-Peer (P2P) computing provides an alternative that does not rely on centralized registries; rather it allows Web services to discover each other dynamically. Under this view, a Web service is a node in a network of peers, which may or may not be Web services. At discovery time, a requester agent queries its neighbors in search of a suitable Web service. If any one of them matches the request, then it replies.  Otherwise each queries its own neighboring peers and the query propagates through the network until a particular hop count or other termination criterion is reached.  </p><p>Peer-to-peer architectures  do not need a centralized registry, since any node will respond to the queries it receives. P2P architectures do not have a single point of failure, such as a centralized registry.  Furthermore, each node may contain its own indexing of the existing Web services.  Finally, nodes contact each other directly, so the information they they receive is known to be current.  (In contrast, in the registry or index approach there may be significant latency between the time a Web service is updated and the updated description is reflected in the registry or index.)</p><p>The reliability provided by the high connectivity of P2P systems comes with performance costs and lack of guarantees of predicting the path of propagation. Any node in the P2P network has to provide the resources needed to guarantee query propagations and response routing, which in turn means that most of the time the node acts as a relayer of information that may be of no interest to the node itself. This results in inefficiencies and large overhead especially as the nodes become more numerous and connectivity increases.  Furthermore, there may be no guarantee that a request will spread across the entire network, therefore there is no guarantee to find the providers of a service. </p></div><div class="div4">
<h5><a name="id2280045" id="id2280045"></a>3.4.2.4 Discovery Service Trade-Offs</h5><p>Because of their respective advantages and disadvantages, P2P systems, indexes and centralized registries strike different trade-offs that make them appropriate in different situations. P2P systems are more appropriate in dynamic environments in which proximity naturally limits the need to propagate requests, such as ubiquitous computing.  Centralized registries may be more appropriate in more static or controlled environments where information does not change frequently.  Indexes may be more appropriate in situations that must scale well and accommodate competition and diversity in indexing strategies.</p></div></div><div class="div3">
<h4><a name="id2280061" id="id2280061"></a>3.4.3 Federated Discovery Services</h4><p>Although the registry viewpoint is a more centralized approach to discovery
than the index approach, there will arise situations where multiple
registries exist on the Web.  It is expected that multiple indexes will
also exist.  In such an environment, web service requesters that need to
use a discovery service may need to obtain information from more than one
registry or index.  Federation refers to the ability to consolidate the
results of queries that span more than a single registry or index, and make them appear more like a single service.</p><p>A registry or index may contain information about other registries or
indexes to help support federation.  For example, a registry dedicated to
air travel services may know about another registry dedicated to rail
travel services.  A third registry for general travel services may contain
information about some travel services, but may look to other registries
for certain categories of services.  A search of the general travel
registry may return a referral to the requester pointing them to the rail
travel registry.  Federation of results in this scenario, as contrasted to
the referral, would require the general travel registry to submit a query
to the rail travel registry on behalf of the requester.  The general travel
registry would then merge the results of the query to the rail travel
registry with the results of a query to its own registry.  The general,
rail, and air travel registries may need to share a common taxonomy or
ontology to avoid forwarding inappropriate queries to other registries.  In
this scenario, we assume the general travel registry examined the query
from the requester and therefore did not forward the query to the air
travel registry.</p><p>The general travel registry could have discovered the rail travel registry
using a spider or index approach.  An indexing engine could have come
across a registry, and based on the information it harvested from the
registry classified it as a rail travel registry.  An alternative approach
would be for the rail travel registry to publish information to the general
travel registry and using the shared taxonomy could classify itself as a
registry for rail travel services.</p><p>Note that each registry or index may provide a web service for discovery,
so it may be appropriate to use a choreography or orchestration description
language to describe the exchanges among these services needed for federation.</p></div><div class="div3">
<h4><a name="id2280135" id="id2280135"></a>3.4.4 Functional Descriptions and Discovery</h4><p>As mentioned at the beginning of <a href="#discovery"><b>2.3.3.1 Discovery</b></a>, Web services discovery requires the ability to search for appropriate Web services based on functional descriptions ("FD" in <a href="#gdp">Figure 3-2</a>) or other criteria.  Because these  functional descriptions need to be machine processable, written by many provider entities and read by many requester entities, an appropriate  language for representing functional descriptions should at least be:</p><ul><li><p>Web friendly (based on URIs and globally scalable)</p></li><li><p>Unambiguous</p></li><li><p>Capable of expressing any existing or future functionality</p></li><li><p>Capable of expressing existing and new vocabularies and relationships between functionalities</p></li></ul><p>This is an area that needs further standardization work.  One such effort is <a href="http://www.daml.org/services/owl-s/1.0/">OWL-S</a>.</p></div></div><div class="div2">
<h3><a name="id2280201" id="id2280201"></a>3.5 Web Service Semantics</h3><p>For computer programs to successfully interact with each other a number of conditions
	must be established:</p><ol type="1"><li><p>There must be a physical connection between them, such that data from one process
	  may reach another</p></li><li><p>There must be <a title="" href="#agree">agreement</a>      (in the sense discussed  in <a href="#stakeholder_using"><b>3.3 Using Web Services</b></a>)  on the <em>form</em> of the data such as
	      whether the data is lines of text, XML structures, etc.  </p></li><li><p>The two (or more) programs must <a title="" href="#agree">share agreement</a> (in the sense discussed  in <a href="#stakeholder_using"><b>3.3 Using Web Services</b></a>)  as to the intended meaning of the
	      data. For example, whether the data is intended to represent an HTML page to be
	      rendered, or whether the data represents the current status of a bank account; the
	      expectations and the processing involved in processing the data is different &#8212; even if
	      the form of the data is identical.</p></li><li><p>There must be <a title="" href="#agree">agreement</a> (in the sense discussed  in <a href="#stakeholder_using"><b>3.3 Using Web Services</b></a>)  as to the implied processing of messages exchanged
              between the programs. For example, purchase ordering Web service is expected &#8212; by the
              agent that places the order &#8212; to process the document containing the purchase
              order <em>as a purchase order</em>, as opposed to simply recording it for auditing
              purposes.</p></li></ol><p>As we shall see below, more may be required, but for now this list is sufficient.</p><div class="div3">
<h4><a name="id2280311" id="id2280311"></a>3.5.1 Message semantics and visibility</h4><p>The extent to which the shared agreement about the form, structure and meaning of a
            message is shared <em>beyond</em> just the agents involved with the message governs
            the overall <em>visibility</em> of the message semantics. The emphasis on messages,
            rather than on the actions that are caused by messages, means that SOAs have good
            visibility:  third parties may inspect the flow of messages and have a some
            assurance as to the services being invoked and the roles of the various parties. This,
            in turn, means that intermediaries, such as firewalls, are in a better situation for
            performing their functions. A firewall can look at the message traffic, and at the
            structure of the message, and make predictable and reasonable decisions about
            security.</p><p>In REST-compliant SOAs, additional visibility comes from the uniform interface semantics,
            essentially those of the HTTP protocol: an intermediary can inspect the URI of the
            resource being manipulated, the TCP/IP address of the requester, and the interface
            operation requested (e.g. GET, PUT, DELETE) and determine whether the requested
            operation should be performed. The TCP/IP and HTTP protocols have a widely supported set
            of conventions (e.g. known ports) to support intermediaries, and firewalls, proxies,
            caches, etc. are almost universal today.</p><p>Visibility, however, goes beyond firewalls. In this architecture, instead of
            emphasising a REST-style uniform interface, we emphasize messages' structure in terms of
            envelopes, headers and bodies.  We enhance visibility architecturally by fostering
            agreements on particular forms of headers. For example, by having well-known standards
            that describe the form and interpretation of authentication tokens in headers, we can
            simultaneously reduce the cost of performing authentication and increase the overall
            visiblity of the message's semantics: if the authentication aspect of a message can be
            specified in a standard way then it is easier for a larger number of interested parties
            to process the message.  Furthermore, increased visibility can reduce the cost of entry into a marketplace.</p><p>Other potential examples of standardized headers include support for message
            reliability, support for message correlation, support for process flow and service
            composition and support for choreography.</p><p>This argument can be extended from obvious infrastructure-related processing of
            messages to more application-related processing of the message. For example, by
            capturing customer identification in a well-understood header, then all applications
            capable of processing that header will be able to extract the customer information of a
            message <em>independently</em> of the intended final disposition of the message.</p><p>This, in turn, suggests an extremely powerful architectural approach to message
            processing: different stakeholders in an organization, represented by different
            applications processing different aspects of messages, can collaborate with a minimal
            pre-ordained design.</p></div><div class="div3">
<h4><a name="id2280404" id="id2280404"></a>3.5.2 Semantics of the Architectural Models</h4><p>The different models in the architecture focus on different aspects of the
            interoperability issues between Web service agents. The <a title="" href="#message_oriented_model">Message Oriented Model</a>  focuses on how Web
            service agents (requester and provider agents) may interact with each other using a message
            oriented communication model. The format of messages as XML infosets and the
            structuring of messages in terms of envelopes, headers and bodies, as described in that
            model, acts to lay a foundation for the standard comprehension of messages exchanged
            between Web service agents.</p><p>The <a title="" href="#service_oriented_model">Service Oriented Model</a> builds on
  	    the basics of message communication by adding the concept of <a title="" href="#action">action</a> and <a title="" href="#service">service</a>. Essentially,
  	    the service model allows us to interpret messages as requests for actions and as
  	    responses to those requests. Furthermore, it allows an interpretation of the different
  	    aspects of messages to be expressed in terms of different expectations, in well
  	    understood ways, of the different parts of the message: in effect, an incremental and
  	    layered approach to service is possible using well understood headers.</p><p>The <a title="" href="#resource_oriented_model">Resource Oriented Model</a> extends
	    this further by adding the concept of <a title="" href="#resource">resource</a>. Resources are important internally to the
	    architecture (a Web service is best understood as a resource in the context of Web
	    service management and in terms of policy management) and externally: resources are an
	    important metaphor for interpreting the interaction between a <a title="" href="#requester_entity">requester entity</a> and a <a title="" href="#provider_entity">provider entity</a>. </p></div><div class="div3">
<h4><a name="id2280504" id="id2280504"></a>3.5.3 The Role of Metadata</h4><p>An important part of the Service Oriented Architecture approach is the extensive use of
            metadata. This is important for several reasons: it fosters interoperability by
            requiring increased precision in the documentation of Web services and it permits tools
            to give a higher degree of automation to the development of Web services (and hence
            lowers the cost of deploying same).</p><p>The metadata associated with a Web service can be regarded as a partial machine-readable description of the semantics of the Web service. In particular using
  	    technologies such as WSDL, a Web service can be described in a machine readable document
  	    as to the forms of expected messages, the datatypes of elements of messages and using a
  	    <a title="" href="#choreography">choreography</a> description language the expected flows of messages between Web service
  	    agents.</p><p>However, current technologies used for describing Web services are probably not yet
            sufficient to meet interoperability requirements on a global scale. We see the following
            areas where increased and richer meta-data would further enhance interoperability:</p><ul><li><p>It should be possible to identify the real-world entities referenced by
	        elements of messages. For example, when using a credit card to arrange for the
	        purchase of goods or services, the element of the message that contains the credit
	        card information is fundamentally a reference to a real-world entity: the account of
	        the card holder.</p><p>The appropriate technology for this is standardized ontology languages, such as
              <a href="http://www.w3.org/2001/sw/">OWL</a>.</p></li><li><p>It should be possible to identify the expected effects of any actions
	        undertaken by Web service requester and provider agents. That this cannot be captured by
	        datatyping can be illustrated with the example of a Web service for withdrawing
	        money from an account as compared to depositing money (more accurately, transferring
	        from an account to another account, or vice versa). The datatypes of messages
	        associated with two such services may be identical, but with dramatically different
	        effects: instead of being paid for goods and services, the risk is that one's
	        account is drained instead.</p><p>We expect that a richer model of services, together with technologies for
	        identifying the effects of actions, is required. Such a model is likely to
	        incorporate concepts such as contracts (both legally binding and technical
	        contracts) as well as ontologies of action.</p></li><li><p>Finally, a Web service program may "understand" what a particular
	        message means in terms of the expected results of the message, but, unless there is
	        also an understanding of the relationship between the <a title="" href="#requester_entity">requester entity</a> and the <a title="" href="#provider_entity">provider entity</a>, the provider agent may not be able to
	        accurately determine whether the requested actions are <em>warranted</em>.</p><p>For example, a provider agent may receive a request to transfer money
	        from one account to another. The request may be  valid in the sense that the datatypes
	        of the message are correct, and that the semantic markers associated with the
	        message lead the provider agent to correctly interpret the message as a transfer
	        request. However, the transaction still may not be valid, or fully comprehensible,
	        unless the provider agent can properly identfy the relationship of the
	        requester agent's owner (i.e., the requester entity)  to the requested action. Currently, such concerns are often treated simply
	        as security considerations, which they are, in an ad hoc fashion. However, when
	        one considers issues such as delegated authority, proxy requests, and so on, it
	        becomes clear that a simple authentication model cannot accurately capture the
	        requirements.</p><p>We expect that a model that formalizes concepts such as institutions, roles (in
	      business terms), "regulations" and regulation formation will be
	      required. With such a model we should be able to capture not only simple notions of
	      authority, but more subtle distinctions such as the authority to delegate an action,
	      authority by virtue of such delegation, authority to authorize and so on.</p></li></ul></div></div><div class="div2">
<h3><a name="security" id="security"></a>3.6 Web Services Security</h3><p>Threats to Web services involve threats to the host system, the application and the entire network infrastructure.  To secure Web services, a range of XML-based security mechanisms are needed to solve
        problems related to authentication, role-based access control, distributed security policy
        enforcement, message layer security that accommodate the presence of intermediaries. </p><p>At this
        time, there are no broadly-adopted specifications for Web services security. As a result
        developers can either build up services that do not use these capabilities or can develop
        ad-hoc solutions that may lead to interoperability problems.</p><p>Web services implementations may require point-to-point and/or end-to-end security mechanisms, depending upon the degree of threat or risk. Traditional, connection-oriented, point-to-point security mechanisms may not meet the
        end-to-end security requirements of Web services. However,
        security is a balance of assessed risk and cost of countermeasures. Depending on
        implementers risk tolerance, point-to-point transport level security can provide enough
        security countermeasures.</p><div class="div3">
<h4><a name="security_policies" id="security_policies"></a>3.6.1 Security policies</h4><p>From the perspective of this architecture, there are three fundamental concepts related to security: the <a title="" href="#resource">resources</a> that must be secured; the mechanisms by which these resources are secured (i.e., <a title="" href="#policy_guard">policy guards</a>); and <a title="" href="#policy">policies</a>, which are
          machine-processable documents describing constraints on these resources.   </p><p>Policies can be logically broken down into two main types: permission policies and
          obligatory policies. A permission policy concerns those actions and accesses that entities
          are permitted to perform and an obligation policy concerns those actions and states that
          entities are required to perform. These are closely related, and dependent: it is not
          consistent to be obliged to perform some action that one does not have permission to
          perform. A given policy document is likely to contain a mix of obligation and permission
          policy statements.</p><p>The two kinds of policies have different enforcement mechanisms: a permission guard is
          a mechanism that can be used to verify that a requested action or access is permitted; an
          audit guard can only verify after the fact that an obligation has not been met. The
          precise form of these guards is likely to vary, both with the resources being controlled
          and with the implementation technologies deployed.</p><p>The architecture is principally concerned with the existence of guards and their role
          in the architecture. In a well engineered system it may be possible to construct guards
          that are not directly visible to either the requester or provider agents. For example, the unauthorized access threat may be countered by a mechanism that
          validates the identity of potential agents who wish access the controlled resource. That
          mechanism is, in turn, controlled by the policy document which expresses what evidence
          must be offered by which agents before the access is permitted.</p><p>A permission guard acts as a guard enabling or disabling access to a resource or
          action. In the context of SOAP, for example, one important role of SOAP intermediaries is
          that of permission guards: the intermediary may not, in fact, forward a message if some
          security policy is violated.</p><p>Not all guards are active processes. For example, confidentiality of information is
          encouraged by encryption of messages. As noted above, it is potentially necessary to
          encrypt not only the content of SOAP messages but also the identities of the sender and
          receiver agents. The guard here is the encryption itself; although this may be further
          backed up by other active guards that apply policy.</p></div><div class="div3">
<h4><a name="id2280826" id="id2280826"></a>3.6.2 Message Level Security Threats</h4><p>Traditional network level security mechanisms such as Transport Layer Security
           (SSL/TLS), Virtual Private Networks (VPNs), IPSec (Internet Protocol Security) and Secure
           Multipurpose Internet Mail Exchange (S/MIME) are point-to-point technologies. Although
           traditional security technologies are used in Web services security, however, they are
           not sufficient for providing end-to-end security context,
	   as Web services
           require more granularities. In general, Web services use a message-based approach that
           enables complex interactions that can include the routing of messages between and across
           various trust domains. </p><p>Web services face traditional security challenges. A message might travel between
           various intermediaries before it reaches its destination. Therefore, message-level
           security is important as opposed to point-to-point, transport-level, security. In <a href="#gees">Figure 3-3</a> below, the
           requester agent is communicating with the ultimate receiver through the use of one or
           more intermediaries. The security context of the SOAP message is end-to-end. However,
           there may be a need for the intermediary to have access to some of the information in the
           message. This is illustrated as a security context between the intermediary and the
           original requester agent, and the intermediary and the ultimate receiver.</p><div class="figure"><a name="gees" id="gees"></a><br /><img src="images/endtoend.png" alt="End-to-End Security" /><p><i><span>Figure 3-3. </span>End-to-End Security</i></p><br /></div><p>The threats listed below addresses message security.</p><div class="div4">
<h5><a name="id2280892" id="id2280892"></a>3.6.2.1 Message Alteration</h5><p>These threats affect message integrity, whereby, an attacker may modify parts (or
             the whole) message. For example, an attacker may delete part of a message, or modify
             part of a message, or insert extra information into a message. The attacks may affect
             message header and/or body parts.</p><p>An attacker may also affect message integrity by manipulating its attachments. For
             example, an attacker may delete an attachment, or modify an attachment, or insert an
             attachment into a message. </p></div><div class="div4">
<h5><a name="id2280916" id="id2280916"></a>3.6.2.2 Confidentiality</h5><p>In this threat, unauthorized entities obtain access to information with in a message
            or message parts. For example, an intermediary obtains access to credit card information
            that was intended for the ultimate recipient.</p></div><div class="div4">
<h5><a name="id2280930" id="id2280930"></a>3.6.2.3 Man-in-the-middle</h5><p>Man-in-the-middle attacks are also known as bucket-brigade attacks. In this kind of
            assault it is possible for an attacker to compromise a SOAP intermediary and then
            intercepts messages between the web service requester and the ultimate receiver. The
            original parties will think that they are communicating with each other. The attacker
            may just have access to the messages or may modify them. Mutual authentication
            techniques can be used to alleviate the threats of this attack.</p></div><div class="div4">
<h5><a name="id2280949" id="id2280949"></a>3.6.2.4 Spoofing</h5><p>Spoofing is a complex attack that exploits trust relationships. The attacker assumes
            the identity of a trusted entity in order to sabotage the security of the target
            entity. As far as the target entity knows, it is carrying on a conversation with a
            trusted entity. Usually, spoofing is used as a technique to launch other form of attacks
            such as forged messages. Strong authentication techniques are needed to defend against
            such attacks.</p></div><div class="div4">
<h5><a name="id2280967" id="id2280967"></a>3.6.2.5 Denial of Service</h5><p>Denial of service (DoS) attacks focus on preventing legitimate users of a service from the ability to use
            the service. DoS attacks are easy to implement and can cause significant damage. DoS
            attacks can disrupt the operation of the agent that is under attack and effectively
            disconnect it from the rest of the world. DoS attacks can take various forms and target
            variety of services. DoS attacks exploit weaknesses in the architecture of the system
            that is under attack. Ironically, security mechanisms themselves add overhead that can be exploited in DoS attacks.</p><p>Distributed denial of service (DDoS) attacks uses the resources of more than one machine to launch synchronized DoS attacks on a resource.</p></div><div class="div4">
<h5><a name="id2280993" id="id2280993"></a>3.6.2.6 Replay Attacks</h5><p>In this attack an intruder intercepts a message and then replays it back to a targeted
            agent. Appropriate authentication techniques coupled with techniques such as time stamp
            and sequence numbering the messages can defend against replay attacks.</p></div></div><div class="div3">
<h4><a name="wssreqs" id="wssreqs"></a>3.6.3 Web Services Security Requirements</h4><p>There are many security challenges for adopting Web services. At the highest level, the
          objective is to create an environment, where message level transactions and business
          processes can be conducted securely in an end-to-end fashion. There is a need to ensure
          that messages are secured during transit, with or without the presence of
          intermediaries. There may also be a need to ensure the security of the data in
          storage. </p><p>The requirements for providing end-to-end security for Web services are summarized in
          the next sub-sections.</p><div class="div4">
<h5><a name="id2281040" id="id2281040"></a>3.6.3.1 Authentication Mechanisms</h5><p>Authentication is needed in order to verify the identities of the requester and provider agents. In some cases, the use of mutual authentication may be needed
            since the participants may not necessarily be directly connected by a single hop. For
            example the participants might be the initial requester and an intermediary. Depending
            on the security policy it may be possible to authenticate the requester, the receiver or
            to mandate the use of mutual authentication. </p><p>Several methods can be used to authenticate services. Techniques include: passwords,
            one time pass and certificates. Password-based authentication must use strong passwords.   Password authentication alone may be insufficient. Based on
            vulnerability assessment it may be necessary to combine password authentication with
            other authentication and authorization process such as certificates, Lightweight
            Directory Access Protocol (LDAP), Remote Authentication Dial-in User Service (RADIUS),
            Kerberos, and Public Key Infrastructure (PKI).</p></div><div class="div4">
<h5><a name="id2281072" id="id2281072"></a>3.6.3.2 Authorization</h5><p>Authorization is needed in order to control access to resources. Once authenticated,
            authorization mechanisms control the requester access to appropriate system
            resources. There should be controlled access to systems and their components. Policy
            determines the access rights of a requester. The principle of least privilege access
            should be used when access rights are given to a requester.</p></div><div class="div4">
<h5><a name="id2281089" id="id2281089"></a>3.6.3.3 Data Integrity and Data Confidentiality</h5><p>Data integrity techniques ensure that information has not been altered, or modified
            during transmission without detection. Data confidentiality ensures that the data is
            only accessible by the intended parties. Data encryption and digital signature
            techniques can be used for this purpose. </p></div><div class="div4">
<h5><a name="id2281105" id="id2281105"></a>3.6.3.4 Integrity of Transactions and Communications</h5><p>This is needed to ensure that the business process was done properly and the flow of
            operations was executed in a correct manner. </p></div><div class="div4">
<h5><a name="id2281118" id="id2281118"></a>3.6.3.5 Non-Repudiation</h5><p>Non-repudiation is a security service that protects a party to a transaction against
            false denial of the occurrence of that transaction by another party. Non-repudiation
            technologies provide evidence about the occurrence of transactions that that may be used
            by a third party to resolve disagreement.</p></div><div class="div4">
<h5><a name="id2281134" id="id2281134"></a>3.6.3.6 End-to-End Integrity and Confidentiality of Messages</h5><p>The integrity and confidentiality of messages must be ensured even in the presence of
            intermediaries. </p></div><div class="div4">
<h5><a name="id2281146" id="id2281146"></a>3.6.3.7 Audit Trails</h5><p>Audit trails are needed in order to trace user access and behavior. They are also
            needed in order to ensure system integrity through verification. Audit trails can be
            performed by agents. Such agents can play the role of an audit guard that can monitor;
            watch resources and other agents, validating those obligations that have been
            established are respected and/or discharged. It is often not possible to prevent the violation of obligations.  Instead, if an audit guard detects a policy violation, some form of retribution or remediation
            must be enacted. The precise forms of this are, of course, beyond the scope of this
            architecture.</p></div><div class="div4">
<h5><a name="id2281168" id="id2281168"></a>3.6.3.8 Distributed Enforcement of Security Policies</h5><p>Implementers must be able to define a security policy and enforce it across various
            platforms with varying privileges. </p></div></div><div class="div3">
<h4><a name="id2281182" id="id2281182"></a>3.6.4 Security Consideration of This Architecture</h4><p>Organizations that implement Web services must be able to conduct business in a secure
          fashion. This implies that all aspects of Web services including routing, management,
          publication, and discovery should be performed in a secure manner. Web services
          implementers must be able to utilize security services such as authentication,
          authorization, encryption and auditing. </p><p>Web services messages can flow through firewalls, and can be tunneled through existing
          ports and protocols. Web services security requires the use of appropriate corporate wide
          policies that may need to be integrated with external cross-enterprise policy and trust
          resolution. Organizations may need to implement the capabilities that are listed next.</p><div class="div4">
<h5><a name="id2281208" id="id2281208"></a>3.6.4.1 Cross-Domain Identities</h5><p>Requester and provider agents may communicate with each other using various
            identity verification schemes from different security domains. Many systems define role
            based access privileges based on identity. It is important for Web services to be able
            to support the mapping of identities across multiple domains and even within a single
            domain. </p><p>A provider entity and a requester entity may use their identities to encrypt and sign messages that
            they exchange. They may exchange identity credentials within a context of
            initial messages (handshake). That allows further trusted interactions. Service's
            identity is optional, and it is perfectly possible to implement a business service
            without an identity if it always acts on behalf of a
	    requester entity (that is, impersonating the
            requester entity). Not having a requester entity's identity translates into anonymous access, which is
            rarely allowed for business services.</p></div><div class="div4">
<h5><a name="id2281240" id="id2281240"></a>3.6.4.2 Distributed Policies</h5><p>Security Policies that are associated with requester entity, service and discovery mechanism
            can be used to define the access privileges of request and responses between
            parties. These polices can be validated at run time in the context of interaction. Each
            party in an interaction validates its own policies. </p></div><div class="div4">
<h5><a name="id2281256" id="id2281256"></a>3.6.4.3 Trust Policies</h5><p>Trust Policies are distributed policies that apply to the environment of the other
            side's party in an interaction. A requester entity needs to <em>trust</em> the environment of
            a service and the provider entity needs to trust the
	    environment of the requester entity. Trust policies
            may be recursive &#8212; they may be defined against trust policies of involved parties
            and even whole domains. An example of this is: "I will trust you if you trust my
            friend and my friend trusts you."</p><p>Distributed Identities, Policies and Trust can be described and processed by a
            machine. For example, an X.509 certificate can be embedded in an message, thus
            asserting the sender&#8217;s Identity. A Policy can be described in XML and attached to the
            service contract. Machines could process, resolve and adjust security based on the given
            descriptions. </p><p>Trust mechanisms can be used to form Delegation and Federation relationships. These
            mechanisms can be used to facilitate secure interactions between web services across
            trust boundaries in a distributed fashion. </p></div><div class="div4">
<h5><a name="id2281308" id="id2281308"></a>3.6.4.4 Secure Discovery Mechanism</h5><p>Secure Discovery Mechanism enforces policies that govern publication and discovery of
            a service. For example, developers of SOA applications for the procurement department
            may not be allowed to discover services available in the human resources department, if
            those developers are not entitled to use human resources services. When publishing a
            service, an identity is usually necessary to assert service publication policies, except
            for some cases of peer-to-peer discovery. When a requester
	    entity discovers a service, it may or
            may not provide an Identity; discovery may well be anonymous.</p></div><div class="div4">
<h5><a name="trust" id="trust"></a>3.6.4.5 Trust and Discovery</h5><p>Suppose a requester entity discovers a Web service
	    being offered by a provider entity that was previously
	    unknown to that requester entity.  Should the requester
	    entity <em>trust</em> that service?  If the use of
	    that service requires the requester to divulge sensitive
	    information (such as credit card numbers) to the service
	    then there may be significant risk involved.  </p><p>This decision &#8212; whether or not to trust a particular
	    service &#8212; inherently arises when a requester entity
	    chooses a Web service from a previously unknown provider
	    entity.  This has ramification in the discovery process,
	    and leads to an important difference between manual
	    discovery and autonomous discovery.  </p><p>When manual discovery is used, a human makes the
	    judgement (perhaps using other, independently obtained
	    information) of whether to trust and engage a previously
	    unknown service that is discovered.  Whereas with
	    autonomous discovery, a machine makes this decision.
	    Since people may not trust a machine to make significant
	    judgement decisions that could put themselves or their
	    organizations at risk, agents performing autonomous
	    discovery are often limited to using private discovery
	    services that list only those services that have been
	    pre-screened and deemed trustworthy by the requester
	    entity.  This limited form of autonomous discovery would
	    be more precisely called autonomous
	    <em>selection</em>, since the available candidates are
	    already known in advance.  Two other ways to mitigate the
	    trust issue in automated discovery include: (1) a agent
	    could autonomously discover candidate Web services and
	    then show them to the human user to choose; or (2) an
	    agent could autonomously discover candidate services and
	    then check a trusted registery for independent information
	    about them, such as a Dunn and Bradstreet quality
	    rating.</p></div><div class="div4">
<h5><a name="id2281395" id="id2281395"></a>3.6.4.6 Secure Messaging</h5><p>Secure Messaging ensures privacy, confidentiality and integrity of interactions. Digital signatures techniques can be used to help ensure
            non-repudiation. </p><p>Techniques that ensure channel security can be used for securing messages. However,
            such techniques are applicable in a few limited cases. Examples include a static direct
            connection between a requester agent and a provider agent. For some applications, such mechanisms can be
            appropriate. However, in the general case, message security techniques such as
            encryption and signing of the message payload can be used in routing and reliable
            messaging.</p><div class="figure"><br /><img src="images/securitytriangle.png" alt="Secure Discovery" /><p><i><span>Figure 3-4. </span>Secure Discovery</i></p><br /></div></div></div><div class="div3">
<h4><a name="privacy" id="privacy"></a>3.6.5 Privacy Considerations</h4><div class="issue"><p class="prefix"><a name="privacy_needs_more_work" id="privacy_needs_more_work"></a><b>Issue (privacy_needs_more_work):</b></p><p class="prefix"><b>The relationship between privacy and Web services technology needs clarification.</b></p><p>There is considerably more complexity to privacy than treated in this section.</p><p class="prefix"><b>Resolution:</b></p><p>None recorded.</p></div><p>Privacy as related to behavior, habits and actions are expressed in terms of policies
          that the owners of data &#8212; typically the users of Web services &#8212; have, together with
          mechanisms necessary to ensure that the owners' rights are respected.</p><p>Privacy policies are typically much more of the obligatory form than access control
          policies. A policy that requires a provider agent to properly propagate P3P tags,
          for example, represents an obligation on the provider entity. However, it is not possible to
          prevent a rogue provider agent from leaking private information. Thus, it should be
          possible to monitor the public actions of the Web service to verify that the P3P tags are
          propagated appropriately.</p><p>Many privacy-related constraints are concerned with maintaining certain kinds of
          state. For example, a provider entity may have a constraint that any P3P tags
          associated with a use of one of its Web services are appropriately propagated to third
          parties. Such a constraint cannot easily expressed in terms of the allowed actions that
          the provider agent may perform. It is an obligation to ensure that the publicly
          observable condition (the proper use of P3P tags) is always maintained (presumably
          maintained in private also). Similarly, a provider agent may link the possible
          actions that a requester agent may perform to the requester agent maintaining
          a particular level of secure access (e.g., administrative tasks may only be performed if
          the request is using secure communications).</p></div></div><div class="div2">
<h3><a name="id2281505" id="id2281505"></a>3.7 Peer-to-Peer Interaction</h3><p>To support Web services interacting in a peer to peer style, the architecture must
          support peer to peer message exchange patterns, must permit Web services to have
          persistent identity, must permit descriptions of the capabilities of peers and must
          support flexibility in the discovery of peers by each other.</p><p>In the <a title="" href="#mep">message exchange pattern</a> concept we allow for Web
          services to communicate with each other using a very general concept of message exchange.
          Furthermore, we allow for the fact that a message exchange pattern can itself be
          identified &#8212; this permits interacting Web service agents to explicitly reference a
          particular message pattern in their interactions.</p><p>A Web service wishing to use a peer-to-peer style interaction may use, for example, a
          publish-subscribe form of message exchange pattern. This kind of message exchange is just
          one of the possible message exchange patterns possible when the pattern is explicitly identifiable.</p><p>In the <a title="" href="#agent">agent</a> concept we note that agents have <a title="" href="#identifier">identifiers</a>. The primary role of an agent identifier is to
          permit long running interactions spanning multiple messages. Much like correlation, an
          agent's identifier can be used to link messages together. For example, in a publish and
          subscribe scenario, a publishing Web service may include references to the Web service
          that requested the subscription, separately from and additionaly to, the actual recipient
          of the service.</p><p>The <a title="" href="#agent">agent</a> concept also clarifies that a given agent may
          adopt the role of a <a title="" href="#provider_agent">provider agent</a> and/or a
            <a title="" href="#requester_agent">requester agent</a>. I.e., these are roles of
          an agent, not necessarily intrinsic to the agent itself. Such flexibility is a key part of
          the peer to peer mode of interaction between Web services.</p><p>In the <a title="" href="#service">service</a> concept we state that services <a title="" href="#hasa">have</a> a <a title="" href="#service_semantics">semantics</a> that may
          be identified in a<a title="" href="#service_description">service description</a> and
          that may be expressed in a <a title="" href="#service_description">service description language</a>. This identification of
          the semantics of a service, and for more advanced agents the description of the service
          contract itself, permits agents implementing Web services to determine the capabilities of
          other peer agents. This is turn, is a critical success factor in the architecture
          supporting peer-to-peer interaction of Web services.</p><p>Finally, the fact that <a title="" href="#service">services</a> have <a title="" href="#service_description">descriptions</a> means that these descriptions may be
          published in <a title="" href="#discovery_service">discovery agencies</a> and also
          retrieved from such agencies. In effect, the availability of explicit descriptions enables
          Web services and agents to discover each other automatically as well as having these hard-coded.</p></div><div class="div2">
<h3><a name="reliability" id="reliability"></a>3.8 Web Services Reliability</h3><p>Dealing with errors and glitches is an inescapable fact of life, especially in the
          context of a global network linking services belonging to many different people. While we
          cannot eliminate errors and glitches, our goal is to both reduce the the error frequency
          for interactions and, where errors occur, to provide a greater amount of information about
          either successful or unsuccessful attempts at service.
        </p><p>Note that our focus on reliability is not really on issues such as syntax errors, or even
          badly written applications. There is sufficient scope for things to go wrong at the level
          of network connections being broken, servers being switched off and on in the middle of
          transactions and even people entering incorrect information in some description file.
        </p><p>In the context of Web services, we can address the issues of reliability at several
          distinct levels: the reliable and predictable delivery of infrastructure services, such as
          message transport and service discovery, of reliable and predictable interactions between
          services, and of the reliable and predictable behavior of individual requester and
          provider agents. This analysis is generally separate from concerns of fault tolerance,
          availability or security, but there may of course be overlapping issues.</p><p>In the context of security, deliberate acts can cause things to go wrong -- for example, denial of service attacks.  This is a
          sufficiently important case that we deal with it in a separate <a title="" href="#security">section</a>.</p><div class="div3">
<h4><a name="message_reliability" id="message_reliability"></a>3.8.1 Message reliability</h4><p>Reliability at the level of messages is often referred to as reliable messaging. In any
          distributed system there are fundamental limits to the reliability of communication
          between agents on a public network. However, in practice there are techniques that we can
          use to greatly increase the reliability of messages, and in those cases where
          communication fails then we can gain some feedback as to what went wrong.
          </p><p>In more detail, we identify two properties of message sending that are important: the
          sender of the message would like to be able to determine whether a given message has been
          received by its intended receiver and that the message has been received exactly once.</p><p>Knowing if a message has been received correctly allows the sender to take compensating
          action in the event the message has not been received. At the very least, the sender may
          attempt to resend a message that has not been received.</p><p>The general goal of reliable messaging is to define mechanisms that make it possible to
          achieve these objectives with a high probability of success in the face of inevitable but
          unpredictable network, system and software failures.</p><p>This goal may also be examined with respect to whether one wishes to confirm only the receipt of a message, or perhaps also to confirm the validity of that message. Three questions may be asked about message validity:</p><ol type="1"><li><p>Was the message received the same as the one sent? This may be determined by such
              techniques as byte counts, check sums, digital signatures.</p></li><li><p>Does the message conform to the formats specified by the agreed upon protocol for
              the message? Typically determined by automatic systems using syntax constraints (e.g.
              XML well formed) and structural constraints (validate against one or more XML schemas
              or WSDL message definitions).</p></li><li><p>Does the message conform to the business rules expected by the receiver? For this
              purpose additional constraints and validity checks related to the business process are
              typically checked by application logic and/or human process managers.</p></li></ol><p>Of these, the first is considered to be part of reliable messaging,
          the last is partly addressed by Web service choreography, but is more closely related to
          the business expectations of the parties.</p><p>The Web services architecture does not itself give specific support for reliable
          messaging, or for reporting in the event of failure. However, it does give guidance as to
          how this may be accomplished. The headers and body structure of messages can be utilized:
          by providing standardized headers to support message auditing then message reliability
          infrastructures can be deployed in ways that do not need to impact applications and
          services.</p><p>In effect, we can augment message traffic as necessary with specific headers and
          intermediaries that implement specific semantics for message reliability and reporting in
          the case that message communication fails. Recall that the architecture does not itself
          mandate a specific means of message delivery. In fact, we envisage many potential modes of
          communication, including HTTP, SMTP, JMS based message transports. A given message may
          even involve multiple kinds of message transport. However, since all messages are
          structured according to SOAP, we can incorporate overall message reliability within the
          SOAP message structure.
          </p><p>Message reliability is most often achieved via an acknoweldgement infrastructure, which is a set of rules defining how the parties to a message should communicate with each other concerning the receipt of that message and its validity. <a href="http://www.oasis-open.org/committees/download.php/1461/WS-ReliabilityV1.0Public.zip">WS-Reliability</a>  and <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnglobspec/html/ws-reliablemessaging.asp">WS-ReliableMessaging</a>  are examples of specifications for an acknowledgement infrastructure that leverage the SOAP Extensibility Model. In cases where the underlying transport layer already provides reliable messaging support (e.g. a queue-based infrastructure), the same level of reliability can be achieved in SOAP by defining a binding that relies on the underlying properties of the transport.</p></div><div class="div3">
<h4><a name="service_reliability" id="service_reliability"></a>3.8.2 Service reliability</h4><p>As with message reliability, we are not in a position to be able to offer guarantees
          that service provider agents and/service requester agents will always perform flawlessly;
          again, especially in the context of a distributed system over a public network where the
          different agents may be owned by different people and subject to different policies and
          management it is not possible to engineer complete service reliability. However, as with
          message communication we can deploy techniques that greatly enhance reliability and reduce
          the cost of failure. The principal technique here is one of transactional context
          management.
          </p><p>Transaction management allows conversations between agents to be managed so that all
          the parties involved have a greater degree of confidence that the transactions between
          them progress satisfactorily, and in the event of failure the failure may be identified
          and transactions either cancelled, rolled back or compensated for.</p><p>The architecture does not give specific advice on how to
          implement transactional reliability. However, again as with message reliability, the
          combination of the flexible and extensible message structures and the concept of multiple
          processing of messages (via intermediaries implementing <a title="" href="#service_role">service roles</a>) gives us guidance.</p><p>One way to incorporate transactional support would be to use standardized headers
          containing information such as transactional bracket markers and context information that are added to messages exchanged between service requester agents and service provider
          agents in such a way that <em>intermediaries</em> can process messages and monitor
          transactions in a way that only minimally impacts existing applications.   Specialized transactional intermediaries could process messages' transaction-specific
          headers (such as beginning of transaction, commitment, roll-back and so on) and mark
          messages that they process with the results; so that applications can respond
          appropriately.</p><p>Related to transactional monitoring is the monitoring of service choreographies. A
          significant aspect of the specification of the interface of a service is the pattern of
          message traffic that one might see. For simple cases, this pattern is often very
          straightforward; however, for most realistic cases, the choreography of services can be
          very complex. Monitoring that messages are arriving in the order expected is potentially a
          significant tool in the deployment of reliable services.</p><p>Again, as with transactional monitoring, one approach would be to deploy specialized intermediary
          processes whose specific function is to ensure that the choreographic as well as
          the static (i.e., message structure) requirements of service usage are being met. This is
          especially important when the provider agent of a service is not in the same ownership
          domain as the requester agent.</p><p>The key architectural property being used here is the potential deployment of third
          party services that monitor and process messages in specific role-oriented ways that
          neither the requesters of services nor the providers of serives needs to be unduly
          concerned with. This is possible because the architecture does not require messages to be
          consumed by single agents &#8212; nor conversely to be produced by single agents &#8212;
          but allows multiple agents to <em>collaborate</em> in the processing of a given
          message. Each service role establishes a specific functionality, often encoded in specific
          headers of the messages.
          </p></div><div class="div3">
<h4><a name="management" id="management"></a>3.8.3 Reliability and management</h4><p>The reliability of the individual requester and provider agents is out of scope of
          this architecture as we do not comment on the realization of Web services. In some cases
          reliability at this level can be enhanced by provider entities adopting deployment
          platforms that have strong management capabilities. Note that platform manageability represents a
          <em>different</em> perspective than the notion of management identified in <a title="" href="#service_management">Service Management</a> (below), which focuses on the manageability
          of services from a peer or business-partner perspective.</p></div></div><div class="div2">
<h3><a name="service_management" id="service_management"></a>3.9 Web Service Management</h3><p>Web service management is the management of Web services through a set of
        management capabilities that enable monitoring, controlling, and reporting of, service
        qualities and service usage.  Such service qualities include health qualities such as
        availability (presence and number of service instances) and performance (e.g. access latency
        and failure rates), and also accessibility (of endpoints).  Facets of service usage
        information that may be managed include frequency, duration, scope, functional extent, and
        access authorization.
        </p><p>A Web service becomes manageable when it exposes a set of management operations that
        support management capabilities.  These management capabilities realize their monitoring,
        controlling and reporting functions with the assistance of a management information model
        that models various types of service usage and service quality information associated with
        management of the Web service.  Typical information types include request and response
        counts, begin and end timers, lifecycle states, entity identifiers (e.g. of senders,
        receivers, contexts, messages, etc.).
        </p><p>Although the provision of management capabilities enables a Web service to become
        manageable, the extent and degree of permissible management are defined in management
        policies that are associated with the Web service.  Management policies therefore are used
        to define the obligations for, and permissions to, managing the Web service.
        </p><p>Just as the Web service being managed needs to have common service semantics that are
        understood by both the requester and provider entities, Web service management also requires
        common management semantics, in relation to management policies and management capabilities,
        to be understood by the requester and provider entities.
        </p><p> <a href="#management_relationships">Figure 3-5</a> illustrates
how the concepts of <a title="" href="#service">service</a>, <a title="" href="#policy">policy</a> and <a title="" href="#capability">capability</a> defined in this architecture  can be applied to management.  </p><div class="figure"><a name="management_relationships" id="management_relationships"></a><br /><img src="images/metaservice.png" alt="Management Concepts and Relationships" /><p><i><span>Figure 3-5. </span>Management Concepts and Relationships</i></p><br /></div><p>More detailed information about Web services management is available in the <a href="http://www.w3.org/2002/ws/arch/4/management/">management documents</a> that were produced by the Management Task Force of this Working Group.</p></div><div class="div2">
<h3><a name="edi" id="edi"></a>3.10 Web Services and EDI: Transaction Tracking</h3><p>One of the basic assumptions that many people make about the role of Web
services is that they will be used for functions similar to those
presently provided by Electronic Data Interchange (EDI).  Since EDI is a well established
technology, it is useful to examine the expectations that current EDI
users may have for a technology that is to be used as a replacement.
That is, what do they do now that they will also expect from a new
technology?   The most basic of these expectations concern security,
message reliability and a function that we will call "tracking".  Since security and message
reliability are covered elsewhere in  this document, this section will focus on tracking.</p><div class="div3">
<h4><a name="edi-tracking-problem" id="edi-tracking-problem"></a>3.10.1 When Something Goes Wrong</h4><p>What happens when a transaction goes awry for reasons
other than the loss of a message or security violations?  Although it is
possible, and useful, to automate safeguards both at the protocol and
application level, experience indicates that there is a virtually
limitless variety of ways that business transactions can fail.  Informal
interviews with current EDI practitioners have indicated that in
practice the 80-20 of what EDI people actually do is involved with the
issue of finding out what has actually happened in transactions when something has gone wrong.   For example, such an interaction may start with a phone
call that goes something like, "Why haven't you paid us?" and continues,
"We think we have paid you".   In these cases there is often a good
faith desire on both sides to figure out what has happened and comply
with the requirements of the transaction, but the information that
people are working with may differ and coming to a common understanding
can take some work.</p></div><div class="div3">
<h4><a name="edi-tracking-need" id="edi-tracking-need"></a>3.10.2 The Need for Tracking</h4><p>In current EDI operations, many of the questions that must be answered in
these cases can be handled in an automated fashion by the vendor of the
proprietary network used in the transactions.  For example, if company A asks if the invoice to company B was
delivered, the vendor can access its records, probably from a central
repository, and respond, "The message was delivered to company B's
mailbox on Dec 24 but they have not as yet downloaded the message".
Queries of this sort are relatively easy to satisfy in this environment
because the vendor is in control of all aspects of the communication.  In a Web services
scenario, where the transactions take place in a distributed
environment, with no central authority, some other means must replace the current automated queries to the EDI vendor
or this important tracking capability will be lost.  </p><p>One possibility would be to provide some kind of uniform tracking interface. The basic requirement here is for companies that are cooperating in a
business transaction to find out at any time what is the status and history of the
transaction.  Significant complexity is added by the fact that
multiple companies may be involved.  That is, company A may initiate a
transaction by sending a message to B, but the process may then involve
messages between B and C.  In some cases the interactions between B and
C may be known to A (as opposed to being part of B's internal process that is opaque to A).   It is not immediately clear whether this
should be handled by A querying both B and C, or if a responding to a
query from A to B should carry with it the obligation to query C and
return the results.  This is presumably an issue which must be ironed
out in the creation of the specification(s) for the uniform interface.</p></div><div class="div3">
<h4><a name="edi-tracking-examples" id="edi-tracking-examples"></a>3.10.3 Examples of Tracking</h4><p>As illustrations, here are some of the typical queries that A might send
to B or C.  Web Services Usage Scenarios <a href="#WSUS">[WSAUS]</a> contains additional examples.</p><p></p><ol type="1"><li><p>(Query to B) Did you receive and process message M from A?</p></li><li><p>(Query to B) Please return copies of all messages associated with Transaction T.</p></li><li><p>(Query to B) Please return copies of all messages between A and B in a given time
range.</p></li><li><p>(Query to C) Please return all messages associated with transactions involving
A during a given time frame (including messages between B and C related
to transactions in which A is involved).</p></li><li><p>(Query to B) Please return copies of messages between B and other companies
involved with a transaction (or all transactions in a date range).</p></li></ol><p>Of course, in all cases, the party performing the query must be authorized to receive the information.</p><p>Current EDI practices may automate some of these queries; others may
involve manual processing.  In general, however, there are significant
cost savings to be realized by automating as much of the process  as
possible.  </p></div><div class="div3">
<h4><a name="edi-tracking-requirements" id="edi-tracking-requirements"></a>3.10.4 Requirements for Effective Tracking</h4><p>In order to help automate the tracking process, there are various requirements, some of
which are probably achievable using current or planned specifications
and others of which may require new ones:</p><ol type="1"><li><p>A uniform, interoperable interface for tracking queries, so that company A
can send a standard query to all of its business partners.  This interface
should be associated with the functional Web services interfaces.  For example, such an interface
might be implemented as part of a management interface.</p></li><li><p>Standard identifiers for transactions and individual messages that are necessary to define the queries.  Note that some of these queries
involve identifiers of participants in a transaction other than sender
and receiver of a particular message.  There are clearly aspects of this
requirement that are related to the choreography domain.</p></li><li><p>Policies controlling whether party A is authorized to make tracking
queries to B.  There may be several variants of such policies:  e.g. a
can query B about messages directly between A and B but not messages
between B and C associated with transactions involving A and so on.  It
may be possible to establish these policies using mechanisms currently
available or under development in the security or policy domain, or
there may be transactional aspects to these policies that are not
currently being considered.</p></li><li><p>A method to establish the trust relationships necessary to implement
the policies in 3.</p></li></ol></div><div class="div3">
<h4><a name="edi-tracking-and-uris" id="edi-tracking-and-uris"></a>3.10.5 Tracking and URIs</h4><p> One of the important connections between Web services architecture and Web architecture as a whole, is the common use of URIs.  Although URIs are important to many aspects of Web services, it is particularly worth noting their potential role and benefit  in indentifying and tracking transactions in Web services.  </p><p>As a simple example to illustrate this benefit, suppose URIs are used as transaction identifiers.  Each time a new transaction is initiated, a new URI is generated  to unambiguously identify that transaction, much like a primary key in a database.  However, while a database key may only be unambiguous within a particular database, a URI is <em>globally unambiguous</em>, which means that it can be conveniently transmitted to others without loss or confusion of meaning.  </p><p>Furthermore, a URI may be <em>dereferenceable</em>: If the URI also represents the location of a document (or a dynamic query into a database), it could act as a convenient link for determining the status or history of that transaction, provided the user is authorized to access such information.  (Security mechanisms will need to ensure that a tracking URI cannot be dereferenced without proper authority and privacy controls, but the use of URIs is largely orthogonal to this requirement.)</p><p>The potential value of this dual use of URIs &#8212; both as globally unambiguous identifiers and as universally dereferenceable links &#8212; is one of the most fundamental and important insights in the architecture of the Web.  Because the Web services architecture builds on the Web architecture, Web services can leverage the benefits of   clarity, simplicity, universality and convenience that this use of URI offers.  </p><p>This is not to say that Web services tracking <em>must</em> be done using URIs in this way.  Indeed, there are other ways tracking can be performed, and any engineering design must take many factors into consideration.  Rather, the point is to illuminate the fact that, because Web services architecture is based on Web architecture, Web services have the <em>possibility</em> of taking advantage of this use of URIs.</p></div></div></div><div class="div1">
<h2><a name="conclusions" id="conclusions"></a>4 Conclusions</h2><div class="div2">
<h3><a name="id2282493" id="id2282493"></a>4.1 Requirements
    Analysis</h3><p>We believe this architecture substantially meets
    the requirements defined in <a href="#WSAREQ">[WSA Reqs]</a>, with the
    exception of security and privacy.  Although this architecture
    contains  substantial material that lays the foundation for
    addressing these, more work is needed.  The Working Group wanted
    to do more to address these but was not able to do so with the
    available resources.  </p></div><div class="div2">
<h3><a name="id2282511" id="id2282511"></a>4.2 Value of This
    Work</h3><p>This architecture lays the conceptual foundation for
    establishing interopable Web services. The architecture identifies
    a number of important abstractions and their interdependencies.
    </p><p>Contributions of this work include the
    following:</p><ul><li><p>Provides a coherent framework that
    allows specific technologies to be considered in a logical context
    and facilitates the work of specification writers and
    architects.</p></li><li><p>Defines a consistent vocabulary,
    including an authoritative definition of "Web service" that has
    received widespread acceptance in
    industry <a href="#WSAGLOSS">[WS Glossary]</a>.</p></li><li><p>Defines an OWL ontology of Web
    services architecture concepts <a href="#OWLO">[OWLO]</a>.</p></li><li><p>Distinguishes SOA  from
    distributed object architecture.  </p></li><li><p>Clarifies
    the architectural relationship between the Web and Web
    services</p></li><li><p>Clarifies the relationship between Web
    services and REST.</p></li><li><p>Identifies gaps and
    inconsistencies in existing Web services
    specifications.</p></li><li><p>Identifies the role of
    semantics and the need for machine-processable semantics and
    ontologies in Web services</p></li></ul></div><div class="div2">
<h3><a name="unresolved_issues" id="unresolved_issues"></a>4.3 Significant Unresolved
    Issues</h3><p>(See also the <a href="http://www.w3.org/2002/ws/arch/2/issues/wsa-issues.html">issues list</a> previously maintained by
	the Working Group.)</p><ol type="1"><li><p>What is the difference between an MEP and a Choreography? [See <a href="#mep"><b>2.3.1.7 Message Exchange Pattern (MEP)</b></a>]</p></li><li><p>What should be the representation returned by an HTTP "GET" on a Web service URI?  [See <a href="#service"><b>2.3.2.10 Service</b></a>]</p></li><li><p>Should URIs be used to identify Web services components, rather than QNames?  [See <a href="#identifier"><b>2.3.3.3 Identifier</b></a>]</p></li><li><p>The relationship between privacy and Web services technology needs clarification.  [See <a href="#privacy"><b>3.6.5 Privacy Considerations</b></a>]</p></li><li><p>SOAP 1.2 and this architecture introduce the concept of "intermediaries", but this concept is not represented in WSDL 2.0.  </p></li><li><p>What happens if two logical WSDL documents define the same service differently?  [See <a href="http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0045.html">email thread</a>   available at http://lists.w3.org/Archives/Public/www-ws-desc/2003Dec/0045.html ]</p></li><li><p>The relationship between conversations, correlations and transactions and choreography is unclear and needs more work.  </p></li><li><p>There is a need for consistent tracking mechanisms in Web services.  [See  <a href="#edi"><b>3.10 Web Services and EDI: Transaction Tracking</b></a>]</p></li></ol></div></div></div><div class="back"><div class="div1">
<h2><a name="id2282689" id="id2282689"></a>A Overview of Web Services Specifications (Non-Normative)</h2><p>An <a href="http://lists.w3.org/Archives/Public/www-ws-arch/2004Feb/0022.html">annotated list of Web services specifications</a> (available at http://lists.w3.org/Archives/Public/www-ws-arch/2004Feb/0022.html) was produced independently by two members of this Working Group, Roger Cutler and Paul Denning.  <em>Although this Working Group feels that this is a useful list, the opinions expressed therein are the personal opinions of those authors and do not represent the consensus of the Working Group.  </em>  </p></div><div class="div1">
<h2><a name="wsstechno" id="wsstechno"></a>B An Overview of Web Services Security Technologies (Non-Normative)</h2><p>This section attempts to provide a non-exhaustive description
      of current available work around Web services security relevant
      to the requirements and solutions presented in <a href="#security"><b>3.6 Web Services Security</b></a>.  </p><p>Note that although these technologies build on existing
	security technologies, they are relatively new and need to be
	fully tested in actual deployment scenarios.</p><div class="div2">
<h3><a name="dsigenc" id="dsigenc"></a>B.1 XML-Signature and XML-Encryption</h3><p>XML signatures are designed for use in XML transactions. It
	  is a standard that was jointly developed by W3C and the IETF
	  (RFC 2807, RFC 3275). The standard defines a schema for
	  capturing the result of a digital signature operation
	  applied to arbitrary data and its processing. XML signatures
	  add authentication, data integrity, and support for
	  non-repudiation to the signed data. </p><p>XML Signature has the ability to sign only specific
	  portions of the XML tree rather than the complete
	  document. This is important when a single XML document may
	  need to be signed by multiple times by a single or multiple
	  parties.  This flexibility can ensure the integrity of
	  certain portions of an XML document, while leaving open the
	  possibility for other portions of the document to
	  change. Signature validation mandates that the data object
	  that was signed be accessible to the party that interested
	  in the transaction. The XML signature will generally
	  indicate the location of the original signed object. </p><p>XML Encryption specifies a process for encrypting data and
	representing the result in XML. The data may be arbitrary data
	(including an XML document), an XML element, or XML element
	content. The result of encrypting data is an XML Encryption
	element which contains or references the cipher data.</p></div><div class="div2">
<h3><a name="wss" id="wss"></a>B.2 Web Services Security</h3><p>Developed at OASIS, Web Services Security (WSS) defines a
            SOAP extension providing quality of protection through
            message integrity, message confidentiality, and message
            authentication. WSS mechanisms can be used to
            accommodate a wide variety of security models and
            encryption technologies. </p><p>The work provides a general mechanism for associating
            security tokens with messages. The specification does not
            require a specific type of security token. It is
            designed to support multiple security token
            formats. WSS describes how to encode binary
            security tokens. The specification describes how to encode
            X.509 certificates and Kerberos tickets. Additionally, it
            also describes how to include opaque encrypted keys. </p><p>The WSS specification defines an end to end
            security framework that provides support for intermediary
            security processing. Message integrity is provided by
            using XML Signature in conjunction with security tokens to
            ensure that messages are transmitted without
            modifications. The integrity mechanisms can support
            multiple signatures, possibly by multiple actors. The
            techniques are extensible such that they can support
            additional signature formats. Message confidentiality is
            granted by using XML Encryption in conjunction with
            security tokens to keep portions of SOAP messages
            confidential. The encryption mechanisms can support
            operations by multiple actors. </p></div><div class="div2">
<h3><a name="xkms" id="xkms"></a>B.3 XML Key Management Specification (XKMS) 2.0</h3><p>XKMS 2.0 is an XML-based way of managing the Public Key
	  Infrastructure (PKI), a system that uses public-key
	  cryptography for encrypting, signing, authorizing and
	  verifying the authenticity of information in the
	  Internet. It specifies protocols for distributing and
	  registering public keys, suitable for use in conjunction
	  with the proposed standard for XML Signature and XML
	  Encryption.</p><p>XKMS allow implementers to outsource the task of key
	  registration and validation to a "trust"
	  utility. This simplify implementation since the actual work
	  of managing public and private key pairs and other PKI
	  details is done by third party. </p><p>An XKMS trust utility works with any PKI system, passing
	  the information back and forth between it and the Web
	  service. Since the trust utility does the work, the Web
	  service itself can be kept simple. XKMS is a W3C
	  specification.</p></div><div class="div2">
<h3><a name="saml" id="saml"></a>B.4 Security Assertion Markup Language (SAML)</h3><p>SAML is an Extensible Markup Language standard (XML) that
	  supports Single Sign On. SAML allows a user to log on once
	  to a Web site and conduct business with affiliated but
	  separate Web sites. SAML can be used in business-to-business
	  and business-to-consumer transactions. </p><p>There are threes basic SAML components: assertions,
	  protocol, and binding. Assertions can be one of three types:
	  authentication, attribute, and authorization. Authentication
	  assertion validates the identity of the user. The attribute
	  assertion contains specific information about the
	  user. While, the authorization assertion identifies what the
	  user is authorized to do.</p><p>The protocol defines how SAML request and receives
	  assertions. There are several available binding for
	  SAML. There are bindings that define how SAML message
	  exchanges are mapped to SOAP, HTTP, SMTP and FTP among
	  others. The Organization for the Advancement of Structured
	  Information Standards (OASIS) is the body developing
	  SAML.</p></div><div class="div2">
<h3><a name="id2282920" id="id2282920"></a>B.5 XACML: Communicating Policy Information</h3><p>XACML is an Extensible Markup Language standard (XML) based
	  technology, developed by Organization for the Advancement of
	  Structured Information Standards (OASIS) for writing access
	  control polices for disparate devices and applications.</p><p>XACML includes an access control language and
	  request/response language that let developers write
	  policies that determine what users can access on a network
	  or over the Web. XACML can be used to connect disparate
	  access control policy engines.</p></div><div class="div2">
<h3><a name="id2282942" id="id2282942"></a>B.6 Identity Federation</h3><p>The Liberty Alliance is defining specifications dealing with various
aspects of identity.  Their phase 2 work is grouped into three
categories:  ID-FF, ID-WSF, and ID-SIS.</p><p>ID-FF (Identity Federation Framework) discusses how businesses or
organizations can be affiliated into circles of trust and trust
relationships. ID-FF includes several normative specifications, which in
turn make normative references to SAML.</p><p>ID-WSF (Identity Web Services Framework) is a set of specifications for
creating, discovering, using, and updating various aspects of identities
through a particular type of web service known as an Identity
Service.  ID-WSF builds on ID-FF.  A user (Principal) may register with
several Identity Services.  A prominent part of ID-WSF is a discovery
service for locating an Identity Service for a given user
(Principal).  ID-SWF also defines a Data Services Template.  ID-WSF has
also defined a draft specification for an approach to negotiating an
authentication method using SOAP messages to identify SASL mechanisms (RFC
2222).</p><p>Note that WS-Security specifically states that establishing a security
context or authentication mechanisms is outside its scope. ID-WSF may fill
this void.  However, WS-Security also defines a Username Token Profile,
which could be used as an authentication mechanism.  Potentially, Liberty
ID-WSF could be used to negotiate the use of WSS Username Token Profile as
the authentication mechanism.  Currently, WSS Username Token Profile is not
registered in IANA's SASL Mechanisms collection.</p><p>ID-SIS (Identity Service Instance Specifications) defines profiles for
particular types of Identity Services.  These profiles conform to the
ID-WSF Data Services Template.  Liberty has defined two such profiles.  The
Employee Profile (ID-SIS-EP) defines how to query and modify information
associated with a Principal in the context of their employer.  The Personal
Profile (ID-SIS-PP) defines how to query and modify identity information
for Principals themselves.</p></div></div><div class="div1">
<h2><a name="id2282999" id="id2282999"></a>C References (Non-Normative)</h2><dl><dt class="label"><a name="ANODC" id="ANODC"></a>Dist Comp</dt><dd><a href="http://research.sun.com/techrep/1994/abstract-29.html"><cite>A Note on Distributed Computing</cite>, S. C. Kendall, J. Waldo, A. Wollrath, G. Wyant, November 1994</a>  (See http://research.sun.com/techrep/1994/abstract-29.html.)</dd><dt class="label"><a name="fielding" id="fielding"></a>Fielding</dt><dd><a href="http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm"><cite>Architectural Styles and the Design of Network-based Software Architectures</cite>, PhD. Dissertation, R. Fielding, 2000</a>  (See http://www.ics.uci.edu/~fielding/pubs/dissertation/top.htm.)</dd><dt class="label"><a name="OWLO" id="OWLO"></a>OWLO</dt><dd><a href="http://www.w3.org/2004/02/wsa/"><cite>OWL Ontology of
	Web service architecture concepts</cite>, M. Paolucci,
	N. Srinivasan, K. Sycara</a>  (See http://www.w3.org/2004/02/wsa/.)</dd><dt class="label"><a name="RFC2396" id="RFC2396"></a>RFC 2396</dt><dd><a href="http://ietf.org/rfc/rfc2396.txt"><cite>Uniform Resource
	Identifiers (URI): Generic Syntax</cite>, IETF RFC 2396, T. Berners-Lee, R. Fielding, L. Masinter,
	August 1998</a>  (See http://ietf.org/rfc/rfc2396.txt.)</dd><dt class="label"><a name="soappart1" id="soappart1"></a>SOAP 1.2 Part 1</dt><dd><a href="http://www.w3.org/TR/2003/REC-soap12-part1-20030624/"><cite>SOAP Version 1.2
	Part 1: Messaging Framework</cite>, W3C Recommendation, M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Nielsen,
	24 June 2003</a>  (See http://www.w3.org/TR/2003/REC-soap12-part1-20030624/.)</dd><dt class="label"><a name="soappart2" id="soappart2"></a>SOAP 1.2 Part 2</dt><dd><a href="http://www.w3.org/TR/2003/REC-soap12-part2-20030624/"><cite>SOAP Version 1.2
	Part 2: Adjuncts</cite>, W3C Recommendation, M. Gudgin, M. Hadley, N. Mendelsohn, J-J. Moreau, H. Nielsen,
	24 June 2003</a>  (See http://www.w3.org/TR/2003/REC-soap12-part2-20030624/.)</dd><dt class="label"><a name="webarch" id="webarch"></a>Web Arch</dt><dd><a href="http://www.w3.org/TR/2003/WD-webarch-20031209/">
	  <cite>Architecture of the World Wide Web, First Edition</cite>,
	  W3C Working Draft, I. Jacobs, 9 December 2003
	</a>  (See http://www.w3.org/TR/2003/WD-webarch-20031209/.)</dd><dt class="label"><a name="WSAGLOSS" id="WSAGLOSS"></a>WS Glossary</dt><dd><a href="http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/"><cite>Web Services
	Glossary</cite>, W3C Working Group Note, H. Haas, A.Brown, 11
	Febuary 2004</a>  (See http://www.w3.org/TR/2004/NOTE-ws-gloss-20040211/.)</dd><dt class="label"><a name="WSAREQ" id="WSAREQ"></a>WSA Reqs</dt><dd><a href="http://www.w3.org/TR/2004/NOTE-wsa-reqs-20040211"><cite>Web Services
	Architecture Requirements</cite>, W3C Working Group Note,
	D. Austin, A. Barbir, C. Ferris, S. Garg, 11 February 2004</a>  (See http://www.w3.org/TR/2004/NOTE-wsa-reqs-20040211.)</dd><dt class="label"><a name="WSUS" id="WSUS"></a>WSAUS</dt><dd><a href="http://www.w3.org/TR/2004/NOTE-ws-arch-scenarios-20040211/"><cite>Web Services
	Architecture Usage Scenarios</cite>, W3C Working Group Note,
	H. He, H. Haas, D. Orchard, 11 February 2004</a>  (See http://www.w3.org/TR/2004/NOTE-ws-arch-scenarios-20040211/.)</dd><dt class="label"><a name="wsdl12" id="wsdl12"></a>WSDL 2.0 Part 1</dt><dd><a href="http://www.w3.org/TR/2003/WD-wsdl20-20031110/"><cite>Web Services Description Language (WSDL) Version 2.0 Part 1: Core Language</cite>,
	W3C Working Draft, R. Chinnici, M. Gudgin, J-J. Moreau, J. Schlimmer, S. Weerawarana, 10 November 2003</a>  (See http://www.w3.org/TR/2003/WD-wsdl20-20031110/.)</dd><dt class="label"><a name="xml10" id="xml10"></a>XML 1.0</dt><dd><a href="http://www.w3.org/TR/2000/REC-xml-20001006"><cite>Extensible Markup Language (XML) 1.0
	(Second Edition)</cite>, W3C Recommendation, T. Bray, J. Paoli, C.M. Sperberg-McQueen, E. Maler.
	6 October 2000</a>  (See http://www.w3.org/TR/2000/REC-xml-20001006.)</dd><dt class="label"><a name="infoset" id="infoset"></a>XML Infoset</dt><dd><a href="http://www.w3.org/TR/2001/REC-xml-infoset-20011024/"><cite>XML
	Information Set</cite>, W3C Recommendation, J. Cowan, R. Tobin, 24 October
	2001</a>  (See http://www.w3.org/TR/2001/REC-xml-infoset-20011024/.)</dd></dl></div><div class="div1">
<h2><a name="id2283417" id="id2283417"></a>D Acknowledgments (Non-Normative)</h2><p>This document has been produced by the <a href="http://www.w3.org/2002/ws/arch/">Web
          Services Architecture Working Group</a>
      .  The chairs of this Working Group were Chris Ferris (until July 2002), Michael Champion (starting July 2002) and Dave Hollander (starting July 2002).  The chairs also wish to thank the following (listed in alphabetic order) for their substantial contributions to the final documents:  Daniel Austin, Mark Baker, Abbie Barbir, David Booth, Martin Chapman, Ugo Corda, Roger Cutler, Paul Denning, Zulah Eckert, Chris Ferris, Hugo Haas, Hao He, Yin-Leng Husband, Mark Jones, Heather Kreger, Michael Mahan, Frank McCabe, Eric Newcomer, David Orchard, Katia Sycara.</p><p>

         Members of the Working Group are (at the time of writing, and in 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 Software, 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><p>The people who have contributed to discussions on the <a href="http://lists.w3.org/Archives/Public/www-ws-arch/">www-ws-arch
      public mailing list</a> are also gratefully acknowledged.</p></div></div></body></html>