You can not select more than 25 topics
Topics must start with a letter or number, can include dashes ('-') and can be up to 35 characters long.
1759 lines
92 KiB
1759 lines
92 KiB
<!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> ©2003 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</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> 2.1 <a href="#S1">S1 Fire-and-forget to single receiver</a><br> 2.1.1 <a href="#N100C8">Scenario Definition</a><br> 2.1.2 <a href="#N100D1">Description</a><br> 2.2 <a href="#S2">S2 Fire-and-forget to multiple receivers</a><br> 2.2.1 <a href="#N100F4">Scenario Definition</a><br> 2.2.2 <a href="#N100FD">Description</a><br> 2.3 <a href="#S3">S3 Request/Response</a><br> 2.3.1 <a href="#N10116">Scenario Definition</a><br> 2.3.2 <a href="#N1011F">Description</a><br> 2.4 <a href="#S4">S4 Remote Procedure Call (RPC)</a><br> 2.4.1 <a href="#N1015B">Scenario Definition</a><br> 2.4.2 <a href="#N10164">Description</a><br> 2.5 <a href="#S5">S5 Request with acknowledgement</a><br> 2.5.1 <a href="#N101B4">Scenario Definition</a><br> 2.5.2 <a href="#N101CC">Description</a><br> 2.6 <a href="#S6">S6 Request with encrypted payload</a><br> 2.6.1 <a href="#N101FC">Scenario Definition</a><br> 2.6.2 <a href="#N10205">Description</a><br> 2.7 <a href="#S7">S7 Third party intermediary</a><br> 2.7.1 <a href="#N10235">Scenario Definition</a><br> 2.7.2 <a href="#N1023E">Description</a><br> 2.8 <a href="#S8">S8 Conversational message exchange</a><br> 2.8.1 <a href="#N1025D">Scenario Definition</a><br> 2.8.2 <a href="#N10266">Description</a><br> 2.9 <a href="#S10">S10 Message header and payload encryption</a><br> 2.9.1 <a href="#N102C3">Scenario Definition</a><br> 2.9.2 <a href="#N102CC">Description</a><br> 2.10 <a href="#S11">S11 Communication via multiple intermediaries</a><br> 2.10.1 <a href="#N102E5">Scenario Definition</a><br> 2.10.2 <a href="#N102EE">Description</a><br> 2.11 <a href="#DS17">DS17 Asynchronous messaging</a><br> 2.11.1 <a href="#N10307">Scenario Definition</a><br> 2.11.2 <a href="#N10310">Description</a><br> 2.12 <a href="#S19">S19 Sending non-XML data</a><br> 2.12.1 <a href="#N10340">Scenario Definition</a><br> 2.12.2 <a href="#N10349">Description</a><br> 2.13 <a href="#S20">S20 Multiple asynchronous responses</a><br> 2.13.1 <a href="#N1037E">Scenario Definition</a><br> 2.13.2 <a href="#N10387">Description</a><br> 2.14 <a href="#S21">S21 Incremental parsing/processing of SOAP messages</a><br> 2.14.1 <a href="#N103BE">Scenario Definition</a><br> 2.14.2 <a href="#N103CA">Description</a><br> 2.15 <a href="#S23">S23 Event notification</a><br> 2.15.1 <a href="#N103FC">Scenario Definition</a><br> 2.15.2 <a href="#N10405">Description</a><br> 2.16 <a href="#DS24">DS24 Caching</a><br> 2.16.1 <a href="#N10448">Scenario Definition</a><br> 2.16.2 <a href="#N1045D">Description</a><br> 2.17 <a href="#S805">S805 Routing</a><br> 2.17.1 <a href="#N104A9">Scenario Definition</a><br> 2.17.2 <a href="#N104B2">Description</a><br> 2.18 <a href="#S807">S807 Tracking</a><br> 2.18.1 <a href="#N104C5">Scenario Definition</a><br> 2.18.2 <a href="#N104CE">Description</a><br> 2.19 <a href="#S809">S809 Caching with expiration</a><br> 2.19.1 <a href="#N104FA">Scenario Definition</a><br> 2.19.2 <a href="#N10503">Description</a><br> 2.20 <a href="#S810">S810 Quality of service</a><br> 2.20.1 <a href="#N10513">Scenario Definition</a><br> 2.20.2 <a href="#N1051C">Description</a><br>3. <a href="#N1052D">References</a><br> 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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Body>
|
|
<r:StockPriceUpdate xmlns:r="http://example.org/2001/06/quotes">
|
|
<r:Symbol>BigCo</r:Symbol>
|
|
<r:Price>34.5</r:Price>
|
|
</r:StockPriceUpdate>
|
|
</env:Body>
|
|
</env:Envelope></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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:MsgHeader xmlns:n="http://example.org/requestresponse">
|
|
<n:MessageId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:MessageId>
|
|
</n:MsgHeader>
|
|
</env:Header>
|
|
<env:Body>
|
|
........
|
|
</env:Body>
|
|
</env:Envelope></pre></div>
|
|
</div>
|
|
<div class="exampleOuter">
|
|
|
|
<div class="exampleHead">Example 3: SOAP response message containing correlation to original request</div>
|
|
<div class="exampleInner"><pre><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:MsgHeader xmlns:n="http://example.org/requestresponse">
|
|
<n:MessageId>uuid:09233523-567b-2891-b623-9dke28yod7m9</n:MessageId>
|
|
<n:ResponseTo>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:ResponseTo>
|
|
</n:MsgHeader>
|
|
</env:Header>
|
|
<env:Body>
|
|
........
|
|
</env:Body>
|
|
</env:Envelope></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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Body>
|
|
<r:GetLastTradePrice env:encodingStyle="http://www.w3.org/2001/09/soap-encoding"
|
|
xmlns:r="http://example.org/2001/06/quotes">
|
|
<r:Symbol>DEF</r:Symbol>
|
|
</r:GetLastTradePrice>
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</pre></div>
|
|
</div>
|
|
<div class="exampleOuter">
|
|
|
|
<div class="exampleHead">Example 5: SOAP RPC response message</div>
|
|
<div class="exampleInner"><pre><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Body>
|
|
<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">
|
|
<rpc:Result>34.5</rpc:Result>
|
|
</r:GetLastTradePriceResponse>
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:MsgHeader xmlns:n="http://example.org/requestresponse">
|
|
<n:MessageId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:MessageId>
|
|
</n:MsgHeader>
|
|
</env:Header>
|
|
<env:Body>
|
|
<r:GetLastTradePrice env:encodingStyle="http://www.w3.org/2001/09/soap-encoding"
|
|
xmlns:r="http://example.org/2001/06/quotes">
|
|
<r:Symbol>DEF</r:Symbol>
|
|
</r:GetLastTradePrice>
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:MsgHeader xmlns:n="http://example.org/requestresponse">
|
|
<n:MessageId>uuid:09233523-567b-2891-b623-9dke28yod7m9</n:MessageId>
|
|
<n:ResponseTo>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:ResponseTo>
|
|
</n:MsgHeader>
|
|
</env:Header>
|
|
<env:Body>
|
|
<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">
|
|
<rpc:Result>34.5</rpc:Result>
|
|
</r:GetLastTradePriceResponse>
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:StatusRequest xmlns:n="http://example.org/status">
|
|
<n:MessageId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:MessageId>
|
|
</n:StatusRequest>
|
|
</env:Header>
|
|
<env:Body>
|
|
-----
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</pre></div>
|
|
</div>
|
|
<div class="exampleOuter">
|
|
|
|
<div class="exampleHead">Example 9: SOAP response message containing delivery status for request</div>
|
|
<div class="exampleInner"><pre><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:StatusResponse xmlns:n="http://example.org/status">
|
|
<n:MessageId>uuid:09233523-567b-2891-b623-9dke28yod7m9</n:MessageId>
|
|
<n:MessageStatus>DELIVERED</n:MessageStatus>
|
|
<n:Timestamp>2001-03-09T12:22:30Z</n:Timestamp>
|
|
</n:StatusResponse>
|
|
</env:Header>
|
|
<env:Body>
|
|
-----
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Body>
|
|
<m:GetLastTradePrice xmln:m="some-URI">
|
|
<m:symbol>IBM</m:symbol>
|
|
</m:GetLastTradePrice>
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</pre></div>
|
|
</div>
|
|
<p>
|
|
The following is the encrypted version of the above plain SOAP message. The
|
|
body entry <m:GetLastTradePrice> is encrypted using a symmetric key
|
|
identified by the key name "Symmetric Key" and replaced by the
|
|
<xenc:EncryptedData> element with an id "encrypted-body-entry".
|
|
A <sec:Encryption> header entry for this encrypted data is added
|
|
to the SOAP header. Note that the <sec:EncryptedDataList> element
|
|
in the header entry has a reference to the <xenc:EncryptedData> element.
|
|
The symmetric key used for encryption is stored in the <xenc:EncryptedKey>
|
|
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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<sec:Encryption xmlns:sec="http://schemas.xmlsoap.org/soap/security/2000-12"
|
|
env:actor="some-URI"
|
|
env:mustUnderstand="true">
|
|
<sec:EncryptedDataList>
|
|
<sec:EncryptedDataReference URI="#encrypted-body-entry"/>
|
|
</sec:EncryptedDataList>
|
|
<xenc:EncryptedKey xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
|
|
Id="EK"
|
|
CarriedKeyName="Symmetric Key"
|
|
Recipient="John Smith">
|
|
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#rsa-1_5"/>
|
|
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
|
|
<ds:KeyName>John Smith's RSA Key</ds:KeyName>
|
|
</ds:KeyInfo>
|
|
<xenc:CipherData>
|
|
<xenc:CipherValue>ENCRYPTED 3DES KEY......</xenc:CipherValue>
|
|
</xenc:CipherData>
|
|
<xenc:ReferenceList>
|
|
<xenc:DataReference URI="#encrypted-body-entry"/>
|
|
</xenc:ReferenceList>
|
|
</xenc:EncryptedKey>
|
|
</sec:Encryption>
|
|
</env:Header>
|
|
<env:Body>
|
|
<xenc:EncryptedData xmlns:xenc="http://www.w3.org/2001/04/xmlenc#"
|
|
Id="encrypted-body-entry"
|
|
Type="http://www.w3.org/2001/04/xmlenc#Element">
|
|
<xenc:EncryptionMethod Algorithm="http://www.w3.org/2001/04/xmlenc#tripledes-cbc"/>
|
|
<ds:KeyInfo xmlns:ds="http://www.w3.org/2000/09/xmldsig#">
|
|
<ds:RetrievalMethod URI="#EK" Type="http://www.w3.org/2001/04/xmlenc#EncryptedKey"/>
|
|
<ds:KeyName>Symmetric Key</ds:KeyName>
|
|
</ds:KeyInfo>
|
|
<xenc:CipherData>
|
|
<xenc:CipherValue>ENCRYPTED BODY ENTRY......</xenc:CipherValue>
|
|
</xenc:CipherData>
|
|
</xenc:EncryptedData>
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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’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’s order being registered. Once received,
|
|
the marketplace then contacts its set of selected sellers again by a set
|
|
of request/response messages. Design decisions made during the implementation
|
|
of the marketplace software will determine whether supplier messages are sent
|
|
from a single SOAP Sender to multiple SOAP Receivers, one at each of the
|
|
seller’s sites. Alternatively, a SOAP Sender could be instantiated for each
|
|
supplier and a physical 1:1 relationship established. Prior agreements on
|
|
message qualities such as reliability, security and structure would be put in
|
|
place between the marketplace and its sellers. These qualities would define
|
|
what additional SOAP Handlers were needed for the message exchange patterns
|
|
between the marketplace and sellers.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="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’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’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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:ConversationState xmlns:n="http://example.org/conversation">
|
|
<n:AgreementId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:AgreementId>
|
|
<n:ConversationId>uuid:02957815-38fh-39gp-0dj2-dm20fusy1n5j</n:ConversationId>
|
|
</n:ConversationState>
|
|
</env:Header>
|
|
<env:Body>
|
|
-----
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:ConversationState xmlns:n="http://example.org/conversation">
|
|
<n:AgreementId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:AgreementId>
|
|
<n:ConversationId>uuid:02957815-38fh-39gp-0dj2-dm20fusy1n5j</n:ConversationId>
|
|
</n:ConversationState>
|
|
</env:Header>
|
|
<env:Body>
|
|
-----
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:MsgHeader xmlns:n="http://example.org/requestresponse">
|
|
<n:MessageId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:MessageId>
|
|
</n:MsgHeader>
|
|
</env:Header>
|
|
<env:Body>
|
|
........
|
|
</env:Body>
|
|
</env:Envelope></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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:MsgHeader xmlns:n="http://example.org/requestresponse">
|
|
<n:MessageId>uuid:09233523-567b-2891-b623-9dke28yod7m9</n:MessageId>
|
|
<n:ResponseTo>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:ResponseTo>
|
|
</n:MsgHeader>
|
|
</env:Header>
|
|
<env:Body>
|
|
........
|
|
</env:Body>
|
|
</env:Envelope></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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:Manifest xmlns:n="http://example.org/manifest">
|
|
<n:Reference n:id="image01"
|
|
xlink:href="cid:payload-1"
|
|
xlink:role="http://example.org/image">
|
|
<n:Description>My first holiday photograph</n:Description>
|
|
</n:Reference>
|
|
<n:Reference n:id="image02"
|
|
xlink:href="cid:payload-2"
|
|
xlink:role="http://example.org/image">
|
|
<n:Description>My second holiday photograph</n:Description>
|
|
</n:Reference>
|
|
</n:Manifest>
|
|
</env:Header>
|
|
<env:Body>
|
|
........
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:MsgHeader xmlns:n="http://example.org/requestresponse">
|
|
<n:MessageId>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:MessageId>
|
|
</n:MsgHeader>
|
|
</env:Header>
|
|
<env:Body>
|
|
........
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:MsgHeader xmlns:n="http://example.org/requestresponse">
|
|
<!-- MessageId will be unique for each response message -->
|
|
<!-- ResponseTo will be constant for each response message in the sequence-->
|
|
<n:MessageId>uuid:09233523-567b-2891-b623-9dke28yod7m9</n:MessageId>
|
|
<n:ResponseTo>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:ResponseTo>
|
|
</n:MsgHeader>
|
|
<s:Sequence xmlns:s="http://example.org/sequence">
|
|
<s:SequenceNumber>1</s:SequenceNumber>
|
|
<s:TotalInSequence>5</s:TotalInSequence>
|
|
</s:Sequence>
|
|
</env:Header>
|
|
<env:Body>
|
|
........
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<n:MsgHeader xmlns:n="http://example.org/requestresponse">
|
|
<!-- MessageId will be unique for each response message -->
|
|
<!-- ResponseTo will be constant for each response message in the sequence-->
|
|
<n:MessageId>uuid:40195729-sj20-pso3-1092-p20dj28rk104</n:MessageId>
|
|
<n:ResponseTo>uuid:09233523-345b-4351-b623-5dsf35sgs5d6</n:ResponseTo>
|
|
</n:MsgHeader>
|
|
<s:Sequence xmlns:s="http://example.org/sequence">
|
|
<s:SequenceNumber>5</s:SequenceNumber>
|
|
<s:TotalInSequence>5</s:TotalInSequence>
|
|
</s:Sequence>
|
|
</env:Header>
|
|
<env:Body>
|
|
........
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<!--Set of headers processed before Body -->
|
|
</env:Header>
|
|
<env:Body>
|
|
<b:BodyDataChunk xmlns:s="http://example.org/2001/06/chunking">
|
|
<b:DataLength>1024</b:DataLength>
|
|
<b:Data>kfkk34jkhfSomeBase64EncodedDatajdsgkjgjajgo34093589uvsjv.....jhfjhf350giqhf</b:Data>
|
|
</b:BodyDataChunk>
|
|
|
|
<!-- More BodyDataChunk elements -->
|
|
|
|
<b:BodyDataChunk xmlns:s="http://example.org/2001/06/chunking">
|
|
<b:DataLength>1024</b:DataLength>
|
|
<b:Data>oqjrj45cmoLastLotOfBase64EncodedData12r9vnhofjhckzlmxjws.....skfjk23ogkkjhq</b:Data>
|
|
</b:BodyDataChunk>
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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’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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Body>
|
|
<s:StockNotificationSubscription xmlns:s="http://example.org/2001/06/subscribe">
|
|
<s:Notify>PRICE</s:Notify>
|
|
<s:Notify>VOLUME</s:Notfy>
|
|
<s:Notify>TIMESTAMP</s:Notfy>
|
|
<s:When>
|
|
<s:Company>BigCo</s:Company>
|
|
<s:Price range="GreaterThan">100</s:Price>
|
|
</s:When>
|
|
</s:StockNotificationSubscription>
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Body>
|
|
<s:StockNotificationSubscriptionAck xmlns:s="http://example.org/2001/06/subscribe">
|
|
<s:SubscriptionId> uuid:40195729-sj20-pso3-1092-p20dj28rk104</s:SubscriptionId>
|
|
</s:StockNotificationSubscriptionAck>
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Body>
|
|
<n:StockNotification xmlns:n="http://example.org/2001/06/notification">
|
|
<n:SubscriptionId> uuid:40195729-sj20-pso3-1092-p20dj28rk104</n:SubscriptionId>
|
|
<n:Company>BigCo</n:Company>
|
|
<n:Price>100.56</n:Price>
|
|
<n:Volume>102345</n:Volume>
|
|
<n:Timestamp>2001-03-09T12:22:30Z</n:Timestamp>
|
|
</n:StockNotification>
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Body>
|
|
<c:CatalogPriceRequest xmlns:c="http://example.org/2001/06/catalog">
|
|
<c:PartNumber>ABC-1234</c:PartNumber>
|
|
</c:CatalogPriceRequest>
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<e nv:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<ca:CacheControl xmlns:ca="http://example.org/2001/06/cache">
|
|
<ca:CacheKey>ABC-1234</ca:CacheKey>
|
|
<ca:Expires>2001-03-09T08:00:00Z</ca:Expires>
|
|
</ca:CacheControl>
|
|
</env:Header>
|
|
<env:Body>
|
|
<c:CatalogPriceResponse xmlns:c="http://example.org/2001/06/catalog">
|
|
<c:PartNumber>ABC-1234</c:PartNumber>
|
|
<c:PartPrice c:currency="USD">120.37</c:PartPrice>
|
|
</c:CatalogPriceResponse>
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Body>
|
|
<c:CatalogPriceResponse xmlns:c="http://example.org/2001/06/catalog">
|
|
<c:PartNumber>ABC-1234</c:PartNumber>
|
|
<c:PartPrice c:currency="USD">120.37</c:PartPrice>
|
|
</c:CatalogPriceResponse>
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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><?xml version="1.0" ?>
|
|
<env:Envelope xmlns:env="http://www.w3.org/2001/09/soap-envelope">
|
|
<env:Header>
|
|
<t:TrackingHeader xmlns:t="http://example.org/2001/06/tracking">
|
|
<t:Via>
|
|
<t:Intermediary>soap://A.com/some/endpoint</t:Intermediary>
|
|
<t:Timestamp>2001-03-09T08:00:00Z</t:Timestamp>
|
|
</t:Via>
|
|
<t:Via>
|
|
<t:Intermediary>soap://B.com</t:Intermediary>
|
|
<t:Timestamp>2001-03-09T08:01:00Z</t:Timestamp>
|
|
</t:Via>
|
|
<t:Via>
|
|
<t:Intermediary>soap://C.com</t:Intermediary>
|
|
<t:Timestamp>2001-03-09T08:02:00Z</t:Timestamp>
|
|
</t:Via>
|
|
<t:Via>
|
|
<t:Intermediary>soap://D.com/some/endpoint</t:Intermediary>
|
|
<t:Timestamp>2001-03-09T08:03:00Z</t:Timestamp>
|
|
</t:Via>
|
|
</t:TrackingHeader>
|
|
<wsrp:path xmlns:wsrp="http://schemas.xmlsoap.org/rp">
|
|
<wsrp:action>http://www.im.org/chat</wsrp:action>
|
|
<wsrp:to>soap://D.com/some/endpoint</wsrp:to>
|
|
<wsrp:fwd>
|
|
<wsrp:via>soap://B.com</wsrp:via>
|
|
<wsrp:via>soap://C.com</wsrp:via>
|
|
</wsrp:fwd>
|
|
<wsrp:from>soap://A.com/some/endpoint</wsrp:from>
|
|
<wsrp:id>uuid:84b9f5d0-33fb-4a81-b02b-5b760641c1d6</wsrp:id>
|
|
</wsrp:path>
|
|
</env:Header>
|
|
<env:Body>
|
|
.....
|
|
</env:Body>
|
|
</env:Envelope>
|
|
</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. & Tech),
|
|
Mark Jones (AT&T),
|
|
Anish Karmarkar (Oracle),
|
|
Jacek Kopecky (Systinet/Idoox),
|
|
Yves Lafon (W3C),
|
|
Michah Lerner (AT&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. & Tech),
|
|
Hervé 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é de France)),
|
|
Olivier Boudeville (EDF (Electricité 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>
|