NOTE-xmlp-scenarios-20030730 92.2 KB

Raw Blame History Permalink

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01 Transitional//EN">
<html lang="en"><head><META http-equiv="Content-Type" content="text/html; charset=utf-8"><title>SOAP Version 1.2 Usage Scenarios</title><style type="text/css">
code           { font-family: monospace; }

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


.diff-chg	{ background-color: orange; }
.diff-del	{ background-color: red; text-decoration: line-through;}
.diff-add	{ background-color: lime; }

table          { empty-cells: show; }


div.exampleInner pre { margin-left: 1em;
                       margin-top: 0em; margin-bottom: 0em}
div.exampleOuter {border: 4px double gray;
                  margin: 0em; padding: 0em}
div.exampleInner { background-color: #d5dee3;
                   border-top-width: 4px;
                   border-top-style: double;
                   border-top-color: #d3d3d3;
                   border-bottom-width: 4px;
                   border-bottom-style: double;
                   border-bottom-color: #d3d3d3;
                   padding: 4px; margin: 0em }
div.exampleWrapper { margin: 4px }
div.exampleHeader { font-weight: bold;
                    margin: 4px}
</style><link type="text/css" rel="stylesheet" href="http://www.w3.org/StyleSheets/TR/W3C-WG-NOTE.css"></head><body>
  <div class="head"><p><a href="http://www.w3.org/"><img width="72" height="48" alt="W3C" src="http://www.w3.org/Icons/w3c_home"></a></p>
