ghopp
/
server_playground
1
0
Fork 0
Code Issues Pull Requests Projects Releases Wiki Activity
Another abandoned server code base... this is kind of an ancestor of taskrambler.
You can not select more than 25 topics Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
160 Commits
1 Branch
0 Tags
51 MiB
 
 
 
 
 
 
Tree: 2a98883031
Branches Tags
${ item.name }
Create tag ${ searchTerm }
Create branch ${ searchTerm }
from '2a98883031'
${ noResults }
server_playground/doc/www.w3.org/TR/2004/NOTE-ws-arch-scenarios-2004.../index.html

1926 lines
167 KiB
Raw Blame History

<?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 Usage Scenarios</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 Usage Scenarios</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-scenarios-20040211/">http://www.w3.org/TR/2004/NOTE-ws-arch-scenarios-20040211/</a>
</dd><dt>Latest version:</dt><dd>
<a href="http://www.w3.org/TR/ws-arch-scenarios/">
http://www.w3.org/TR/ws-arch-scenarios/</a>
</dd><dt>Previous version:</dt><dd>
<a href="http://www.w3.org/TR/2003/WD-ws-arch-scenarios-20030514/">http://www.w3.org/TR/2003/WD-ws-arch-scenarios-20030514/</a>
</dd><dt>Editors:</dt><dd>Hao He, Thomson Corporation</dd><dd>Hugo Haas (until May 2003), W3C</dd><dd>David Orchard (until May 2003), BEA Systems</dd></dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2004 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p></div><hr /><div>
<h2><a name="abstract" id="abstract"></a>Abstract</h2><p>This document describes the Web Service Architecture use cases and Usage
Scenarios.</p><p>It is a collection of use cases and usage scenarios which
illustrate the use of Web services. They are
used to generate requirements for the Web services architecture,
as well as to evaluate existing technologies.</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>. It has been
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>.</p><p>The document has been refactored since its previous version,
and this publication as a Working Group Note coincides with the
end of the Working Group's charter period.</p><p>Discussion of this document is invited on the public mailing
list <a href="mailto:www-ws-arch@w3.org">www-ws-arch@w3.org</a>
(<a href="http://lists.w3.org/Archives/Public/www-ws-arch/">public
archives</a>).</p><p>Patent disclosures relevant to this document 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="#intro">Introduction</a><br />
    1.1 <a href="#howtoread">How to read this document</a><br />
2 <a href="#uc">Use cases</a><br />
    2.1 <a href="#ta">Travel agent use case, static discovery</a><br />
        2.1.1 <a href="#Descriptio">Description</a><br />
        2.1.2 <a href="#Scope">Scope</a><br />
        2.1.3 <a href="#Stakeholder">Stakeholders / Interests</a><br />
        2.1.4 <a href="#Actors">Actors &amp; Goals</a><br />
        2.1.5 <a href="#Cases">Usage scenarios</a><br />
            2.1.5.1 <a href="#L109">User requests availabilities about some travel dates</a><br />
            2.1.5.2 <a href="#L156">User chooses flight and looks for hotels</a><br />
            2.1.5.3 <a href="#L212">User books hotel room and flight</a><br />
            2.1.5.4 <a href="#L309">Developer creates travel agent web service that queries for airline flights.</a><br />
            2.1.5.5 <a href="#Notes">Notes on the scenario</a><br />
    2.2 <a href="#tadd">Travel agent use case, dynamic discovery</a><br />
        2.2.1 <a href="#Description-dd">Description</a><br />
        2.2.2 <a href="#dd-Scope">Scope</a><br />
        2.2.3 <a href="#dd-Stakeholder">Stakeholders / Interests</a><br />
        2.2.4 <a href="#dd-Actors">Actors &amp; Goals</a><br />
        2.2.5 <a href="#dd-Cases">Usage scenarios</a><br />
            2.2.5.1 <a href="#L209">User requests availabilities about some travel dates</a><br />
            2.2.5.2 <a href="#L256">User chooses flight and looks for hotels</a><br />
            2.2.5.3 <a href="#L312">User books hotel room and flight</a><br />
            2.2.5.4 <a href="#id2270824">Notes on the scenario</a><br />
    2.3 <a href="#edi">EDI-like purchasing</a><br />
        2.3.1 <a href="#Descriptio1">Description</a><br />
        2.3.2 <a href="#Scope1">Scope</a><br />
        2.3.3 <a href="#Stakeholde1">Stakeholders / Interests</a><br />
        2.3.4 <a href="#Actors1">Actors &amp; Goals</a><br />
        2.3.5 <a href="#Cases1">Usage Scenarios</a><br />
            2.3.5.1 <a href="#L1091">Typical Widget Purchase</a><br />
            2.3.5.2 <a href="#L1561">Transaction Log Mismatch</a><br />
            2.3.5.3 <a href="#L212rc">SmallCo Incorrectly Thinks They Weren't Paid</a><br />
            2.3.5.4 <a href="#L213">SmallCo Really Wasn't Paid</a><br />
3 <a href="#description">Usage Scenarios</a><br />
    3.1 <a href="#S001">S001 Fire-and-forget to single receiver</a><br />
        3.1.1 <a href="#id2274071">Scenario Definition</a><br />
        3.1.2 <a href="#id2274651">Description</a><br />
    3.2 <a href="#S002">S002 Fire-and-forget to multiple receivers</a><br />
        3.2.1 <a href="#id2274727">Scenario Definition</a><br />
        3.2.2 <a href="#id2274740">Description</a><br />
    3.3 <a href="#S003">S003 Request/Response</a><br />
        3.3.1 <a href="#id2274806">Scenario Definition</a><br />
        3.3.2 <a href="#id2274827">Description</a><br />
    3.4 <a href="#S004">S004 Remote Procedure Call (RPC)</a><br />
        3.4.1 <a href="#id2274992">Scenario Definition</a><br />
        3.4.2 <a href="#id2275005">Description</a><br />
    3.5 <a href="#S006">S006 Multiple Faults </a><br />
        3.5.1 <a href="#id2275248">Scenario Definition</a><br />
        3.5.2 <a href="#id2275259">Description</a><br />
    3.6 <a href="#S010">S010 Request with acknowledgement</a><br />
        3.6.1 <a href="#id2275290">Scenario Definition</a><br />
        3.6.2 <a href="#id2275322">Description</a><br />
        3.6.3 <a href="#id2274543">WS-Arch WG Specific</a><br />
            3.6.3.1 <a href="#id2274549">Requirements</a><br />
            3.6.3.2 <a href="#id2274577">Non-requirements</a><br />
            3.6.3.3 <a href="#id2274606">Candidate Technologies</a><br />
        3.6.4 <a href="#id2274618">Use case citations</a><br />
    3.7 <a href="#S030">S030 Third party intermediary</a><br />
        3.7.1 <a href="#id2275677">Scenario Definition</a><br />
        3.7.2 <a href="#id2275693">Description</a><br />
    3.8 <a href="#S031">S031 Communication via multiple intermediaries</a><br />
        3.8.1 <a href="#id2275800">Scenario Definition</a><br />
        3.8.2 <a href="#id2275820">Description</a><br />
    3.9 <a href="#S032">S032 Caching</a><br />
        3.9.1 <a href="#id2275891">Scenario Definition</a><br />
        3.9.2 <a href="#id2275949">Description</a><br />
    3.10 <a href="#S035">S035 Routing</a><br />
        3.10.1 <a href="#id2276168">Scenario Definition</a><br />
        3.10.2 <a href="#id2276187">Description</a><br />
    3.11 <a href="#S036">S036 Tracking</a><br />
        3.11.1 <a href="#id2276215">Scenario Definition</a><br />
        3.11.2 <a href="#id2276232">Description</a><br />
    3.12 <a href="#S037">S037 Caching with expiration</a><br />
        3.12.1 <a href="#id2276353">Scenario Definition</a><br />
        3.12.2 <a href="#id2276367">Description</a><br />
    3.13 <a href="#S040">S040 Conversational message exchange</a><br />
        3.13.1 <a href="#id2276394">Scenario Definition</a><br />
        3.13.2 <a href="#id2276410">Description</a><br />
        3.13.3 <a href="#id2276592">WS-Arch WG Specific</a><br />
            3.13.3.1 <a href="#id2276598">Requirements</a><br />
            3.13.3.2 <a href="#id2276651">Non-requirements</a><br />
            3.13.3.3 <a href="#id2276677">Candidate Technologies</a><br />
        3.13.4 <a href="#id2276696">Use case citations</a><br />
    3.14 <a href="#S061">S061 Request with encrypted payload</a><br />
        3.14.1 <a href="#id2276720">Scenario Definition</a><br />
        3.14.2 <a href="#id2276744">Description</a><br />
        3.14.3 <a href="#id2276901">WS-Arch WG Specific</a><br />
            3.14.3.1 <a href="#id2276907">Requirements</a><br />
            3.14.3.2 <a href="#id2276938">Candidate Technologies</a><br />
        3.14.4 <a href="#id2276949">Use case citations</a><br />
    3.15 <a href="#S062">S062 Message header and payload encryption</a><br />
        3.15.1 <a href="#id2276980">Scenario Definition</a><br />
        3.15.2 <a href="#id2277008">Description</a><br />
        3.15.3 <a href="#id2277061">Use case citations</a><br />
    3.16 <a href="#S0621">S0621 Attachment encryption</a><br />
        3.16.1 <a href="#id2277091">Scenario Definition</a><br />
        3.16.2 <a href="#id2277114">Description</a><br />
        3.16.3 <a href="#id2277134">Use case citations</a><br />
    3.17 <a href="#S063">S063 Authentication </a><br />
        3.17.1 <a href="#id2277164">Scenario Definition</a><br />
        3.17.2 <a href="#id2277174">Description</a><br />
        3.17.3 <a href="#id2277183">WS-Arch WG Specific</a><br />
            3.17.3.1 <a href="#id2277189">Requirements</a><br />
            3.17.3.2 <a href="#id2277227">Candidate Technologies</a><br />
        3.17.4 <a href="#id2277238">Use case citations</a><br />
    3.18 <a href="#S064">S064 Message Integrity</a><br />
        3.18.1 <a href="#id2277267">Scenario Definition</a><br />
        3.18.2 <a href="#id2277281">Description</a><br />
        3.18.3 <a href="#id2277289">WS-Arch WG Specific</a><br />
            3.18.3.1 <a href="#id2277295">Requirements</a><br />
            3.18.3.2 <a href="#id2277319">Candidate Technologies</a><br />
    3.19 <a href="#S065">S065 Authentication of data</a><br />
        3.19.1 <a href="#id2277342">Scenario Definition</a><br />
        3.19.2 <a href="#id2277355">Description</a><br />
        3.19.3 <a href="#id2277384">WS-Arch WG Specific</a><br />
            3.19.3.1 <a href="#id2277390">Requirements</a><br />
            3.19.3.2 <a href="#id2277415">Non-requirements</a><br />
            3.19.3.3 <a href="#id2277422">Candidate Technologies</a><br />
        3.19.4 <a href="#id2277432">Use case citations</a><br />
    3.20 <a href="#S070">S070 Asynchronous messaging</a><br />
        3.20.1 <a href="#id2277467">Scenario Definition</a><br />
        3.20.2 <a href="#id2277484">Description</a><br />
        3.20.3 <a href="#id2277593">WS-Arch WG Specific</a><br />
            3.20.3.1 <a href="#id2277599">Requirements</a><br />
            3.20.3.2 <a href="#id2277643">Candidate Technologies</a><br />
        3.20.4 <a href="#id2277661">Use case citations</a><br />
    3.21 <a href="#S072">S072 Multiple asynchronous responses</a><br />
        3.21.1 <a href="#id2277684">Scenario Definition</a><br />
        3.21.2 <a href="#id2277699">Description</a><br />
    3.22 <a href="#S080">S080 Transaction</a><br />
        3.22.1 <a href="#id2277856">Scenario Definition</a><br />
        3.22.2 <a href="#id2277866">Description</a><br />
        3.22.3 <a href="#id2277875">WS-Arch WG Specific</a><br />
            3.22.3.1 <a href="#id2277881">Candidate Technologies</a><br />
        3.22.4 <a href="#id2277892">Use case citations</a><br />
    3.23 <a href="#S090">S090 Sending non-XML data</a><br />
        3.23.1 <a href="#id2277915">Scenario Definition</a><br />
        3.23.2 <a href="#id2277932">Description</a><br />
        3.23.3 <a href="#id2278103">WS-Arch WG Specific</a><br />
            3.23.3.1 <a href="#id2278109">Candidate Technologies</a><br />
        3.23.4 <a href="#id2278120">Use case citations</a><br />
    3.24 <a href="#S200">S200 Event notification</a><br />
        3.24.1 <a href="#id2278144">Scenario Definition</a><br />
        3.24.2 <a href="#id2278163">Description</a><br />
    3.25 <a href="#S300">S300 System Messages</a><br />
        3.25.1 <a href="#id2278342">Scenario Definition</a><br />
        3.25.2 <a href="#id2278355">Description</a><br />
        3.25.3 <a href="#id2278371">WS-Arch WG Specific</a><br />
            3.25.3.1 <a href="#id2278377">Requirements</a><br />
            3.25.3.2 <a href="#id2278408">Non-requirements</a><br />
            3.25.3.3 <a href="#id2278415">Candidate Technologies</a><br />
    3.26 <a href="#S500">S500 Service Metadata </a><br />
        3.26.1 <a href="#id2278438">Scenario Definition</a><br />
        3.26.2 <a href="#id2278449">Description</a><br />
        3.26.3 <a href="#id2278476">WS-Arch WG Specific</a><br />
            3.26.3.1 <a href="#id2278481">Requirements</a><br />
            3.26.3.2 <a href="#id2278506">Non-requirements</a><br />
    3.27 <a href="#S501">S501 Service Level attributes</a><br />
        3.27.1 <a href="#id2278525">Scenario Definition</a><br />
        3.27.2 <a href="#id2278535">Description</a><br />
        3.27.3 <a href="#id2278564">WS-Arch WG Specific</a><br />
            3.27.3.1 <a href="#id2278569">Requirements</a><br />
            3.27.3.2 <a href="#id2278576">Non-requirements</a><br />
    3.28 <a href="#S502">S502 Operation Level attributes </a><br />
        3.28.1 <a href="#id2278595">Scenario Definition</a><br />
        3.28.2 <a href="#id2278606">Description</a><br />
        3.28.3 <a href="#id2278625">WS-Arch WG Specific</a><br />
            3.28.3.1 <a href="#id2278631">Requirements</a><br />
            3.28.3.2 <a href="#id2278638">Non-requirements</a><br />
    3.29 <a href="#S504">S504 Versioning</a><br />
        3.29.1 <a href="#id2278656">Scenario Definition</a><br />
        3.29.2 <a href="#id2278667">Description</a><br />
        3.29.3 <a href="#id2278686">WS-Arch WG Specific</a><br />
            3.29.3.1 <a href="#id2278692">Requirements</a><br />
            3.29.3.2 <a href="#id2278699">Non-requirements</a><br />
    3.30 <a href="#S505">S505 Classification system for operations</a><br />
        3.30.1 <a href="#id2278717">Scenario Definition</a><br />
        3.30.2 <a href="#id2278726">Description</a><br />
        3.30.3 <a href="#id2278802">WS-Arch WG Specific</a><br />
            3.30.3.1 <a href="#id2278808">Requirements</a><br />
            3.30.3.2 <a href="#id2278814">Non-requirements</a><br />
    3.31 <a href="#S510">S510 Quality of service</a><br />
        3.31.1 <a href="#id2278833">Scenario Definition</a><br />
        3.31.2 <a href="#id2278852">Description</a><br />
    3.32 <a href="#S600">S600 Address based Discovery </a><br />
        3.32.1 <a href="#id2278994">Scenario Definition</a><br />
        3.32.2 <a href="#id2279006">Description</a><br />
        3.32.3 <a href="#id2279030">WS-Arch WG Specific</a><br />
            3.32.3.1 <a href="#id2279036">Requirements</a><br />
            3.32.3.2 <a href="#id2279054">Non-requirements</a><br />
            3.32.3.3 <a href="#id2279061">Candidate Technologies</a><br />
        3.32.4 <a href="#id2279071">Use case citations</a><br />
    3.33 <a href="#S601">S601 Registry based discovery</a><br />
        3.33.1 <a href="#id2279097">Scenario Definition</a><br />
        3.33.2 <a href="#id2279108">Description</a><br />
        3.33.3 <a href="#id2279117">WS-Arch WG Specific</a><br />
            3.33.3.1 <a href="#id2279122">Requirements</a><br />
            3.33.3.2 <a href="#id2279155">Non-requirements</a><br />
            3.33.3.3 <a href="#id2279162">Candidate Technologies</a><br />
    3.34 <a href="#S602">S602 Management Capability Discovery</a><br />
        3.34.1 <a href="#id2279185">Scenario Definition</a><br />
        3.34.2 <a href="#id2279198">Description</a><br />
4 <a href="#id2283177">References</a><br />
</p>
<h3><a name="appendices" id="appendices"></a>Appendix</h3><p class="toc">A <a href="#id2283348">Acknowledgments</a> (Non-Normative)<br />
</p></div><hr /><div class="body"><div class="div1">
<h2><a name="intro" id="intro"></a>1 Introduction</h2><p>This document specifies a variety of Web services use cases and usage
scenarios. In the context of Web services, a use case is a sequence of interactions between a service requestor and one
or more services, which achieve measurable results for the requestor.
Highlighting either architectural or technical significance, a usage scenario represents an atomic step in
a path through a use case. By combining and adopting different usage scenarios, one can thus produce different paths for the
same use case. Use cases described in this document usually have paths for illustrative purpose and may include more scenarios than
necessary in real implementation. </p><div class="div2">
<h3><a name="howtoread" id="howtoread"></a>1.1 How to read this document</h3><p>A reader may start with a use case that he or she is most familiar with. Attention should be brought to technical problems
raised in the use case and how they are addressed in various scenarios. </p><p>The usage scenarios within use cases all follow a common template: the "Goal/Context"introduces the purpose of the usage scenario; the "Scenario/Steps" explains the typical operation of the scenario; the "Extensions" presents variations on the scenario (typically involving failure modes or exceptions); and the "Technologies/Requirements" explains what is needed to implement the scenario.</p><p>Usage scenarios should be read under the context of a use case. They are useful as references when deciding
the actual path in a use case. For this purpose, extensive cross links between use cases and scenarios have been built.
</p></div></div><div class="div1">
<h2><a name="uc" id="uc"></a>2 Use cases</h2><p>This section contains use cases giving more context to
some of the individual usage scenarios listed in <a href="#description"><b>3 Usage Scenarios</b></a>.</p><div class="div2">
<h3><a name="ta" id="ta"></a>2.1 Travel agent use case, static discovery</h3><div class="div3">
<h4><a name="Descriptio" id="Descriptio"></a>2.1.1 Description</h4><p>A company (travel agent) wants to offer the ability to book
complete vacation packages: plane/train/bus tickets, hotels, car rental,
excursions, etc.</p><p>Service providers (airlines, bus companies, hotel chains, etc) are
providing Web services to query their offerings and perform reservations.</p><p>Credit card companies are providing services to guarantee payments
made by consumers.</p><p>This use case assumes that the discovery of the specific service providers and metadata happens prior to the invocation, and that a developer uses the description to create the web service invocation.
This could be considered a "static" use case. By contrast, in a "dynamic" use case, the discovery of the specific service providers and metadata, and the subsequent web service invocation are performed by software agents at run time, see also <a href="#tadd"><b>2.2 Travel agent use case, dynamic discovery</b></a>.
</p></div><div class="div3">
<h4><a name="Scope" id="Scope"></a>2.1.2 Scope</h4><p>For this version of the usage scenario, we will limit ourselves to booking
of vacation packages. We will assume that cancellation is not possible once a
package has been purchased.</p></div><div class="div3">
<h4><a name="Stakeholder" id="Stakeholder"></a>2.1.3 Stakeholders / Interests</h4><p>The travel agent provides a system to provide the user with options for
his/her vacation and earns money by charging fees for each package bought.</p><p>Service providers (hotels, airlines) sell their services
by making them available widely using Web services.</p><p>Credit card companies enable customers to use their credit cards in a very
large number of cases by making payment Web services available and make profit with each money transaction.</p><p>The consumer books a vacation easily by choosing among a large variety of
offers.</p><p>Only the user in the scenario is a human being. The travel agent service,
airline, hotel and payment services that the travel agent service is
interacting with, are machines. </p></div><div class="div3">
<h4><a name="Actors" id="Actors"></a>2.1.4 Actors &amp; Goals</h4><p>The goal of the consumer is to get the best combination of services and prices suiting his/her needs.</p><p>The travel agent tries to provide customer satisfaction and sell packages.</p><p>The service providers are aiming at selling as many
products as possible.</p><p>The credit card companies guarantee and do the payments of
the purchased products.</p><p>Developers use WSDL and platforms to create instances of web services.</p></div><div class="div3">
<h4><a name="Cases" id="Cases"></a>2.1.5 Usage scenarios</h4><p>The following usage scenarios describe how a user would make a reservation for a
vacation package (flight and hotel room), and how a developer would create a portion of a service.</p><div class="figure"><a name="ta-over-stat" id="ta-over-stat"></a><br /><img src="ta.png" alt="Overview of the travel agent use case" /><p><i><span>Figure 2-1. </span>Overview of the travel agent use case</i></p><br /></div><p>It has to be noted that some additional technology is or may be needed for this
usage scenario:</p><ul><li><p>context maintenance.</p></li><li><p>reliability: in order to make money, each step needs to happen.</p></li><li><p>trust mechanisms for the services to do business with each other.</p></li><li><p>description of choreography of services: if a reservation of a flight
involves interacting with a couple of Web services, the airline would
document in a machine readable way how to interact with the two single
services in order to get the desired result, including how to handle
errors if the process fails before the operation is completed.</p></li><li><p>transactions: either compensating or atomic transactions may make the implementation of the reservation be of higher quality.
</p></li><li><p>...</p></li></ul><p>Note that this usage scenario could be different in the following ways:</p><ul><li><p>the user could have bought some travel agent software; the travel agent
service could reside locally on his/her computer.</p></li><li><p>the user could write tools to interact directly with the airline and
hotel services.</p></li></ul><p>The WSDL for most of the interactions are in the <a href="http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/wsdl12/wsdl12-primer.html">WSDL Primer</a>
</p><div class="div4">
<h5><a name="L109" id="L109"></a>2.1.5.1 User requests availabilities about some travel dates</h5><div class="div5">
<h6><a name="Goal" id="Goal"></a>2.1.5.1.1 Goal / Context</h6><p>The user has the location of a travel agent service. </p><p>The user provides a destination and some dates to the travel agent
service. The travel agent service inquires airlines about deals and presents
them to the user.</p></div><div class="div5">
<h6><a name="Scenario" id="Scenario"></a>2.1.5.1.2 Scenario / Steps</h6><ol type="1"><li><p>The user is presented with a form to fill in order to provide the
travel agent service with details about dates of his/her travel and the
destination.</p></li><li><p>The user submits the information to the service in order to get a list
of flights corresponding to his/her schedule.</p></li><li><p>The travel agent service finds a list of flights from each service it has in its catalogue.</p></li><li><p>For each airline:</p><ol type="a"><li><p>The travel agent service requests a list of flights accommodating
the user.</p></li></ol></li><li><p>The travel agent service presents the results of the queries to the
user letting him choose the best option.</p></li></ol></div><div class="div5">
<h6><a name="Extensions" id="Extensions"></a>2.1.5.1.3 Extensions</h6><p>If no flight can be found, the user should be presented with an error.</p></div><div class="div5">
<h6><a name="Technologi" id="Technologi"></a>2.1.5.1.4 Technologies / Requirements</h6><p>Response to queries: XML documents that the travel agent service processes
and merges together.</p></div></div><div class="div4">
<h5><a name="L156" id="L156"></a>2.1.5.2 User chooses flight and looks for hotels</h5><div class="div5">
<h6><a name="Goal1" id="Goal1"></a>2.1.5.2.1 Goal / Context</h6><p>The user has been presented with options for flights to go to his/her
destination. The user chooses a preferred flight. The service puts the seats
on hold, and goes on with proposing lodging options to the user.</p></div><div class="div5">
<h6><a name="Scenario1" id="Scenario1"></a>2.1.5.2.2 Scenario / Steps</h6><ol type="1"><li><p>The user communicates his/her choice for the flight.</p></li><li><p>The travel agent service requests the chosen airline to put the flight
on hold:</p><ol type="a"><li><p>The travel agent service sends the request accordingly.</p></li></ol></li><li><p>The airline returns a confirmation identifier with an expiry date.</p></li><li><p>The travel agent service searches its catalogue of hotels</p></li><li><p>For each hotel found:</p><ol type="a"><li><p>The travel agent service requests accommodation options for the
period.</p></li></ol></li><li><p>The travel agent service looks for payment services available, and
builds a list of options for the user.</p></li><li><p>The travel agent service presents the results of the queries to the
user letting him choose the best option, along with the payment options
offered.</p></li></ol></div><div class="div5">
<h6><a name="Extensions1" id="Extensions1"></a>2.1.5.2.3 Extensions</h6><p>If the seats chosen are not available anymore, the travel agent service
presents the user with an error message and the user is presented with an
updated list of available flights to choose from.</p></div><div class="div5">
<h6><a name="Technologi1" id="Technologi1"></a>2.1.5.2.4 Technologies / Requirements</h6></div></div><div class="div4">
<h5><a name="L212" id="L212"></a>2.1.5.3 User books hotel room and flight</h5><div class="div5">
<h6><a name="Goal2" id="Goal2"></a>2.1.5.3.1 Goal / Context</h6><p>The user has been presented with options for hotels to go to his/her
destination and a means of payment. The user chooses a hotel option. The
travel agent service contacts a payment service for payment authorization. The service
books the hotel and confirms the flight, using the payment authorization from
the payment service (i.e. a credit card company).</p></div><div class="div5">
<h6><a name="Scenario2" id="Scenario2"></a>2.1.5.3.2 Scenario / Steps</h6><ol type="1"><li><p>The user communicates his/her accommodation choice to the travel agent
service.</p></li><li><p>The travel agent service contacts the payment service that the user chose
to confirm payment:</p><ol type="a"><li><p>The travel agent service requests a description of how to guarantee
payment of the total amount.</p></li><li><p>The travel agent service sends the request accordingly.</p></li><li><p>The response indicates success with an authorization identifier, signed
by the payment authority.</p></li></ol></li><li><p>The travel agent service books the hotel room:</p><ol type="a"><li><p>The travel agent service sends a request in order to find out how
to cancel the reservation should a problem occur later in the
process.</p></li><li><p>The travel agent service sends the
request accordingly, along with a payment authorization
identifier from the payment service.</p></li></ol></li><li><p>The travel agent service confirms the flight reservation:</p><ol type="a"><li><p>The travel agent service sends the
request to buy a ticket on hold, along with a payment authorization
identifier from the payment service.</p></li></ol></li><li><p>The travel agent service charges a fee to the user:</p><ol type="a"><li><p>The travel agent service sends the request to the payment service, along with
the authorization identifier signed by the payment service.</p></li></ol></li><li><p>The service provides the user with various confirmation identifiers and
wishes the user a good vacation.</p></li></ol><p>When the travel agent service communicates a proof of
payment authorization to the hotel and airline services,
the message should carry some proof that the
authorization token is indeed coming from a payment
service (see <a href="#S065"><b>3.19 S065 Authentication of data</b></a>). </p><p>Communication with the payment service will
requires confidentiality, which can be achieved with
encryption technologies (e.g. <a href="#S061"><b>3.14 S061 Request with encrypted payload</b></a>,
<a href="#S062"><b>3.15 S062 Message header and payload encryption</b></a> and <a href="#S0621"><b>3.16 S0621 Attachment encryption</b></a>).</p><p>Communication with the payment service could require the image of a signature, aka a binary attachment, using
attachments technologies (e.g. <a href="#S090"><b>3.23 S090 Sending non-XML data</b></a>).</p><p>Communication with the payment service should be delivered exactly once, using
reliable messaging technologies (e.g. <a href="#S010"><b>3.6 S010 Request with acknowledgement</b></a>).</p><p>Communication with the payment service and the hotel reservation could be under transactional control, which can be achieved with
transaction technologies (e.g. <a href="#S080"><b>3.22 S080 Transaction</b></a>).</p></div><div class="div5">
<h6><a name="Extensions2" id="Extensions2"></a>2.1.5.3.3 Extensions</h6><p>If the payment service doesn't confirm the validity of the user's payment
option, the user should be presented with an error.</p><p>If the hotel room cannot be booked, the user should be presented with an
error and should get to choose from an updated list of options.</p><p>If the flight reservation cannot be confirmed, the hotel room reservation
should be canceled and the user should be presented with an error and start
the reservation process again.</p></div><div class="div5">
<h6><a name="Technologi2" id="Technologi2"></a>2.1.5.3.4 Technologies / Requirements</h6><p>Authentication technology: used by the payment authority to sign the
payment authorization to be trusted by the hotel service, the airline service
and the travel agent service.</p><p>Encryption technology: used by the payment service and the travel agent
service to communicate the user's payment information confidentially.</p></div></div><div class="div4">
<h5><a name="L309" id="L309"></a>2.1.5.4 Developer creates travel agent web service that queries for airline flights.</h5><div class="div5">
<h6><a name="DescriptionGoal" id="DescriptionGoal"></a>2.1.5.4.1 Goal / Context</h6><p>The developer has a URI, which identifies an airline service</p><p>The user provides a destination and some dates to the travel agent
service. The travel agent service inquires airlines about deals and presents
them to the user.</p></div><div class="div5">
<h6><a name="DescriptionScenario" id="DescriptionScenario"></a>2.1.5.4.2 Scenario / Steps</h6><ol type="1"><li><p>The developer uses the identifier to retrieve a WSDL, (e.g. <a href="#S600"><b>3.32 S600 Address based Discovery </b></a>). </p></li><li><p>The developer creates an implementation of the service based upon the WSDL</p></li><li><p>The developer tests the implementation</p></li><li><p>The developer deploys the implementation at the travel agent server</p></li></ol></div></div><div class="div4">
<h5><a name="Notes" id="Notes"></a>2.1.5.5 Notes on the scenario</h5><p>This scenario illustrates how a program, the travel agent service, can
interact with airline services, hotel services, with prior
knowledge of them and of the way they work.</p></div></div></div><div class="div2">
<h3><a name="tadd" id="tadd"></a>2.2 Travel agent use case, dynamic discovery</h3><p>This use case,in which the description of the services is discovered at run time, is variation of the <a href="#ta"><b>2.1 Travel agent use case, static discovery</b></a>.</p><div class="div3">
<h4><a name="Description-dd" id="Description-dd"></a>2.2.1 Description</h4><p>A company (travel agent) wants to offer to people the ability to book
complete vacation packages: plane/train/bus tickets, hotels, car rental,
excursions, etc.</p><p>Service providers (airlines, bus companies, hotel chains, etc) are
providing Web services to query their offerings and perform reservations.</p><p>Credit card companies are also providing services to guarantee payments
made by consumers.</p><p>Due to the loosely coupled-nature of Web services, the travel agent
doesn't need to have a priori agreements with service providers or credit
card companies. This allows the travel agent to have access to more services,
offering more options to its customers, the credit card companies to offer
their services broadly and therefore make their customers happy, and the
service providers can offer their services broadly and easily and therefore
generating more business for themselves.</p></div><div class="div3">
<h4><a name="dd-Scope" id="dd-Scope"></a>2.2.2 Scope</h4><p>Same as <a href="#Scope"><b>2.1.2 Scope</b></a></p></div><div class="div3">
<h4><a name="dd-Stakeholder" id="dd-Stakeholder"></a>2.2.3 Stakeholders / Interests</h4><p>Same as <a href="#Stakeholder"><b>2.1.3 Stakeholders / Interests</b></a></p></div><div class="div3">
<h4><a name="dd-Actors" id="dd-Actors"></a>2.2.4 Actors &amp; Goals</h4><p>Same as <a href="#Actors"><b>2.1.4 Actors &amp; Goals</b></a></p></div><div class="div3">
<h4><a name="dd-Cases" id="dd-Cases"></a>2.2.5 Usage scenarios</h4><p>Same as <a href="#Cases"><b>2.1.5 Usage scenarios</b></a></p><div class="figure"><a name="ta-over-dyn" id="ta-over-dyn"></a><br /><img src="ta.png" alt="Overview of the travel agent use case" /><p><i><span>Figure 2-2. </span>Overview of the travel agent use case</i></p><br /></div><div class="figure"><a name="ta-onto" id="ta-onto"></a><br /><img src="exa1.png" alt="Use of common concepts in the dynamic travel agent use case" /><p><i><span>Figure 2-3. </span>Use of common concepts in the dynamic travel agent use case</i></p><br /></div><p>It has to be noted that some additional technology is needed for this
usage scenario:</p><ul><li><p>context maintenance.</p></li><li><p>reliability: in order to make money, each step needs to happen.</p></li><li><p>trust mechanisms for the services to do business with each other.</p></li><li><p>description of choreography of services: if a reservation of a flight
involves interacting with a couple of Web services, the airline would
document in a machine readable way how to interact with the two single
services in order to get the desired result, including how to handle
errors if the process fails before the operation is completed.</p></li><li><p>...</p></li></ul><p>Note that this usage scenario could be different in the following ways:</p><ul><li><p>the user could have bought some travel agent software; the travel agent
service could reside locally on his/her computer.</p></li><li><p>the user could write tools to interact directly with the airline and
hotel services.</p></li></ul><div class="div4">
<h5><a name="L209" id="L209"></a>2.2.5.1 User requests availabilities about some travel dates</h5><div class="div5">
<h6><a name="l209-Goal" id="l209-Goal"></a>2.2.5.1.1 Goal / Context</h6><p>The user gets the location of a travel agent service via an unspecified
way (search engine, URI in an email, service directory, etc).</p><p>The user provides a destination and some dates to the travel agent
service. The travel agent service inquires airlines about deals and presents
them to the user.</p></div><div class="div5">
<h6><a name="L209-Scenario" id="L209-Scenario"></a>2.2.5.1.2 Scenario / Steps</h6><ol type="1"><li><p>The user is presented with a form to fill in order to provide the
travel agent service with details about dates of his/her travel and the
destination.</p></li><li><p>The user submits the information to the service in order to get a list
of flights corresponding to his/her schedule.</p></li><li><p>The travel agent service finds a list of airlines.</p></li><li><p>For each airline found:</p><ol type="a"><li><p>The travel agent service requests a description of how to
communicate with the service found.</p></li><li><p>The travel agent service requests a list of flights accommodating
the user.</p></li></ol></li><li><p>The travel agent service presents the results of the queries to the
user letting him choose the best option.</p></li></ol></div><div class="div5">
<h6><a name="L209-Extensions" id="L209-Extensions"></a>2.2.5.1.3 Extensions</h6><p>If no flight can be found, the user should be presented with an error.</p></div><div class="div5">
<h6><a name="L209-Technologi" id="L209-Technologi"></a>2.2.5.1.4 Technologies / Requirements</h6><p>Discovery technology: used by the travel agent service to find the
airlines services.</p><p>Description language: used by the airlines to describe their query
services to the travel agent service.</p><p>Response to queries: XML documents that the travel agent service processes
and merge together.</p><p>Ontologies: the data coming from different airline services and expressed
with different XML vocabularies needs some semantics to be merged in a
meaningful way.</p></div></div><div class="div4">
<h5><a name="L256" id="L256"></a>2.2.5.2 User chooses flight and looks for hotels</h5><div class="div5">
<h6><a name="L256-Goal1" id="L256-Goal1"></a>2.2.5.2.1 Goal / Context</h6><p>The user has been presented with options for flights to go to his/her
destination. The user chooses a preferred flight. The service puts the seats
on hold, and goes on with proposing lodging options to the user.</p></div><div class="div5">
<h6><a name="L256-Scenario1" id="L256-Scenario1"></a>2.2.5.2.2 Scenario / Steps</h6><ol type="1"><li><p>The user communicates his/her choice for the flight.</p></li><li><p>The travel agent service requests the chosen airline to put the flight
on hold:</p><ol type="a"><li><p>The travel agent service requests a description of how to put a
seat on hold to the airline service.</p></li><li><p>The travel agent service sends the request accordingly.</p></li></ol></li><li><p>The airline returns a confirmation identifier with an expiry date.</p></li><li><p>The travel agent service finds a list of hotels.</p></li><li><p>For each hotel found:</p><ol type="a"><li><p>The travel agent service requests a description of how to
communicate with the service found.</p></li><li><p>The travel agent service requests accommodation options for the
period.</p></li></ol></li><li><p>The travel agent service looks for payment services available, and
builds a list of options for the user.</p></li><li><p>The travel agent service presents the results of the queries to the
user letting him choose the best option, along with the payment options
offered.</p></li></ol></div><div class="div5">
<h6><a name="id2270476" id="id2270476"></a>2.2.5.2.3 Extensions</h6><p>If the seats chosen are not available anymore, the travel agent service
presents the user with an error message and the user is presented with an
updated list of available flights to choose from.</p></div><div class="div5">
<h6><a name="id2270489" id="id2270489"></a>2.2.5.2.4 Technologies / Requirements</h6><p>Description language: used by the airlines to describe their services to
put tickets on hold to the travel agent service, by the hotels to describe
their query services to the travel agent service.</p><p>Discovery technology: used by the travel agent service to find the hotels
services.</p><p>Ontologies: the data coming from different accommodation services and
expressed with different XML vocabularies needs some semantics to be merged
in a meaningful way.</p></div></div><div class="div4">
<h5><a name="L312" id="L312"></a>2.2.5.3 User books hotel room and flight</h5><div class="div5">
<h6><a name="L312-Goal2" id="L312-Goal2"></a>2.2.5.3.1 Goal / Context</h6><p>The user has been presented with options for hotels to go to his/her
destination and a means of payment. The user chooses a hotel option. The
travel agent service contacts a payment service for payment authorization. The service
books the hotel and confirms the flight, using the payment authorization from
the payment service (i.e. a credit card company).</p></div><div class="div5">
<h6><a name="L312-Scenario2" id="L312-Scenario2"></a>2.2.5.3.2 Scenario / Steps</h6><ol type="1"><li><p>The user communicates his/her accommodation choice to the travel agent
service.</p></li><li><p>The travel agent service contacts the payment service that the user chose
to confirm payment:</p><ol type="a"><li><p>The travel agent service requests a description of how to guarantee
payment of the total amount.</p></li><li><p>The travel agent service send the request accordingly.</p></li><li><p>The response indicates success with an authorization identifier, signed
by the payment authority.</p></li></ol></li><li><p>The travel agent service books the hotel room:</p><ol type="a"><li><p>The travel agent service requests a description of how to book a
room to the chosen hotel service.</p></li><li><p>The travel agent service sends a request in order to find out how
to cancel the reservation should a problem occur later in the
process.</p></li><li><p>The travel agent service sends the
request accordingly, along with a payment authorization
identifier from the payment service.</p></li></ol></li><li><p>The travel agent service confirms the flight reservation:</p><ol type="a"><li><p>The travel agent service requests a description of how to buy a
ticket on hold to the airline service.</p></li><li><p>The travel agent service sends a request in order to find out how
to cancel the reservation should a problem occur later in the
process.</p></li><li><p>The travel agent service sends the
request accordingly, along with a payment authorization
identifier from the payment service.</p></li></ol></li><li><p>The travel agent service charges a fee to the user: </p><ol type="a"><li><p>The travel agent service requests a description of how to request
payment to the payment service.</p></li><li><p>The travel agent service sends the request accordingly, along with
the authorization identifier signed by the payment service.</p></li></ol></li><li><p>The service provides the user with various confirmation identifiers and
wishes the user a good vacation.</p></li></ol><p>When the travel agent service communicates a proof of
payment authorization to the hotel and airline services,
the message should carry some proof that the
authorization token is indeed coming from a payment
service (see <a href="#S065"><b>3.19 S065 Authentication of data</b></a>).</p><p>Also, communication with the payment service will
requires confidentiality, which can be achieved with
encryption technologies (e.g. <a href="#S061"><b>3.14 S061 Request with encrypted payload</b></a>,
<a href="#S062"><b>3.15 S062 Message header and payload encryption</b></a> and <a href="#S0621"><b>3.16 S0621 Attachment encryption</b></a>).</p><div class="figure"><a name="ta-trans" id="ta-trans"></a><br /><img src="exa2.png" alt="Overview of the transactions" /><p><i><span>Figure 2-4. </span>Overview of the transactions</i></p><br /></div></div><div class="div5">
<h6><a name="id2270765" id="id2270765"></a>2.2.5.3.3 Extensions</h6><p>If the payment service doesn't confirm the validity of the user's payment
option, the user should be presented with an error.</p><p>If the hotel room cannot be booked, the user should be presented with an
error and should get to choose from an updated list of options.</p><p>If the flight reservation cannot be confirmed, the hotel room reservation
should be canceled and the user should be presented with an error and start
the reservation process again.</p></div><div class="div5">
<h6><a name="id2270790" id="id2270790"></a>2.2.5.3.4 Technologies / Requirements</h6><p>Service description technology: used by the payment authority to describe
its confirmation service, by the hotel to describe its room booking service,
and by the airline to describe its service to buy tickets by confirming seats
on hold.</p><p>Authentication technology: used by the payment authority to sign the
payment authorization to be trusted by the hotel service, the airline service
and the travel agent service.</p><p>Encryption technology: used by the payment service and the travel agent
service to communicate the user's payment information confidentially.</p><p>Ontologies: the payment confirmation needs to be used in a way meaningful
to the travel service, hotel and airline services; in other words, the output
of one service needs to be used as the input to other services that might use
different vocabularies.</p></div></div><div class="div4">
<h5><a name="id2270824" id="id2270824"></a>2.2.5.4 Notes on the scenario</h5><p>This scenario illustrates how a program, the travel agent service, can
interact dynamically with airline services, hotel services, without a priori
knowledge of them or of the way they work. Thanks to the ontologies used, the
program can adapt to variations of formats that an airline service might be
using and adapt to the introduction of new products.</p><p>However, there is a limit to what the travel agent service can understand.
For example, it is likely to be able to understand the introduction of a new
class of tickets, say class Z. However, if the restrictions on class Z
tickets use concepts that it is not aware of (say that class Z tickets can
only be bought more than 60 days in advance and with a valid international
student identification), the developers of the travel agent service will need
to implement the extra logic to make it understand this new type of
restriction, including validating the student identification.</p></div></div></div><div class="div2">
<h3><a name="edi" id="edi"></a>2.3 EDI-like purchasing</h3><div class="div3">
<h4><a name="Descriptio1" id="Descriptio1"></a>2.3.1 Description</h4><p>A large company (BigCo) wants to purchase widgets from a small
widget manufacturer (SmallCo) using web services to transmit the
various documents (e.g. purchase orders and invoices) involved.
There are web services set up at both BigCo and SmallCo that handle
the document transmissions required to implement an
industry-specific business process which has been defined by an
industry-vertical standards body (e.g. ComProServ from <a href="http://www.api.org/faeb/pidx/">PIDX</a>, a protocol for
obtaining oil field services). In addition to the documents
involved in this business process there are payments sent through a
different financial service.</p><p>BigCo and SmallCo set up a trading relationship in which web
services provide functions similar to those offered in a
proprietary setting by EDI VAN's (Value Added Networks).</p></div><div class="div3">
<h4><a name="Scope1" id="Scope1"></a>2.3.2 Scope</h4><p>The focus of this use case is the technical infrastructure
required to implement the business processes, not the business
processes themselves. In this example we will assume that BigCo and
SmallCo have already set up their trading relationship. How they
found each other and made the agreement to trade with each other is
beyond the scope of this example. Payments in this example are sent
through financial institutions and involve electronic processes
beyond the scope of this example (because it is beyond the scope of the EDI people whose experience forms the basis of this use case). Opinions may differ about what aspects of the requirements belong in Web Services "technical infrastructure" and which belong in "business process". For example, we think that unique ID and timedate stamping of the messages should be "infrastructure" but that sequencing of the messages belongs in "business process". These issues are discussed as they arise below.</p></div><div class="div3">
<h4><a name="Stakeholde1" id="Stakeholde1"></a>2.3.3 Stakeholders / Interests</h4><p>BigCo purchases widgets, both via EDI provided by a VAN and via web services as described in this
use case. BigCo uses big software packages internally. For example,
financials and business information are handled by an ERP system, and there is an eProcurement front end (perhaps
from a different provider) that implements the
purchasing logic. Connectivity and data transport within the
company are provided by an EAI system. BigCo's primary motivations in this activity are cost
control, reliability and security. Automated processing is much
cheaper than typing invoices in by hand and also can be more
accurate.</p><p>SmallCo manufactures widgets and gets orders from BigCo
occasionally (perhaps a few per month). SmallCo's primary
motivation is to do business with BigCo and other companies of this
sort, and messaging with electronic procurement systems is part of
what you need to do to get the sale. However, SmallCo needs to keep
the cost down and cannot afford to purchase elaborate software
systems to implement these processes. SmallCo uses a low-end
bookkeeping system (e.g. QuickBooks, PeachTree Accounting) and does
a lot of hand entry into this system. SmallCo has a web site hosted
by a local ISP.</p></div><div class="div3">
<h4><a name="Actors1" id="Actors1"></a>2.3.4 Actors &amp; Goals</h4><p>BigCo: A business analyst is responsible for the relationship
between BigCo and SmallCo, an engineer initiates the request for
purchase, the purchasing department handles the mechanics of the
transaction.</p><p>SmallCo: Mom takes the order and tells Sonny to ship out N
widgets, meanwhile telling Pop to enter the transaction into
Quickbooks and generate an invoice against BigCo.</p></div><div class="div3">
<h4><a name="Cases1" id="Cases1"></a>2.3.5 Usage Scenarios</h4><p>The following usage scenarios first illustrate the steps involved in a
typical purchasing transaction, then show some typical "fixing the
screwups" operations.</p><div class="div4">
<h5><a name="L1091" id="L1091"></a>2.3.5.1 Typical Widget Purchase</h5><div class="div5">
<h6><a name="Goal1rc" id="Goal1rc"></a>2.3.5.1.1 Goal / Context</h6><p>An engineer needs to purchase widgets for a project, finds the
SmallCo offering in a catalog and initiates the purchase.</p></div><div class="div5">
<h6><a name="Scenario1rc" id="Scenario1rc"></a>2.3.5.1.2 Scenario / Steps</h6><p>A typical transaction looks like this:</p><ol type="1"><li><p>Engineer finds SmallCo widget offering in an internal web
catalog of goods and services.</p></li><li><p>Engineer initiates a request for quote to SmallCo.</p></li><li><p>SmallCo responds with a quote.</p></li><li><p>Engineer initiates a purchase order that is sent to
SmallCo.</p></li><li><p>SmallCo receives the P.O. ships the widget and sends an
invoice.</p></li><li><p>BigCo receives the widget, checks that the received widget is
really what was ordered, and initiates payment through a
financial service.</p></li><li><p>BigCo sends a payment advice to SmallCo.</p></li></ol><p>There are lots of other messages that might be sent in a
purchasing scenario. This is just sort of a bare-bones illustrative
example.</p><p>The messages that go from BigCo to SmallCo are generated
automatically by the software systems in BigCo. SmallCo, on the
other hand, is using a shareware web services module that
implements the web services necessary for these commercial
transactions in a generic way but knows nothing about the
industry-specific business protocols involved.</p></div><div class="div5">
<h6><a name="Extensions1rc" id="Extensions1rc"></a>2.3.5.1.3 Extensions</h6><p>Failure of the process at each step triggers appropriate
actions, often involving flagging the transaction for attention by
a person in the purchasing department of BigCo or raising an error condition in the web service facility of SmallCo.</p></div><div class="div5">
<h6><a name="Technologi1rc" id="Technologi1rc"></a>2.3.5.1.4 Technologies / Requirements</h6><p>The basic transactions take place via Asynchronous
Messaging ( see <a href="#S070"><b>3.20 S070 Asynchronous messaging</b></a>). However, each of the steps of this process must also
be reliable ( see also <a href="#S010"><b>3.6 S010 Request with acknowledgement</b></a>). That is, there is a process in place by which when a
message is sent the sender knows that it will either get through or
create an error condition, and that there is a high probability of
it getting through. Each message generates a confirmation of
receipt message back to the sender, that is, Request with
Acknowledgement ( see <a href="#S010"><b>3.6 S010 Request with acknowledgement</b></a>). In addition, each message carries a unique
identifier, a date-time stamp (showing the time at which the
message was sent, not necessarily the delivery time), and
information that allows the messages to be logically ordered.
(These capabilities will be exercised in subsequent scenarios). The
identification requirements may be part of Conversational
Message Exchange (see <a href="#S040"><b>3.13 S040 Conversational message exchange</b></a>).</p><p>We are requiring here that the messages be ordered but not
sequenced, even though many of the VAN's on which this usage scenario
is based do offer sequencing. Sequencing would imply that each
message between two partners in a given direction has a sequential
index and that no gaps are allowed. One could then, if desired, set
up a process in which sequential receipt were enforced. That is, if
BigCo gets message 22 from SmallCo and then receives message 24,
BigCo would not accept message 24 (presumably holding it in some
sort of buffer) until message 23 arrived, and probably would throw
some sort of error if it did not arrive in some time period. We are
not including this type of operation in the usage scenario because we
feel that it is fairly unusual actually to make use of this logic.
Moreover, if desired such sequencing could be made part of the
payload and included in the business logic. The only reason we can
think of to include sequencing in the enveloping mechanism would be
to enforce sequencing across different types of business
transaction, and we don't think that this is likely to be very
useful. Would you want to hold up an invoice, for example, because
a message involving HR had not arrived yet?</p><p>The usual security features (Accessibility, Authentication (see <a href="#S063"><b>3.17 S063 Authentication </b></a> ),
Authorization, Confidentiality, Integrity and non-Repudiation) are
all matters of concern. Non-Repudiation is of particular
importance, although in practical terms less in terms of a legal
process than simply the ability to say, "You got this invoice on
March 24, and here is your signed confirmation of receipt". That
is, by far the most common scenarios that require non-repudiation (see also <a href="#S065"><b>3.19 S065 Authentication of data</b></a>)
involve people in both companies trying, in good faith, to sort out
something which would go wrong in some transaction. What is
required in these cases is an unambiguous record, not rock-solid
legal proof. Taking these issues to court is a very rare occurrence
given an ongoing trading relationship between businesses. This is
probably a less strong requirement than what is usually called
"non-repudiation", but stronger than "auditing". Perhaps we can
call this requirement "reconciliation". Various aspects of
Reconciliation will be
exercised in the usage scenarios below.</p><p>Other aspects of security are also necessary. It must be
possible for both BigCo and SmallCo to be sure that the messages
they receive are actually from the company that they are supposed
to be. That is, each company must be able to identify itself
unambiguously (Authentication, see <a href="#S063"><b>3.17 S063 Authentication </b></a>)).
In addition, there is the question of what actions the company is
authorized to request from the web service. For example, BigCo
needs to be able to query SmallCo's web service for a list of
messages that have been sent between these two participants, but
not for information about transactions with other companies that
purchase widgets from SmallCo. Both companies need to be confident
that the communications cannot be tampered with or observed by
third parties, and that third parties cannot send communications
pretending to be who they are not.</p><p>The SmallCo web service knows how to receive and send messages
and will present these messages to users at SmallCo in a browser
window. A SmallCo employee transfers information from the XML to
their bookkeeping system via cut and paste. How does SmallCo
generate the XML that goes into the messages that it sends? The web
service knows how to generate the envelop (message ID, datetime,
and so on), but not the message contents. To assist SmallCo's
either BigCo or the industry standards body provides a web site
that implements messages like "quote" and "invoice" in a web form
into which a SmallCo person types information and which returns
suitably formatted XML in the browser window.</p></div></div><div class="div4">
<h5><a name="L1561" id="L1561"></a>2.3.5.2 Transaction Log Mismatch</h5><div class="div5">
<h6><a name="Goal11" id="Goal11"></a>2.3.5.2.1 Goal / Context</h6><p>BigCo has instituted an automated reconciliation procedure to check on a
monthly basis that messages have not been lost by comparing
transaction logs from BigCo and SmallCo. In this scenario a
discrepancy is found and addressed.</p></div><div class="div5">
<h6><a name="Scenario1rc1" id="Scenario1rc1"></a>2.3.5.2.2 Scenario / Steps</h6><ol type="1"><li><p>At the end of the month the Bigco web service automatically
sends a request to the SmallCo web server for a list of the message
ID's sent and received during that month.</p></li><li><p>The SmallCo response is automatically checked against a list of
messages processed by the purchasing system, and it is found that a
whole bunch of messages show up on SmallCo's logs as sent to Bigco
but not on BigCo's as received and processed.</p></li><li><p>The BigCo web service raises an error condition that is sent to
a person in the Purchasing Department who looks into the
situation.</p></li><li><p>It turns out that all the lost messages were from a particular
weekend during which a server at BigCo was misconfigured and was
trashing messages.</p></li><li><p>BigCo sends a request to the SmallCo web server to resend the
messages in question that have been lost.</p></li></ol></div><div class="div5">
<h6><a name="Extensions1rc1" id="Extensions1rc1"></a>2.3.5.2.3 Extensions</h6><p>Somebody from BigCo calls up SmallCo, apologizes, and explains
why they have not been responding in a timely manner.</p></div><div class="div5">
<h6><a name="Technologi11" id="Technologi11"></a>2.3.5.2.4 Technologies / Requirements</h6><p>Reconciliation: the SmallCo web service must be able to respond
to (authorized) requests for information about what messages have
been received and/or sent in a time period or between marker
messages. The web service must be capable of resending messages on
request.</p></div></div><div class="div4">
<h5><a name="L212rc" id="L212rc"></a>2.3.5.3 SmallCo Incorrectly Thinks They Weren't Paid</h5><div class="div5">
<h6><a name="Goal2rc" id="Goal2rc"></a>2.3.5.3.1 Goal / Context</h6><p>SmallCo thinks that it has not been paid because they did not
receive the payment advice. In fact, they received it but didn't store it into
their records so they think that they have not been paid. However,
the payment was really made through the bank into their account.
The objective here is to reconcile the differences so everyone agrees what
has happened.</p></div><div class="div5">
<h6><a name="Scenario2rc" id="Scenario2rc"></a>2.3.5.3.2 Scenario / Steps</h6><ol type="1"><li><p>SmallCo calls their contact in BigCo (a business analyst) and
complains that they were not paid for a particular order. They give
the business analyst the ID of the invoice message.</p></li><li><p>The BigCo purchasing department pulls all the messages involved
with this transaction (the transaction is labeled in the business
process definition, not the web service envelop), and finds that
payment was actually made and confirmed by the bank.</p></li><li><p>BigCo sends copies of this information to SmallCo, including
the message ID of the payment advice and identifying information
for the bank payment. The bank payment information includes
information that links it to the ID of this transaction (again,
this is in the business process definition, not the web service
envelop).</p></li><li><p>SmallCo queries its web service for the payment advice message,
checks its own bank statements, and eventually realizes that they
really were paid and did not book it properly.</p></li></ol></div><div class="div5">
<h6><a name="Extensions2rc" id="Extensions2rc"></a>2.3.5.3.3 Extensions</h6><p>SmallCo notifies BigCo that everything is now in order.</p></div><div class="div5">
<h6><a name="Technologi2rc" id="Technologi2rc"></a>2.3.5.3.4 Technologies / Requirements</h6><p>Reconciliation: the key here is to be able to retrieve messages by ID. The
linkage of the messages into a transaction is beyond the scope of
the web service itself and belongs in the definition of the business process.</p></div></div><div class="div4">
<h5><a name="L213" id="L213"></a>2.3.5.4 SmallCo Really Wasn't Paid</h5><div class="div5">
<h6><a name="Goal3" id="Goal3"></a>2.3.5.4.1 Goal / Context</h6><p>SmallCo sent an invoice and this time they really didn't get
paid. After a while they call BigCo as in the previous scenario.
The objective here is to get SmallCo paid.</p></div><div class="div5">
<h6><a name="Scenario3" id="Scenario3"></a>2.3.5.4.2 Scenario / Steps</h6><ol type="1"><li><p>SmallCo calls their contact in BigCo (a business analyst) and
complains that they were not paid for a particular order. They give
the business analyst the ID of the invoice message.</p></li><li><p>The BigCo purchasing department pulls all the messages involved
with this transaction (the transaction is labeled in the business
process definition, not the web service envelop), and finds that
payment really wasn't made. Somebody didn't approve it and the
transaction died. (Of course, this is after a flurry of documents,
letters, and phone calls back and forth, not to mention various
emails within BigCo, many of them to people that have never heard
of SmallCo or anything else that has anything to do with the
problem at hand).</p></li><li><p>BigCo eventually notices their mistake and initiates payment.</p></li></ol></div><div class="div5">
<h6><a name="Extensions3" id="Extensions3"></a>2.3.5.4.3 Extensions</h6><p>BigCo notifies the SmallCo that the check was in the mail.</p></div><div class="div5">
<h6><a name="Technologi3" id="Technologi3"></a>2.3.5.4.4 Technologies / Requirements</h6><p>The requirements are really the same as for the last scenario.
We just wanted to illustrate that there are all sorts of ways the
business process can go wrong, no matter what technical
processes are in place, and that the fault may lie on either side of the transaction.</p></div></div></div></div></div><div class="div1">
<h2><a name="description" id="description"></a>3 Usage Scenarios</h2><p>The notations used are <a href="http://www.w3.org/TR/2003/WD-xmlp-am-20030220/#Sec2">the ones
from XML Protocol Abstract Model</a>.</p><div class="div2">
<h3><a name="S001" id="S001"></a>3.1 S001 Fire-and-forget to single receiver</h3><div class="div3">
<h4><a name="id2274071" id="id2274071"></a>3.1.1 Scenario Definition</h4><p>
A sender wishes to send an unacknowledged message to a single receiver
(e.g. send a stock price update every 15 minutes).
</p></div><div class="div3">
<h4><a name="id2274651" id="id2274651"></a>3.1.2 Description</h4><div class="figure"><a name="fig1" id="fig1"></a><br /><img src="soap-usage-fig1.png" alt="Fire-and-forget to single receiver" /><p><i><span>Figure 3-1. </span>Fire-and-forget to single receiver</i></p><br /></div><p>
A fire-and-forget feature in scenario S001 requires a mechanism to send a
message to a single SOAP Receiver and is illustrated in
<a href="#fig1">Figure 3-1</a>. The SOAP
Sender does not require any status information that the message has been
sent to or received by the recipient. The underlying transport protocol
may implement a response mechanism, but status on whether the message was
successfully sent or otherwise is not returned to the sending SOAP Processor.
</p><div class="exampleOuter">
<div class="exampleHead">Example: Fire-and-forget SOAP message</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Body&gt;
&lt;r:StockPriceUpdate xmlns:r="http://example.org/2001/06/quotes"&gt;
&lt;r:Symbol&gt;BigCo&lt;/r:Symbol&gt;
&lt;r:Price&gt;34.5&lt;/r:Price&gt;
&lt;/r:StockPriceUpdate&gt;
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;</pre></div></div></div></div><div class="div2">
<h3><a name="S002" id="S002"></a>3.2 S002 Fire-and-forget to multiple receivers</h3><div class="div3">
<h4><a name="id2274727" id="id2274727"></a>3.2.1 Scenario Definition</h4><p>
A sender wishes to send unacknowledged messages to a set of receivers
(e.g. send a stock price update every 15 minutes).
</p></div><div class="div3">
<h4><a name="id2274740" id="id2274740"></a>3.2.2 Description</h4><div class="figure"><a name="fig2" id="fig2"></a><br /><img src="soap-usage-fig2.png" alt="Fire-and-forget to multiple receivers " /><p><i><span>Figure 3-2. </span>Fire-and-forget to multiple receivers </i></p><br /></div><p>
Scenario S002 extends <a href="#S001">S001</a> to implement a fire-and-forget feature to multiple
SOAP Receivers and is illustrated in <a href="#fig2">Figure 3-2</a>. This requires a mechanism
to deliver the same message to multiple SOAP Receivers. The delivery of
the messages could be implemented using multicast distribution technology
if the underlying transport layer supports this. An alternative
implementation may use repeated applications of scenario <a href="#S001">S001</a> with a
distribution list of intended recipients.
</p></div></div><div class="div2">
<h3><a name="S003" id="S003"></a>3.3 S003 Request/Response</h3><div class="div3">
<h4><a name="id2274806" id="id2274806"></a>3.3.1 Scenario Definition</h4><p>
Two parties wish to conduct electronic business by the exchange of business
documents. The sending party packages one or more documents into a request
message, which is then sent to the receiving party. The receiving party then
processes the message contents and responds to the sending party. Examples of
the sending party's documents may be purchase order requests, manufacturing
information and patient healthcare information. Examples of the receiving
party's responses may include order confirmations, change control information
and contractual acknowledgements.
</p></div><div class="div3">
<h4><a name="id2274827" id="id2274827"></a>3.3.2 Description</h4><p>
Scenario S003 requires a request/response message feature. A request
containing some business document is sent by a SOAP Sender to a SOAP Receiver
where some business application is invoked. The business application
processes the request and generates a response, which is returned to the
SOAP Sender that originated the request. Two alternative solutions are
described which depend upon the characteristics of the underlying transport
layer. In either case, the SOAP Sender is informed of the status (successful
or otherwise) of the request message delivery.
</p><div class="figure"><a name="fig3" id="fig3"></a><br /><img src="soap-usage-fig3.png" alt="Request/Response using underlying transport" /><p><i><span>Figure 3-3. </span>Request/Response using underlying transport</i></p><br /></div><p>
If the underlying transport protocol supports the correlation of a request
and its matching response directly, then the solution illustrated in <a href="#fig3">Figure 3-3</a>
may be appropriate. An example of such an underlying transport protocol would
be a synchronous HTTP POST. This implementation would make use of the
transport binding proposed in other XML Protocol WG documents. The business
document sent as a request by the SOAP Sender would be inserted as the
payload of the request message. Following the receipt of the request, the
processing application would generate a document which would be returned
as the payload of the response message with appropriate status codes. If for
whatever reason, the request message was not received or processed by the
intended business application, suitable status messages would be generated
by the underlying transport layer and reported to the SOAP Sender.
</p><div class="figure"><a name="fig4" id="fig4"></a><br /><img src="soap-usage-fig4.png" alt="Request/Response using SOAP headers" /><p><i><span>Figure 3-4. </span>Request/Response using SOAP headers</i></p><br /></div><p>
If the underlying transport protocol does not support a request/response
model, then the configuration shown in <a href="#fig4">Figure 3-4</a> may be appropriate. Examples
of such an underlying protocol may include unidirectional queuing middleware.
In this case, message identification and correlation is provided by SOAP
Headers. In the request SOAP message, a Message Identifier Handler is
responsible for generating a unique message identifier and inserting it into
a SOAP Header. This forms part of the SOAP request message and is sent from
SOAP Application 1 to the receiving SOAP Application 2. The request message
is processed by a business application and a response message is assembled.
This includes a SOAP Header built by a Message Correlation Handler which
links the response message to its associated request.
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP request message containing a message identifier</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:MsgHeader xmlns:n="http://example.org/requestresponse"&gt;
&lt;n:MessageId&gt;uuid:09233523-345b-4351-b623-5dsf35sgs5d6&lt;/n:MessageId&gt;
&lt;/n:MsgHeader&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
........
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;</pre></div></div><div class="exampleOuter">
<div class="exampleHead">Example: SOAP response message containing correlation to original request</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:MsgHeader xmlns:n="http://example.org/requestresponse"&gt;
&lt;n:MessageId&gt;uuid:09233523-567b-2891-b623-9dke28yod7m9&lt;/n:MessageId&gt;
&lt;n:ResponseTo&gt;uuid:09233523-345b-4351-b623-5dsf35sgs5d6&lt;/n:ResponseTo&gt;
&lt;/n:MsgHeader&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
........
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;</pre></div></div></div></div><div class="div2">
<h3><a name="S004" id="S004"></a>3.4 S004 Remote Procedure Call (RPC)</h3><div class="div3">
<h4><a name="id2274992" id="id2274992"></a>3.4.1 Scenario Definition</h4><p>
The sender invokes the service by passing parameters that are serialized
into a message for transmission to the receiving server.
</p></div><div class="div3">
<h4><a name="id2275005" id="id2275005"></a>3.4.2 Description</h4><p>
Scenario S004 differs from scenario <a href="#S003">S003</a> in that the request message consists of
a set of serialized parameters used to invoke some remote procedure which
responds with a set of results. This is a different programming model to the
document exchange one illustrated by scenario <a href="#S003">S003</a>. Scenario S4 requires a
request/response mechanism as in <a href="#S003">S003</a>, with the parameter and result
serialization needed for the RPC programming model form the SOAP Body
element.
</p><div class="figure"><a name="fig5" id="fig5"></a><br /><img src="soap-usage-fig5.png" alt="RPC using underlying transport" /><p><i><span>Figure 3-5. </span>RPC using underlying transport</i></p><br /></div><p>
<a href="#fig5">Figure 3-5</a> illustrates an RPC invocation over an underlying transport protocol
such as HTTP that supports request/response. In this case, no additional
headers are needed to correlate the request and response messages. Example
request and response SOAP messages are:
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP RPC request message</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Body&gt;
&lt;r:UpdateLastTradePrice env:encodingStyle="http://www.w3.org/2002/06/soap-encoding"
xmlns:r="http://example.org/2001/06/quotes"&gt;
&lt;r:Symbol&gt;DEF&lt;/r:Symbol&gt;
&lt;/r:UpdateLastTradePrice&gt;
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div><div class="exampleOuter">
<div class="exampleHead">Example: SOAP RPC response message</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Body&gt;
&lt;r:UpdateLastTradePriceResponse env:encodingStyle="http://www.w3.org/2002/06/soap-encoding"
xmlns:r="http://example.org/2001/06/quotes"
xmlns:rpc="http://www.w3.org/2002/06/soap-rpc"&gt;
&lt;rpc:Result&gt;34.5&lt;/rpc:Result&gt;
&lt;/r:UpdateLastTradePriceResponse&gt;
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div><div class="figure"><a name="fig6" id="fig6"></a><br /><img src="soap-usage-fig6.png" alt="RPC using SOAP headers" /><p><i><span>Figure 3-6. </span>RPC using SOAP headers</i></p><br /></div><p>
In <a href="#fig6">Figure 3-6</a>, the underlying transport protocol does not support
request/response directly. The RPC request and response elements again form
the Body of the SOAP messages. Correlation of the request and response is
provided by the Message Identifier and Message Correlation handlers as
described in scenario <a href="#S003">S003</a>.
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP RPC request message with message identification</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:MsgHeader xmlns:n="http://example.org/requestresponse"&gt;
&lt;n:MessageId&gt;uuid:09233523-345b-4351-b623-5dsf35sgs5d6&lt;/n:MessageId&gt;
&lt;/n:MsgHeader&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
&lt;r:UpdateLastTradePrice env:encodingStyle="http://www.w3.org/2002/06/soap-encoding"
xmlns:r="http://example.org/2001/06/quotes"&gt;
&lt;r:Symbol&gt;DEF&lt;/r:Symbol&gt;
&lt;/r:UpdateLastTradePrice&gt;
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div><div class="exampleOuter">
<div class="exampleHead">Example: SOAP RPC response message containing correlation to original request</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:MsgHeader xmlns:n="http://example.org/requestresponse"&gt;
&lt;n:MessageId&gt;uuid:09233523-567b-2891-b623-9dke28yod7m9&lt;/n:MessageId&gt;
&lt;n:ResponseTo&gt;uuid:09233523-345b-4351-b623-5dsf35sgs5d6&lt;/n:ResponseTo&gt;
&lt;/n:MsgHeader&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
&lt;r:UpdateLastTradePriceResponse env:encodingStyle="http://www.w3.org/2002/06/soap-encoding"
xmlns:r="http://example.org/2001/06/quotes"
xmlns:rpc="http://www.w3.org/2002/06/soap-rpc"&gt;
&lt;rpc:Result&gt;34.5&lt;/rpc:Result&gt;
&lt;/r:UpdateLastTradePriceResponse&gt;
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div></div></div><div class="div2">
<h3><a name="S006" id="S006"></a>3.5 S006 Multiple Faults </h3><div class="div3">
<h4><a name="id2275248" id="id2275248"></a>3.5.1 Scenario Definition</h4><p>Declaration of a method that raises multiple faults</p></div><div class="div3">
<h4><a name="id2275259" id="id2275259"></a>3.5.2 Description</h4><p>A web service interface method can fail due to several reasons. The faults raised by the method may be semantically different from each other and further more, some of the faults may be standard faults defined for a group of web services. For example, in an accounting system, there may be a general "creation fault" defined for indicating the failure such as out of resources or PO already exists. The creation of PO could also fail because the data provided to initialize the PO is invalid. The web service method "createPO" might then fail because of any of the reasons described above and may want to raise separate faults depending on the reason for failure.
</p></div></div><div class="div2">
<h3><a name="S010" id="S010"></a>3.6 S010 Request with acknowledgement</h3><div class="div3">
<h4><a name="id2275290" id="id2275290"></a>3.6.1 Scenario Definition</h4><p>
A sender wishes to reliably exchange data with a receiver. It wishes to be
notified of the status of the data delivery to the receiver. The status may
take the form of:
</p><ol type="1"><li><p>The data has been successfully delivered to the receiver, or</p></li><li><p>Some failure has occurred which prevents the successful delivery to the receiver.</p></li></ol></div><div class="div3">
<h4><a name="id2275322" id="id2275322"></a>3.6.2 Description</h4><div class="figure"><a name="fig7" id="fig7"></a><br /><img src="soap-usage-fig7.png" alt="Request with acknowledgement" /><p><i><span>Figure 3-7. </span>Request with acknowledgement</i></p><br /></div><p>
<a href="#fig7">Figure 3-7</a> illustrates a request/response scenario with the SOAP Sender
requesting status information from the matching SOAP Receiver. This status
may provide delivery information to the sender in addition to other business
related responses that the receiving application may generate. <a href="#fig7">Figure 3-7</a>
assumes that the underlying transport protocol supports the request/response
exchange model. A Status Handler is registered with the SOAP Sender and
configured to request the status information. A matching handler on the SOAP
Receiver generates the requested status information and places it in the
response message which is then returned to the originating SOAP Sender.
</p><p>
In the example SOAP messages below, a StatusRequest header element includes
an identifier for the message being sent. The inclusion of the StatusRequest
header results in the receiving SOAP processor including a StatusResponse
Header in the response. This includes information about the delivered message
including an enumerated status and timestamp.
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP request message with status request header</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:StatusRequest xmlns:n="http://example.org/status"&gt;
&lt;n:MessageId&gt;uuid:09233523-345b-4351-b623-5dsf35sgs5d6&lt;/n:MessageId&gt;
&lt;/n:StatusRequest&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
-----
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div><div class="exampleOuter">
<div class="exampleHead">Example: SOAP response message containing delivery status for request</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:StatusResponse xmlns:n="http://example.org/status"&gt;
&lt;n:MessageId&gt;uuid:09233523-567b-2891-b623-9dke28yod7m9&lt;/n:MessageId&gt;
&lt;n:MessageStatus&gt;DELIVERED&lt;/n:MessageStatus&gt;
&lt;n:Timestamp&gt;2001-03-09T12:22:30Z&lt;/n:Timestamp&gt;
&lt;/n:StatusResponse&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
-----
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div></div><div class="div3">
<h4><a name="id2274543" id="id2274543"></a>3.6.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2274549" id="id2274549"></a>3.6.3.1 Requirements</h5><ol type="1"><li><p>A Sender shall be able to determine from a receiver message whether a
message has been reliably delivered, as specified by the receiver.</p></li><li><p>A sender and receiver shall be able to engage in message exchange patterns
that exhibit best-effort, at least once, at most once, ordered qualities of
service. </p></li></ol></div><div class="div4">
<h5><a name="id2274577" id="id2274577"></a>3.6.3.2 Non-requirements</h5><ol type="1"><li><p>specifying quality of service of the sender/receiver software,
particularly the durability of the message on a particular side. Justification: QoS would be a static definition, not part of a reliability ACK Protocol. It seems in appropriate to specify a software quality in a wire-protocol.</p></li><li><p>Sender over-riding receiver default QoS (i.e. TCP's ack before enqueue)
</p></li></ol></div><div class="div4">
<h5><a name="id2274606" id="id2274606"></a>3.6.3.3 Candidate Technologies</h5><p>OASIS WS-Reliability, WS-RM, WS-Acknowledgement, ebXML Messaging Service, Proprietary Messaging Systems, Java Messaging Service</p></div></div><div class="div3">
<h4><a name="id2274618" id="id2274618"></a>3.6.4 Use case citations</h4><p>
This scenario is cited in <a href="#Technologi1rc"><b>2.3.5.1.4 Technologies / Requirements</b></a>; <a href="#Technologi1rc"><b>2.3.5.1.4 Technologies / Requirements</b></a>; <a href="#Scenario2"><b>2.1.5.3.2 Scenario / Steps</b></a>.</p></div></div><div class="div2">
<h3><a name="S030" id="S030"></a>3.7 S030 Third party intermediary</h3><div class="div3">
<h4><a name="id2275677" id="id2275677"></a>3.7.1 Scenario Definition</h4><p>
A blind auction marketplace serves as a broker between buyers and suppliers.
Buyers submit their requirements to the marketplace hub, which broadcasts
this information to multiple suppliers. Suppliers respond to the marketplace
hub where the information is logged and ultimately delivered to the buyer.
</p></div><div class="div3">
<h4><a name="id2275693" id="id2275693"></a>3.7.2 Description</h4><div class="figure"><a name="fig9" id="fig9"></a><br /><img src="soap-usage-fig9.png" alt="Marketplace intermediary" /><p><i><span>Figure 3-8. </span>Marketplace intermediary</i></p><br /></div><p>
<a href="#fig9">Figure 3-8</a> illustrates an infrastructure where SOAP based messaging is used to
support a third party marketplace acting as an intermediary between buyers and
sellers. The market place business model involves the recruitment of multiple
suppliers for goods and services. Buyers may then connect to the marketplace
and take advantage of the services they provide. The marketplace acts as a
channel for the commercial transactions between a buyer and its chosen seller.
A marketplace can exist to serve both B2B and B2C transactions.
</p><p>
In scenario S030, the marketplace acts as a blind intermediary. A buyer connects
to the marketplace and places an order for items or services it requires. The
buyer may be as simple as a browser or as complex as a procurement application.
Once the marketplace has received the buyer's order, it contacts an appropriate
set of sellers who then provide competitive bids against the order. The
marketplace can then select the most attractive bid and connect the winning
seller to the buyer. A purchasing process is then initiated with the
marketplace acting as an intermediary in the transaction.
</p><p>
From a SOAP messaging point of view, the scenario illustrated in <a href="#fig9">Figure 3-8</a>
consists of a set of request/response messages between the buyer and the
marketplace resulting in the buyer's order being registered. Once received,
the marketplace then contacts its set of selected sellers again by a set
of request/response messages. Design decisions made during the implementation
of the marketplace software will determine whether supplier messages are sent
from a single SOAP Sender to multiple SOAP Receivers, one at each of the
seller's sites. Alternatively, a SOAP Sender could be instantiated for each
supplier and a physical 1:1 relationship established. Prior agreements on
message qualities such as reliability, security and structure would be put in
place between the marketplace and its sellers. These qualities would define
what additional SOAP Handlers were needed for the message exchange patterns
between the marketplace and sellers.
</p></div></div><div class="div2">
<h3><a name="S031" id="S031"></a>3.8 S031 Communication via multiple intermediaries</h3><div class="div3">
<h4><a name="id2275800" id="id2275800"></a>3.8.1 Scenario Definition</h4><p>
An intermediary forwards a message to the ultimate receiver on behalf of an
initial sender. The initial sender wishes to enforce the non-repudiation
property of the route. Any intermediate message service handler that appends
a routing message must log the routing header information. Signed routing
headers and the message readers must be logged at the message handler which
passes the message to the ultimate receiver to provide the evidence of
non-repudiation.
</p></div><div class="div3">
<h4><a name="id2275820" id="id2275820"></a>3.8.2 Description</h4><div class="figure"><a name="fig12" id="fig12"></a><br /><img src="soap-usage-fig12.png" alt="Routing and logging through intermediaries" /><p><i><span>Figure 3-9. </span>Routing and logging through intermediaries</i></p><br /></div><p>
Scenario S031 requires an audit chain to be created between a SOAP Sender that
originates the message and the ultimate SOAP Receiver including any SOAP
Intermediaries that the message passes through. <a href="#fig12">Figure 3-9</a> illustrates a
possible implementation of this scenario. Each SOAP Node on the message
path has access to a persistent store (typically a database) that can be
used to store an audit record for each message. A Routing Logging Handler
on each SOAP Node has the responsibility of logging each message in the
persistent store. A further responsibility of the handler is to sign the
message routing header before passing the message on to the next SOAP Node
in the path. Support for certificates and other artifacts required for signing
a message are not shown.
</p></div></div><div class="div2">
<h3><a name="S032" id="S032"></a>3.9 S032 Caching</h3><div class="div3">
<h4><a name="id2275891" id="id2275891"></a>3.9.1 Scenario Definition</h4><p>
Some applications may wish to make caching possible for latency, bandwidth
use or other gains in efficiency. To enable this, it should be possible to
assign cacheability in a variety of circumstances. For example, "read"
caching might be used to store messages at intermediaries for reuse in the
response phase of the request/response message exchange pattern. Such caching
might be on the scope of an entire message, a SOAP module, or scoped to
individual SOAP module elements.
</p><p>
Similarly, "write" caching may be useful in situations when a
request message in a request/response message exchange pattern (as well as
similar messages in other message exchange patterns) does not need to be
immediately forwarded or responded to. Such cacheability might be scoped by
different methods, as outlined above.
</p><p>
Cacheability scoped by different elements might be associated by an attribute
to the target element, through use of XML Query or XPath to describe the
target elements in a header, or implied by the document schema, for example.
</p><p>
Cacheability mechanisms applied to messages, bodies or elements might include
time-to-live (delta time), expiry (absolute time), entity validation, temporal
validation, subscription to invalidation services, and object update/purge.
</p><p>
Finally, some applications may be capable of describing the dependencies and
relationships between message elements. For example, a response element may
be applicable to a wide range of requests; it would be beneficial to describe
this element's relationship with request elements, so that it may satisfy a
wide range of requests in an economical fashion. Similarly, the presence of a
particular element may be a trigger for a cacheability mechanism to be applied
to another element, such as validation or invalidation.
</p></div><div class="div3">
<h4><a name="id2275949" id="id2275949"></a>3.9.2 Description</h4><p>
Caching is frequently used as an optimization in distributed systems. It can
be used to avoid re-doing computations or complex database access when the
results remain valid for an extended period of time. In this case, subsequent
requests for the same information can be served with the cached version rather
than repeat the processing with the associated overheads. Another use of
caching is in the transmission of data where copies may be held at leaf
servers for local service provision rather than repeatedly access a central
information repository. This has the combined effect of providing faster
access to the information, reducing network bandwidth requirements and
reducing the workload on a central server. Caching may be provided as part
of an underlying transport infrastructure but in the case of this scenario,
it is assumed that the caching is independent of any underlying transport.
</p><p>
An example of this kind of scenario is the caching of the response to a
request in situations where a subsequent request can be safely answered
with the same result. This example coincides with scenario S809 (Caching
with expiry) where a catalog is updated at 8am each morning. Once the catalog
has been updated, all price queries against it are valid until 8am the
following day. If a price query request is repeated against the same item,
then a cached response can be returned to the SOAP Sender otherwise the
request is forwarded to the catalog server and its response is cached. All
entries in the cache are purged at the time of the updated catalog being
available. <a href="#fig18">Figure 3-10</a> illustrates a possible architecture.
</p><div class="figure"><a name="fig18" id="fig18"></a><br /><img src="soap-usage-fig18.png" alt="Result Caching" /><p><i><span>Figure 3-10. </span>Result Caching</i></p><br /></div><p>
SOAP Application 1 initiates a request for catalog price information
illustrated in the following example.
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP request message for catalog price information</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Body&gt;
&lt;c:CatalogPriceRequest xmlns:c="http://example.org/2001/06/catalog"&gt;
&lt;c:PartNumber&gt;ABC-1234&lt;/c:PartNumber&gt;
&lt;/c:CatalogPriceRequest&gt;
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div><p>
The caching intermediary SOAP Application 2 is unable to fulfill the request
from its local store so it forward the request which ultimately arrives at
the catalog server SOAP Application 3. The catalog server process the request
and assembles a response message containing the requested price information.
An additional SOAP Header is placed in the response to control any caches that
may exist in the return path. The CacheControl Header contains a CacheKey
which allows matching of future requests to the cached response together with
an Expires element that sets the time the local copy must be purged. This
response is returned via the caching intermediary.
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP response with caching header received by intermediary</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;ca:CacheControl xmlns:ca="http://example.org/2001/06/cache"&gt;
&lt;ca:CacheKey&gt;ABC-1234&lt;/ca:CacheKey&gt;
&lt;ca:Expires&gt;2001-03-09T08:00:00Z&lt;/ca:Expires&gt;
&lt;/ca:CacheControl&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
&lt;c:CatalogPriceResponse xmlns:c="http://example.org/2001/06/catalog"&gt;
&lt;c:PartNumber&gt;ABC-1234&lt;/c:PartNumber&gt;
&lt;c:PartPrice c:currency="USD"&gt;120.37&lt;/c:PartPrice&gt;
&lt;/c:CatalogPriceResponse&gt;
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div><p>
At the caching intermediary, the CacheControl header information is used to
make a local copy of the response message, keyed by the CacheKey. The copy
will be purged at the time specified by the Expires element. The CacheControl
header element is removed by the intermediary and the catalog price
information is returned to the original sender. The request/response path for
this message is the complete roundtrip between the original SOAP Sender and
SOAP Receiver and is shown by <em>Message Path 1</em> in <a href="#fig18">Figure 3-10</a>.
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP response with received by original Sender</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Body&gt;
&lt;c:CatalogPriceResponse xmlns:c="http://example.org/2001/06/catalog"&gt;
&lt;c:PartNumber&gt;ABC-1234&lt;/c:PartNumber&gt;
&lt;c:PartPrice c:currency="USD"&gt;120.37&lt;/c:PartPrice&gt;
&lt;/c:CatalogPriceResponse&gt;
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div><p>
Since there is now a local copy of the price information for item ABC-1234
in the intermediary cache, subsequent requests for price information can be
fulfilled by the intermediary. This is the shorter request/response path
<em>Message Path 2</em>.
</p></div></div><div class="div2">
<h3><a name="S035" id="S035"></a>3.10 S035 Routing</h3><div class="div3">
<h4><a name="id2276168" id="id2276168"></a>3.10.1 Scenario Definition</h4><p>
A developer wishes to force an explicit message path through certain
intermediaries - for instance, he might use an anonymizing intermediary
to make a call to a specified remote service without allowing the target
service to track the identity/IP of the caller. In this case, the
intermediary is responsible for calling the target service and returning
the results to the caller, using its own authentication credentials if
any are required by the target service.
</p></div><div class="div3">
<h4><a name="id2276187" id="id2276187"></a>3.10.2 Description</h4><p>
This scenario has been addressed in detail by the WS-Routing <a href="#">[WSRP]</a>
(formerly SOAP-RP) specification.
</p></div></div><div class="div2">
<h3><a name="S036" id="S036"></a>3.11 S036 Tracking</h3><div class="div3">
<h4><a name="id2276215" id="id2276215"></a>3.11.1 Scenario Definition</h4><p>
A service provider wishes to track incoming messages to see exactly which processing
intermediaries have touched it by the time it arrives at its destination. It
therefore requires a tracking extension to be included by all clients, and by
any processing intermediaries along the message paths from the clients to the server.
</p></div><div class="div3">
<h4><a name="id2276232" id="id2276232"></a>3.11.2 Description</h4><div class="figure"><a name="fig19" id="fig19"></a><br /><img src="soap-usage-fig19.png" alt="Message Tracking" /><p><i><span>Figure 3-11. </span>Message Tracking</i></p><br /></div><p>
Scenario S036 describes a routing requirement which is addressed in detail by the
WS-Routing <a href="#">[WSRP]</a> (formerly SOAP-RP) specification. This describes how a message
may be rerouted through some messaging infrastructure. Once the message has arrived
at its ultimate receiver, the route the message has taken may be required for
auditing purposes. A track of the message path may be created by adding a tracking
header to the message in addition to any routing information.
</p><p>
This is illustrated in the following example. A routing header has been added to
the message in accordance with WS-Routing <a href="#">[WSRP]</a>. A TrackingHeader is used to
maintain a list of Intermediary names and associated Timestamp elements. As the
message passes through each intermediary, a Tracking Handler appends a Via element
to the TrackingHeader. The Via element contains the name of the intermediary
together with the date/time the message arrived or was forwarded by the intermediary.
The list of Via elements therefore forms the audit trail for the message.
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP request with routing and tracking headers</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;t:TrackingHeader xmlns:t="http://example.org/2001/06/tracking"&gt;
&lt;t:Via&gt;
&lt;t:Intermediary&gt;soap://A.example.com/some/endpoint&lt;/t:Intermediary&gt;
&lt;t:Timestamp&gt;2001-03-09T08:00:00Z&lt;/t:Timestamp&gt;
&lt;/t:Via&gt;
&lt;t:Via&gt;
&lt;t:Intermediary&gt;soap://B.example.com&lt;/t:Intermediary&gt;
&lt;t:Timestamp&gt;2001-03-09T08:01:00Z&lt;/t:Timestamp&gt;
&lt;/t:Via&gt;
&lt;t:Via&gt;
&lt;t:Intermediary&gt;soap://C.example.com&lt;/t:Intermediary&gt;
&lt;t:Timestamp&gt;2001-03-09T08:02:00Z&lt;/t:Timestamp&gt;
&lt;/t:Via&gt;
&lt;t:Via&gt;
&lt;t:Intermediary&gt;soap://D.example.com/some/endpoint&lt;/t:Intermediary&gt;
&lt;t:Timestamp&gt;2001-03-09T08:03:00Z&lt;/t:Timestamp&gt;
&lt;/t:Via&gt;
&lt;/t:TrackingHeader&gt;
&lt;wsrp:path xmlns:wsrp="http://schemas.xmlsoap.org/rp"&gt;
&lt;wsrp:action&gt;http://www.im.org/chat&lt;/wsrp:action&gt;
&lt;wsrp:to&gt;soap://D.example.com/some/endpoint&lt;/wsrp:to&gt;
&lt;wsrp:fwd&gt;
&lt;wsrp:via&gt;soap://B.example.com&lt;/wsrp:via&gt;
&lt;wsrp:via&gt;soap://C.example.com&lt;/wsrp:via&gt;
&lt;/wsrp:fwd&gt;
&lt;wsrp:from&gt;soap://A.example.com/some/endpoint&lt;/wsrp:from&gt;
&lt;wsrp:id&gt;uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6&lt;/wsrp:id&gt;
&lt;/wsrp:path&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
.....
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div></div></div><div class="div2">
<h3><a name="S037" id="S037"></a>3.12 S037 Caching with expiration</h3><div class="div3">
<h4><a name="id2276353" id="id2276353"></a>3.12.1 Scenario Definition</h4><p>BizCo updates their online price catalog every morning at 8AM.
Therefore, when remote clients access their SOAP inventory service,
clients and intermediaries may cache the results of any price queries
until 8AM the next day.
</p></div><div class="div3">
<h4><a name="id2276367" id="id2276367"></a>3.12.2 Description</h4><p>See description for <a href="#S032">S032</a>.
</p></div></div><div class="div2">
<h3><a name="S040" id="S040"></a>3.13 S040 Conversational message exchange</h3><div class="div3">
<h4><a name="id2276394" id="id2276394"></a>3.13.1 Scenario Definition</h4><p>
Two partners are engaged in a long-running process, which involves multiple
message exchanges. Examples of such processes may be complex supply chain
management, dynamic manufacturing scheduling or information retrieval. There
may be multiple instances of the same process in progress between the same
two partners.
</p></div><div class="div3">
<h4><a name="id2276410" id="id2276410"></a>3.13.2 Description</h4><div class="figure"><a name="fig10" id="fig10"></a><br /><img src="soap-usage-fig10.png" alt="Conversational message exchange" /><p><i><span>Figure 3-12. </span>Conversational message exchange</i></p><br /></div><p>
Interactions between business partners are usually more complex than a
single request/response message exchange. A long running set of message
exchanges may, for example be used to implement a business interaction such
as procurement of goods or services. In this case there are advantages in
grouping individual messages into a longer running set of exchanges. Such an
exchange of messages is known as a conversation. Conversations may continue
between a pair of trading partners for a long time. Completion of a
conversation instance may take days, weeks or months. In a procurement process, an example conversation
may be:
</p><ol type="1"><li><p>A buyer request a quotation for some goods, the seller responds with the quote.</p></li><li><p>The buyer places a purchase order which the seller accepts.</p></li><li><p>The seller informs the buyer of delivery dates, the buyer accepts.</p></li><li><p>The buyer acknowledges delivery of the goods, the seller acknowledges.</p></li><li><p>The buyer provides payment, the seller issue a receipt.</p></li></ol><p>
All of the example message exchanges are related an instance of any agreement
between the two partners. For a message to be valid as part of the agreed
rules, each partner has to check whether the current message is valid within
the scope of the TPA.
</p><p>
<a href="#fig10">Figure 3-12</a> illustrates how this scenario could be implemented. Each partner's
SOAP processor has access to a database which is configured by the agreement agreed
between the two partners. A Conversation State Handler in the SOAP Sender
configures its SOAP Block with information that identifies a message with
conversation instance it is part of. A matching handler in the SOAP Receiver
uses the sender's information to test whether the received message is
acceptable within the rules of the agreement. It does this by checking with its own
rules database where the state information on each of the conversation
instances currently active is stored. If a message violates the rules of the
agreement, then the application can raise a fault condition.
</p><p>
Note that <a href="#fig10">Figure 3-12</a> does not include handlers for other message headers to
support reliability or security which may be required under the agreement.
</p><p>
In the following request and response examples, a ConversationState Header
is used to identify which agreement governs the exchange between the two
trading partners (AgreementId). To support multiple concurrent conversations
under the same agreement, a ConversationId element is included. The values of
AgreementId and ConversationId will remain constant for the lifetime of a
particular conversational exchange and will appear in both request and
response messages.
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP request message as part of a conversational exchange</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:ConversationState xmlns:n="http://example.org/conversation"&gt;
&lt;n:AgreementId&gt;uuid:09233523-345b-4351-b623-5dsf35sgs5d6&lt;/n:AgreementId&gt;
&lt;n:ConversationId&gt;uuid:02957815-38fh-39gp-0dj2-dm20fusy1n5j&lt;/n:ConversationId&gt;
&lt;/n:ConversationState&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
-----
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div><div class="exampleOuter">
<div class="exampleHead">Example: SOAP response message as part of a conversational exchange</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:ConversationState xmlns:n="http://example.org/conversation"&gt;
&lt;n:AgreementId&gt;uuid:09233523-345b-4351-b623-5dsf35sgs5d6&lt;/n:AgreementId&gt;
&lt;n:ConversationId&gt;uuid:02957815-38fh-39gp-0dj2-dm20fusy1n5j&lt;/n:ConversationId&gt;
&lt;/n:ConversationState&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
-----
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div></div><div class="div3">
<h4><a name="id2276592" id="id2276592"></a>3.13.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2276598" id="id2276598"></a>3.13.3.1 Requirements</h5><ol type="1"><li><p>A Sender shall be able to specify information in a message for its internal use. The sender shall send the same information for subsequent messages in a given conversation.
The receiver is required to echo this information for messages in a given conversation. An example of this is a client-side conversation ID.
</p></li><li><p>A Receiver shall be able to specify information in a message for its internal use. The receiver shall send the same information for subsequent messages in a given conversation.
The sender is required to echo this information for messages in a given conversation. An example of this is a server-side conversation ID.
</p></li><li><p>A Sender and a Receiver shall have a specification of sequences of allowable messages. This is sometimes called choreography, orchestration, or workflow. An example of this is Robin Milner's pi calculus.</p></li><li><p>A Sender and a receiver shall have a specification of the static characteristics of the interchange. The agreement might be specified in some or all of the messages exchanged.</p></li></ol></div><div class="div4">
<h5><a name="id2276651" id="id2276651"></a>3.13.3.2 Non-requirements</h5><ol type="1"><li><p>starting/stopping conversations at the protocol level. This is an application feature.
</p></li><li><p> timing out conversations at the protocol level. This is an application feature.</p></li></ol></div><div class="div4">
<h5><a name="id2276677" id="id2276677"></a>3.13.3.3 Candidate Technologies</h5><p>Sequencing aka choreography: WSCL, WSFL, XLang</p><p>Conversations: ebXML Message Service</p><p>Static characteristics: ebXML CPP/CPA, WSEL?</p></div></div><div class="div3">
<h4><a name="id2276696" id="id2276696"></a>3.13.4 Use case citations</h4><p>
This scenario is cited in <a href="#Technologi1rc"><b>2.3.5.1.4 Technologies / Requirements</b></a>.</p></div></div><div class="div2">
<h3><a name="S061" id="S061"></a>3.14 S061 Request with encrypted payload</h3><div class="div3">
<h4><a name="id2276720" id="id2276720"></a>3.14.1 Scenario Definition</h4><p>
A sender wishes to exchange data with a receiver and has agreed to encrypt
the all of or a portion of the payload. The sending and receiving applications agree on the encryption
methodology. Data is encrypted by the originating application and sent to
the receiver via SOAP. The data reaches the receiving application untouched,
and may then be decrypted in the agreed-upon manner. This
scenario is applicable to the Travel Reservation Use Case
(see <a href="#ta"><b>2.1 Travel agent use case, static discovery</b></a>).
</p></div><div class="div3">
<h4><a name="id2276744" id="id2276744"></a>3.14.2 Description</h4><div class="figure"><a name="fig8" id="fig8"></a><br /><img src="soap-usage-fig8.png" alt="Request with encrypted payload" /><p><i><span>Figure 3-13. </span>Request with encrypted payload</i></p><br /></div><p>
Scenario S061 describes two applications that wish to share encrypted data as an
opaque body in a SOAP message. It places no requirements on the SOAP messaging
layer. <a href="#fig8">Figure 3-13</a> illustrates this scenario.
</p><div class="exampleOuter">
<div class="exampleHead">Example: Plaintext SOAP message</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Body&gt;
&lt;m:PurchaseTicket xmln:m="some-URI"&gt;
&lt;m:PNR&gt;ABCDEFGH&lt;/m:PNR&gt;
&lt;m:CreditCard&gt;4500123456789abc&lt;/m:CreditCard&gt;
&lt;/m:PurchaseTicket&gt;
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div><p>
The following is the encrypted version of the above plain SOAP message. The
body entry &lt;m:PurchaseTicket&gt; is encrypted using a symmetric key
identified by the key name "Symmetric Key" and replaced by the
&lt;xenc:EncryptedData&gt; element with an id "encrypted-body-entry".
A &lt;sec:Encryption&gt; header entry for this encrypted data is added
to the SOAP header. Note that the &lt;sec:EncryptedDataList&gt; element
in the header entry has a reference to the &lt;xenc:EncryptedData&gt; element.
The symmetric key used for encryption is stored in the &lt;xenc:EncryptedKey&gt;
element in the header entry in an encrypted form, that is, it is encrypted by
John Smith's RSA public key.
</p><div class="exampleOuter">
<div class="exampleHead">Example: Encrypted SOAP message</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;sec:Encryption xmlns:sec="http://schemas.xmlsoap.org/soap/security/2000-12"
env:actor="some-URI"
env:mustUnderstand="true"&gt;
&lt;sec:EncryptedDataList&gt;
&lt;sec:EncryptedDataReference URI="#encrypted-body-entry"/&gt;
&lt;/sec:EncryptedDataList&gt;
&lt;xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Id="EK"
CarriedKeyName="Symmetric Key"
Recipient="John Smith"&gt;
&lt;xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/&gt;
&lt;ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"&gt;
&lt;ds:KeyName&gt;John Smith's RSA Key&lt;/ds:KeyName&gt;
&lt;/ds:KeyInfo&gt;
&lt;xenc:CipherData&gt;
&lt;xenc:CipherValue&gt;ENCRYPTED 3DES KEY......&lt;/xenc:CipherValue&gt;
&lt;/xenc:CipherData&gt;
&lt;xenc:ReferenceList&gt;
&lt;xenc:DataReference URI="#encrypted-body-entry"/&gt;
&lt;/xenc:ReferenceList&gt;
&lt;/xenc:EncryptedKey&gt;
&lt;/sec:Encryption&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
&lt;xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
Id="encrypted-body-entry"
Type="http://www.w3.org/2001/04/xmlenc#Element"&gt;
&lt;xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/&gt;
&lt;ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#"&gt;
&lt;ds:RetrievalMethod URI="#EK" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/&gt;
&lt;ds:KeyName&gt;Symmetric Key&lt;/ds:KeyName&gt;
&lt;/ds:KeyInfo&gt;
&lt;xenc:CipherData&gt;
&lt;xenc:CipherValue&gt;ENCRYPTED BODY ENTRY......&lt;/xenc:CipherValue&gt;
&lt;/xenc:CipherData&gt;
&lt;/xenc:EncryptedData&gt;
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div></div><div class="div3">
<h4><a name="id2276901" id="id2276901"></a>3.14.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2276907" id="id2276907"></a>3.14.3.1 Requirements</h5><ol type="1"><li><p>Encrypt portions of the payload</p></li><li><p>Point to Point</p></li><li><p>Specification of c14n algorithm used. Perhaps in spec, or in WSD?</p></li></ol></div><div class="div4">
<h5><a name="id2276938" id="id2276938"></a>3.14.3.2 Candidate Technologies</h5><p>SOAP-Security, WS-Security</p></div></div><div class="div3">
<h4><a name="id2276949" id="id2276949"></a>3.14.4 Use case citations</h4><p>
This scenario is cited in <a href="#Scenario2"><b>2.1.5.3.2 Scenario / Steps</b></a>; <a href="#L312-Scenario2"><b>2.2.5.3.2 Scenario / Steps</b></a>.</p></div></div><div class="div2">
<h3><a name="S062" id="S062"></a>3.15 S062 Message header and payload encryption</h3><div class="div3">
<h4><a name="id2276980" id="id2276980"></a>3.15.1 Scenario Definition</h4><p>
Two trading partners engaged in a message exchange may agree to
cryptographically sign and verify one or more message header, such as a routing
header or a conversation header, and/ or the payload. The sender or originating application may
perform the signing of the payload. The sending message handler signs the
message header. A routing header may be appended to the message header.
The routing header may also be signed by a message service
handler. This scenario is applicable to the Travel
Reservation Use Case (see <a href="#ta"><b>2.1 Travel agent use case, static discovery</b></a>) for the communications to the credit card service, where the message is not being sent over a secure channel, such as SMTP.
</p></div><div class="div3">
<h4><a name="id2277008" id="id2277008"></a>3.15.2 Description</h4><div class="figure"><a name="fig11" id="fig11"></a><br /><img src="soap-usage-fig11.png" alt="Header and payload encryption" /><p><i><span>Figure 3-14. </span>Header and payload encryption</i></p><br /></div><p>
In scenario <a href="#S061">S061</a>, two applications communicated using encrypted payloads.
These opaque payloads had no impact on the SOAP processing layer. In this
scenario, the action of signing and/or encrypting the headers or payload
is the responsibility of the SOAP processing layer. <a href="#fig11">Figure 3-14</a> illustrates
how the encryption agreements are accessible to a Message Signing Handler
on the SOAP Sender and a matching Message Verification Handler on the SOAP
Receiver. An additional Message Routing Header may also be part of the SOAP
message. This header may also be signed and verified if needed by the security
requirements of the message exchange.
</p></div><div class="div3">
<h4><a name="id2277061" id="id2277061"></a>3.15.3 Use case citations</h4><p>
This scenario is cited in <a href="#Scenario2"><b>2.1.5.3.2 Scenario / Steps</b></a>; <a href="#L312-Scenario2"><b>2.2.5.3.2 Scenario / Steps</b></a>.</p></div></div><div class="div2">
<h3><a name="S0621" id="S0621"></a>3.16 S0621 Attachment encryption</h3><div class="div3">
<h4><a name="id2277091" id="id2277091"></a>3.16.1 Scenario Definition</h4><p>
Two trading partners engaged in a message exchange may agree to
cryptographically sign and verify an attachment, that is content that is not directly part of the SOAP envelope.
The sender or originating application may
perform the encryption of the attachment. This scenario is
applicable for the Travel Reservation Use Case (see
<a href="#ta"><b>2.1 Travel agent use case, static discovery</b></a>) for the communications to the credit card service, where a image of a signature is attached to the message.
</p></div><div class="div3">
<h4><a name="id2277114" id="id2277114"></a>3.16.2 Description</h4><p>
In scenario S0621, two applications communicated using encrypted payloads.
These opaque payloads had no impact on the SOAP processing layer. In this
scenario, the action of encrypting the attachment
is the responsibility of the SOAP processing layer. This scenario is similar to <a href="#S062">S062</a>.
</p></div><div class="div3">
<h4><a name="id2277134" id="id2277134"></a>3.16.3 Use case citations</h4><p>
This scenario is cited in <a href="#Scenario2"><b>2.1.5.3.2 Scenario / Steps</b></a>; <a href="#L312-Scenario2"><b>2.2.5.3.2 Scenario / Steps</b></a>.</p></div></div><div class="div2">
<h3><a name="S063" id="S063"></a>3.17 S063 Authentication </h3><div class="div3">
<h4><a name="id2277164" id="id2277164"></a>3.17.1 Scenario Definition</h4><p>A web service client presents credentials or tokens to a web service.</p></div><div class="div3">
<h4><a name="id2277174" id="id2277174"></a>3.17.2 Description</h4><p></p></div><div class="div3">
<h4><a name="id2277183" id="id2277183"></a>3.17.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2277189" id="id2277189"></a>3.17.3.1 Requirements</h5><ol type="1"><li><p>Shall support Username/password credential</p></li><li><p>Shall support binary credentials, such as X.509 certificates</p></li><li><p>Shall support authentication across trust domains.</p></li><li><p>Shall define a trust model.</p></li></ol></div><div class="div4">
<h5><a name="id2277227" id="id2277227"></a>3.17.3.2 Candidate Technologies</h5><p>HTTP Authentication, WS-Security</p></div></div><div class="div3">
<h4><a name="id2277238" id="id2277238"></a>3.17.4 Use case citations</h4><p>
This scenario is cited in <a href="#Technologi1rc"><b>2.3.5.1.4 Technologies / Requirements</b></a>; <a href="#Technologi1rc"><b>2.3.5.1.4 Technologies / Requirements</b></a>.</p></div></div><div class="div2">
<h3><a name="S064" id="S064"></a>3.18 S064 Message Integrity</h3><div class="div3">
<h4><a name="id2277267" id="id2277267"></a>3.18.1 Scenario Definition</h4><p>A sender and receiver may wish to be able to determine if a message has been modified in transit, and point-to-point encryption is not appropriate, perhaps because of intermediaries or system architecture choices.</p></div><div class="div3">
<h4><a name="id2277281" id="id2277281"></a>3.18.2 Description</h4><p></p></div><div class="div3">
<h4><a name="id2277289" id="id2277289"></a>3.18.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2277295" id="id2277295"></a>3.18.3.1 Requirements</h5><ol type="1"><li><p>Sign arbitrary portions of a document</p></li><li><p>Shall use Digital Signatures</p></li></ol></div><div class="div4">
<h5><a name="id2277319" id="id2277319"></a>3.18.3.2 Candidate Technologies</h5><p>SOAP Security, WS-Security</p></div></div></div><div class="div2">
<h3><a name="S065" id="S065"></a>3.19 S065 Authentication of data</h3><div class="div3">
<h4><a name="id2277342" id="id2277342"></a>3.19.1 Scenario Definition</h4><p>Part of a request sent to a Web service need to be
authenticated, e.g. to guarantee that a payment
authorization for a purchase was issued by a well-known and
trusted bank.</p></div><div class="div3">
<h4><a name="id2277355" id="id2277355"></a>3.19.2 Description</h4><p>A request is sent from a user to a Web service. This
request contains some payment authorization issued by a
payment service.</p><p>Before processing the request, the service verifies that
the payment authorization information has been issued by a
valid payment organization (bank, credit card company,
...).</p><p>Variant of this scenario: the user sends the request to
the Web service via the payment organization, with a payment
authorization request. The payment organization processes
the payment authorization request, includes payment
authorization information with a signature guaranteeing its
authenticity. It then forwards it to the Web service; the
request contains at this point the original request from the
user along with the signed payment authorization.</p></div><div class="div3">
<h4><a name="id2277384" id="id2277384"></a>3.19.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2277390" id="id2277390"></a>3.19.3.1 Requirements</h5><ol type="1"><li><p>The security framework must support authentication
of data.</p></li><li><p>It must be possible to sign part of messages.</p></li></ol></div><div class="div4">
<h5><a name="id2277415" id="id2277415"></a>3.19.3.2 Non-requirements</h5></div><div class="div4">
<h5><a name="id2277422" id="id2277422"></a>3.19.3.3 Candidate Technologies</h5><p>XML-Signature, WS-Security</p></div></div><div class="div3">
<h4><a name="id2277432" id="id2277432"></a>3.19.4 Use case citations</h4><p>
This scenario is cited in <a href="#Technologi1rc"><b>2.3.5.1.4 Technologies / Requirements</b></a>; <a href="#Scenario2"><b>2.1.5.3.2 Scenario / Steps</b></a>; <a href="#L312-Scenario2"><b>2.2.5.3.2 Scenario / Steps</b></a>.</p></div></div><div class="div2">
<h3><a name="S070" id="S070"></a>3.20 S070 Asynchronous messaging</h3><div class="div3">
<h4><a name="id2277467" id="id2277467"></a>3.20.1 Scenario Definition</h4><p>
A sender sends a message asynchronously to a receiver expecting some response
at a later time. The sender tags the request with an identifier allowing the
response to be correlated with the originating request. The sender may also
tag the message with an identifier for another service (other than the
originating sender) which will be the recipient of the response.
</p></div><div class="div3">
<h4><a name="id2277484" id="id2277484"></a>3.20.2 Description</h4><div class="figure"><a name="fig13" id="fig13"></a><br /><img src="soap-usage-fig13.png" alt="Asynchronous messaging" /><p><i><span>Figure 3-15. </span>Asynchronous messaging</i></p><br /></div><p>
Scenario S070 is the same as the basic request/response pattern described in
scenario <a href="#S003">S003</a>. The difference is that the request and response messages are
separated in time and implemented as two unidirectional messages. The sending
SOAP Application does not block and wait for the response to return. The
sending SOAP Application is notified when a response is received by its SOAP
Receiver. It then uses the correlation information within the received message
to match the response to a message it sent some time earlier.
</p><p>
<a href="#fig13">Figure 3-15</a> illustrates a possible implementation. In the request SOAP message,
a Message Identifier Handler is responsible for generating a unique message
identifier and inserting it into a SOAP Header. This forms part of the SOAP
request message and is sent from SOAP Application 1 to the receiving SOAP
Application 2. The request message is processed by a business application
and a response message is assembled. This includes a SOAP Header built by
a Message Correlation Handler which links the response message to its
associated request.
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP asynchronous request message containing a message identifier</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:MsgHeader xmlns:n="http://example.org/requestresponse"&gt;
&lt;n:MessageId&gt;uuid:09233523-345b-4351-b623-5dsf35sgs5d6&lt;/n:MessageId&gt;
&lt;/n:MsgHeader&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
........
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;</pre></div></div><div class="exampleOuter">
<div class="exampleHead">Example: SOAP asynchronous response message containing correlation to original request</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:MsgHeader xmlns:n="http://example.org/requestresponse"&gt;
&lt;n:MessageId&gt;uuid:09233523-567b-2891-b623-9dke28yod7m9&lt;/n:MessageId&gt;
&lt;n:ResponseTo&gt;uuid:09233523-345b-4351-b623-5dsf35sgs5d6&lt;/n:ResponseTo&gt;
&lt;/n:MsgHeader&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
........
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;</pre></div></div></div><div class="div3">
<h4><a name="id2277593" id="id2277593"></a>3.20.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2277599" id="id2277599"></a>3.20.3.1 Requirements</h5><ol type="1"><li><p>. A sender shall be able to specify a URI for a receiver to send subsequent
messages to, aka callback.</p><ol type="a"><li><p>This address can be contained in a message (dynamic)
</p></li><li><p>This address can be defined at an interface (static)
</p></li><li><p>This address can be specified in a 3rd party</p></li></ol></li></ol></div><div class="div4">
<h5><a name="id2277643" id="id2277643"></a>3.20.3.2 Candidate Technologies</h5><p>Static: ebXML CPP/CPA</p><p>Dynamic: WS-Address, WS-Callback</p><p>Third Party: ebXML Registry, UDDI</p></div></div><div class="div3">
<h4><a name="id2277661" id="id2277661"></a>3.20.4 Use case citations</h4><p>
This scenario is cited in <a href="#Technologi1rc"><b>2.3.5.1.4 Technologies / Requirements</b></a>.</p></div></div><div class="div2">
<h3><a name="S072" id="S072"></a>3.21 S072 Multiple asynchronous responses</h3><div class="div3">
<h4><a name="id2277684" id="id2277684"></a>3.21.1 Scenario Definition</h4><p>
An application requests some information from a server, which is returned at a
later time in multiple responses. This can be because the requested information
was not available all at once (e.g., distributed web searches).
</p></div><div class="div3">
<h4><a name="id2277699" id="id2277699"></a>3.21.2 Description</h4><div class="figure"><a name="fig16" id="fig16"></a><br /><img src="soap-usage-fig16.png" alt="Multiple asynchronous responses" /><p><i><span>Figure 3-16. </span>Multiple asynchronous responses</i></p><br /></div><p>
Scenario S072 is an extension of scenario <a href="#S070">S070</a> - asynchronous messaging.
Instead of a single response message, more than one can be sent by the
receiving application to the originator. A simple architecture would be
the same as <a href="#S070">S070</a> with multiple responses received by the originating
application and correlated to the original request by a Message Correlation
Handler. <a href="#fig16">Figure 3-16</a> illustrates an extension to this using a Sequence Handler.
The Sequence Handler ensures that a unique sequence number is added to each
response message. If the responding application knows in advance that there
will be a fixed number of multiple responses, then the Sequence Handler may
use an N of M format to indicate how many response messages are to be expected.
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP request message containing a message identifier</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:MsgHeader xmlns:n="http://example.org/requestresponse"&gt;
&lt;n:MessageId&gt;uuid:09233523-345b-4351-b623-5dsf35sgs5d6&lt;/n:MessageId&gt;
&lt;/n:MsgHeader&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
........
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div><div class="exampleOuter">
<div class="exampleHead">Example: First SOAP response message containing sequencing and correlation to original request</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:MsgHeader xmlns:n="http://example.org/requestresponse"&gt;
&lt;!-- MessageId will be unique for each response message --&gt;
&lt;!-- ResponseTo will be constant for each response message in the sequence--&gt;
&lt;n:MessageId&gt;uuid:09233523-567b-2891-b623-9dke28yod7m9&lt;/n:MessageId&gt;
&lt;n:ResponseTo&gt;uuid:09233523-345b-4351-b623-5dsf35sgs5d6&lt;/n:ResponseTo&gt;
&lt;/n:MsgHeader&gt;
&lt;s:Sequence xmlns:s="http://example.org/sequence"&gt;
&lt;s:SequenceNumber&gt;1&lt;/s:SequenceNumber&gt;
&lt;s:TotalInSequence&gt;5&lt;/s:TotalInSequence&gt;
&lt;/s:Sequence&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
........
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div><div class="exampleOuter">
<div class="exampleHead">Example: Final SOAP response message containing sequencing and correlation to original request</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:MsgHeader xmlns:n="http://example.org/requestresponse"&gt;
&lt;!-- MessageId will be unique for each response message --&gt;
&lt;!-- ResponseTo will be constant for each response message in the sequence--&gt;
&lt;n:MessageId&gt;uuid:40195729-sj20-pso3-1092-p20dj28rk104&lt;/n:MessageId&gt;
&lt;n:ResponseTo&gt;uuid:09233523-345b-4351-b623-5dsf35sgs5d6&lt;/n:ResponseTo&gt;
&lt;/n:MsgHeader&gt;
&lt;s:Sequence xmlns:s="http://example.org/sequence"&gt;
&lt;s:SequenceNumber&gt;5&lt;/s:SequenceNumber&gt;
&lt;s:TotalInSequence&gt;5&lt;/s:TotalInSequence&gt;
&lt;/s:Sequence&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
........
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div></div></div><div class="div2">
<h3><a name="S080" id="S080"></a>3.22 S080 Transaction</h3><div class="div3">
<h4><a name="id2277856" id="id2277856"></a>3.22.1 Scenario Definition</h4><p>Transaction contexts are shared between two systems</p></div><div class="div3">
<h4><a name="id2277866" id="id2277866"></a>3.22.2 Description</h4><p></p></div><div class="div3">
<h4><a name="id2277875" id="id2277875"></a>3.22.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2277881" id="id2277881"></a>3.22.3.1 Candidate Technologies</h5><p>WS-Transaction, WS-Coordination, OASIS BTP</p></div></div><div class="div3">
<h4><a name="id2277892" id="id2277892"></a>3.22.4 Use case citations</h4><p>
This scenario is cited in <a href="#Scenario2"><b>2.1.5.3.2 Scenario / Steps</b></a>.</p></div></div><div class="div2">
<h3><a name="S090" id="S090"></a>3.23 S090 Sending non-XML data</h3><div class="div3">
<h4><a name="id2277915" id="id2277915"></a>3.23.1 Scenario Definition</h4><p>
A digital camera wishes to transmit image data over a wireless link using
SOAP to a remote server. The binary image data (non-XML) accompanies the
message. The digital camera represents a situation in which connections from
the receiver to the sender may not be permitted due to device limitations or
firewalls.
</p></div><div class="div3">
<h4><a name="id2277932" id="id2277932"></a>3.23.2 Description</h4><div class="figure"><a name="fig14" id="fig14"></a><br /><img src="soap-usage-fig14.png" alt="Sending non-XML data" /><p><i><span>Figure 3-17. </span>Sending non-XML data</i></p><br /></div><p>
Support for non-XML data has been described elsewhere. The SOAP with
Attachments <a href="#">[SOAPAttach]</a> note to the W3C has been adopted by the ebXML
Message Services specification <a href="#">[EBXML]</a> as the basis for defining a message
structure which can support non-XML data. The <a href="http://www.w3.org/2000/xp/Group/">XML Protocol Working
Group</a> is working on the optimization of the transmission of SOAP
messages, which includes the transmission of non-XML data along with
a SOAP envelope: <a href="http://www.w3.org/TR/soap12-mtom/">SOAP
Message Transmission Optimization Mechanism</a>. Supporting non-XML data requires
additional packaging of the message which can be provided by a MIME multipart
structure and impacts the binding of a message to its underlying transport
protocol. <a href="#fig14">Figure 3-17</a> illustrates a unidirectional SOAP message path. A Message
Manifest Handler is implemented which creates a set of references to the
different parts of a multipart MIME package. Each part is referenced by its
content identifier.
</p><div class="figure"><a name="fig15" id="fig15"></a><br /><img src="soap-usage-fig15.png" alt="Using MIME packaging for non-XML data" /><p><i><span>Figure 3-18. </span>Using MIME packaging for non-XML data</i></p><br /></div><p>
<a href="#fig15">Figure 3-18</a> illustrates how different parts of a message are packaged using MIME
multipart. The outermost MIME envelope packages a set of individual MIME parts.
The first MIME part contains a SOAP message which includes the Manifest Header
block created by the Message Manifest Handler. The second and subsequent MIME
parts contain payload(s) which may be XML documents or any other MIME content
type such as image, audio or video data. The SOAP manifest header can contain
elements that reference the separate MIME parts using their content identifiers.
This may be achieved using XLink references as shown in the following example.
The XLink role attribute may be used to further qualify the type of data
contained within the payload.
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP message containing a manifest for non-XML data</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Header&gt;
&lt;n:Manifest xmlns:n="http://example.org/manifest"&gt;
&lt;n:Reference n:id="image01"
xlink:href="cid:payload-1"
xlink:role="http://example.org/image"&gt;
&lt;n:Description&gt;My first holiday photograph&lt;/n:Description&gt;
&lt;/n:Reference&gt;
&lt;n:Reference n:id="image02"
xlink:href="cid:payload-2"
xlink:role="http://example.org/image"&gt;
&lt;n:Description&gt;My second holiday photograph&lt;/n:Description&gt;
&lt;/n:Reference&gt;
&lt;/n:Manifest&gt;
&lt;/env:Header&gt;
&lt;env:Body&gt;
........
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div></div><div class="div3">
<h4><a name="id2278103" id="id2278103"></a>3.23.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2278109" id="id2278109"></a>3.23.3.1 Candidate Technologies</h5><p>SOAP with Attachments, DIME, Infoset Addendum to SwA</p></div></div><div class="div3">
<h4><a name="id2278120" id="id2278120"></a>3.23.4 Use case citations</h4><p>
This scenario is cited in <a href="#Scenario2"><b>2.1.5.3.2 Scenario / Steps</b></a>.</p></div></div><div class="div2">
<h3><a name="S200" id="S200"></a>3.24 S200 Event notification</h3><div class="div3">
<h4><a name="id2278144" id="id2278144"></a>3.24.1 Scenario Definition</h4><p>
An application subscribes to notifications of certain named events from an
event source. When such events occur, notifications are sent back to the
originating application (first party notification) or to another application
(third party notification). For example, an application can subscribe to
notification of various aspects of a printer's status (e.g., running out of
paper, ink etc.). The notifications of such events could be delivered to a
management application.
</p></div><div class="div3">
<h4><a name="id2278163" id="id2278163"></a>3.24.2 Description</h4><div class="figure"><a name="fig17" id="fig17"></a><br /><img src="soap-usage-fig17.png" alt="Publish and subscribe" /><p><i><span>Figure 3-19. </span>Publish and subscribe</i></p><br /></div><p>
Scenario S200 describes event notification using a publish subscribe mechanism.
An implementation of this scenario uses an example of the request/response
scenario <a href="#S003">S003</a> to register a subscription and fire-and-forget to multiple
receivers scenario <a href="#S002">S002</a> for the notification. <a href="#fig17">Figure 3-19</a> illustrates how a
request/response message pattern can be used with a Subscription Request
Handler to register an interest (or subscription) in some set of events.
The registration is made with some subscription service. The success or
otherwise of the registration is returned to the subscribing application
using a Subscription Ack Handler which provides an acknowledgement to the
subscribing application.
</p><p>
Delivery of an event notification to a set of subscribers may be implemented
using the fire-and-forget to multiple receivers scenario <a href="#S002">S002</a>. The subscription
service provides the list of valid applications that have registered an
interested in a particular event. This list may then be converted into a
group address or distribution list to support the implementation of the
fire-and-forget scenario.
</p><p>
A subscription request may include a list of events within the SOAP Body as
in the following example.In this example, a subscription is registered with
a stock price notification service. The subscribing application will be
informed of company BigCo's stock price, volume traded and time whenever
the price is greater than 100.
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP event subscription request message</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Body&gt;
&lt;s:StockNotificationSubscription xmlns:s="http://example.org/2001/06/subscribe"&gt;
&lt;s:Notify&gt;PRICE&lt;/s:Notify&gt;
&lt;s:Notify&gt;VOLUME&lt;/s:Notfy&gt;
&lt;s:Notify&gt;TIMESTAMP&lt;/s:Notfy&gt;
&lt;s:When&gt;
&lt;s:Company&gt;BigCo&lt;/s:Company&gt;
&lt;s:Price range="GreaterThan"&gt;100&lt;/s:Price&gt;
&lt;/s:When&gt;
&lt;/s:StockNotificationSubscription&gt;
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div><p>
An acknowledgement may include an identifier to the subscription as in the
following example:
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP event subscription acknowledgement response</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Body&gt;
&lt;s:StockNotificationSubscriptionAck xmlns:s="http://example.org/2001/06/subscribe"&gt;
&lt;s:SubscriptionId&gt; uuid:40195729-sj20-pso3-1092-p20dj28rk104&lt;/s:SubscriptionId&gt;
&lt;/s:StockNotificationSubscriptionAck&gt;
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div><p>
The identification may be used in subsequent notifications to the application
as a result of the subscription:
</p><div class="exampleOuter">
<div class="exampleHead">Example: SOAP event notification</div><div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2002/06/soap-envelope"&gt;
&lt;env:Body&gt;
&lt;n:StockNotification xmlns:n="http://example.org/2001/06/notification"&gt;
&lt;n:SubscriptionId&gt; uuid:40195729-sj20-pso3-1092-p20dj28rk104&lt;/n:SubscriptionId&gt;
&lt;n:Company&gt;BigCo&lt;/n:Company&gt;
&lt;n:Price&gt;100.56&lt;/n:Price&gt;
&lt;n:Volume&gt;102345&lt;/n:Volume&gt;
&lt;n:Timestamp&gt;2001-03-09T12:22:30Z&lt;/n:Timestamp&gt;
&lt;/n:StockNotification&gt;
&lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div></div></div></div><div class="div2">
<h3><a name="S300" id="S300"></a>3.25 S300 System Messages</h3><div class="div3">
<h4><a name="id2278342" id="id2278342"></a>3.25.1 Scenario Definition</h4><p>
A sender or other party sends messages to a receiver inquiring about the status of the service or message or to control the execution of the message
</p></div><div class="div3">
<h4><a name="id2278355" id="id2278355"></a>3.25.2 Description</h4><p>A sender wishes to determine if a service is available. It sends a synchronous message querying the status of the service. Later, the sender sends an asynchronous message to the service. The sender then wishes to determine or control the status of the asynchronous message. It sends a synchronous message querying the status of the asynch message.
</p></div><div class="div3">
<h4><a name="id2278371" id="id2278371"></a>3.25.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2278377" id="id2278377"></a>3.25.3.1 Requirements</h5><ol type="1"><li><p>Shall be possible to "ping" availability of service</p></li><li><p>Shall be possible to query message status</p></li><li><p>Shall be possible to control message</p></li></ol></div><div class="div4">
<h5><a name="id2278408" id="id2278408"></a>3.25.3.2 Non-requirements</h5></div><div class="div4">
<h5><a name="id2278415" id="id2278415"></a>3.25.3.3 Candidate Technologies</h5><p>ebXML Ping, Status messages</p></div></div></div><div class="div2">
<h3><a name="S500" id="S500"></a>3.26 S500 Service Metadata </h3><div class="div3">
<h4><a name="id2278438" id="id2278438"></a>3.26.1 Scenario Definition</h4><p>Service providers can provide custom data</p></div><div class="div3">
<h4><a name="id2278449" id="id2278449"></a>3.26.2 Description</h4><p>A WS provider can decorate various elements of the service description with custom attributes. These attributes may be application specific and would be described by the WS provider in an additional documentation. Such custom attributes may be defined in a specific schema. WS provider may include such extra information as owner e-mail, link to SLA, security and session requirements for a particular message, etc.</p><p>
A conversation between two trading partners may also be defined by shared
configuration information such as an ebXML Collaboration Profile Agreement (CPA).
A conversation agreement includes information such as expected response times, business process
actions that each party undertakes to complete, security information and
message content structures.
</p></div><div class="div3">
<h4><a name="id2278476" id="id2278476"></a>3.26.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2278481" id="id2278481"></a>3.26.3.1 Requirements</h5><ol type="1"><li><p>Information inline in the WSDL</p></li><li><p>Information external to the WSDL</p></li></ol></div><div class="div4">
<h5><a name="id2278506" id="id2278506"></a>3.26.3.2 Non-requirements</h5></div></div></div><div class="div2">
<h3><a name="S501" id="S501"></a>3.27 S501 Service Level attributes</h3><div class="div3">
<h4><a name="id2278525" id="id2278525"></a>3.27.1 Scenario Definition</h4><p>Declaration of service level attributes</p></div><div class="div3">
<h4><a name="id2278535" id="id2278535"></a>3.27.2 Description</h4><p>Two web services, implementing the interface for "looking up for insurance providers", from different sources are offered in a registry. One of the two services actually performs extensive data validation on the data provided, for example making sure that the zip codes in the address provided are valid", while the other web service assumes that the data provided is valid and searches for insurance providers has already been validated and uses it to perform its search without any further validation. The interface was developed by an industry consortium that agreed to reflect the data validation capability of the services as a service-level attribute. Some intelligent registries may then actually allow search criteria that can be predicated on these service-level attributes or alternatively, the client application may check the value of the service level attribute itself at runtime to find out its value. The service-level attribute may be mapped to accessor methods which can be invoked either by the intelligent registry as part of executing the search query or by the client application itself.</p></div><div class="div3">
<h4><a name="id2278564" id="id2278564"></a>3.27.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2278569" id="id2278569"></a>3.27.3.1 Requirements</h5></div><div class="div4">
<h5><a name="id2278576" id="id2278576"></a>3.27.3.2 Non-requirements</h5></div></div></div><div class="div2">
<h3><a name="S502" id="S502"></a>3.28 S502 Operation Level attributes </h3><div class="div3">
<h4><a name="id2278595" id="id2278595"></a>3.28.1 Scenario Definition</h4><p>Declaration of operational level attributes
</p></div><div class="div3">
<h4><a name="id2278606" id="id2278606"></a>3.28.2 Description</h4><p>In an advanced architecture where distributed transactions are supported, a web service may want to declare some of its operations as transactional as opposed to the entire interface being transactional. A web service offering various financial related web services may be able to verify a buyer's credit in a non-transactional manner but may require the client application to start a transaction before invoking the operation to prepare an invoice. The target web service may have a declarator on the method specification that indicates that the operation for invoicing requires transaction
</p></div><div class="div3">
<h4><a name="id2278625" id="id2278625"></a>3.28.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2278631" id="id2278631"></a>3.28.3.1 Requirements</h5></div><div class="div4">
<h5><a name="id2278638" id="id2278638"></a>3.28.3.2 Non-requirements</h5></div></div></div><div class="div2">
<h3><a name="S504" id="S504"></a>3.29 S504 Versioning</h3><div class="div3">
<h4><a name="id2278656" id="id2278656"></a>3.29.1 Scenario Definition</h4><p>Specifying interface versioning</p></div><div class="div3">
<h4><a name="id2278667" id="id2278667"></a>3.29.2 Description</h4><p>A WS provider can describe versions of interfaces implemented by a service. WS client can bind to the necessary interface version. This way there is no ambiguity when WS provider changes service interfaces and client has created a static proxy that uses previous version of interfaces.
WS provider can deprecate and remove interfaces as desired, and the client would know that. Client would send a SOAP request that would not be accepted (as namespaces do not match), as opposed to client trying to send a SOAP request that could be accepted, but improperly executed.
</p></div><div class="div3">
<h4><a name="id2278686" id="id2278686"></a>3.29.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2278692" id="id2278692"></a>3.29.3.1 Requirements</h5></div><div class="div4">
<h5><a name="id2278699" id="id2278699"></a>3.29.3.2 Non-requirements</h5></div></div></div><div class="div2">
<h3><a name="S505" id="S505"></a>3.30 S505 Classification system for operations</h3><div class="div3">
<h4><a name="id2278717" id="id2278717"></a>3.30.1 Scenario Definition</h4><p></p></div><div class="div3">
<h4><a name="id2278726" id="id2278726"></a>3.30.2 Description</h4><p>Imagine a component framework in which components and their operations (building finally the component's functionality) should be described with WSDL. In the framework the components are using operations from each other dynamically: in the program code there is no "hard-wired" function call but instead a "semantic description/reference" of what kind of operation to use, which will be dissolved just in time before execution. With this "semantic description" a search for suitable operations could be started in a (logical) centralized registry (maybe with UDDI). The registry contains (WSDL) information of all currently available components/operations within the framework. Result of the search query are the concrete binding parameters (protocol, URL, operation signature, etc.) of the matching operations. Finding a suitable match _automatically_ (without manual/human interaction) will be done by searching in the registered WSDL files for the specified "semantic description". One half of this "semantic description" are the parameters defined with complex XML schema types. The other one should be the determination of the operation (i.e. its functionality). But only considering the operation name has the same drawbacks as comparing parameters only by their name (or even simple types like integer, string, etc.): only operations with exactly the same name as chosen from the operation's programmer are returned. So with introducing a kind of "type system" for operations (or maybe a classification) would bring the benefit that the result set of the above mentioned query could return operations with different names, but which are implementing the same functionality/behavior. With this it would also be possible to exchange one component (respectively their operation/s) with another independently developed one, which has the same functionality but with (maybe only slightly) different operation name(s) - and this without further manual interaction.
</p></div><div class="div3">
<h4><a name="id2278802" id="id2278802"></a>3.30.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2278808" id="id2278808"></a>3.30.3.1 Requirements</h5></div><div class="div4">
<h5><a name="id2278814" id="id2278814"></a>3.30.3.2 Non-requirements</h5></div></div></div><div class="div2">
<h3><a name="S510" id="S510"></a>3.31 S510 Quality of service</h3><div class="div3">
<h4><a name="id2278833" id="id2278833"></a>3.31.1 Scenario Definition</h4><p>
A SOAP sender (not necessarily the initial SOAP sender) wants the SOAP
message to be handled with specific quality of service as it traverses
the SOAP message path to include multiple SOAP Processing intermediaries.
Information in the SOAP message is used to select appropriate QoS
mechanisms (e.g., RSVP, Diffserv, MPLS, etc.). Selection of QoS may be
constrained by QoS policies, Service Level Agreements (SLAs), Service
Level Specifications (SLS).
</p></div><div class="div3">
<h4><a name="id2278852" id="id2278852"></a>3.31.2 Description</h4><p>
A SOAP header block is one possible approach to implementing this scenario. The
SOAP 1.2 specification does not define this hypothetical SOAP Quality Of Service
(QoS) block. An initial SOAP sender sends a SOAP message containing a QoS header
block through one or more SOAP intermediaries to an ultimate SOAP receiver. The
intermediary is targeted by the initial SOAP sender from within the SOAP message
by inserting a role attribute within the QoS Block to be used at the SOAP
intermediary as described in the SOAP processing model (Part 1, section 2.5).
The SOAP specifications do not state how the role attribute is to be used by
the SOAP sender. Potentially, it can be used in the context of the SOAP binding
framework to provide a hint for message routing. However, message routing is not within the scope of the SOAP 1.2
specifications. The SOAP intermediary must examine the SOAP QoS Block, and
determine how to invoke the QoS capabilities exposed via the SOAP binding. If
the SOAP QoS Block is marked mustUnderstand, then the intermediary is expected
to be QoS-aware. If it is not QoS-aware, then a SOAP fault is generated, as this
mandatory header cannot be processed. If it is QoS-aware, but cannot honor the
specific QoS parameters carried in the QoS Block, then any fault or other
response to the sender or elsewhere (e.g., log file) is not defined in the SOAP
specifications. The specification of the QoS extension, when defined, would need
to describe error handling, negotiations, or other processing under all
circumstances.
</p><p>
If the intermediary is QoS-aware, then presumably the information in the QoS
Block is used when forwarding the SOAP message further along on its message path
toward the ultimate SOAP receiver. In addition to the use of SOAP Blocks to
extend the functionality of SOAP, this scenario may also require extensions to
the HTTP binding, or a completely new binding. The Binding Framework allows for
additional properties, outside the SOAP envelope, that may be required to invoke
the lower layer QoS mechanisms. Additional properties (within the Binding
Framework) may be required. For sake of discussion, lets assume that the SOAP
node will send the SOAP message using HTTP, but traffic classification of this
HTTP flow would be done using diffserv so particular per-hop behaviors can be
used within the network en-route to the next SOAP node. Traffic classification
for diffserv can be done by the SOAP node sending the SOAP message, or by network
devices (assuming they know how to recognize the particular HTTP flow). If
traffic classification is handled by a network device, perhaps communications
would be needed between the SOAP node and the network device, for example, to
provide the network device with the TCP/IP port numbers and IP addresses of the
HTTP connection. This would presume some way to obtain this port and address
information, which probably involves an API or properties that are beyond the
scope of the SOAP 1.2 specifications.
</p><p>
For example, to state that a separate spec can define properties in accordance
with the binding framework to extend the capability of the HTTP binding (or any
other binding). In the case of SOAP RPC, a QoS extension at the ultimate SOAP
receiver may attempt to insert a QoS Block in RPC response. The RPC response
may succeed, but perhaps the desired QoS cannot be delivered on the return
message path. It is not clear if a SOAP fault should be generated. Likewise, if
a SOAP Intermediary on the return message path cannot honor the QoS Block
(assumed to be marked mustUnderstand), is it permissible to convert the SOAP RPC
response to a SOAP fault? A SOAP extension in the initial SOAP sender is needed
to insert this SOAP QoS Block. The sender may need to use properties as defined
by the SOAP binding framework to communicate QoS parameters to be used by the
underlying network. Since a SOAP binding must define the rules for how the data
is exchanged using the underlying protocol, a custom or supplemental binding may
be required to support this QoS usage scenario. The HTTP binding described in the
SOAP 1.2 specification does not explicitly support QoS properties. The SOAP 1.2
specification does not preclude extensions to this HTTP binding, which would
provide the capability to define either QoS properties or a requirement to
examine the SOAP envelope (i.e., SOAP QoS Block) to determine the QoS used for
transmission. Alternatively, a completely new binding can be specified that
includes QoS explicitly, rather than as an extension to an existing binding
</p></div></div><div class="div2">
<h3><a name="S600" id="S600"></a>3.32 S600 Address based Discovery </h3><div class="div3">
<h4><a name="id2278994" id="id2278994"></a>3.32.1 Scenario Definition</h4><p>Given a particular service address, a sender wishes to determine the description of the service</p></div><div class="div3">
<h4><a name="id2279006" id="id2279006"></a>3.32.2 Description</h4><p>A Sender has an identifier for a service. It sends a message to a the service requesting the WSD definition that is appropriate. This could be designed using standardized SOAP messages with particular parameters, or other designs</p><p>If the identifier is a URL, then the developers tools interact directly with the URL according to a TBD mechanism. </p><p>If the identifier is a QName, then how is the WSDL retrieved. Is there a potential issue?</p></div><div class="div3">
<h4><a name="id2279030" id="id2279030"></a>3.32.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2279036" id="id2279036"></a>3.32.3.1 Requirements</h5><ol type="1"><li><p>A sender and receiver shall be able to exchange WSD descriptions given just a URI for the receivers service.</p></li></ol></div><div class="div4">
<h5><a name="id2279054" id="id2279054"></a>3.32.3.2 Non-requirements</h5></div><div class="div4">
<h5><a name="id2279061" id="id2279061"></a>3.32.3.3 Candidate Technologies</h5><p>WS-Inspection,</p></div></div><div class="div3">
<h4><a name="id2279071" id="id2279071"></a>3.32.4 Use case citations</h4><p>
This scenario is cited in <a href="#DescriptionScenario"><b>2.1.5.4.2 Scenario / Steps</b></a>.</p></div></div><div class="div2">
<h3><a name="S601" id="S601"></a>3.33 S601 Registry based discovery</h3><div class="div3">
<h4><a name="id2279097" id="id2279097"></a>3.33.1 Scenario Definition</h4><p>People or Software use a registry to discover web services and the interface specifications.</p></div><div class="div3">
<h4><a name="id2279108" id="id2279108"></a>3.33.2 Description</h4><p></p></div><div class="div3">
<h4><a name="id2279117" id="id2279117"></a>3.33.3 WS-Arch WG Specific</h4><div class="div4">
<h5><a name="id2279122" id="id2279122"></a>3.33.3.1 Requirements</h5><ol type="1"><li><p>Service Providers can publish WSD of service(s)</p></li><li><p>Service consumers can discover WSD of service(s)</p></li><li><p>Service consumers can invoke Services based upon discovered service description</p></li></ol></div><div class="div4">
<h5><a name="id2279155" id="id2279155"></a>3.33.3.2 Non-requirements</h5></div><div class="div4">
<h5><a name="id2279162" id="id2279162"></a>3.33.3.3 Candidate Technologies</h5><p>UDDI, ebXML Registry</p></div></div></div><div class="div2">
<h3><a name="S602" id="S602"></a>3.34 S602 Management Capability Discovery</h3><div class="div3">
<h4><a name="id2279185" id="id2279185"></a>3.34.1 Scenario Definition</h4><p>An administrator in the IT organization of a company discovers (via
means outside the scope of this scenario) a number of web services
within the environment and wishes to manage them where possible.
</p></div><div class="div3">
<h4><a name="id2279198" id="id2279198"></a>3.34.2 Description</h4><p>An administrator in the IT organization becomes aware of a web service
running in the company's environment and through some discovery
mechanism, locates its WSD and endpoint address. Using some form of
management agent software, the administrator tests for manageability of
the service by checking for presence of a standardized Management
operation that indicates management capability. </p><p>
The web service is found to have been developed with management in mind
and in fact offers a set of Management operations that exposes a range
of management capabilities. The administrator lists the management
operations available and then invokes the appropriate management
operation for the task at hand.
</p></div></div></div><div class="div1">
<h2><a name="id2283177" id="id2283177"></a>4 References</h2><dl><dt class="label"><a name="WSA" id="WSA"></a>WS Arch</dt><dd><a href="http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/">
<cite>Web Services
Architecture</cite>, W3C Working Group Note,
D. Booth, H. Haas, F. McCabe, E. Newcomer, M. Champion, C. Ferris, D. Orchard,
11 February 2004</a> (See http://www.w3.org/TR/2004/NOTE-ws-arch-20040211/.)</dd><dt class="label"><a name="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="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="WSAWGCharter" id="WSAWGCharter"></a>WSA Charter</dt><dd><a href="http://www.w3.org/2002/01/ws-arch-charter">
<cite>Web Services Architecture
Charter</cite>
</a> (See http://www.w3.org/2002/01/ws-arch-charter.)</dd><dt class="label"><a name="xmlpuc" id="xmlpuc"></a>XMLP US</dt><dd><a href="http://www.w3.org/TR/2001/WD-xmlp-scenarios-20011217/">
<cite>XML Protocol Usage
Scenarios</cite>, W3C Working Draft, J. Ibbotson, 17
December 2001</a> (See http://www.w3.org/TR/2001/WD-xmlp-scenarios-20011217/.)</dd></dl></div></div><div class="back"><div class="div1">
<h2><a name="id2283348" id="id2283348"></a>A Acknowledgments (Non-Normative)</h2><p>A large part of this document was excerpted from the XML
Protocol Usage Scenarios<a href="#xmlpuc">[XMLP US]</a>, edited by John
Ibbotson.</p><p>The editors would like to thank Roger Cutler for (<a href="#edi">EDI use case</a>), Yin-Leng Husband for (<a href="#S602">S602</a>), and Bill Donoghoe for reviewing this document. </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></div></div></body></html>