<h1>SOAP Version 1.2 Usage Scenarios</h1>
<h2>W3C Working Group Note 30 July 2003</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2003/NOTE-xmlp-scenarios-20030730">http://www.w3.org/TR/2003/NOTE-xmlp-scenarios-20030730</a>
	</dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/TR/xmlp-scenarios">
	http://www.w3.org/TR/xmlp-scenarios</a>
	</dd><dt>Previous versions:</dt><dd><a href="http://www.w3.org/TR/2002/WD-xmlp-scenarios-20020626">
	http://www.w3.org/TR/2002/WD-xmlp-scenarios-20020626</a>
	</dd><dt>Editor:</dt>
      <dd>John Ibbotson, IBM</dd>
    </dl><p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> &copy;2003 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>&reg;</sup>(<a href="http://www.lcs.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a>, <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-software">software licensing</a> rules apply.</p></div><hr><div>
<h2><a name="abstract">Abstract</a></h2>
      <p>This document describes the SOAP Usage Scenarios and how they may be
      implemented using the SOAP 1.2 specification.</p>
    </div><div>
<h2><a name="status">Status of this Document</a></h2>
     <p><em>This section describes the status of this document
          at the time of its publication. Other documents may
          supersede this document. The latest status of this document
          series is maintained at the W3C.</em></p>

    <p>
      The WG has decided to discontinue work on SOAP Version 1.2 Usage Scenarios, and on this document.
      The WG developed the SOAP Version 1.2 Usage Scenario to help develop SOAP Version 1.2. The scenarios have served their purpose in this regard, and the WG no longer intends to work on them.</p>

      <p>The most recent changes to this document are: updated links to the
Working Group Charter, added a link to the IPR declaration, and publication
as a Working Group Note per the <a href="http://www.w3.org/2003/06/Process-20030618/process.html#tr-end">W3C Process Document, Section 7.5</a>.</p>

      <p>Comments on this document should be sent to <a href="mailto:xmlp-comments@w3.org">xmlp-comments@w3.org</a>
	(public archive <a href="#CommentArchive">[7]</a>). It is inappropriate to send discussion email
to this address. Any comment should include a reference to this document</p>

      <p>Discussion of this document takes place on the public <a href="mailto:xml-dist-app@w3.org">xml-dist-app@w3.org</a>
          mailing list <a href="#DiscussionArchive">[6]</a> under the email
          communication rules in the XML Protocol Working Group
          Charter <a href="#XMLPCharter">[5]</a>.</p>

    <p>Patent disclosures relevant to this specification may be found on the Working Group's <a href="http://www.w3.org/2000/xp/Group/2/10/16-IPR-statements.html">patent disclosure page</a>.</p>

     <p>This Note has been endorsed by the W3C XML Protocol Working Group, but has not
        been reviewed or endorsed by W3C Members.</p>
<p>The XML Protocol Working Group is part of the <a href="http://www.w3.org/2002/ws/Activity">Web Services Activity</a>.</p>
                        <p>A <a href="http://www.w3.org/TR/">list of all W3C technical reports</a> can be found
	                 at http://www.w3.org/TR/.</p>

    </div>
  <hr><div class="toc">
<h2><a name="shortcontents">Short Table of Contents</a></h2><p class="toc">1. <a href="#intro">Introduction</a><br>2. <a href="#description">Documentation of Usage Scenarios</a><br>3. <a href="#N1052D">References</a><br>A. <a href="#acks">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="toc">
<h2><a name="contents">Table of Contents</a></h2><p class="toc">1. <a href="#intro">Introduction</a><br>2. <a href="#description">Documentation of Usage Scenarios</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.1 <a href="#S1">S1 Fire-and-forget to single receiver</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.1 <a href="#N100C8">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.1.2 <a href="#N100D1">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.2 <a href="#S2">S2 Fire-and-forget to multiple receivers</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.1 <a href="#N100F4">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.2.2 <a href="#N100FD">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.3 <a href="#S3">S3 Request/Response</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.3.1 <a href="#N10116">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.3.2 <a href="#N1011F">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.4 <a href="#S4">S4 Remote Procedure Call (RPC)</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.4.1 <a href="#N1015B">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.4.2 <a href="#N10164">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.5 <a href="#S5">S5 Request with acknowledgement</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.5.1 <a href="#N101B4">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.5.2 <a href="#N101CC">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.6 <a href="#S6">S6 Request with encrypted payload</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.6.1 <a href="#N101FC">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.6.2 <a href="#N10205">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.7 <a href="#S7">S7 Third party intermediary</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.7.1 <a href="#N10235">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.7.2 <a href="#N1023E">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.8 <a href="#S8">S8 Conversational message exchange</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.8.1 <a href="#N1025D">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.8.2 <a href="#N10266">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.9 <a href="#S10">S10 Message header and payload encryption</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.9.1 <a href="#N102C3">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.9.2 <a href="#N102CC">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.10 <a href="#S11">S11 Communication via multiple intermediaries</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.10.1 <a href="#N102E5">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.10.2 <a href="#N102EE">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.11 <a href="#DS17">DS17 Asynchronous messaging</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.11.1 <a href="#N10307">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.11.2 <a href="#N10310">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.12 <a href="#S19">S19 Sending non-XML data</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.12.1 <a href="#N10340">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.12.2 <a href="#N10349">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.13 <a href="#S20">S20 Multiple asynchronous responses</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.13.1 <a href="#N1037E">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.13.2 <a href="#N10387">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.14 <a href="#S21">S21 Incremental parsing/processing of SOAP messages</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.14.1 <a href="#N103BE">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.14.2 <a href="#N103CA">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.15 <a href="#S23">S23 Event notification</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.15.1 <a href="#N103FC">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.15.2 <a href="#N10405">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.16 <a href="#DS24">DS24 Caching</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.16.1 <a href="#N10448">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.16.2 <a href="#N1045D">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.17 <a href="#S805">S805 Routing</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.17.1 <a href="#N104A9">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.17.2 <a href="#N104B2">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.18 <a href="#S807">S807 Tracking</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.18.1 <a href="#N104C5">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.18.2 <a href="#N104CE">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.19 <a href="#S809">S809 Caching with expiration</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.19.1 <a href="#N104FA">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.19.2 <a href="#N10503">Description</a><br>&nbsp;&nbsp;&nbsp;&nbsp;2.20 <a href="#S810">S810 Quality of service</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.20.1 <a href="#N10513">Scenario Definition</a><br>&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;&nbsp;2.20.2 <a href="#N1051C">Description</a><br>3. <a href="#N1052D">References</a><br>&nbsp;&nbsp;&nbsp;&nbsp;3.1 <a href="#N10532">Informative References</a><br></p>
<h3><a id="appendix" name="appendix">Appendix</a></h3><p class="toc">A. <a href="#acks">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="body">
    <div class="div1">

<h2><a name="intro"></a>1. Introduction</h2>
      <p>Introduction to the SOAP usage scenarios.</p>
    </div>
    <div class="div1">

<h2><a name="description"></a>2. Documentation of Usage Scenarios</h2>

      <div class="div2">

<h3><a name="S1"></a>2.1 S1 Fire-and-forget to single receiver</h3>
        <div class="div3">

<h4><a name="N100C8"></a>2.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="N100D1"></a>2.1.2 Description</h4>
          <img src="soap-usage-fig1.png" alt="Figure 1 Fire-and-forget to single receiver">
          <p>
          A fire-and-forget feature in scenario S1 requires a mechanism to send a
          message to a single SOAP Receiver and is illustrated in Figure 1. 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 1: 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/2001/09/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="S2"></a>2.2 S2 Fire-and-forget to multiple receivers</h3>
        <div class="div3">

<h4><a name="N100F4"></a>2.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="N100FD"></a>2.2.2 Description</h4>
          <img src="soap-usage-fig2.png" alt="Figure 2 Fire-and-forget to multiple receivers ">
          <p>
          Scenario S2 extends S1 to implement a fire-and-forget feature to multiple
          SOAP Receivers and is illustrated in Figure 2. 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 S1 with a
          distribution list of intended recipients.
          </p>
        </div>
      </div>

      <div class="div2">

<h3><a name="S3"></a>2.3 S3 Request/Response</h3>
        <div class="div3">

<h4><a name="N10116"></a>2.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="N1011F"></a>2.3.2 Description</h4>
          <p>
          Scenario S3 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>
          <img src="soap-usage-fig3.png" alt="Figure 3 Request/Response using underlying transport">
          <p>
          If the underlying transport protocol supports the correlation of a request
          and its matching response directly, then the solution illustrated in Figure 3
          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 appropiate 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>
          <img src="soap-usage-fig4.png" alt="Figure 4 Request/Response using SOAP headers">
          <p>
          If the underlying transport protocol does not support a request/response
          model, then the configuration shown in Figure 4 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 2: 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/2001/09/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 3: 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/2001/09/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="S4"></a>2.4 S4 Remote Procedure Call (RPC)</h3>
        <div class="div3">

<h4><a name="N1015B"></a>2.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="N10164"></a>2.4.2 Description</h4>
          <p>
          Scenario S4 differs from scenario S3 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 S3. Scenario S4 requires a
          request/response mechanism as in S3, with the parameter and result
          serialization needed for the RPC programming model form the SOAP Body
          element.
          </p>
          <img src="soap-usage-fig5.png" alt="Figure 5 RPC using underlying transport">
          <p>
          Figure 5 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 4: SOAP RPC request message</div>
	        <div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope"&gt;
  &lt;env:Body&gt;
    &lt;r:GetLastTradePrice env:encodingStyle="http://www.w3.org/2001/09/soap-encoding"
                            xmlns:r="http://example.org/2001/06/quotes"&gt;
      &lt;r:Symbol&gt;DEF&lt;/r:Symbol&gt;
    &lt;/r:GetLastTradePrice&gt;
  &lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div>
          </div>
          <div class="exampleOuter">

<div class="exampleHead">Example 5: SOAP RPC response message</div>
	        <div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope"&gt;
  &lt;env:Body&gt;
    &lt;r:GetLastTradePriceResponse env:encodingStyle="http://www.w3.org/2001/09/soap-encoding"
                            xmlns:r="http://example.org/2001/06/quotes"
                            xmlns:rpc="http://www.w3.org/2001/09/soap-rpc"&gt;
      &lt;rpc:Result&gt;34.5&lt;/rpc:Result&gt;
    &lt;/r:GetLastTradePriceResponse&gt;
  &lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div>
          </div>
          <img src="soap-usage-fig6.png" alt="Figure 6 RPC using SOAP headers">
          <p>
          In Figure 6, 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 S3.
          </p>
          <div class="exampleOuter">

<div class="exampleHead">Example 6: 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/2001/09/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:GetLastTradePrice env:encodingStyle="http://www.w3.org/2001/09/soap-encoding"
                            xmlns:r="http://example.org/2001/06/quotes"&gt;
      &lt;r:Symbol&gt;DEF&lt;/r:Symbol&gt;
    &lt;/r:GetLastTradePrice&gt;
  &lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div>
          </div>
          <div class="exampleOuter">

<div class="exampleHead">Example 7: 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/2001/09/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:GetLastTradePriceResponse env:encodingStyle="http://www.w3.org/2001/09/soap-encoding"
                                    xmlns:r="http://example.org/2001/06/quotes"
                                    xmlns:rpc="http://www.w3.org/2001/09/soap-rpc"&gt;
      &lt;rpc:Result&gt;34.5&lt;/rpc:Result&gt;
    &lt;/r:GetLastTradePriceResponse&gt;
  &lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div>
          </div>
        </div>
      </div>

      <div class="div2">

<h3><a name="S5"></a>2.5 S5 Request with acknowledgement</h3>
        <div class="div3">

<h4><a name="N101B4"></a>2.5.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>
            <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="N101CC"></a>2.5.2 Description</h4>
          <img src="soap-usage-fig7.png" alt="Figure 7 Request with acknowledgement">
          <p>
          Figure 7 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. Figure 7
          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 8: SOAP request message with staus request header</div>
	        <div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2001/09/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 9: 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/2001/09/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>

      <div class="div2">

<h3><a name="S6"></a>2.6 S6 Request with encrypted payload</h3>
        <div class="div3">

<h4><a name="N101FC"></a>2.6.1 Scenario Definition</h4>
          <p>
          A sender wishes to exchange data with a receiver and has agreed to encrypt
          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.
          </p>
        </div>
        <div class="div3">

<h4><a name="N10205"></a>2.6.2 Description</h4>
          <img src="soap-usage-fig8.png" alt="Figure 8 Request with encrypted payload">
          <p>
          Scenario S6 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. Figure 8 illustrates this scenario.
          </p>
          <div class="exampleOuter">

<div class="exampleHead">Example 10: Plaintext SOAP message</div>
	        <div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope"&gt;
  &lt;env:Body&gt;
    &lt;m:GetLastTradePrice xmln:m="some-URI"&gt;
      &lt;m:symbol&gt;IBM&lt;/m:symbol&gt;
    &lt;/m:GetLastTradePrice&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:GetLastTradePrice&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 11: Encrypted SOAP message</div>
	        <div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2001/09/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>

      <div class="div2">

<h3><a name="S7"></a>2.7 S7 Third party intermediary</h3>
        <div class="div3">

<h4><a name="N10235"></a>2.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="N1023E"></a>2.7.2 Description</h4>
          <img src="soap-usage-fig9.png" alt="Figure 9 Marketplace intermediary">
          <p>
          Figure 9 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 S7, 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&rsquo;s order, it contacts an appropriate
          set of sellers who then provide competitive bids aginst 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 Figure 9
          consists of a set of request/response messages between the buyer and the
          marketplace resulting in the buyer&rsquo;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&rsquo;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="S8"></a>2.8 S8 Conversational message exchange</h3>
        <div class="div3">

<h4><a name="N1025D"></a>2.8.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="N10266"></a>2.8.2 Description</h4>
          <img src="soap-usage-fig10.png" alt="Figure 10 Conversational message exchange">
          <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.
          </p>
          <p>
          A conversation between two trading partners may be defined by shared
          configuration information such as an ebXML Trading Partner Agreement (TPA).
          A TPA includes information such as expected response times, business process
          actions that each party undertakes to complete, security information and
          message content structures. In a procurement process, an example conversation
          may be:
          </p>
          <ol>
            <li>
              <p>A buyer request a quotation for some goods, the seller responds with the quote.</p>
            </li>
            <li>
              <p>The buyer places a puchase 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 the TPA
          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>
          Figure 10 illustrates how this scenario could be implemented. Each partner&rsquo;s
          SOAP processor has access to a database which is configured by the TPA 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&rsquo;s information to test whether the received message is
          acceptable within the rules of the TPA. 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
          TPA, then the application can raise a fault condition.
          </p>
          <p>
          Note that Figure 10 does not include handlers for other message headers to
          support reliability or security which may be required under the agreed TPA.
          </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 12: 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/2001/09/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 13: 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/2001/09/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>

      <div class="div2">

<h3><a name="S10"></a>2.9 S10 Message header and payload encryption</h3>
        <div class="div3">

<h4><a name="N102C3"></a>2.9.1 Scenario Definition</h4>
          <p>
          Two trading partners engaged in a message exchange may agree to
          cryptographically sign and verify either the message header, the routing
          header(s) 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.
          </p>
        </div>
        <div class="div3">

<h4><a name="N102CC"></a>2.9.2 Description</h4>
          <img src="soap-usage-fig11.png" alt="Figure 11 Header and payload encryption">
          <p>
          In scenario S6, 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. Figure 11 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>

      <div class="div2">

<h3><a name="S11"></a>2.10 S11 Communication via multiple intermediaries</h3>
        <div class="div3">

<h4><a name="N102E5"></a>2.10.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="N102EE"></a>2.10.2 Description</h4>
          <img src="soap-usage-fig12.png" alt="Figure 12 Routing and logging through intermediaries">
          <p>
          Scenario S11 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. Figure 12 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="DS17"></a>2.11 DS17 Asynchronous messaging</h3>
        <div class="div3">

<h4><a name="N10307"></a>2.11.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="N10310"></a>2.11.2 Description</h4>
          <img src="soap-usage-fig13.png" alt="Figure 13 Asynchronous messaging">
          <p>
          Scenario DS17 is the same as the basic request/response pattern described in
          scenario S3. 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>
          Figure 11 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 14: 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/2001/09/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 15: 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/2001/09/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="S19"></a>2.12 S19 Sending non-XML data</h3>
        <div class="div3">

<h4><a name="N10340"></a>2.12.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="N10349"></a>2.12.2 Description</h4>
          <img src="soap-usage-fig14.png" alt="Figure 14 Sending non-XML data">
          <p>
          Support for non-XML data has been described elsewhere. The SOAP with
          Attachments <a href="#SOAPAttach">[2]</a> note to the W3C has been adopted by the ebXML
          Message Services specification <a href="#EBXML">[1]</a> as the basis for defining a message
          structure which can support non-XML data. 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. Figure 14 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>
          <img src="soap-usage-fig15.png" alt="Figure 15 Using MIME packaging for non-XML data">
          <p>
          Figure 15 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 16: 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/2001/09/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>

      <div class="div2">

<h3><a name="S20"></a>2.13 S20 Multiple asynchronous responses</h3>
        <div class="div3">

<h4><a name="N1037E"></a>2.13.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="N10387"></a>2.13.2 Description</h4>
          <img src="soap-usage-fig16.png" alt="Figure 16 Multiple asynchronous responses">
          <p>
          Scenario S20 is an extension of scenario DS17 - 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 DS17 with multiple responses received by the originating
          application and corelated to the original request by a Message Correlation
          Handler. Figure 15 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 17: 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/2001/09/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 18: 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/2001/09/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 19: 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/2001/09/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="S21"></a>2.14 S21 Incremental parsing/processing of SOAP messages</h3>
        <div class="div3">

<h4><a name="N103BE"></a>2.14.1 Scenario Definition</h4>
          <p>
          An SOAP sender generates a lengthy SOAP message that is incrementally
          transmitted and received by a SOAP receiver. The SOAP receiver employs a
          SOAP handler that can incrementally process the body as it is received
          (e.g., employing a SAX-style XML parser on the body as it arrives). Note
          that the entire message need not be present at one time at any point in its
          existence.
          </p>
          <p>
          This would be particularly helpful for memory-limited processors. It is also
          very efficient for services which are consistent with incremental, real-time
          transformations of the data, direct archiving of received data, etc. It would
          also be useful in scenarios in which voluminous body data can be directly
          transduced into application data structures or events by a SOAP (module)
          processor. In particular, there is no need for the explicit construction of a
          DOM model of the data. Support for various data models might still be possible
          even with incremental processing if the models are incrementally constructible.
          </p>
        </div>
        <div class="div3">

<h4><a name="N103CA"></a>2.14.2 Description</h4>
          <p>
          Scenario S21 requires the incremental parsing and processing of a SOAP message
          by a receiver. This is a general scenario with memory-limited processor
          requirements forming a subset of the scenario. If the SOAP Body contains a
          large amount of data, then it may be processed incrementally by a SAX parser
          if the data is chunked as in the following example. The SAX parser will have a
          handler triggered by the BodyDataChunk element.
          </p>
          <div class="exampleOuter">

<div class="exampleHead">Example 20: 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/2001/09/soap-envelope"&gt;
  &lt;env:Header&gt;
    &lt;!--Set of headers processed before Body --&gt;
  &lt;/env:Header&gt;
  &lt;env:Body&gt;
    &lt;b:BodyDataChunk xmlns:s="http://example.org/2001/06/chunking"&gt;
      &lt;b:DataLength&gt;1024&lt;/b:DataLength&gt;
      &lt;b:Data&gt;kfkk34jkhfSomeBase64EncodedDatajdsgkjgjajgo34093589uvsjv.....jhfjhf350giqhf&lt;/b:Data&gt;
    &lt;/b:BodyDataChunk&gt;

    &lt;!-- More BodyDataChunk elements --&gt;

    &lt;b:BodyDataChunk xmlns:s="http://example.org/2001/06/chunking"&gt;
      &lt;b:DataLength&gt;1024&lt;/b:DataLength&gt;
      &lt;b:Data&gt;oqjrj45cmoLastLotOfBase64EncodedData12r9vnhofjhckzlmxjws.....skfjk23ogkkjhq&lt;/b:Data&gt;
    &lt;/b:BodyDataChunk&gt;
  &lt;/env:Body&gt;
&lt;/env:Envelope&gt;
</pre></div>
          </div>
          <p>
          If a SOAP request is being streamed and processed incrementally, then the
          matching response message may be streamed to the original sender. In this
          case, the design of the receiving application is critical with respect to
          timing and error handling.
          </p>
          <ol>
            <li>
            <p>If errors are generated by the SOAP request Headers, then a SOAP Fault is
            inserted in the response and processing of the request message is terminated.</p>
            </li>
            <li>
            <p>The SOAP receiving application may treat each BodyDataChunk element as
            atomic. A positive or negative acknowledgement is streamed to the SOAP
            response depending on whether the BodyDataChunk element was successfully
            processed or not. The SOAP response message is terminated once the end of
            the SOAP request is reached.</p>
            </li>
            <li>
            <p>Alternatively, the SOAP receiving application may process each BodyDataChunk
            until either the end of the SOAP request is received or a fault occurs. In
            the case of a fault, a SOAP Body fault element is streamed to the SOAP
            response and processing of the SOAP request is terminated.</p>
            </li>
          </ol>
        </div>
      </div>

      <div class="div2">

<h3><a name="S23"></a>2.15 S23 Event notification</h3>
        <div class="div3">

<h4><a name="N103FC"></a>2.15.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="N10405"></a>2.15.2 Description</h4>
          <img src="soap-usage-fig17.png" alt="Figure 17 Publish and subscribe">
          <p>
          Scenario S23 describes event notification using a publish subscribe mechanism.
          An implementation of this scenario uses an example of the request/response
          scenario S3 to register a subscription and fire-and-forget to multiple
          receivers scenario S2 for the notification. Figure 17 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 noification to a set of subscribers may be implemented
          using the fire-and-forget to multiple receivers scenario S2. 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&rsquo;s stock price, volume traded and time whenever
          the price is greater than 100.
          </p>
          <div class="exampleOuter">

<div class="exampleHead">Example 21: 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/2001/09/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 22: 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/2001/09/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 23: SOAP event notification</div>
	        <div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;env:Envelope xmlns:env="http://www.w3.org/2001/09/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="DS24"></a>2.16 DS24 Caching</h3>
        <div class="div3">

<h4><a name="N10448"></a>2.16.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 cachability 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="N1045D"></a>2.16.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. Figure 18 illustrates a possible architecture.
          </p>
          <img src="soap-usage-fig18.png" alt="Figure 18 Result Caching">
          <p>
          SOAP Application 1 initiates a request for catalog price information
          illustrated in the following example.
          </p>
          <div class="exampleOuter">

<div class="exampleHead">Example 24: 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/2001/09/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 fulfil 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 25: SOAP response with caching header received by intermediary</div>
	        <div class="exampleInner"><pre>&lt;?xml version="1.0" ?&gt;
&lt;e nv:Envelope xmlns:env="http://www.w3.org/2001/09/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 Figure 18.
          </p>
          <div class="exampleOuter">

<div class="exampleHead">Example 26: 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/2001/09/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="S805"></a>2.17 S805 Routing</h3>
        <div class="div3">

<h4><a name="N104A9"></a>2.17.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="N104B2"></a>2.17.2 Description</h4>
          <p>
          This scenario has been addressed in detail by the WS-Routing <a href="#WSRP">[4]</a>
          (formerly SOAP-RP) specification.
          </p>
        </div>
      </div>

      <div class="div2">

<h3><a name="S807"></a>2.18 S807 Tracking</h3>
        <div class="div3">

<h4><a name="N104C5"></a>2.18.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="N104CE"></a>2.18.2 Description</h4>
          <img src="soap-usage-fig19.png" alt="Figure 19 Message Tracking">
          <p>
          Scenario S805 describes a routing requirement whch is addressed in detail by the
          WS-Routing <a href="#WSRP">[4]</a> (formerly SOAP-RP) specification. This describes how a message
          may be reouted 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">[4]</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 27: 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/2001/09/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.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.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.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.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.com/some/endpoint&lt;/wsrp:to&gt;
        &lt;wsrp:fwd&gt;
          &lt;wsrp:via&gt;soap://B.com&lt;/wsrp:via&gt;
          &lt;wsrp:via&gt;soap://C.com&lt;/wsrp:via&gt;
        &lt;/wsrp:fwd&gt;
        &lt;wsrp:from&gt;soap://A.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="S809"></a>2.19 S809 Caching with expiration</h3>
        <div class="div3">

<h4><a name="N104FA"></a>2.19.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="N10503"></a>2.19.2 Description</h4>
          <p>See description for DS24.
          </p>
        </div>
      </div>

      <div class="div2">

<h3><a name="S810"></a>2.20 S810 Quality of service</h3>
        <div class="div3">

<h4><a name="N10513"></a>2.20.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="N1051C"></a>2.20.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>

    <div class="div1">

<h2><a name="N1052D"></a>3. References</h2>

      <div class="div2">

<h3><a name="N10532"></a>3.1 Informative References</h3>
        <dl>
          <dt class="label"><a name="EBXML"></a>[1] </dt><dd>Message Service Specification, ebXML TRP Version 1.0  (See <a href="http://www.ebxml.org/specs/ebMS.pdf">http://www.ebxml.org/specs/ebMS.pdf</a>.)</dd>

          <dt class="label"><a name="SOAPAttach"></a>[2] </dt><dd>SOAP Messages with Attachments  (See <a href="http://www.w3.org/TR/SOAP-attachments">http://www.w3.org/TR/SOAP-attachments</a>.)</dd>

          <dt class="label"><a name="SOAPReqs"></a>[3] </dt><dd>XML Protocol (SOAP) Requirements  (See <a href="http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#N2082">http://www.w3.org/TR/2001/WD-xmlp-reqs-20010319/#N2082</a>.)</dd>

          <dt class="label"><a name="WSRP"></a>[4] </dt><dd>Web Services Routing Protocol (WS-Routing)  (See <a href="http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsrvspev/html/ws-routing.asp">http://msdn.microsoft.com/library/default.asp?url=/library/en-us/dnsrvspev/html/ws-routing.asp</a>.)</dd>
          <dt class="label"><a name="XMLPCharter"></a>[5] </dt><dd>XML Protocol Charter  (See <a href="http://www.w3.org/2002/10/XML-Protocol-Charter">http://www.w3.org/2002/10/XML-Protocol-Charter</a>.)</dd>
       	  <dt class="label"><a name="DiscussionArchive"></a>[6] </dt><dd>XML Protocol Discussion Archive  (See <a href="http://lists.w3.org/Archives/Public/xml-dist-app/">http://lists.w3.org/Archives/Public/xml-dist-app/</a>.)</dd>
          <dt class="label"><a name="CommentArchive"></a>[7] </dt><dd>XML Protocol Comments Archive  (See <a href="http://lists.w3.org/Archives/Public/xmlp-comments/">http://lists.w3.org/Archives/Public/xmlp-comments/</a>.)</dd>
	    </dl>
      </div>
    </div>

  </div>
  <div class="back">
    <div class="div1">

<h2><a name="acks"></a>A. Acknowledgements (Non-Normative)</h2>

      <p>This specification is the work of the W3C XML Protocol Working Group.</p>

      <p>Members of the Working Group are (at the time of writing, and in
      alphabetical order): Carine Bournez (W3C),
David Fallside (IBM),
Tony Graham (Sun Microsystems),
Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor),
Marc Hadley (Sun Microsystems),
Gerd Hoelzing (SAP AG),
Oisin Hurley (IONA Technologies),
John Ibbotson (IBM),
Kazunori Iwasa (Fujitsu Limited),
Mario Jeckle (DaimlerChrysler R. &amp; Tech),
Mark Jones (AT&amp;T),
Anish Karmarkar (Oracle),
Jacek Kopecky (Systinet/Idoox),
Yves Lafon (W3C),
Michah Lerner (AT&amp;T),
Noah Mendelsohn (IBM, formerly of Lotus Development),
Jeff Mischkinsky (Oracle),
Nilo Mitra (Ericsson),
Jean-Jacques Moreau (Canon),
Masahiko Narita (Fujitsu Limited),
Eric Newcomer (IONA Technologies),
Mark Nottingham (BEA Systems, formerly of Akamai Technologies),
David Orchard (BEA Systems, formerly of Jamcracker),
Andreas Riegg (DaimlerChrysler R. &amp; Tech),
Herv&eacute; Ruellan (Canon),
Jeff Schlimmer (Microsoft Corporation),
Miroslav Simek (Systinet/Idoox),
Pete Wenzel (SeeBeyond),
Volker Wiechers (SAP AG).
</p>

      <p>Previous members were: Yasser alSafadi (Philips Research),
Bill Anderson (Xerox),
Vidur Apparao (Netscape),
Camilo Arbelaez (WebMethods),
Mark Baker (Idokorro Mobile (Planetfred), formerly of Sun Microsystems),
Philippe Bedu (EDF (Electricit&eacute; de France)),
Olivier Boudeville (EDF (Electricit&eacute; de France)),
Don Box (Microsoft Corporation, formerly of DevelopMentor),
Tom Breuel (Xerox),
Dick Brooks (Group 8760),
Winston Bumpus (Novell),
David Burdett (Commerce One),
Charles Campbell (Informix Software),
Alex Ceponkus (Bowstreet),
Michael Champion (Software AG),
David Chappell (Sonic Software),
Miles Chaston (Epicentric),
David Clay (Oracle),
David Cleary (Progress Software),
Conleth O'Connell (Vignette),
Ugo Corda (Xerox),
Paul Cotton (Microsoft Corporation),
Fransisco Cubera (IBM),
Jim d'Augustine (eXcelon),
Ron Daniel (Interwoven),
Glen Daniels (Macromedia, formerly of Allaire),
Dug Davis (IBM),
Ray Denenberg (Library of Congress),
Paul Denning (MITRE),
Frank DeRose (Tibco),
Mike Dierken (DataChannel),
Andrew Eisenberg (Progress Software),
Brian Eisenberg (DataChannel),
Colleen Evans (Sonic Software),
John Evdemon (XMLSolutions),
David Ezell (Hewlett-Packard),
Eric Fedok (Active Data Exchange),
Chris Ferris (Sun Microsystems),
Daniela Florescu (Propel),
Dan Frantz (BEA Systems),
Michael Freeman (Engenia Software),
Dietmar Gaertner (Software AG),
Scott Golubock (Epicentric),
Rich Greenfield (Library of Congress),
Hugo Haas (W3C),
Mark Hale (Interwoven),
Randy Hall (Intel),
Bjoern Heckel (Epicentric),
Erin Hoffman (Tradia),
Steve Hole (MessagingDirect Ltd.),
Mary Holstege (Calico Commerce),
Jim Hughes (Fujitsu Software Corporation),
Yin-Leng Husband (Hewlett-Packard, formerly of Compaq),
Ryuji Inoue (Matsushita Electric),
Scott Isaacson (Novell),
Murali Janakiraman (Rogue Wave),
Eric Jenkins (Engenia Software),
Jay Kasi (Commerce One),
Jeffrey Kay (Engenia Software),
Richard Koo (Vitria Technology Inc.),
Alan Kropp (Epicentric),
Julian Kumar (Epicentric),
Peter Lecuyer (Progress Software),
Tony Lee (Vitria Technology Inc.),
Amy Lewis (TIBCO),
Bob Lojek (Intalio),
Henry Lowe (OMG),
Brad Lund (Intel),
Matthew MacKenzie (XMLGlobal Technologies),
Murray Maloney (Commerce One),
Richard Martin (Active Data Exchange),
Highland Mary Mountain (Intel),
Alex Milowski (Lexica),
Kevin Mitchell (XMLSolutions),
Ed Mooney (Sun Microsystems),
Dean Moses (Epicentric),
Don Mullen (Tibco),
Rekha Nagarajan (Calico Commerce),
Raj Nair (Cisco),
Mark Needleman (Data Research Associates),
Art Nevarez (Novell),
Henrik Nielsen (Microsoft Corporation),
Kevin Perkins (Compaq),
Jags Ramnaryan (BEA Systems),
Vilhelm Rosenqvist (NCR),
Marwan Sabbouh (MITRE),
Waqar Sadiq (Vitria Technology Inc.),
Rich Salz (Zolera),
Krishna Sankar (Cisco),
George Scott (Tradia),
Shane Sesta (Active Data Exchange),
Lew Shannon (NCR),
John-Paul Sicotte (MessagingDirect Ltd.),
Simeon Simeonov (Macromedia, formerly from Allaire),
Aaron Skonnard (DevelopMentor),
Nick Smilonich (Unisys),
Soumitro Tagore (Informix Software),
James Tauber (Bowstreet),
Lynne Thompson (Unisys),
Patrick Thompson (Rogue Wave),
Jim Trezzo (Oracle),
Asir Vedamuthu (WebMethods),
Randy Waldrop (WebMethods),
Fred Waskiewicz (OMG),
David Webber (XMLGlobal Technologies),
Ray Whitmer (Netscape),
Stuart Williams (Hewlett-Packard),
Yan Xu (DataChannel),
Amr Yassin (Philips Research),
Susan Yee (Active Data Exchange),
Jin Yu (Martsoft).
</p>

<p>The people who have contributed to discussions on
<a href="mailto:xml-dist-app@w3.org">xml-dist-app@w3.org</a>
are also gratefully acknowledged.</p>

    </div>
  </div>
</body></html>