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.
4288 lines
179 KiB
4288 lines
179 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 Part 2: Adjuncts (Second Edition)</title><style type="text/css">
|
|
code { font-family: monospace; }
|
|
|
|
div.constraint,
|
|
div.issue,
|
|
div.note,
|
|
div.notice { margin-left: 2em; }
|
|
|
|
|
|
|
|
.diff-chg { background-color: #E47833;; }
|
|
.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 rel="stylesheet" type="text/css" href="http://www.w3.org/StyleSheets/TR/W3C-REC.css"></head><body>
|
|
<div class="head"><p><a href="http://www.w3.org/"><img src="http://www.w3.org/Icons/w3c_home" alt="W3C" height="48" width="72"></a></p>
|
|
<h1>SOAP Version 1.2 Part 2: Adjuncts (Second Edition)</h1>
|
|
<h2>W3C Recommendation 27 April 2007</h2><dl><dt>This version:</dt><dd><a href="http://www.w3.org/TR/2007/REC-soap12-part2-20070427/">http://www.w3.org/TR/2007/REC-soap12-part2-20070427/</a></dd><dt>Latest version:</dt><dd><a href="http://www.w3.org/TR/soap12-part2/">http://www.w3.org/TR/soap12-part2/</a></dd><dt>Previous versions:</dt><dd><a href="http://www.w3.org/TR/2006/PER-soap12-part2-20061219/">http://www.w3.org/TR/2006/PER-soap12-part2-20061219/</a></dd><dt>Editors:</dt>
|
|
<dd>Martin Gudgin, Microsoft</dd>
|
|
<dd>Marc Hadley, Sun Microsystems</dd>
|
|
<dd>Noah Mendelsohn, IBM</dd>
|
|
<dd>Jean-Jacques Moreau, Canon</dd>
|
|
<dd>Henrik Frystyk Nielsen, Microsoft</dd>
|
|
<dd>Anish Karmarkar, Oracle</dd>
|
|
<dd>Yves Lafon, W3C</dd>
|
|
</dl><p>Please refer to the <a href="http://www.w3.org/2007/04/REC-soap12-part2-20070427-errata.html"><strong>errata</strong></a> for this document, which may
|
|
include normative corrections.</p>
|
|
<p>See also <a href="http://www.w3.org/2003/03/Translations/byTechnology?technology=soap12-part2"> translations</a>.</p>
|
|
<p class="copyright"><a href="http://www.w3.org/Consortium/Legal/ipr-notice#Copyright">Copyright</a> © 2007 <a href="http://www.w3.org/"><acronym title="World Wide Web Consortium">W3C</acronym></a><sup>®</sup> (<a href="http://www.csail.mit.edu/"><acronym title="Massachusetts Institute of Technology">MIT</acronym></a>, <a href="http://www.ercim.org/"><acronym title="European Research Consortium for Informatics and Mathematics">ERCIM</acronym></a>, <a href="http://www.keio.ac.jp/">Keio</a>), All Rights Reserved. W3C <a href="http://www.w3.org/Consortium/Legal/ipr-notice#Legal_Disclaimer">liability</a>, <a href="http://www.w3.org/Consortium/Legal/ipr-notice#W3C_Trademarks">trademark</a> and <a href="http://www.w3.org/Consortium/Legal/copyright-documents">document use</a> rules apply.</p></div><hr><div>
|
|
<h2><a name="abstract">Abstract</a></h2>
|
|
<p>SOAP Version 1.2 is a lightweight protocol intended for
|
|
exchanging structured information in a decentralized, distributed
|
|
environment. SOAP Version 1.2 Part 2: Adjuncts defines a set of adjuncts that may
|
|
be used with SOAP Version 1.2 Part 1: Messaging Framework. This specification
|
|
depends on SOAP Version 1.2 Part 1: Messaging Framework <a href="#SOAP-PART1">[SOAP Part 1]</a>. </p>
|
|
</div><div>
|
|
<h2><a name="status">Status of this Document</a></h2>
|
|
|
|
<p><em>This section describes the status of this document at the time of its publication. Other documents may supersede this document. A list of current W3C publications and the latest revision of this technical report can be found in the <a href="http://www.w3.org/TR/">W3C technical reports index</a> at http://www.w3.org/TR/.</em></p>
|
|
|
|
<p>This document is a <a href="http://www.w3.org/2005/10/Process-20051014/tr.html#RecsW3C">W3C Recommendation</a>. It has been produced by the <a href="http://www.w3.org/2000/xp/Group/">XML Protocol Working Group</a>, which
|
|
is part of the <a href="http://www.w3.org/2002/ws/Activity">Web Services
|
|
Activity</a>.
|
|
This second edition updates and supersedes the <a href="http://www.w3.org/TR/2003/REC-soap12-part2-20030624/">original Recommendation</a> by the inclusion of the accumulated <a href="http://www.w3.org/2003/06/REC-soap12-20030624-errata.html">errata</a>.
|
|
Changes between these two versions are described in a
|
|
<a href="diff-part2.html">diff document</a>.
|
|
Additionally, it incorporates changes to the SOAP Request Response Message
|
|
Exchange pattern (MEP) to permit the SOAP envelope in the response to be
|
|
optional, to allow for one-way message interactions.</p>
|
|
|
|
<p>This document has been reviewed by W3C Members, by software developers, and by other W3C groups and interested parties, and is endorsed by the Director as a W3C Recommendation. It is a stable document and may be used as reference material or cited from another document. W3C's role in making the Recommendation is to draw attention to the specification and to promote its widespread deployment. This enhances the functionality and interoperability of the Web.</p>
|
|
|
|
<p>Please report errors in this document to the public mailing list <a href="mailto:xmlp-comments@w3.org">xmlp-comments@w3.org</a>
|
|
(<a href="http://lists.w3.org/Archives/Public/xmlp-comments/">archive</a>).
|
|
It is inappropriate to send discussion email to this address.</p>
|
|
|
|
<p>SOAP Version 1.2 supercedes all previous versions of SOAP, including SOAP Version 1.1 <a href="#soap11">[SOAP 1.1]</a></p>
|
|
|
|
<p>The SOAP 1.2 Implementation Report can be found at <a href="http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html">
|
|
http://www.w3.org/2000/xp/Group/2/03/soap1.2implementation.html</a>.
|
|
Additional implementation experience of the Request
|
|
Optional Response MEP can be found in the WSDL 2.0 implementation testing here:
|
|
<a href="http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/Dashboard.html">http://dev.w3.org/cvsweb/~checkout~/2002/ws/desc/test-suite/Dashboard.html</a>.</p>
|
|
|
|
<p> This document is governed by the <a href="http://www.w3.org/TR/2002/NOTE-patent-practice-20020124">24 January 2002 CPP</a> as amended by the <a href="http://www.w3.org/2004/02/05-pp-transition">W3C Patent Policy Transition Procedure</a>. W3C maintains a <a rel="disclosure" href="http://www.w3.org/2000/xp/Group/2/10/16-IPR-statements.html">public list of any patent disclosures</a> made in connection with the deliverables of the group; that page also includes instructions for disclosing a patent. An individual who has actual knowledge of a patent which the individual believes contains <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#def-essential">Essential Claim(s)</a> must disclose the information in accordance with <a href="http://www.w3.org/Consortium/Patent-Policy-20040205/#sec-Disclosure">section 6 of the W3C Patent Policy</a>. </p>
|
|
|
|
<p>A list of current <a href="http://www.w3.org/TR/">W3C Recommendations and
|
|
other technical reports</a> can be found at <a href="http://www.w3.org/TR">http://www.w3.org/TR</a>.</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="#datamodel">SOAP Data Model</a><br>3. <a href="#soapenc">SOAP Encoding</a><br>4. <a href="#soapforrpc">SOAP RPC Representation</a><br>5. <a href="#soapfeatspec">A Convention for Describing Features and Bindings</a><br>6. <a href="#soapsupmep">SOAP-Supplied Message Exchange Patterns and Features</a><br>7. <a href="#soapinhttp">SOAP HTTP Binding</a><br>8. <a href="#refs">References</a><br>A. <a href="#ietf-draft">The application/soap+xml Media Type</a><br>B. <a href="#namemap">Mapping Application-Defined Names to XML Names</a><br>C. <a href="#encschema">Using W3C XML Schema with SOAP Encoding</a> (Non-Normative)<br>D. <a href="#id2279382">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> 1.1 <a href="#notcon">Notational Conventions</a><br>2. <a href="#datamodel">SOAP Data Model</a><br> 2.1 <a href="#graphedges">Graph Edges</a><br> 2.1.1 <a href="#edgelabels">Edge labels</a><br> 2.2 <a href="#graphnodes">Graph Nodes</a><br> 2.2.1 <a href="#singlemultiref">Single and Multi Reference Nodes</a><br> 2.3 <a href="#values">Values</a><br>3. <a href="#soapenc">SOAP Encoding</a><br> 3.1 <a href="#encrules">Mapping between XML and the SOAP Data Model</a><br> 3.1.1 <a href="#encodingedgesandnodes">Encoding Graph Edges and Nodes</a><br> 3.1.2 <a href="#simpleenc">Encoding Simple Values</a><br> 3.1.3 <a href="#complexenc">Encoding Compound Values</a><br> 3.1.4 <a href="#enctypename">Computing the Type Name Property</a><br> 3.1.4.1 <a href="#itemtypeattr">itemType Attribute Information Item</a><br> 3.1.5 <a href="#uniqueids">Unique identifiers</a><br> 3.1.5.1 <a href="#idattr">id Attribute Information Item</a><br> 3.1.5.2 <a href="#refattr">ref Attribute Information Item</a><br> 3.1.5.3 <a href="#uniqueidconstraints">Constraints on id and ref Attribute Information
|
|
Items</a><br> 3.1.6 <a href="#arraySizeattr">arraySize Attribute Information Item</a><br> 3.1.7 <a href="#nodeTypeattr">nodeType Attribute Information Item</a><br> 3.2 <a href="#encfaults">Decoding Faults</a><br>4. <a href="#soapforrpc">SOAP RPC Representation</a><br> 4.1 <a href="#RPConWeb">Use of RPC on the World Wide Web</a><br> 4.1.1 <a href="#RPCWebArguments">Identification of RPC Resources</a><br> 4.1.2 <a href="#RPCResourceRetrieval">Distinguishing Resource Retrievals from other RPCs</a><br> 4.2 <a href="#rpcsoapbdy">RPC and SOAP Body</a><br> 4.2.1 <a href="#rpcinvocation">RPC Invocation</a><br> 4.2.2 <a href="#rpcresponse">RPC Response</a><br> 4.2.3 <a href="#rpcencrestriction">SOAP Encoding Restriction</a><br> 4.3 <a href="#rpcsoaphead">RPC and SOAP Header</a><br> 4.4 <a href="#rpcfaults">RPC Faults</a><br>5. <a href="#soapfeatspec">A Convention for Describing Features and Bindings</a><br> 5.1 <a href="#modprop">Model and Properties</a><br> 5.1.1 <a href="#bindprops">Properties</a><br> 5.1.2 <a href="#bindpropsscope">Property Scope</a><br> 5.1.2.1 <a href="#soapmec">Message Exchange Context</a><br> 5.1.2.2 <a href="#soapenvc">Environment Context</a><br> 5.1.3 <a href="#bindpropfeat">Properties and Features</a><br>6. <a href="#soapsupmep">SOAP-Supplied Message Exchange Patterns and Features</a><br> 6.1 <a href="#meppropconv">Property Conventions for SOAP Message Exchange Patterns</a><br> 6.2 <a href="#singlereqrespmep">SOAP Request-Response Message Exchange Pattern</a><br> 6.2.1 <a href="#mepname">SOAP Feature Name</a><br> 6.2.2 <a href="#bindinfdesc">Description</a><br> 6.2.3 <a href="#bindformdesc">State Machine Description</a><br> 6.2.4 <a href="#bindfaulthdn">Fault Handling</a><br> 6.3 <a href="#soapresmep">SOAP Response Message Exchange Pattern</a><br> 6.3.1 <a href="#mepname2">SOAP Feature Name</a><br> 6.3.2 <a href="#bindinfdesc2">Description</a><br> 6.3.3 <a href="#bindformdesc2">State Machine Description</a><br> 6.3.4 <a href="#bindfaulthdn2">Fault Handling</a><br> 6.4 <a href="#WebMethodFeature">SOAP Web Method Feature</a><br> 6.4.1 <a href="#WebMethodFeatureName">SOAP Feature Name</a><br> 6.4.2 <a href="#WebMethodFeatureDesc">Description</a><br> 6.4.3 <a href="#webmethodstatemachine">SOAP Web Method Feature State Machine </a><br> 6.5 <a href="#ActionFeature">SOAP Action Feature</a><br> 6.5.1 <a href="#ActionFeatureName">SOAP Feature Name</a><br> 6.5.2 <a href="#ActionFeatureDesc">Description</a><br> 6.5.3 <a href="#actionstatemachine">SOAP Action Feature State Machine </a><br>7. <a href="#soapinhttp">SOAP HTTP Binding</a><br> 7.1 <a href="#http-intro">Introduction</a><br> 7.1.1 <a href="#httpoptionality">Optionality</a><br> 7.1.2 <a href="#httpuse">Use of HTTP</a><br> 7.1.3 <a href="#httpinterop">Interoperability with non-SOAP HTTP Implementations</a><br> 7.1.4 <a href="#httpmediatype">HTTP Media-Type</a><br> 7.2 <a href="#http-bindname">Binding Name</a><br> 7.3 <a href="#http-suptransmep">Supported Message Exchange Patterns</a><br> 7.4 <a href="#http-suptfeatures">Supported Features</a><br> 7.5 <a href="#http-msgexop">MEP Operation</a><br> 7.5.1 <a href="#http-reqsoapnode">Behavior of Requesting SOAP Node</a><br> 7.5.1.1 <a href="#http-reqbindreqstate">Init</a><br> 7.5.1.2 <a href="#http-reqbindwaitstate">Requesting</a><br> 7.5.1.3 <a href="#http-reqbindrecstate">Sending+Receiving</a><br> 7.5.1.4 <a href="#http-reqbindrecstate2">Receiving</a><br> 7.5.1.5 <a href="#http-reqsuccfail">Success and Fail</a><br> 7.5.2 <a href="#http-bindrespnode">Behavior of Responding SOAP Node</a><br> 7.5.2.1 <a href="#http-respbindreceive">Init</a><br> 7.5.2.2 <a href="#http-respbindprocess">Receiving</a><br> 7.5.2.3 <a href="#http-respbindrespond">Receiving+Sending</a><br> 7.5.2.4 <a href="#http-respbindrespond2">Sending</a><br> 7.5.2.5 <a href="#http-respsuccfail">Success and Fail</a><br> 7.6 <a href="#seccond">Security Considerations</a><br>8. <a href="#refs">References</a><br> 8.1 <a href="#refs-norm">Normative References</a><br> 8.2 <a href="#refs-inform">Informative References</a><br></p>
|
|
<h3><a name="appendix" id="appendix">Appendices</a></h3><p class="toc">A. <a href="#ietf-draft">The application/soap+xml Media Type</a><br>B. <a href="#namemap">Mapping Application-Defined Names to XML Names</a><br> B.1 <a href="#namemap-rules">Rules for Mapping Application-Defined Names to XML Names</a><br> B.2 <a href="#namemap-ex">Examples</a><br>C. <a href="#encschema">Using W3C XML Schema with SOAP Encoding</a> (Non-Normative)<br> C.1 <a href="#validmin">Validating Using the Minimum Schema</a><br> C.2 <a href="#validenc">Validating Using the SOAP Encoding Schema</a><br> C.3 <a href="#validschema">Validating Using More Specific Schemas</a><br>D. <a href="#id2279382">Acknowledgements</a> (Non-Normative)<br></p></div><hr><div class="body">
|
|
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="intro"></a>1. Introduction</h2>
|
|
|
|
<p>SOAP Version 1.2 (SOAP) is a lightweight protocol intended
|
|
for exchange of structured information in a
|
|
decentralized, distributed environment. The SOAP specification
|
|
consists of three parts. Part 2 (this document)
|
|
defines a set of adjuncts that MAY be used with the SOAP
|
|
messaging framework:</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>The SOAP Data Model represents application-defined data structures and values
|
|
as a directed, edge-labeled graph of nodes (see <a href="#datamodel"><b>2. SOAP Data Model</b></a>).</p>
|
|
</li>
|
|
<li>
|
|
<p>The SOAP Encoding defines a set of rules for encoding
|
|
instances of data that conform to the SOAP Data Model for
|
|
inclusion in SOAP messages (see <a href="#soapenc"><b>3. SOAP Encoding</b></a>).</p>
|
|
</li>
|
|
<li>
|
|
<p>The SOAP RPC Representation defines a convention for how
|
|
to use the SOAP Data Model for representing RPC calls and
|
|
responses (see <a href="#soapforrpc"><b>4. SOAP RPC Representation</b></a>).</p>
|
|
</li>
|
|
<li>
|
|
<p>The section for describing features and bindings defines
|
|
a convention for describing features and binding in terms
|
|
of properties and property values (see <a href="#soapfeatspec"><b>5. A Convention for Describing Features and Bindings</b></a>).</p>
|
|
</li>
|
|
<li>
|
|
<p>The section on SOAP-Supplied Message Exchange
|
|
Patterns and Features defines a request response
|
|
message exchange pattern and a message exchange
|
|
pattern supporting non-SOAP requests for SOAP
|
|
responses, (see <a href="#soapsupmep"><b>6. SOAP-Supplied Message Exchange Patterns and Features</b></a>).</p>
|
|
</li>
|
|
<li>
|
|
<p>The SOAP Web Method feature defines a feature for
|
|
control of methods used on the World Wide Web (see
|
|
<a href="#WebMethodFeature"><b>6.4 SOAP Web Method Feature</b></a>).</p>
|
|
</li>
|
|
<li>
|
|
<p>The SOAP HTTP Binding defines a binding of SOAP
|
|
to HTTP (see <a href="#RFC2616">[RFC 2616]</a>) following the
|
|
rules of the <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew">SOAP Protocol
|
|
Binding Framework</a>, <a href="#SOAP-PART1">[SOAP Part 1]</a> (see <a href="#soapinhttp"><b>7. SOAP HTTP Binding</b></a>).</p>
|
|
</li>
|
|
</ol>
|
|
<p>SOAP 1.2 Part 0 <a href="#SOAP-PART0">[SOAP Part 0]</a> is a non-normative document intended to
|
|
provide an easily understandable tutorial on the features of the SOAP Version
|
|
1.2 specifications.</p>
|
|
<p>SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> defines the SOAP messaging
|
|
framework.</p>
|
|
<div class="note"><p class="prefix"><b>Note:</b></p>
|
|
<p>In previous versions of this specification the SOAP
|
|
name was an acronym. This is no longer the case.</p>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="notcon"></a>1.1 Notational Conventions</h3>
|
|
|
|
<p>The keywords "MUST", "MUST NOT", "REQUIRED", "SHALL",
|
|
"SHALL NOT", "SHOULD", "SHOULD NOT", "RECOMMENDED", "MAY",
|
|
and "OPTIONAL" in this document are to be interpreted as
|
|
described in RFC 2119 <a href="#RFC2119">[RFC 2119]</a>.</p>
|
|
|
|
<p>This specification uses a number of namespace prefixes throughout; they
|
|
are listed in <a href="#tabprefns"><b>Table 1</b></a>. Note that the choice of any namespace
|
|
prefix is arbitrary and not semantically significant (see XML Infoset <a href="#XMLInfoSet">[XML InfoSet]</a>).</p>
|
|
|
|
<a name="tabprefns"></a><table border="1">
|
|
<caption>Table 1: Prefixes and Namespaces used in this specification</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">Prefix</th>
|
|
<th rowspan="1" colspan="1">Namespace</th>
|
|
<th rowspan="1" colspan="1">Notes</th>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">env</td>
|
|
<td rowspan="1" colspan="1">"http://www.w3.org/2003/05/soap-envelope"</td>
|
|
<td rowspan="1" colspan="1">Defined by SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">enc</td>
|
|
<td rowspan="1" colspan="1">"http://www.w3.org/2003/05/soap-encoding"</td>
|
|
<td rowspan="1" colspan="1">A normative XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1]</a>,
|
|
<a href="#XMLSchemaP2">[XML Schema Part 2]</a> document for the
|
|
"http://www.w3.org/2003/05/soap-encoding"
|
|
namespace can be found at <a href="http://www.w3.org/2003/05/soap-encoding">http://www.w3.org/2003/05/soap-encoding</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">rpc</td>
|
|
<td rowspan="1" colspan="1">"http://www.w3.org/2003/05/soap-rpc"</td>
|
|
<td rowspan="1" colspan="1">A normative XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1]</a>,
|
|
<a href="#XMLSchemaP2">[XML Schema Part 2]</a> document for the
|
|
"http://www.w3.org/2003/05/soap-rpc"
|
|
namespace can be found at <a href="http://www.w3.org/2003/05/soap-rpc">http://www.w3.org/2003/05/soap-rpc</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">xs</td>
|
|
<td rowspan="1" colspan="1">"http://www.w3.org/2001/XMLSchema"</td>
|
|
<td rowspan="1" colspan="1">Defined in the W3C XML Schema
|
|
specification <a href="#XMLSchemaP1">[XML Schema Part 1]</a>, <a href="#XMLSchemaP2">[XML Schema Part 2]</a>.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">xsi</td>
|
|
<td rowspan="1" colspan="1">"http://www.w3.org/2001/XMLSchema-instance"</td>
|
|
<td rowspan="1" colspan="1">Defined in the W3C XML Schema
|
|
specification <a href="#XMLSchemaP1">[XML Schema Part 1]</a>, <a href="#XMLSchemaP2">[XML Schema Part 2]</a>.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>Namespace names of the general form "http://example.org/..."
|
|
and "http://example.com/..." represent
|
|
application or context-dependent URIs (see RFC 3986 <a href="#RFC3986">[RFC 3986]</a>).</p>
|
|
|
|
<p>This specification uses the Extended Backus-Naur Form
|
|
(EBNF) as described in XML 1.0 <a href="#XML">[XML 1.0]</a>.</p>
|
|
|
|
<p>With the exception of examples and sections explicitly marked
|
|
as "Non-Normative", all parts of this specification are
|
|
normative.</p>
|
|
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="datamodel"></a>2. SOAP Data Model</h2>
|
|
|
|
<p>The SOAP Data Model represents application-defined data
|
|
structures and values as a directed edge-labeled graph of nodes.
|
|
Components of this graph are described in the following
|
|
sections.</p>
|
|
|
|
<p>
|
|
The purpose of the SOAP Data Model is to provide a mapping
|
|
of non-XML based data to some wire representation. It is important
|
|
to note that use of the SOAP Data Model, the accompanying SOAP
|
|
Encoding (see <a href="#soapenc"><b>3. SOAP Encoding</b></a>), and/or the SOAP RPC
|
|
Representation (see <a href="#soapforrpc"><b>4. SOAP RPC Representation</b></a>) is
|
|
OPTIONAL. Applications which already model data in XML may not need to use the SOAP
|
|
Data Model. Due to their optional nature, it is NOT a
|
|
requirement to implement the SOAP Data Model, the SOAP
|
|
Encoding and/or the SOAP RPC Representation as part of a
|
|
SOAP node.
|
|
</p>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="graphedges"></a>2.1 Graph Edges</h3>
|
|
<p>
|
|
Edges in the graph are said to <em>originate</em> at a
|
|
graph node
|
|
and <em>terminate</em> at a graph node. An edge that
|
|
originates at a graph
|
|
node is known as an <em>outbound edge</em> with respect to that
|
|
graph node. An edge that terminates at a graph node is known as an <em>inbound
|
|
edge</em> with respect to that graph node. An edge MAY originate and
|
|
terminate at the same graph node. An edge MAY
|
|
have only an originating graph node, that is be outbound only. An edge MAY have only a
|
|
terminating graph node, that is be inbound only.</p>
|
|
|
|
<p>The outbound edges of a given graph node MAY be
|
|
distinguished by label or by position. Position
|
|
is a total order on such edges; thus, if any
|
|
outbound edges from a given node are distinguished by
|
|
position, then all outbound edges from that node are so distinguished.</p>
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="edgelabels"></a>2.1.1 Edge labels</h4>
|
|
|
|
<p>An edge label is an XML qualified name. Two edge
|
|
labels are equal if and only if their XML expanded names are
|
|
equal. I.e., both of the following are true:</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
Their local name values are the same.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Either of the following is true:</p>
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
Both of their namespace name values are missing.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Their namespace name values are both present and are
|
|
both the same.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>See <a href="#values"><b>2.3 Values</b></a> for uses of edge labels and position
|
|
to distinguish the members of encoded values, and
|
|
XML Schema <a href="#XMLSchemaP2">[XML Schema Part 2]</a> for more
|
|
information about comparing XML qualified names.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="graphnodes"></a>2.2 Graph Nodes</h3>
|
|
|
|
<p>A graph node has zero or more outbound edges. A graph node that has no
|
|
outbound edges has an optional lexical value. All graph nodes have an
|
|
optional type name of type <em>xs:QName</em> in the namespace named
|
|
"http://www.w3.org/2001/XMLSchema" (see
|
|
XML Schema <a href="#XMLSchemaP2">[XML Schema Part 2]</a>).</p>
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="singlemultiref"></a>2.2.1 Single and Multi Reference Nodes</h4>
|
|
<p>
|
|
A graph node may be <em>single reference</em> or
|
|
<em>multi reference</em>. A
|
|
single reference graph node has a single inbound edge. A multi
|
|
reference graph node has multiple inbound edges.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="values"></a>2.3 Values</h3>
|
|
|
|
<p>A simple value is represented as a graph node with a lexical value.
|
|
</p>
|
|
|
|
<p>A compound value is represented as a graph node with zero or more
|
|
outbound edges as follows:
|
|
</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
A graph node whose outbound edges are distinguished solely
|
|
by their labels is known as a "struct". The outbound edges
|
|
of a struct MUST be labeled with distinct names (see
|
|
<a href="#edgelabels"><b>2.1.1 Edge labels</b></a>).
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
A graph node whose outbound edges are distinguished solely
|
|
by position is known as an "array". The outbound edges of
|
|
an array MUST NOT be labeled.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="soapenc"></a>3. SOAP Encoding</h2>
|
|
|
|
<p>
|
|
SOAP Encoding provides a means of encoding instances of data
|
|
that conform to the data model described in <a href="#datamodel"><b>2. SOAP Data Model</b></a>. This encoding
|
|
MAY be used to transmit data in SOAP header blocks and/or SOAP
|
|
bodies. Other data models, alternate encodings of the SOAP
|
|
Data Model as well as unencoded data MAY also be used in SOAP
|
|
messages (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>,
|
|
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapencattr">SOAP
|
|
encodingStyle Attribute</a> for specification of alternative
|
|
encoding styles and see <a href="#soapforrpc"><b>4. SOAP RPC Representation</b></a> for
|
|
restrictions on data models and encodings used to represent SOAP
|
|
Remote Procedure Calls (RPC)).
|
|
</p>
|
|
|
|
<p>The serialization rules defined in this section are
|
|
identified by the URI
|
|
"http://www.w3.org/2003/05/soap-encoding". SOAP
|
|
messages using this particular serialization SHOULD indicate
|
|
that fact by using the SOAP <code>encodingStyle</code> attribute
|
|
information item (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>
|
|
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapencattr">SOAP
|
|
encodingStyle Attribute</a>).
|
|
</p>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="encrules"></a>3.1 Mapping between XML and the SOAP Data Model</h3>
|
|
|
|
<p>
|
|
XML allows very flexible encoding of data. SOAP Encoding
|
|
defines a narrower set of rules for encoding the graphs
|
|
described in <a href="#datamodel"><b>2. SOAP Data Model</b></a>. This section
|
|
defines the encoding at a high level, and the subsequent
|
|
sub-sections describe the encoding rules in more detail. The
|
|
encodings described in this
|
|
section can be used in conjunction with the mapping of RPC
|
|
requests and responses specified in <a href="#soapforrpc"><b>4. SOAP RPC Representation</b></a>.
|
|
</p>
|
|
|
|
<p>
|
|
The encodings are described below from the perspective of a
|
|
de-serializer. In each case, the presence of an XML
|
|
serialization is presumed, and the mapping to a corresponding
|
|
graph is described.
|
|
</p>
|
|
|
|
<p>
|
|
More than one encoding is typically possible
|
|
for a given graph. When serializing a graph for transmission
|
|
inside a SOAP message,
|
|
a representation that deserializes to the identical graph MUST
|
|
be used; when multiple such representations are possible, any
|
|
of them MAY be used. When receiving an encoded SOAP message,
|
|
all representations MUST be accepted.
|
|
</p>
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="encodingedgesandnodes"></a>3.1.1 Encoding Graph Edges and Nodes</h4>
|
|
|
|
<p>
|
|
Each graph edge is encoded as an <em>element information
|
|
item</em> and each <em>element information item</em>
|
|
represents a graph edge. <a href="#complexenc"><b>3.1.3 Encoding Compound Values</b></a>
|
|
describes the relationship between edge labels and the [local name] and
|
|
[namespace name] properties of such <em>element
|
|
information items</em>.
|
|
</p>
|
|
|
|
<p>The graph node at which an edge terminates is
|
|
determined by examination of the serialized XML as follows:</p>
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
If the <em>element information item</em> representing
|
|
the edge does not have a <code>ref</code> <em>attribute
|
|
information item</em> (see <a href="#refattr"><b>3.1.5.2 ref Attribute Information Item</b></a>)
|
|
among its attributes then that <em>element information
|
|
item</em> is said to <em>represent</em> a node in
|
|
the graph and the edge terminates at that node.
|
|
In such cases the <em>element
|
|
information item</em> represents both a graph edge
|
|
and a graph node</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
If the <em>element information item</em> representing
|
|
the edge does have a <code>ref</code> <em>attribute
|
|
information item</em> (see <a href="#refattr"><b>3.1.5.2 ref Attribute Information Item</b></a>) among its attributes,
|
|
then the value of that <em>attribute information
|
|
item</em> MUST be identical to the value of exactly one
|
|
<code>id</code> <em>attribute information item</em> (
|
|
see <a href="#idattr"><b>3.1.5.1 id Attribute Information Item</b></a>) in the same envelope.
|
|
In this case the edge terminates at the graph node
|
|
represented by the <em>element information item</em>
|
|
on which the <code>id</code> <em>attribute information
|
|
item</em> appears. That <em>element information
|
|
item</em> MUST be in the scope of an
|
|
<code>encodingStyle</code> attribute with a value of
|
|
"http://www.w3.org/2003/05/soap-encoding"
|
|
(see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>,
|
|
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapencattr">SOAP encodingStyle
|
|
Attribute</a>).
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>
|
|
All nodes in the graph are encoded as described in 1
|
|
above. Additional inbound edges for multi reference graph nodes
|
|
are encoded as described in 2 above.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="simpleenc"></a>3.1.2 Encoding Simple Values</h4>
|
|
<p>
|
|
The lexical
|
|
value of a graph node representing a simple value is the sequence of
|
|
Unicode characters identified by the <em>character
|
|
information item</em> children of the <em>element
|
|
information item</em> representing that node.
|
|
The <em>element information item</em> representing a simple value node MAY have
|
|
among its attributes a 'nodeType' <em>attribute information item</em> (see <a href="#nodeTypeattr"><b>3.1.7 nodeType Attribute Information Item</b></a>).
|
|
Note that
|
|
certain Unicode characters cannot be represented in XML (see XML 1.0 <a href="#XML">[XML 1.0]</a>).
|
|
</p>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="complexenc"></a>3.1.3 Encoding Compound Values</h4>
|
|
<p>
|
|
An outbound edge of a graph node is encoded as an
|
|
<em>element information item</em> child of the
|
|
<em>element information item</em> that represents the
|
|
node (see <a href="#encodingedgesandnodes"><b>3.1.1 Encoding Graph Edges and Nodes</b></a>).
|
|
Particular rules apply depending on what kind of compound
|
|
value the graph node represents. These rules are as follows:</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>For a graph edge which is distinguished by label, the [local name] and
|
|
[namespace name] properties of the child
|
|
<em>element information item</em>
|
|
together determine the value of the edge
|
|
label.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
For a graph edge which is distinguished by position:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
The ordinal position of the graph edge corresponds
|
|
to the position of the child <em>element information
|
|
item</em> relative to its siblings
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>The [local name] and [namespace name]
|
|
properties of the child <em>element information
|
|
item</em> are not significant.
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<p>The element information item representing a compound
|
|
value node MAY have among its attributes a
|
|
<code>nodeType</code> <em>attribute information
|
|
item</em> (see <a href="#nodeTypeattr"><b>3.1.7 nodeType Attribute Information Item</b></a>).
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>The following rules apply to the encoding of a graph node that
|
|
represents an "array":</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
The <em>element information item</em>
|
|
representing an array node MAY have among its
|
|
attributes an <code>itemType</code> <em>attribute
|
|
information item</em> (see <a href="#itemtypeattr"><b>3.1.4.1 itemType Attribute Information Item</b></a>).
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
The <em>element information item</em>
|
|
representing an array node MAY have among its
|
|
attributes an <code>arraySize</code> <em>attribute
|
|
information item</em> (see <a href="#arraySizeattr"><b>3.1.6 arraySize Attribute Information Item</b></a>).
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
If a graph edge does not terminate in a graph node then
|
|
it can either be omitted from the serialization or it can be
|
|
encoded as an <em>element information item</em>
|
|
with an <em>xsi:nil</em> <em>attribute
|
|
information item</em> whose value is "true".
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
</div>
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="enctypename"></a>3.1.4 Computing the Type Name Property</h4>
|
|
<p>
|
|
The type name property of a graph node is a {namespace name,
|
|
local name} pair computed as follows:</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>
|
|
If the <em>element information item</em> representing the
|
|
graph node has an <code>xsi:type</code> <em>attribute
|
|
information item</em>
|
|
among its attributes then the type name property of the
|
|
graph node is the value of the <code>xsi:type</code> <em>attribute
|
|
information item</em>.</p>
|
|
<div class="note"><p class="prefix"><b>Note:</b></p>
|
|
<p>
|
|
This attribute is of type <em>xs:QName</em> (see
|
|
XML Schema <a href="#XMLSchemaP2">[XML Schema Part 2]</a>); its value consists of the
|
|
pair {namespace name, local name}. Neither the prefix used to
|
|
construct the QName nor any information relating to any
|
|
definition of the type is considered to be part of the
|
|
value. The SOAP graph carries only the qualified name of the
|
|
type.
|
|
</p>
|
|
</div>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Otherwise if the parent <em>element information item</em> of the
|
|
<em>element information item</em> representing the graph
|
|
node has an <code>enc:itemType</code> <em>attribute
|
|
information item</em> (see <a href="#itemtypeattr"><b>3.1.4.1 itemType Attribute Information Item</b></a>)
|
|
among its attributes then the type
|
|
name property of the graph node is the value of the
|
|
<code>enc:itemType</code> <em>attribute information item</em>
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
Otherwise the value of the type name property of the graph
|
|
node is unspecified.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<div class="note"><p class="prefix"><b>Note:</b></p>
|
|
<p>
|
|
These rules define how the type name property
|
|
of a graph node in
|
|
a graph is computed from a serialized encoding. This
|
|
specification does not mandate validation using any particular
|
|
schema language or type system. Nor does it include built in types or
|
|
provide any standardized faults to reflect value/type
|
|
name conflicts.
|
|
</p>
|
|
<p>
|
|
However, nothing prohibits development of
|
|
additional specifications to describe the use of SOAP Encoding with
|
|
particular schema languages or type systems. Such additional
|
|
specifications MAY mandate validation using particular
|
|
schema language, and MAY specify faults to be generated if
|
|
validation fails. Such additional specifications MAY specify
|
|
augmentations to the deserialized graph based on information
|
|
determined from such a validation. The use by SOAP Encoding of xsi:type
|
|
is intended to facilitate integration with the W3C XML Schema
|
|
language (see <a href="#encschema"><b>C. Using W3C XML Schema with SOAP Encoding</b></a>). Other XML based
|
|
schema languages, data schemas and programmatic type systems
|
|
MAY be used but only to the extent that they are compatible
|
|
with the serialization described in this specification.
|
|
</p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
|
|
<h5><a name="itemtypeattr"></a>3.1.4.1 itemType Attribute Information Item</h5>
|
|
<p>
|
|
The <code>itemType</code> <em>attribute information item</em> has
|
|
the following Infoset properties:
|
|
</p>
|
|
<ul>
|
|
|
|
<li>
|
|
<p>
|
|
A [local name] of <code>itemType</code> .
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
A [namespace name] of "http://www.w3.org/2003/05/soap-encoding".
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
A [specified] property with a value of "true".
|
|
</p>
|
|
</li>
|
|
|
|
</ul>
|
|
<p>
|
|
The type of the <code>itemType</code> <em>attribute
|
|
information item</em> is <em>xs:QName</em>.
|
|
The value of the <code>itemType</code> <em>attribute
|
|
information item</em> is used to compute the type name
|
|
property (see <a href="#enctypename"><b>3.1.4 Computing the Type Name Property</b></a>) of members of
|
|
an array.
|
|
</p>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="uniqueids"></a>3.1.5 Unique identifiers</h4>
|
|
|
|
<div class="div4">
|
|
|
|
<h5><a name="idattr"></a>3.1.5.1 id Attribute Information Item</h5>
|
|
<p>
|
|
The <code>id</code> <em>attribute information item</em> has
|
|
the following Infoset properties:
|
|
</p>
|
|
<ul>
|
|
|
|
<li>
|
|
<p>A [local name] of <code>id</code> .</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>A [namespace name] of "http://www.w3.org/2003/05/soap-encoding".</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>A [specified] property with a value of
|
|
"true".</p>
|
|
</li>
|
|
|
|
</ul>
|
|
<p>
|
|
The type of the <code>id</code> <em>attribute
|
|
information item</em> is <em>xs:ID</em>.
|
|
The value of the <code>id</code> <em>attribute information
|
|
item</em> is a unique identifier that can be referred to by
|
|
a <code>ref</code> <em>attribute information item</em>
|
|
(see <a href="#refattr"><b>3.1.5.2 ref Attribute Information Item</b></a>).
|
|
</p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
|
|
<h5><a name="refattr"></a>3.1.5.2 ref Attribute Information Item</h5>
|
|
<p>
|
|
The <code>ref</code> <em>attribute information item</em> has
|
|
the following Infoset properties:
|
|
</p>
|
|
<ul>
|
|
|
|
<li>
|
|
<p>A [local name] of <code>ref</code> .</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>A [namespace name] of "http://www.w3.org/2003/05/soap-encoding".</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>A [specified] property with a value of
|
|
"true".</p>
|
|
</li>
|
|
|
|
</ul>
|
|
<p>
|
|
The type of the <code>ref</code> <em>attribute information
|
|
item</em> is <em>xs:IDREF</em>.
|
|
The value of the <code>ref</code> <em>attribute information
|
|
item</em> is a reference to a unique identifier defined
|
|
by an <code>id</code> <em>attribute information item</em>
|
|
(see <a href="#idattr"><b>3.1.5.1 id Attribute Information Item</b></a>).
|
|
</p>
|
|
|
|
</div>
|
|
<div class="div4">
|
|
|
|
<h5><a name="uniqueidconstraints"></a>3.1.5.3 Constraints on id and ref Attribute Information
|
|
Items</h5>
|
|
<p>
|
|
The value of a <code>ref</code> <em>attribute information item</em> MUST also be
|
|
the value of exactly one <code>id</code> <em>attribute information item</em>.
|
|
</p>
|
|
<p>
|
|
A <code>ref</code> <em>attribute information item</em> and
|
|
an <code>id</code> <em>attribute information item</em>
|
|
MUST NOT appear on the same <em>element information item</em>.
|
|
</p>
|
|
</div>
|
|
</div>
|
|
|
|
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="arraySizeattr"></a>3.1.6 arraySize Attribute Information Item</h4>
|
|
<p>
|
|
The <code>arraySize</code> <em>attribute information item</em> has
|
|
the following Infoset properties:
|
|
</p>
|
|
<ul>
|
|
|
|
<li>
|
|
<p>
|
|
A [local name] of <code>arraySize</code> .
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>A [namespace name] of "http://www.w3.org/2003/05/soap-encoding".
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>
|
|
The type of the <code>arraySize</code> <em>attribute
|
|
information item</em> is <em>enc:arraySize</em>.
|
|
The value of the <code>arraySize</code> <em>attribute information item</em>
|
|
MUST conform to the following EBNF grammar</p>
|
|
|
|
|
|
<h5></h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="arraysizedefn"></a>[1] </td><td><code>arraySizeValue</code></td><td> ::= </td><td><code>("*" | concreteSize) nextConcreteSize*</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="nextconcretesize"></a>[2] </td><td><code>nextConcreteSize</code></td><td> ::= </td><td><code>whitespace concreteSize</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="concretesize"></a>[3] </td><td><code>concreteSize</code></td><td> ::= </td><td><code>[0-9]+</code></td></tr></tbody><tbody><tr valign="baseline"><td><a name="whitespace"></a>[4] </td><td><code>white space</code></td><td> ::= </td><td><code>(#x20 | #x9 | #xD | #xA)+</code></td></tr></tbody></table>
|
|
<p>
|
|
The arraySize attribute conveys a suggested mapping of a SOAP array to a
|
|
multi-dimensional program data structure. The cardinality of the arraySize
|
|
list represents the number of dimensions, with individual values providing
|
|
the extents of the respective dimensions. When SOAP encoding
|
|
multidimensional arrays, nodes are selected such that the last subscript
|
|
(i.e., the subscript corresponding to the last specified dimension) varies
|
|
most rapidly, and so on with the first varying most slowly. An asterisk
|
|
MAY be used only in place of the first size to indicate a dimension of
|
|
unspecified extent; asterisks MUST NOT appear in other positions in the
|
|
list. The default value of the <code>arraySize</code> <em>attribute information item</em> is
|
|
"*", i.e., a single dimension of unspecified extent.
|
|
</p>
|
|
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="nodeTypeattr"></a>3.1.7 nodeType Attribute Information Item</h4>
|
|
<p>
|
|
The <code>nodeType</code> <em>attribute information item</em> has
|
|
the following Infoset properties:
|
|
</p>
|
|
<ul>
|
|
|
|
<li>
|
|
<p>
|
|
A [local name] of <code>nodeType</code> .
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>A [namespace name] of "http://www.w3.org/2003/05/soap-encoding".
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>A [specified] property with a value of
|
|
"true".</p>
|
|
</li>
|
|
|
|
</ul>
|
|
<p>
|
|
The type of the <code>nodeType</code> <em>attribute
|
|
information item</em> is <em>enc:nodeType</em>.</p>
|
|
|
|
|
|
<p>
|
|
The value of the <code>nodeType</code> <em>attribute information item</em>
|
|
MUST, if present, be one of the strings "simple" or "struct" or "array". The value
|
|
indicates what kind of a value this node represents - a simple value, a
|
|
compound struct value or a compound array value respectively.
|
|
</p>
|
|
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="encfaults"></a>3.2 Decoding Faults</h3>
|
|
|
|
<p>
|
|
During deserialization a SOAP receiver:
|
|
</p>
|
|
|
|
<ul>
|
|
|
|
<li>
|
|
<p>
|
|
SHOULD generate an "env:Sender" SOAP
|
|
fault with a subcode of <code>enc:MissingID</code>
|
|
if the message contains a <code>ref</code> <em>attribute
|
|
information item</em> but no corresponding <code>id</code>
|
|
<em>attribute information item</em> (see <a href="#uniqueidconstraints"><b>3.1.5.3 Constraints on id and ref Attribute Information
|
|
Items</b></a>).
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
SHOULD generate an "env:Sender" SOAP
|
|
fault with a subcode of <code>enc:DuplicateID</code>
|
|
if the message contains two or more <code>id</code> <em>attribute
|
|
information item</em> that have the same value. (see <a href="#uniqueidconstraints"><b>3.1.5.3 Constraints on id and ref Attribute Information
|
|
Items</b></a>).
|
|
</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
MAY generate an "env:Sender" SOAP fault with a
|
|
subcode of <code>enc:UntypedValue</code> if the type name
|
|
property of an encoded graph node is unspecified.
|
|
</p>
|
|
</li>
|
|
|
|
</ul>
|
|
</div>
|
|
|
|
</div>
|
|
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="soapforrpc"></a>4. SOAP RPC Representation</h2>
|
|
|
|
<p>One of the design goals of SOAP is to facilitate
|
|
the exchange of messages that map conveniently to definitions
|
|
and invocations of methods and procedures in commonly used
|
|
programming languages. For that purpose, this section defines
|
|
a uniform representation of remote procedure call (RPC) requests and responses. It
|
|
does not define actual mappings to any particular programming
|
|
language. The representation is entirely platform-independent
|
|
and considerable effort has been made to encourage usage that
|
|
is consistent with the Web in general.</p>
|
|
|
|
<p>As mentioned in section <a href="#datamodel"><b>2. SOAP Data Model</b></a>, use and
|
|
implementation of the SOAP RPC Representation is OPTIONAL.</p>
|
|
|
|
<p> The SOAP <code>encodingStyle</code> attribute information item (see
|
|
SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapencattr">SOAP encodingStyle
|
|
Attribute</a>) is used to indicate the encoding style of
|
|
the RPC representation. The encoding thus specified MUST support the <a href="#datamodel"><b>2. SOAP Data Model</b></a>. The encoding style defined in <a href="#soapenc"><b>3. SOAP Encoding</b></a> supports such constructs and is therefore
|
|
suitable for use with the SOAP RPC Representation. </p>
|
|
|
|
<p>
|
|
This SOAP RPC Representation is not predicated on any SOAP
|
|
protocol binding. When SOAP is bound to HTTP, an RPC invocation
|
|
maps naturally to an HTTP request and an RPC response maps to an
|
|
HTTP response. (see <a href="#soapinhttp"><b>7. SOAP HTTP Binding</b></a>). However, the
|
|
SOAP RPC Representation is not limited to the SOAP HTTP Binding.
|
|
</p>
|
|
|
|
<p>To invoke an RPC, the following information is needed:</p>
|
|
|
|
<ul>
|
|
<li><p>The address of the target SOAP node.</p></li>
|
|
|
|
<li><p>A procedure or method name.</p></li>
|
|
|
|
<li>
|
|
<p>The identities
|
|
and values of any arguments to be passed to the procedure or method. Arguments used to
|
|
identify Web resources SHOULD be distinguished from those representing data or control information (see
|
|
<a href="#RPCWebArguments"><b>4.1.1 Identification of RPC Resources</b></a>.)</p>
|
|
</li>
|
|
<li>
|
|
<p>Values for properties as required by any features of the
|
|
binding to be used. For example, "GET" or "POST"
|
|
for the <code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> property of the <a href="#WebMethodFeature"><b>6.4 SOAP Web Method Feature</b></a>.</p>
|
|
</li>
|
|
|
|
<li><p>Optional header data.</p></li>
|
|
|
|
</ul>
|
|
|
|
<p>SOAP RPC relies on the protocol binding to provide a mechanism
|
|
for carrying the URI of the target SOAP node. For HTTP the request URI
|
|
indicates the resource against which the invocation is being
|
|
made. Other than requiring it to be a valid URI, SOAP places no
|
|
restriction on the form of an identifier (see RFC 3986 <a href="#RFC3986">[RFC 3986]</a>
|
|
for more information on URIs). The section <a href="#RPCWebArguments"><b>4.1.1 Identification of RPC Resources</b></a> further discusses the use
|
|
of URIs for identifying RPC resources.</p>
|
|
<p>The SOAP RPC Representation employs the <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> and <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>. Use of the SOAP RPC Representation with other MEPs MAY be possible, but is beyond the
|
|
scope of this specification.</p>
|
|
|
|
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="RPConWeb"></a>4.1 Use of RPC on the World Wide Web</h3>
|
|
<p>
|
|
The following guidelines SHOULD be followed when deploying
|
|
SOAP RPC applications
|
|
on the World Wide Web.</p>
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="RPCWebArguments"></a>4.1.1 Identification of RPC Resources</h4>
|
|
<p>The World Wide Web identifies resources with URIs, but common programming conventions convey identification information in the arguments to
|
|
procedures, or in the names of those procedures. For example, the call:</p>
|
|
<p><code>
|
|
updateQuantityInStock(PartNumber="123", NewQuantity="200")
|
|
</code></p>
|
|
<p>suggests that the resource to be
|
|
updated is the <code>QuantityInStock</code> for <code>PartNumber</code> "123".
|
|
Accordingly, when mapping to
|
|
or from a programming language method or procedure, any arguments that serve to identify resources
|
|
(such as the part number above) should when practical be represented in the URI to which the SOAP message is addressed.
|
|
When mapping to or from a programming language method or procedure, the name of which
|
|
identifies or qualifies the identification of a resource (such as QuantityInStock above), such naming or
|
|
qualification should when practical be represented in the URI to which the SOAP message is addressed.
|
|
No standard means of representation of arguments or method names is provided by this specification.</p>
|
|
|
|
<div class="note"><p class="prefix"><b>Note:</b></p>
|
|
<p>Conventions for specific URI encodings of procedure
|
|
names and arguments, as well as for controlling the
|
|
inclusion of such arguments in the SOAP RPC body could be established in conjunction with the development
|
|
of Web Service interface description languages. They could be developed when SOAP is bound to particular
|
|
programming languages or could be established on an application- or
|
|
procedure-specific basis.</p>
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="RPCResourceRetrieval"></a>4.1.2 Distinguishing Resource Retrievals from other RPCs</h4>
|
|
<p>
|
|
The World Wide Web depends on mechanisms that optimize commonly performed information retrieval
|
|
tasks. Specifically, protocols such as HTTP <a href="#RFC2616">[RFC 2616]</a> provide a GET method which is
|
|
used to perform safe
|
|
retrievals, i.e., to perform retrievals that are idempotent, free of side effects, and for which security considerations do not
|
|
preclude the use of cached results or URI-based resource identification.</p>
|
|
<p>
|
|
Certain procedure or method calls represent requests for information retrieval. For example, the call:</p>
|
|
<p><code>getQuantityInStock(PartNumber="123")</code></p>
|
|
<p>might be used to retrieve the quantity established in
|
|
the example above.</p>
|
|
|
|
<p>The following conventions can be employed to implement SOAP retrievals and other
|
|
RPCs on the Web:
|
|
</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
The conventions described in <a href="#RPCWebArguments"><b>4.1.1 Identification of RPC Resources</b></a> are used to identify the
|
|
resource with a URI.
|
|
</p>
|
|
</li>
|
|
<li>
|
|
<p>In cases where all the arguments have been represented in the URI,
|
|
no SOAP header blocks are to be transmitted and the operation is a safe
|
|
retrieval, the <a href="#WebMethodFeature"><b>6.4 SOAP Web Method Feature</b></a> and the <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a> are used. Accordingly, no SOAP envelope is
|
|
transmitted for the request, and the
|
|
<code>http://www.w3.org/2003/05/soap/features/web-method/Method</code>
|
|
property is set to "GET". The results of the retrieval
|
|
are a SOAP RPC response as described in <a href="#rpcresponse"><b>4.2.2 RPC Response</b></a></p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
In cases where the operation to be performed is not a retrieval, when
|
|
SOAP header blocks are to be transmitted (a digital signature, for example),
|
|
or when a retrieval is not safe, the <a href="#WebMethodFeature"><b>6.4 SOAP Web Method Feature</b></a> and the <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> are used. The
|
|
request envelope is encoded as described in <a href="#rpcinvocation"><b>4.2.1 RPC Invocation</b></a>, and the results are as described in <a href="#rpcresponse"><b>4.2.2 RPC Response</b></a>. The <code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> property is
|
|
set to "POST".</p>
|
|
</li></ul>
|
|
|
|
<p>The SOAP RPC Representation does not define any other value for the
|
|
<code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> .</p>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="rpcsoapbdy"></a>4.2 RPC and SOAP Body</h3>
|
|
|
|
<p>RPC invocations (except for safe retrievals: see <a href="#RPCResourceRetrieval"><b>4.1.2 Distinguishing Resource Retrievals from other RPCs</b></a>) and responses are both carried in the
|
|
SOAP <code>Body</code> element (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapbody">SOAP Body</a>) using the
|
|
following representation:</p>
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="rpcinvocation"></a>4.2.1 RPC Invocation</h4>
|
|
|
|
<p>An RPC invocation is modeled as follows:</p>
|
|
|
|
<ul>
|
|
<li><p>The invocation is represented by a single
|
|
struct containing an outbound edge for each [in] or [in/out]
|
|
parameter. The struct is named identically to the procedure or
|
|
method and the conventions of <a href="#namemap"><b>B. Mapping Application-Defined Names to XML Names</b></a>
|
|
SHOULD be used to represent method names that are not legal
|
|
XML names.</p></li>
|
|
|
|
<li><p>Each outbound edge has a label
|
|
corresponding to the name of the parameter. The conventions of
|
|
<a href="#namemap"><b>B. Mapping Application-Defined Names to XML Names</b></a> SHOULD be used to represent parameter
|
|
names that are not legal XML names.</p></li>
|
|
|
|
</ul>
|
|
|
|
<p>Applications MAY process invocations with missing
|
|
parameters but also MAY fail to process the invocation and return a fault.</p>
|
|
|
|
</div>
|
|
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="rpcresponse"></a>4.2.2 RPC Response</h4>
|
|
|
|
<p>An RPC response is modeled as follows:</p>
|
|
|
|
<ul>
|
|
<li><p>The response is represented by a single struct
|
|
containing an outbound edge for the return value and each [out]
|
|
or [in/out] parameter. The name of the struct is not significant.</p></li>
|
|
|
|
<li><p>Each parameter is represented by an outbound edge
|
|
with a label corresponding to the name of the parameter. The conventions of
|
|
<a href="#namemap"><b>B. Mapping Application-Defined Names to XML Names</b></a> SHOULD be used to represent parameter
|
|
names that are not legal XML names.</p></li>
|
|
|
|
<li><p>
|
|
A non-void return value is represented as follows:</p>
|
|
|
|
<ol>
|
|
<li>
|
|
<p>There MUST be an outbound edge with a local name of <code>result</code> and a namespace
|
|
name of "http://www.w3.org/2003/05/soap-rpc"
|
|
which terminates in a terminal node</p>
|
|
</li>
|
|
<li>
|
|
<p>
|
|
The type of that terminal node is a xs:QName and its value
|
|
is the name of the outbound edge which terminates in the
|
|
actual return value.
|
|
</p>
|
|
</li>
|
|
</ol>
|
|
|
|
<p>If the return value of the procedure is void
|
|
then an outbound edge with a local name of <code>result</code> and a namespace
|
|
name of "http://www.w3.org/2003/05/soap-rpc"
|
|
MUST NOT be present.</p>
|
|
</li>
|
|
|
|
|
|
<li><p>Invocation faults are handled according to the
|
|
rules in <a href="#rpcfaults"><b>4.4 RPC Faults</b></a>. If a protocol binding
|
|
adds additional rules for fault expression, those MUST also
|
|
be followed.</p></li>
|
|
</ul>
|
|
|
|
|
|
</div>
|
|
|
|
<div class="div3">
|
|
|
|
|
|
<h4><a name="rpcencrestriction"></a>4.2.3 SOAP Encoding Restriction</h4>
|
|
|
|
<p>When using SOAP encoding (see <a href="#soapenc"><b>3. SOAP Encoding</b></a>) in
|
|
conjunction with the RPC convention described here, the SOAP
|
|
<code>Body</code> MUST contain only a single child <em>element
|
|
information item</em>, that child being the serialized RPC
|
|
invocation or response struct.</p>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="rpcsoaphead"></a>4.3 RPC and SOAP Header</h3>
|
|
|
|
<p>Additional information relevant to the encoding of an RPC
|
|
invocation but not part of the formal procedure or method
|
|
signature MAY be expressed in a SOAP envelope carrying an RPC invocation or response.
|
|
Such additional information MUST be expressed as SOAP header blocks.</p>
|
|
|
|
|
|
</div>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="rpcfaults"></a>4.4 RPC Faults</h3>
|
|
|
|
<p>The SOAP RPC Representation introduces additional SOAP fault
|
|
subcode values to be used in conjunction with the fault codes
|
|
described in SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#faultcodes">SOAP Fault Codes</a>.</p>
|
|
|
|
<p>Errors arising during RPC invocations are reported
|
|
according to the following rules:</p>
|
|
|
|
<ol>
|
|
|
|
<li><p>A fault with a <code>Value</code> of
|
|
<code>Code</code> set to "env:Receiver" SHOULD
|
|
be generated when the receiver cannot handle the message
|
|
because of some temporary condition, e.g. when it is out of
|
|
memory.</p>
|
|
|
|
<div class="note"><p class="prefix"><b>Note:</b></p>
|
|
<p>Throughout this document, the term "<code>Value</code> of
|
|
<code>Code</code> " is used as a shorthand for "value of
|
|
the <code>Value</code> child <em>element information
|
|
item</em> of the <code>Code</code> <em>element
|
|
information item</em>" (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>, <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#faultcodeelement">SOAP Code
|
|
Element </a>).</p>
|
|
</div>
|
|
|
|
</li>
|
|
|
|
<li>
|
|
<p>A fault with a <code>Value</code> of <code>Code</code>
|
|
set to "env:DataEncodingUnknown"
|
|
SHOULD be generated when the arguments
|
|
are encoded in a data encoding unknown to the
|
|
receiver.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>A fault with a <code>Value</code> of <code>Code</code>
|
|
set to "env:Sender" and a
|
|
<code>Value</code> of <code>Subcode</code> set to
|
|
"rpc:ProcedureNotPresent"
|
|
MAY be generated when the receiver
|
|
does not support the procedure or method specified.</p>
|
|
|
|
<div class="note"><p class="prefix"><b>Note:</b></p>
|
|
<p>Throughout this document, the term "<code>Value</code> of
|
|
<code>Subcode</code> " is used as a shorthand for "value of
|
|
the <code>Value</code> child <em>element information
|
|
item</em> of the <code>Subcode</code> <em>element
|
|
information item</em>" (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>, <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#faultsubcodeelement">SOAP Subcode
|
|
element</a>).</p>
|
|
</div>
|
|
|
|
</li>
|
|
|
|
<li>
|
|
<p>A fault with a <code>Value</code> of <code>Code</code>
|
|
set to "env:Sender" and a
|
|
<code>Value</code> of <code>Subcode</code> set to
|
|
"rpc:BadArguments"
|
|
MUST be generated when the receiver
|
|
cannot parse the arguments or when there is a
|
|
mismatch in number and/or type of the arguments
|
|
between what the receiver expects and what was
|
|
sent.</p>
|
|
</li>
|
|
|
|
<li><p>Other faults arising in an extension or from the
|
|
application SHOULD be generated as described in SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapfault">SOAP Fault Codes</a>.</p>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
<p>In all cases the values of the <code>Detail</code> and
|
|
<code>Reason</code> <em>element information items</em>
|
|
are implementation-defined. Details of their use MAY be specified by an
|
|
external document.</p>
|
|
|
|
<div class="note"><p class="prefix"><b>Note:</b></p><p>Senders might receive different faults from
|
|
those listed above in response to an RPC invocation if the
|
|
receiver does not support the (optional) RPC convention described
|
|
here.</p></div>
|
|
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="soapfeatspec"></a>5. A Convention for Describing Features and Bindings</h2>
|
|
|
|
<p>This section describes a convention describing Features (including
|
|
MEPs) and Bindings in terms of properties and property values. The
|
|
convention is sufficient to describe the distributed states of Feature
|
|
and Binding specifications as mandated by the Binding Framework (see
|
|
SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew">SOAP Protocol Binding
|
|
Framework</a>) and it is used to describe a Request-Response MEP (see <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a>), a Response MEP (see <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>), the SOAP Web Method feature (see <a href="#WebMethodFeature"><b>6.4 SOAP Web Method Feature</b></a>) and the SOAP HTTP Binding (see <a href="#soapinhttp"><b>7. SOAP HTTP Binding</b></a>) elsewhere in this document. Along with the convention
|
|
itself, an informal model is defined that describes how properties
|
|
propagate through a SOAP system. Note that this model is intended to be
|
|
illustrative only, and is not meant to imply any constraints on the
|
|
structure or layering of any particular SOAP implementation.</p>
|
|
|
|
<div class="div2">
|
|
<h3><a name="modprop"></a>5.1 Model and Properties</h3>
|
|
|
|
<p>In general, a SOAP message is the information that one SOAP node wishes to
|
|
exchange with another SOAP node according to a particular set of features,
|
|
including a MEP. In addition, there may be information essential to exchanging
|
|
a message that is not part of the message itself. Such information is sometimes
|
|
called message metadata. In the model, the message, any message metadata,
|
|
and the various information items that enable features are represented as
|
|
abstractions called properties.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a name="bindprops"></a>5.1.1 Properties</h4>
|
|
|
|
<p>Under the convention, properties are represented as follows:</p>
|
|
|
|
<ul>
|
|
<li><p>Properties are named with URIs.</p></li>
|
|
|
|
<li><p>Where appropriate, property values SHOULD have
|
|
an XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1]</a> <a href="#XMLSchemaP2">[XML Schema Part 2]</a> type listed in the specification which
|
|
introduces the property.</p></li>
|
|
</ul>
|
|
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="bindpropsscope"></a>5.1.2 Property Scope</h4>
|
|
|
|
<p>Properties within a SOAP node differ in terms of their scope and the
|
|
origins of their values. As shown in the figure below, we make the
|
|
distinction between per-message-exchange properties and more widely scoped
|
|
properties by assigning them to different containers called Message
|
|
Exchange Context and Environment Context respectively. All properties,
|
|
regardless of their scope, are shared by a SOAP node and a particular
|
|
Binding.</p>
|
|
|
|
<img src="xmlp-framework-props.png" alt="Model describing properties shared between SOAP and Binding">
|
|
<p align="center">Figure 1: Model describing properties shared between SOAP and Binding</p>
|
|
|
|
|
|
<div class="div4">
|
|
<h5><a name="soapmec"></a>5.1.2.1 Message Exchange Context</h5>
|
|
|
|
<p>A message exchange context is a collection of properties whose scope is
|
|
limited to an instance of a given message exchange pattern. An example
|
|
of a message exchange context property is the identifier of the message
|
|
exchange pattern in use.</p>
|
|
|
|
</div>
|
|
|
|
|
|
|
|
<div class="div4">
|
|
<h5><a name="soapenvc"></a>5.1.2.2 Environment Context</h5>
|
|
|
|
<p>The Environment Context is a collection of properties whose scope
|
|
extends beyond an instance of a given message exchange pattern.
|
|
Examples of Environment Context properties are the IP address of the
|
|
SOAP node or the current date and time.</p>
|
|
|
|
<p>The values of properties in Environment Context may depend upon local
|
|
circumstances (as depicted by the external arrow from Environment Context in
|
|
the figure above). More specifically, the properties in the example
|
|
could be influenced by an operating system user ID on whose behalf a
|
|
message exchange is being executed. The mapping of information in a
|
|
particular implementation to such properties is outside the scope of
|
|
the binding framework although the abstract representation of such
|
|
information as properties is not.</p>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="bindpropfeat"></a>5.1.3 Properties and Features</h4>
|
|
|
|
<p>A feature may be expressed through multiple properties and a single property
|
|
may enable more than one feature. For example, the properties called User ID and
|
|
Password may be used to enable a feature called Authentication. As a second example,
|
|
a single property called Message ID could be used to enable one feature called
|
|
Transaction and a second feature called Message Correlation.</p>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="soapsupmep"></a>6. SOAP-Supplied Message Exchange Patterns and Features</h2>
|
|
|
|
<div class="div2">
|
|
<h3><a name="meppropconv"></a>6.1 Property Conventions for SOAP Message Exchange Patterns</h3>
|
|
|
|
<p><a href="#tabmeppropdefs"><b>Table 2</b></a> describes the properties
|
|
(in accordance with the property naming conventions
|
|
defined in this document) that support the description of
|
|
message exchange patterns (MEPs). Other properties may
|
|
be involved in the specification of particular MEPs,
|
|
but the properties in this table are generally applicable to all MEPs.</p>
|
|
|
|
<a name="tabmeppropdefs"></a><table border="1">
|
|
<caption>Table 2: Property definitions supporting the description of MEPs</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</span></code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value:</b>The name
|
|
of the MEP in
|
|
operation.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Type:</b> xs:anyURI
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</span></code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value:</b> A value that denotes a pattern-specific,
|
|
binding-independent reason for the failure of a message
|
|
exchange. Underlying protocol binding specifications
|
|
may define properties to convey more binding-specific
|
|
details of the failure.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Type:</b> xs:anyURI
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</span></code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value:</b>The identifier of the pattern-specific role of the
|
|
local SOAP node participating in the message
|
|
exchange.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Type:</b> xs:anyURI
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr><tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</span></code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value:</b> The identifier of the current state of the message
|
|
exchange. This value is managed by the binding
|
|
instance and may be inspected by other entities
|
|
monitoring the progress of the message
|
|
exchange.
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Type:</b> xs:anyURI
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
</div>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="singlereqrespmep"></a>6.2 SOAP Request-Response Message Exchange Pattern</h3>
|
|
|
|
<p>This section defines the message exchange pattern (MEP) called "Request-Response". The
|
|
description is an abstract presentation of the operation of
|
|
this MEP. It is not intended to describe a real
|
|
implementation or to suggest how a real implementation should
|
|
be structured.</p>
|
|
|
|
<div class="div3">
|
|
<h4><a name="mepname"></a>6.2.1 SOAP Feature Name</h4>
|
|
|
|
<p>This message exchange pattern is identified by
|
|
the URI (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#procsoapmsgs">SOAP Features</a>):</p>
|
|
<ul><li><p>"http://www.w3.org/2003/05/soap/mep/request-response/"</p></li></ul>
|
|
|
|
</div>
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="bindinfdesc"></a>6.2.2 Description</h4>
|
|
|
|
<p>The SOAP Request-Response MEP defines a
|
|
pattern for the exchange of a SOAP message acting as a
|
|
request followed by a message acting as a response.
|
|
The response message MAY contain a SOAP envelope,
|
|
or else the response MUST be a binding-specific
|
|
message indicating that the request has been received.
|
|
In the absence of failure in the underlying
|
|
protocol, this MEP consists of exactly two
|
|
messages.</p>
|
|
|
|
<p>In the normal operation of a message exchange conforming to
|
|
the Request-Response MEP, a
|
|
request message is first transferred from the requesting SOAP
|
|
node to the responding SOAP node. Following the successful
|
|
processing of the request message by the responding SOAP node,
|
|
a response message is transferred from the responding
|
|
SOAP node to the requesting SOAP node. </p>
|
|
|
|
<p>Abnormal operation during a Request-Response message exchange
|
|
might be caused by a failure to transfer the request message, a
|
|
failure at the responding SOAP node to process the request
|
|
message, or a failure to transfer the response message. Such
|
|
failures might be silent at either or both of the requesting and
|
|
responding SOAP nodes involved, or might result in the generation of a SOAP
|
|
or binding-specific fault (see <a href="#bindfaulthdn"><b>6.2.4 Fault Handling</b></a>).
|
|
Also, during abnormal operation
|
|
each SOAP node involved in the message exchange might differ in
|
|
its determination of the successful completion of the message
|
|
exchange. </p>
|
|
|
|
<p>The scope of a Request-Response MEP is limited to
|
|
the exchange of a request message and a response message between
|
|
one requesting and one responding SOAP node. This pattern does
|
|
not mandate any correlation between multiple requests nor
|
|
specific timing for multiple requests. Implementations MAY choose
|
|
to support multiple ongoing requests (and associated response
|
|
processing) at the same time.</p>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="bindformdesc"></a>6.2.3 State Machine Description</h4>
|
|
|
|
<p>The Request-Response MEP defines a set of properties described in <a href="#tabreqresprops"><b>Table 3</b></a>.</p>
|
|
|
|
<a name="tabreqresprops"></a><table border="1">
|
|
<caption>Table 3: Property definitions for Request-Response MEP</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><b>Value: </b>An abstract structure that represents the current
|
|
outbound message in the message exchange. This
|
|
abstracts both SOAP Envelope and any other
|
|
information structures that are transferred along
|
|
with the envelope.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><b>Type: </b>Not specified</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><b>Value: </b>An abstract structure that represents the current
|
|
inbound message in the message exchange. This
|
|
abstracts both SOAP Envelope and any other
|
|
information structures that are transferred along
|
|
with the envelope.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><b>Type: </b>Not specified</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><b>Value: </b>The identifier of the immediate destination of an
|
|
outbound message.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><b>Type: </b>xs:anyURI</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/mep/ImmediateSender</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><b>Value: </b>The identifier of the immediate sender of an inbound
|
|
message.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><b>Type: </b>xs:anyURI</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>To initiate a message exchange conforming to the
|
|
Request-Response MEP, the requesting SOAP node instantiates a
|
|
local message exchange context. <a href="#tabreqcon"><b>Table 4</b></a> describes how
|
|
the context is initialized.</p>
|
|
|
|
<a name="tabreqcon"></a><table border="1">
|
|
<caption>Table 4: Instantiation of a Message Exchange Context
|
|
for a requesting SOAP node</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</span></code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value:</b> "http://www.w3.org/2003/05/soap/mep/request-response/"</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</span></code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value:</b> "None"</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Notes:</b> A relative URI whose
|
|
base URI is the value of the property named
|
|
<code><span class="squeezeBigLiterals">http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</span></code>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</span></code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value:</b> "RequestingSOAPNode"</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Notes:</b> A relative URI whose
|
|
base URI is the value of the property named
|
|
<code><span class="squeezeBigLiterals">http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</span></code>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</span></code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value:</b> "Init"</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Notes:</b> A relative URI whose base URI is the value of the property named
|
|
<code><span class="squeezeBigLiterals">http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/Role</span></code>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/mep/OutboundMessage</span></code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value:</b> An abstraction of the request message </td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name:</b> <code><span class="squeezeBigLiterals">http://www.w3.org/2003/05/soap/mep/ImmediateDestination</span></code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value:</b> An identifier (URI) that denotes the responding SOAP node</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>There may be other properties related to the operation of
|
|
the message exchange context instance. Such properties are
|
|
initialized according to their own feature specifications.
|
|
</p>
|
|
|
|
<p>Once the message exchange context is initialized, control
|
|
of the context is passed to a (conforming) local binding
|
|
instance. </p>
|
|
|
|
<p>The diagram below shows the logical state transitions at
|
|
the requesting and responding SOAP nodes during the lifetime
|
|
of the message exchange. At each SOAP node, the local binding
|
|
instance updates (logically) the value of the
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/
|
|
ExchangeContext/State</code> property to reflect the current
|
|
state of the message exchange. The state names are relative
|
|
URIs, relative to a base URI value carried in the
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/
|
|
ExchangeContext/Role</code> property of the local message
|
|
exchange context.</p>
|
|
|
|
<img src="StateTransitions.png" alt="Request-Response MEP State Transition Diagram.">
|
|
<p align="center">Figure 2: Request-Response MEP State Transition Diagram.</p>
|
|
|
|
|
|
<p>When the local binding instance at the responding SOAP
|
|
node starts to receive an inbound request message, it
|
|
(logically) instantiates a message exchange context. <a href="#tabrescon"><b>Table 5</b></a>
|
|
describes the properties that the binding initializes as
|
|
part of the context's instantiation.</p>
|
|
|
|
<a name="tabrescon"></a><table border="1">
|
|
<caption>Table 5: Instantiation of Message Exchange Context for
|
|
an inbound request message at a responding SOAP node</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>"http://www.w3.org/2003/05/soap/mep/request-response/"
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><b>Notes: </b>Initialized as early as possible during the life cycle
|
|
of the message exchange.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>"None"
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><b>Notes: </b>A relative URI whose base URI is the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</code>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><b>Property name: </b><code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>"RespondingSOAPNode"
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Notes: </b>A relative URI whose base URI is the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> .
|
|
Initialized as early as possible during the life cycle the message exchange.
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b><code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>"Init"
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><b>Notes: </b>A relative URI whose base URI is the
|
|
value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/Role</code>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>When the requesting and responding SOAP nodes transition between
|
|
states, the local binding instance (logically) updates a number of
|
|
properties. <a href="#tabreqstatetrans"><b>Table 6</b></a> and <a href="#tabresstatetrans"><b>Table 7</b></a> describe these updates for the requesting
|
|
and the responding SOAP nodes, respectively.</p>
|
|
|
|
<a name="tabreqstatetrans"></a><table border="1">
|
|
<caption>Table 6: Requesting SOAP Node State Transitions</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">CurrentState</th>
|
|
<th rowspan="1" colspan="1"> </th>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">"Init"</td>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Unconditional</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Requesting"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Initiate transmission of request message
|
|
abstracted in
|
|
<code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> .</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="2" colspan="1">"Requesting"</td>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message transmission failure</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Set
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code> to
|
|
"transmissionFailure"</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Start receiving response message</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Sending+Receiving"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Set
|
|
<code>http://www.w3.org/2003/05/soap/mep/ImmediateSender</code> to denote the sender of the response message (may differ from the values in <code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code> ).
|
|
Start making an abstraction of the response message available in <code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code> .</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="2" colspan="1">"Sending+Receiving"</td>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message exchange failure</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Set
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code> to
|
|
"exchangeFailure"</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Completed sending request message. Completed receiving response message.</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Success"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>If a SOAP envelope is received in the response (I.e., in <code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code> ), then process it according to the SOAP processing model.</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p> </p>
|
|
|
|
<a name="tabresstatetrans"></a><table border="1">
|
|
<caption>Table 7: Responding SOAP Node State Transitions</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">CurrentState</th>
|
|
<th rowspan="1" colspan="1"> </th>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">"Init"</td>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Start receiving request message</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Receiving"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Set
|
|
<code>http://www.w3.org/2003/05/soap/mep/ImmediateSender</code> to denote the sender of the request message (if determinable).
|
|
Start making an abstraction of the request message available in <code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code> .
|
|
Pass control of message exchange context to SOAP processor.</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="2" colspan="1">"Receiving"</td>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message reception failure</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Set
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code> to
|
|
"receptionFailure".</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Start of response message available in <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> </td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Receiving+Sending"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Initiate transmission of response message. If an envelope is provided in abstracted in <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> then include that in the response message.</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="2" colspan="1">"Receiving+Sending"</td>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message exchange failure</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Set <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code> to
|
|
"exchangeFailure".</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Completed receiving request message. Completed sending response message.</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Success"</td></tr>
|
|
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>Bindings that implement this MEP
|
|
MAY provide for streaming of SOAP responses.
|
|
That is, responding SOAP nodes MAY begin transmission
|
|
of a SOAP response while a SOAP request is still being
|
|
received and processed. When SOAP nodes implement
|
|
bindings that support streaming, the following
|
|
rules apply:</p>
|
|
|
|
<ul>
|
|
<li><p>All the rules in SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>
|
|
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#bindfw">Binding
|
|
Framework</a> regarding streaming of individual SOAP
|
|
messages MUST be obeyed for both request and response SOAP
|
|
messages.</p></li>
|
|
|
|
<li><p>When using streaming SOAP bindings, requesting SOAP nodes
|
|
MUST avoid deadlock by accepting and if necessary processing
|
|
SOAP response information while the SOAP request is being transmitted.</p>
|
|
|
|
<div class="note"><p class="prefix"><b>Note:</b></p><p>Depending on the implementation used and the size of
|
|
the messages involved, this rule MAY require that SOAP applications
|
|
stream application-level response processing in parallel with request
|
|
generation.</p></div>
|
|
</li>
|
|
|
|
<li><p>A requesting SOAP node MAY enter the "Fail" state,
|
|
and thus abort transmission of the outbound SOAP request,
|
|
based on information contained in an incoming streamed SOAP
|
|
response.</p></li>
|
|
|
|
</ul>
|
|
|
|
</div>
|
|
|
|
<div class="div3">
|
|
|
|
|
|
<h4><a name="bindfaulthdn"></a>6.2.4 Fault Handling</h4>
|
|
|
|
<p>During the operation of the Request-Response MEP, the
|
|
participating SOAP nodes may generate SOAP faults.</p>
|
|
|
|
<p>If a SOAP fault is generated by the responding SOAP node
|
|
while it is in the "Receiving" state, the SOAP
|
|
fault is made available in <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> and the
|
|
state machine transitions to the "Receiving+Sending" state.</p>
|
|
|
|
<p>This MEP makes no claims about the disposition or
|
|
handling of SOAP faults generated by the requesting SOAP node
|
|
during any processing of the response message that follows the
|
|
"Success" state in the requesting SOAP node's state transition
|
|
table (see <a href="#tabreqstatetrans"><b>Table 6</b></a>).</p>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
|
|
<div class="div2">
|
|
|
|
|
|
<h3><a name="soapresmep"></a>6.3 SOAP Response Message Exchange Pattern</h3>
|
|
|
|
<p>This section defines the message exchange pattern (MEP)
|
|
called "SOAP Response". The description is an abstract
|
|
presentation of the operation of this MEP. It is not intended to
|
|
describe a real implementation or to suggest how a real
|
|
implementation should be structured.</p>
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="mepname2"></a>6.3.1 SOAP Feature Name</h4>
|
|
<p>This message exchange pattern is identified by
|
|
the URI (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#procsoapmsgs">SOAP Features</a>):</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
"http://www.w3.org/2003/05/soap/mep/soap-response/"
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="bindinfdesc2"></a>6.3.2 Description</h4>
|
|
|
|
<p>The SOAP Response MEP defines a pattern for
|
|
the exchange of a non-SOAP message acting as a request
|
|
followed by a SOAP message acting as a response. In the
|
|
absence of failure in the underlying protocol, this MEP
|
|
consists of exactly two messages, only one of which is a
|
|
SOAP message:</p>
|
|
|
|
<ul>
|
|
<li>
|
|
<p>A request
|
|
transmitted in a binding-specific manner that does not include a SOAP envelope and hence does not
|
|
involve any SOAP processing by the receiving SOAP node.</p>
|
|
</li>
|
|
<li>
|
|
<p>A response message which contains a SOAP
|
|
envelope. The MEP is completed by the processing of the SOAP envelope
|
|
following the rules of the SOAP processing model (see
|
|
SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>, section
|
|
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#msgexchngmdl">SOAP Processing Model</a>).
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
<p>
|
|
Abnormal operation during a SOAP Response message exchange might be
|
|
caused by a failure to transfer the request message or the
|
|
response message. Such failures might be silent at either or both
|
|
of the requesting and responding SOAP nodes involved, or might
|
|
result in the generation of a SOAP or binding-specific fault (see
|
|
section <a href="#bindfaulthdn2"><b>6.3.4 Fault Handling</b></a>). Also, during abnormal
|
|
operation each SOAP node involved in the message exchange might
|
|
differ in its determination of the successful completion of the
|
|
message exchange.
|
|
</p>
|
|
|
|
<p>The scope of a SOAP Response MEP is limited to
|
|
the request for an exchange of a response message between
|
|
one requesting and one responding SOAP node. This pattern does
|
|
not mandate any correlation between multiple requests nor
|
|
specific timing for multiple requests. Implementations MAY choose
|
|
to support multiple ongoing requests (and associated response
|
|
processing) at the same time.</p>
|
|
<div class="note"><p class="prefix"><b>Note:</b></p>
|
|
<p>This MEP cannot be used in conjunction with features expressed as SOAP header blocks in the request because there is no SOAP envelope in which to carry them.</p>
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
<div class="div3">
|
|
|
|
<h4><a name="bindformdesc2"></a>6.3.3 State Machine Description</h4>
|
|
<p>The SOAP Response MEP defines a set of properties described in <a href="#tabreqresprops2"><b>Table 8</b></a>.</p>
|
|
<a name="tabreqresprops2"></a><table border="1">
|
|
<caption>Table 8: Property definitions for SOAP Response MEP</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">Property Name</th>
|
|
<th rowspan="1" colspan="1">Property Description</th>
|
|
<th rowspan="1" colspan="1">Property Type</th>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code>
|
|
</td>
|
|
<td rowspan="1" colspan="1">An abstract structure that represents the current
|
|
outbound message in the message exchange. This
|
|
abstracts both SOAP Envelope Infoset (which MAY be null) and any other
|
|
information structures that are transferred along
|
|
with the envelope.</td>
|
|
<td rowspan="1" colspan="1">Not specified</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code>
|
|
</td>
|
|
<td rowspan="1" colspan="1">An abstract structure that represents the current
|
|
inbound message in the message exchange. This
|
|
abstracts both SOAP Envelope Infoset (which MAY be null) and any other
|
|
information structures that are transferred along
|
|
with the envelope.
|
|
</td>
|
|
<td rowspan="1" colspan="1">Not specified</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code>
|
|
</td>
|
|
<td rowspan="1" colspan="1"><p>The identifier of the immediate destination of an
|
|
outbound message.</p></td>
|
|
<td rowspan="1" colspan="1">xs:anyURI</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<code>http://www.w3.org/2003/05/soap/mep/ImmediateSender</code>
|
|
</td>
|
|
<td rowspan="1" colspan="1"><p>The identifier of the immediate sender of an inbound
|
|
message.</p></td>
|
|
<td rowspan="1" colspan="1">xs:anyURI</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p>To initiate a message exchange conforming to the
|
|
SOAP Response MEP, the requesting SOAP node instantiates a
|
|
local message exchange context. <a href="#tabreqcon2"><b>Table 9</b></a> describes how
|
|
the context is initialized.</p>
|
|
|
|
<a name="tabreqcon2"></a><table border="1">
|
|
<caption>Table 9: Instantiation of a Message Exchange Context
|
|
for a requesting SOAP node</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b>
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>
|
|
"http://www.w3.org/2003/05/soap/mep/soap-response/"
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b>
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>
|
|
"None"
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Notes: </b>A relative URI that will be resolved against the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</code>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b>
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>
|
|
"RequestingSOAPNode"
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Notes: </b>A relative URI that will be resolved against the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</code>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b>
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>
|
|
"Init"
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Notes: </b>A relative URI whose base URI is the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/Role</code>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b>
|
|
<code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>An abstraction of the request
|
|
message that does not include a SOAP
|
|
envelope infoset.</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b>
|
|
<code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>An identifier (URI) that denotes
|
|
the responding SOAP node </td>
|
|
</tr>
|
|
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>There may be other properties related to the operation of
|
|
the message exchange context instance. Such properties are
|
|
initialized according to their own feature specifications.
|
|
</p>
|
|
<p>Once the message exchange context is initialized, control
|
|
of the context is passed to a (conforming) local binding
|
|
instance. </p>
|
|
<p>The diagram below shows the logical state transitions at
|
|
the requesting and responding SOAP nodes during the lifetime
|
|
of the message exchange. At each SOAP node, the local binding
|
|
instance updates (logically) the value of the
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</code> property to
|
|
reflect the current state of the message exchange. The state names
|
|
are relative URIs, relative to a Base URI value carried in
|
|
the <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</code> property of the local
|
|
message exchange context.</p>
|
|
<img src="StateTransitions2.png" alt="SOAP Response MEP State Transition Diagram.">
|
|
<p align="center">Figure 3: SOAP Response MEP State Transition Diagram</p>
|
|
|
|
<p>When the local binding instance at the responding SOAP
|
|
node starts to receive an inbound request message, it
|
|
(logically) instantiates a message exchange context. <a href="#tabrescon2"><b>Table 10</b></a>
|
|
describes the properties that the binding initializes as
|
|
part of the context's instantiation.</p>
|
|
|
|
<a name="tabrescon2"></a><table border="1">
|
|
<caption>Table 10: Instantiation of Message Exchange Context for
|
|
an inbound request message</caption>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b>
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>
|
|
"http://www.w3.org/2003/05/soap/mep/soap-response/"
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Notes: </b>
|
|
Initialized as early as possible during the life cycle of the message exchange. </td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b>
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>
|
|
"None"
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Notes: </b>A relative URI that will be resolved against the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</code>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b>
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>
|
|
"RespondingSOAPNode"
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Notes: </b>
|
|
A relative URI that will be resolved against the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> .
|
|
Initialized as early as possible during the life cycle the message exchange.
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Property name: </b>
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</code>
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Value: </b>
|
|
"Init"
|
|
</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<b>Notes: </b>A relative URI that will be resolved against the value of the property named <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/Role</code>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p>When the requesting and responding SOAP nodes transition between
|
|
states, the local binding instance (logically) updates a number of
|
|
properties. <a href="#tabreqstatetrans2"><b>Table 11</b></a> and <a href="#tabresstatetrans2"><b>Table 12</b></a> describe these updates for the requesting
|
|
and the responding SOAP nodes, respectively.</p>
|
|
<a name="tabreqstatetrans2"></a><table border="1">
|
|
<caption>Table 11: Requesting SOAP Node State Transitions</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">CurrentState</th>
|
|
<th rowspan="1" colspan="1"> </th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="1" colspan="1">"Init"</td>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Unconditional</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Requesting"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Initiate request</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="2" colspan="1">"Requesting"</td>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message transmission failure</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Set
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code> to
|
|
"transmissionFailure"</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Start receiving response message</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Receiving"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Set
|
|
<code>http://www.w3.org/2003/05/soap/mep/ImmediateSender</code> to denote the sender of the response message
|
|
(may differ from the values in <code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code> ).
|
|
Start making an abstraction of the response message available in
|
|
<code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code> .</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="2" colspan="1">"Receiving"</td>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message exchange failure</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Set
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code> to
|
|
"exchangeFailure"</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Completed receiving response message.</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Success"</td></tr>
|
|
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
<p> </p>
|
|
|
|
<a name="tabresstatetrans2"></a><table border="1">
|
|
<caption>Table 12: Responding SOAP Node State Transitions</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">CurrentState</th>
|
|
<th rowspan="1" colspan="1"> </th>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="1" colspan="1">"Init"</td>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Start receiving request</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Receiving"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Set <code>http://www.w3.org/2003/05/soap/mep/ImmediateSender</code>
|
|
to denote the sender of the request message (if determinable). Pass control of message exchange context to SOAP processor.</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="2" colspan="1">"Receiving"</td>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message reception failure</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Set
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code> to
|
|
"receptionFailure".</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Start of response message available in
|
|
<code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> </td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Sending"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Initiate transmission of response message abstracted in
|
|
<code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> .</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="2" colspan="1">"Sending"</td>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Message exchange failure</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Fail"</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>Action: </b>Set <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/FailureReason</code> to
|
|
"exchangeFailure".</td></tr>
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<table>
|
|
<tbody>
|
|
<tr><td rowspan="1" colspan="1"><b>Transition Condition: </b>Completed sending response message.</td></tr>
|
|
<tr><td rowspan="1" colspan="1"><b>NextState: </b>"Success"</td></tr>
|
|
|
|
</tbody>
|
|
</table>
|
|
</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="bindfaulthdn2"></a>6.3.4 Fault Handling</h4>
|
|
<p>During the operation of the SOAP Response MEP, the
|
|
participating SOAP nodes may generate SOAP faults.</p>
|
|
|
|
<p>If a SOAP fault is generated
|
|
by the responding SOAP node while it is in the
|
|
"Receiving" state, the SOAP fault is
|
|
made available in
|
|
<code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code>
|
|
and the state machine transitions to the
|
|
"Sending" state.</p>
|
|
|
|
<p>This MEP makes no claims about the disposition or
|
|
handling of SOAP faults generated by the requesting SOAP node
|
|
during any processing of the response message that follows the
|
|
"Success" state in the requesting SOAP node's state transition
|
|
table (see <a href="#tabreqstatetrans2"><b>Table 11</b></a>).</p>
|
|
|
|
</div>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="WebMethodFeature"></a>6.4 SOAP Web Method Feature</h3>
|
|
<p>This section defines the "SOAP Web Method Feature".</p>
|
|
<div class="div3">
|
|
|
|
<h4><a name="WebMethodFeatureName"></a>6.4.1 SOAP Feature Name</h4>
|
|
<p>The SOAP Web Method feature is identified by the URI (see
|
|
SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#procsoapmsgs">SOAP Features</a>):</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
"http://www.w3.org/2003/05/soap/features/web-method/"
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="WebMethodFeatureDesc"></a>6.4.2 Description</h4>
|
|
|
|
|
|
<p>
|
|
Underlying protocols designed for use on the World
|
|
Wide Web provide for manipulation of resources using a small set of Web methods
|
|
such as GET, PUT, POST, and DELETE.
|
|
These methods are formally defined in the HTTP specification <a href="#RFC2616">[RFC 2616]</a>, but other underlying protocols might also support them.
|
|
Bindings to HTTP or such other protocols SHOULD use the
|
|
SOAP Web Method feature to give applications control over the Web methods to be used when sending a SOAP message.</p>
|
|
|
|
<p>Bindings supporting this feature SHOULD use the appropriate embodiment of that method if provided by the underlying protocol; for example, the HTTP binding
|
|
provided with this specification represents the "GET" Web method as an HTTP GET request, and the "POST" method
|
|
as an HTTP POST request (see <a href="#soapinhttp"><b>7. SOAP HTTP Binding</b></a>). Bindings supporting this feature SHOULD provide to the receiving node indication of the Web method used for transmission.</p>
|
|
|
|
<p>The SOAP Web Method feature MAY be implemented by bindings to underlying
|
|
transports that have no preferred embodiment of particular Web methods (e.g. do not distinguish GET from POST). Such bindings SHOULD provide to the receiving node indication of the Web method used for transmission, but need take no other action in support of the feature. </p>
|
|
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="webmethodstatemachine"></a>6.4.3 SOAP Web Method Feature State Machine </h4>
|
|
<p>The SOAP Web Method feature defines a single property, which is described in <a href="#tabwebmethprops"><b>Table 13</b></a>.</p>
|
|
<a name="tabwebmethprops"></a><table border="1">
|
|
<caption>Table 13: Property definition for the SOAP Web Method feature</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">Property Name</th>
|
|
<th rowspan="1" colspan="1">Property Description</th>
|
|
<th rowspan="1" colspan="1">Property Type</th>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<code>http://www.w3.org/2003/05/soap/features/web-method/Method</code>
|
|
</td>
|
|
<td rowspan="1" colspan="1">One of "GET", "POST",
|
|
"PUT", "DELETE" (or others which may subsequently be added to the repertoire
|
|
of Web methods.)</td>
|
|
<td rowspan="1" colspan="1">Not specified</td>
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
|
</table>
|
|
<p>This specification provides for the use of the SOAP Web Method feature in conjunction with the
|
|
<a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> and <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a> message exchange patterns. This
|
|
feature MAY be used with other MEPs if and only if provided for in the specifications of those MEPs.</p>
|
|
<p>
|
|
A node sending a request message MUST provide a value for the
|
|
<code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> property.
|
|
A protocol binding supporting this feature SHOULD set the value of the
|
|
<code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> property at the receiving node to match that provided by the sender;
|
|
the means of
|
|
transmission for the method property is binding-specific.</p>
|
|
|
|
<p>A responding node SHOULD respond in a manner consistent with the Web method requested (e.g. a
|
|
"GET" should
|
|
result in retrieval of a representation of the identified resource) or SHOULD fault in an
|
|
application-specific manner if the Web method cannot be supported. </p>
|
|
|
|
<p>Bindings implementing this feature
|
|
MUST employ a Message Exchange Pattern with semantics that are
|
|
compatible with the Web method selected. For example, the SOAP
|
|
Response Message Exchange Pattern (see <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>) is compatible with GET.</p>
|
|
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="ActionFeature"></a>6.5 SOAP Action Feature</h3>
|
|
<p>This section defines the "SOAP Action Feature".</p>
|
|
<div class="div3">
|
|
|
|
<h4><a name="ActionFeatureName"></a>6.5.1 SOAP Feature Name</h4>
|
|
<p>The SOAP Action feature is identified by the URI
|
|
(see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#procsoapmsgs">SOAP Features</a>):</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
"http://www.w3.org/2003/05/soap/features/action/"
|
|
</p>
|
|
</li>
|
|
</ul>
|
|
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="ActionFeatureDesc"></a>6.5.2 Description</h4>
|
|
|
|
|
|
<p>
|
|
Many SOAP 1.2 underlying protocol bindings will likely
|
|
utilize the "application/soap+xml" media type (described in
|
|
<a href="#ietf-draft"><b>A. The application/soap+xml Media Type</b></a>) to transmit XML serializations of SOAP messages.
|
|
The media type specifies an optional <code>action</code> parameter, which can be used to optimize dispatch or routing,
|
|
among other things. The Action Feature specifies well-known
|
|
URIs to indicate support for the <code>action</code> parameter in
|
|
bindings which use MIME, and also to refer to value of the
|
|
parameter itself.
|
|
</p>
|
|
|
|
</div>
|
|
<div class="div3">
|
|
|
|
<h4><a name="actionstatemachine"></a>6.5.3 SOAP Action Feature State Machine </h4>
|
|
<p>The SOAP Action feature defines a single property, which is described in <a href="#tabactionprops"><b>Table 14</b></a>. The value of this property MUST be an absolute URI<a href="#RFC3986">[RFC 3986]</a> and MUST NOT be empty.</p>
|
|
<a name="tabactionprops"></a><table border="1">
|
|
<caption>Table 14: Property definition for the SOAP Action feature</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">Property Name</th>
|
|
<th rowspan="1" colspan="1">Property Type</th>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">
|
|
<p><code>http://www.w3.org/2003/05/soap/features/action/Action</code> </p>
|
|
</td>
|
|
<td rowspan="1" colspan="1"><p><code>xsd:anyURI</code> </p></td>
|
|
</tr>
|
|
|
|
|
|
</tbody>
|
|
</table>
|
|
<p>If the <code>http://www.w3.org/2003/05/soap/features/action/Action</code>
|
|
property has a value at a SOAP sender utilizing a
|
|
binding supporting this feature, the sender MUST use the
|
|
property value as the value of the <code>action</code> parameter in
|
|
the media type designator.</p>
|
|
|
|
<p>Conversely, if a value arrives in the <code>action</code> parameter of
|
|
the media type designator at a SOAP receiver, the receiver MUST
|
|
make that value available as the value of the <code>http://www.w3.org/2003/05/soap/features/action/Action</code>
|
|
property.</p>
|
|
|
|
</div>
|
|
</div>
|
|
|
|
|
|
</div>
|
|
|
|
<div class="div1">
|
|
<h2><a name="soapinhttp"></a>7. SOAP HTTP Binding</h2>
|
|
|
|
<div class="div2">
|
|
<h3><a name="http-intro"></a>7.1 Introduction</h3>
|
|
|
|
<p>The SOAP HTTP Binding provides a binding of SOAP to HTTP. The
|
|
binding conforms to the SOAP Protocol Binding Framework (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew">SOAP Protocol Binding
|
|
Framework</a>) and supports the message
|
|
exchange patterns and features described in <a href="#soapsupmep"><b>6. SOAP-Supplied Message Exchange Patterns and Features</b></a>.</p>
|
|
|
|
<div class="div3">
|
|
|
|
|
|
<h4><a name="httpoptionality"></a>7.1.1 Optionality</h4>
|
|
|
|
<p>The SOAP HTTP Binding is optional and SOAP nodes are NOT
|
|
required to implement it. A SOAP node that correctly and
|
|
completely implements the SOAP HTTP Binding may to be said
|
|
to "conform to the SOAP 1.2 HTTP Binding."</p>
|
|
|
|
<p>The SOAP version 1.2 specification does not preclude
|
|
development of other bindings to HTTP or bindings to other
|
|
protocols, but communication with nodes using such other
|
|
bindings is not a goal. Note that other bindings of SOAP
|
|
to HTTP MAY be written to provide support for SOAP Message
|
|
exchange patterns other than <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> or the <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>. Such alternate bindings MAY therefore
|
|
make use of HTTP features and status codes not required
|
|
for this binding. </p>
|
|
|
|
</div>
|
|
|
|
|
|
<div class="div3">
|
|
<h4><a name="httpuse"></a>7.1.2 Use of HTTP</h4>
|
|
|
|
<p>The SOAP HTTP binding defines a base URI according
|
|
to the rules in HTTP/1.1 <a href="#RFC2616">[RFC 2616]</a>. I.e., the base URI
|
|
is the HTTP Request-URI or the value of the HTTP
|
|
Content-Location header field.</p>
|
|
|
|
<p>This binding of SOAP to HTTP is intended to make
|
|
appropriate use of HTTP as an application protocol. For
|
|
example, successful responses are sent with status code
|
|
200 or 202, and failures are indicated as 4XX or 5XX. This
|
|
binding is not intended to fully exploit the features of
|
|
HTTP, but rather to use HTTP specifically for the purpose
|
|
of communicating with other SOAP nodes implementing the
|
|
same binding. Therefore, this HTTP binding for SOAP does
|
|
not specify the use and/or meaning of all possible HTTP
|
|
methods, header fields and status responses. It specifies
|
|
only those which are pertinent to the <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> or the <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>, or which are likely to be introduced
|
|
by HTTP mechanisms (such as proxies) acting between the
|
|
SOAP nodes.</p>
|
|
|
|
<p>Certain
|
|
optional features provided by this binding depend on capabilities provided by
|
|
HTTP/1.1, for example content
|
|
negotiation. Implementations SHOULD thus use HTTP/1.1
|
|
<a href="#RFC2616">[RFC 2616]</a> (or later compatible versions that share the
|
|
same major version number). Implementations MAY also be
|
|
deployed using HTTP/1.0, although in this case certain optional binding features
|
|
may not be provided.</p>
|
|
|
|
<div class="note"><p class="prefix"><b>Note:</b></p><p>SOAP HTTP Binding implementations need to account for the
|
|
fact that HTTP/1.0 intermediaries (which may or may
|
|
not also be SOAP intermediaries) may alter the representation of
|
|
SOAP messages, even in situations where both the initial SOAP sender and
|
|
ultimate SOAP receiver use HTTP/1.1.</p></div>
|
|
|
|
|
|
</div>
|
|
|
|
|
|
<div class="div3">
|
|
<h4><a name="httpinterop"></a>7.1.3 Interoperability with non-SOAP HTTP Implementations</h4>
|
|
<p>
|
|
Particularly when used with the <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>, the HTTP messages
|
|
produced by this binding are likely to be
|
|
indistinguishable from those produced by non-SOAP implementations
|
|
performing similar operations.
|
|
Accordingly, some degree of interoperation can be made possible between SOAP nodes and other HTTP
|
|
implementations when using this binding.
|
|
For example, a conventional Web server (i.e., one not
|
|
written specifically to conform to this specification) might be used to respond
|
|
to SOAP-initiated HTTP GET's with representations of
|
|
<code>Content-Type</code> "application/soap+xml".
|
|
Such interoperation is not a normative feature of this specification.
|
|
</p>
|
|
|
|
<p>Even though HTTP often is used on the
|
|
well-known TCP port 80, the use of HTTP is not limited to
|
|
that port. As a result, it is possible to have a dedicated
|
|
HTTP server for handling SOAP processing on a distinct TCP
|
|
port. Alternatively, it is possible to use a separate
|
|
virtual host for dealing with SOAP processing. Such
|
|
configuration, however, is a matter of convenience and is
|
|
not a requirement of this specification (see SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#secbindappspecprot">Binding to
|
|
Application-Specific Protocols</a>).</p>
|
|
</div>
|
|
|
|
|
|
<div class="div3">
|
|
<h4><a name="httpmediatype"></a>7.1.4 HTTP Media-Type</h4>
|
|
<p>Conforming implementations of this binding:</p>
|
|
|
|
<ol>
|
|
|
|
<li><p>MUST be capable of sending and receiving messages
|
|
serialized using media type "application/soap+xml" whose proper
|
|
use and parameters are described in <a href="#ietf-draft"><b>A. The application/soap+xml Media Type</b></a>.</p></li>
|
|
|
|
<li><p>MAY send requests and responses using other media types
|
|
providing that such media types provide for at least the
|
|
transfer of SOAP XML Infoset.</p></li>
|
|
|
|
<li><p>MAY, when sending requests, provide an HTTP Accept
|
|
header field. This header field:</p>
|
|
|
|
<ul>
|
|
|
|
<li><p>SHOULD indicate an ability to accept at minimum
|
|
"application/soap+xml".</p></li>
|
|
|
|
<li><p>MAY additionally indicate willingness to accept
|
|
other media types that satisfy 2 above.</p></li>
|
|
|
|
</ul>
|
|
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="http-bindname"></a>7.2 Binding Name</h3>
|
|
|
|
<p>This binding is identified by the URI (see
|
|
SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#transpbindframew">SOAP Protocol Binding
|
|
Framework</a>):</p>
|
|
|
|
<ul>
|
|
|
|
<li><p>"http://www.w3.org/2003/05/soap/bindings/HTTP/"</p>
|
|
</li>
|
|
|
|
</ul>
|
|
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="http-suptransmep"></a>7.3 Supported Message Exchange Patterns</h3>
|
|
|
|
<p>An implementation of the SOAP HTTP Binding
|
|
MUST support the following message exchange
|
|
patterns (MEPs):</p>
|
|
|
|
<ul>
|
|
<li><p>
|
|
"http://www.w3.org/2003/05/soap/mep/request-response/"
|
|
(see <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a>) </p></li>
|
|
<li>
|
|
<p>
|
|
"http://www.w3.org/2003/05/soap/mep/soap-response/"
|
|
(see <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>) </p>
|
|
</li>
|
|
</ul>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="http-suptfeatures"></a>7.4 Supported Features</h3>
|
|
<p>An implementation of the SOAP HTTP Binding
|
|
MUST support the following additional features:</p>
|
|
<ul>
|
|
<li>
|
|
<p>
|
|
"http://www.w3.org/2003/05/soap/features/web-method/"
|
|
(see <a href="#WebMethodFeature"><b>6.4 SOAP Web Method Feature</b></a>) </p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>
|
|
"http://www.w3.org/2003/05/soap/features/action/"
|
|
(see <a href="#ActionFeature"><b>6.5 SOAP Action Feature</b></a>) </p>
|
|
</li>
|
|
</ul>
|
|
|
|
<p>The possible values of
|
|
<code>http://www.w3.org/2003/05/soap/features/web-method/Method</code>
|
|
property are restricted in this HTTP binding according to the MEP
|
|
in use (as present in
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> ):</p>
|
|
|
|
<a name="tabwebmethodvalues"></a><table border="1">
|
|
<caption>Table 15: Possible values of the Web-Method Method property</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="1" colspan="1"><code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</code> </th>
|
|
<th rowspan="1" colspan="1"><code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> </th>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">"http://www.w3.org/2003/05/soap/mep/request-response/"</td>
|
|
<td rowspan="1" colspan="1">"POST"</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">"http://www.w3.org/2003/05/soap/mep/soap-response/"</td>
|
|
<td rowspan="1" colspan="1">"GET"</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<div class="note"><p class="prefix"><b>Note:</b></p><p>Other SOAP Version 1.2 bindings to HTTP may permit
|
|
other combinations of
|
|
<code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/ExchangePatternName</code>
|
|
and
|
|
<code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> .</p></div>
|
|
|
|
|
|
</div>
|
|
|
|
<div class="div2">
|
|
<h3><a name="http-msgexop"></a>7.5 MEP Operation</h3>
|
|
|
|
<p>For binding instances conforming to this specification:</p>
|
|
|
|
<ul>
|
|
|
|
<li><p>A SOAP node instantiated at an HTTP client may assume the role (i.e., the
|
|
property <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/Role</code> ) of
|
|
"RequestingSOAPNode".</p></li>
|
|
|
|
<li><p>A SOAP node instantiated at an HTTP server may assume the role (i.e.,
|
|
the property <code>http://www.w3.org/2002/12/soap/bindingFramework/ExchangeContext/Role</code> ) of
|
|
"RespondingSOAPNode". </p></li>
|
|
|
|
</ul>
|
|
|
|
<p>The remainder of this section describes the MEP state machine
|
|
and its relation to the HTTP protocol. In the state tables below,
|
|
the states are defined as values of the property <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/State</code>
|
|
(see <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> and <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>), and are of type <code>xs:anyURI</code> .
|
|
For brevity, relative URIs are used, the base URI being the value of <code>http://www.w3.org/2003/05/soap/bindingFramework/ExchangeContext/Role</code> .</p>
|
|
|
|
<p>The message exchange pattern in use is indicated by the HTTP method
|
|
used in the request. HTTP GET corresponds to the SOAP-Response MEP,
|
|
HTTP POST corresponds to the SOAP Request-Response MEP.</p>
|
|
|
|
<div class="div3">
|
|
|
|
|
|
<h4><a name="http-reqsoapnode"></a>7.5.1 Behavior of Requesting SOAP Node</h4>
|
|
|
|
<p>The overall flow of the behavior of a requesting SOAP node
|
|
follows a state machine description consistent with either <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> or <a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a>
|
|
(differences are indicated as necessary.) This binding supports
|
|
streaming and, as a result, requesting SOAP nodes MUST avoid
|
|
deadlock by accepting and if necessary processing SOAP response
|
|
information while the SOAP request is being transmitted (see
|
|
<a href="#bindformdesc"><b>6.2.3 State Machine Description</b></a>). The following subsections describe
|
|
each state in detail.</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="http-reqbindreqstate"></a>7.5.1.1 Init</h5>
|
|
|
|
<p>In the "Init" state, a HTTP request is formulated according to <a href="#tabreqstateinitfields"><b>Table 16</b></a> and transmission of the request is initiated.</p>
|
|
|
|
|
|
<a name="tabreqstateinitfields"></a><table border="1">
|
|
<caption>Table 16: HTTP Request Fields</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">Field</th>
|
|
<th rowspan="1" colspan="1">Value</th></tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">HTTP Method</td>
|
|
<td rowspan="1" colspan="1">According to the <code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> property. POST and GET are the only values supported by this binding.</td></tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">Request URI</td>
|
|
<td rowspan="1" colspan="1">The value of the URI carried in the
|
|
<code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code> property of the
|
|
message exchange context.</td></tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><p>Content-Type header field</p></td>
|
|
<td rowspan="1" colspan="1">The media type of the request entity body, if present; otherwise,
|
|
omitted (see <a href="#http-intro"><b>7.1 Introduction</b></a> for a description of permissible media types).
|
|
If the SOAP envelope infoset in the <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> property is null,
|
|
then the <code>Content-Type</code> header field MAY be omitted.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><p>action parameter</p></td>
|
|
<td rowspan="1" colspan="1"><p>According to the value of the <code>http://www.w3.org/2003/05/soap/features/action/Action</code> property.</p></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><p>Accept header field (optional)</p></td>
|
|
<td rowspan="1" colspan="1">List of media types that are acceptable in
|
|
response to the request message.</td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><p>Additional header fields</p></td>
|
|
<td rowspan="1" colspan="1"><p>Generated in accordance with the rules for the binding-specific expression of any optional features in use for this
|
|
message exchange. For example, a Content-Encoding header field
|
|
(see HTTP <a href="#RFC2616">[RFC 2616]</a>, section 14.11) may be used to
|
|
express an optional compression feature.</p></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">HTTP entity body</td>
|
|
<td rowspan="1" colspan="1"><p>SOAP message serialized according to the rules for
|
|
carrying SOAP messages in the media type given by the
|
|
Content-Type header field. Rules for carrying SOAP messages in
|
|
media type "application/soap+xml" are given
|
|
in <a href="#ietf-draft"><b>A. The application/soap+xml Media Type</b></a>. If the SOAP envelope infoset in the
|
|
<code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> property is null,
|
|
the entity body is omitted</p></td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
</div>
|
|
|
|
<div class="div4">
|
|
|
|
|
|
<h5><a name="http-reqbindwaitstate"></a>7.5.1.2 Requesting</h5>
|
|
|
|
<p>In the "Requesting" state, sending
|
|
of the request continues while waiting for the start of the
|
|
response message. <a href="#tabreqstatereqtrans"><b>Table 17</b></a> details
|
|
the transitions that take place when a requesting SOAP node
|
|
receives an HTTP status line and response header fields. For
|
|
some status codes there is a choice of possible next state. In
|
|
cases where "Fail" is one of the choices, the
|
|
transition is dependent on whether a SOAP message is present in
|
|
the HTTP response. If a SOAP message is present, the next state
|
|
is "Sending+Receiving" or
|
|
"Receiving", otherwise the next state is
|
|
"Fail". The choice between
|
|
"Sending+Receiving" and
|
|
"Receiving" depends of the MEP in use:
|
|
"Sending+Receiving" is the next state for Request-Response while
|
|
"Receiving" is the next state for SOAP-Response.</p>
|
|
|
|
<a name="tabreqstatereqtrans"></a><table border="1">
|
|
<caption>Table 17: HTTP status code dependent transitions</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th valign="top" rowspan="1" colspan="1">Status Code</th>
|
|
<th valign="top" rowspan="1" colspan="1">Reason phrase</th>
|
|
<th valign="top" rowspan="1" colspan="1">Significance/Action</th>
|
|
<th valign="top" rowspan="1" colspan="1">NextState</th></tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">2xx</td>
|
|
<td valign="top" rowspan="1" colspan="1">Successful</td>
|
|
<td valign="top" rowspan="1" colspan="1"> </td>
|
|
<td valign="top" rowspan="1" colspan="1"> </td></tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">200</td>
|
|
<td valign="top" rowspan="1" colspan="1">OK</td>
|
|
<td valign="top" rowspan="1" colspan="1">
|
|
<p>The response message follows in the HTTP response entity body.
|
|
Start making an abstraction of the response message available in
|
|
<code>http://www.w3.org/2003/05/soap/mep/InboundMessage</code> .</p></td>
|
|
<td valign="top" rowspan="1" colspan="1">"Sending+Receiving" or "Receiving"</td></tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">202</td>
|
|
<td valign="top" rowspan="1" colspan="1">OK</td>
|
|
<td valign="top" rowspan="1" colspan="1">
|
|
<p> The request has been accepted, but either (a) no response envelope
|
|
is provided or (b) an envelope representing information related to
|
|
the request is provided -- such envelopes SHOULD be processed using
|
|
the SOAP Processing model (see
|
|
SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>, section
|
|
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#msgexchngmdl">SOAP Processing Model</a>).</p></td>
|
|
<td valign="top" rowspan="1" colspan="1">"Receiving" (which will immediately transition to
|
|
"Success")</td></tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">301, 302, 307</td>
|
|
<td valign="top" rowspan="1" colspan="1">Redirect</td>
|
|
<td valign="top" rowspan="1" colspan="1"><p>The requested resource has
|
|
moved. In the case of unsafe HTTP method, like POST or PUT, explicit confirmation
|
|
is required before proceeding as follow. </p>
|
|
<p>In the case of a safe method, like GET, or if the redirection has been approved,
|
|
the HTTP request SHOULD be retried using the URI carried in the
|
|
associated Location header field as the new value for the
|
|
<code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code> property.</p></td>
|
|
<td valign="top" rowspan="1" colspan="1">"Init" or "Fail"</td></tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">303</td>
|
|
<td valign="top" rowspan="1" colspan="1">See Other</td>
|
|
<td valign="top" rowspan="1" colspan="1"><p>The requested resource has moved and the HTTP request SHOULD be
|
|
retried using the URI carried in the associated Location header field as the new
|
|
value for the <code>http://www.w3.org/2003/05/soap/mep/ImmediateDestination</code>
|
|
property. The value of
|
|
<code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> is changed to
|
|
""GET"", the value of <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> is
|
|
set to "null". [Note: Status code 303 MUST NOT be sent unless the request
|
|
SOAP envelope has been processed according to the SOAP processing model
|
|
and the SOAP response is to be made available by retrieval from the URI
|
|
provided with the 303.]</p></td>
|
|
<td valign="top" rowspan="1" colspan="1">"Init"</td></tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">4xx</td>
|
|
<td valign="top" rowspan="1" colspan="1">Client Error</td>
|
|
<td valign="top" rowspan="1" colspan="1"> </td>
|
|
<td valign="top" rowspan="1" colspan="1"> </td></tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">400</td>
|
|
<td valign="top" rowspan="1" colspan="1">Bad Request</td>
|
|
<td valign="top" rowspan="1" colspan="1">
|
|
<p>Indicates a problem with the received HTTP request message.</p></td>
|
|
<td valign="top" rowspan="1" colspan="1"><p>"Sending+Receiving", "Receiving" or "Fail"</p></td></tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">401</td>
|
|
<td valign="top" rowspan="1" colspan="1">Unauthorized</td>
|
|
<td valign="top" rowspan="1" colspan="1"><p>Indicates that the HTTP
|
|
request requires authorization.</p>
|
|
<p>The message exchange is
|
|
regarded as having completed unsuccessfully.</p>
|
|
</td>
|
|
<td valign="top" rowspan="1" colspan="1">
|
|
"Requesting" or "Fail"</td></tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">405</td>
|
|
<td valign="top" rowspan="1" colspan="1">Method not allowed</td>
|
|
<td valign="top" rowspan="1" colspan="1">
|
|
<p>Indicates that the peer HTTP server does not support the requested HTTP
|
|
method at the given request URI. The message exchange is
|
|
regarded as having completed unsuccessfully.</p></td>
|
|
<td valign="top" rowspan="1" colspan="1">"Fail"</td></tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">415</td>
|
|
<td valign="top" rowspan="1" colspan="1">Unsupported Media Type</td>
|
|
<td valign="top" rowspan="1" colspan="1">
|
|
<p>Indicates that the peer HTTP server does not support the Content-type used
|
|
to encode the request message. The message exchange is regarded
|
|
as having completed unsuccessfully.</p></td>
|
|
<td valign="top" rowspan="1" colspan="1">
|
|
"Fail"</td></tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">5xx</td>
|
|
<td valign="top" rowspan="1" colspan="1">Server Error</td>
|
|
<td valign="top" rowspan="1" colspan="1"> </td>
|
|
<td valign="top" rowspan="1" colspan="1"> </td></tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">500</td>
|
|
<td valign="top" rowspan="1" colspan="1">Internal Server Error</td>
|
|
<td valign="top" rowspan="1" colspan="1">
|
|
<p>Indicates a server problem or a problem with the received request</p></td>
|
|
<td valign="top" rowspan="1" colspan="1">
|
|
<p>"Sending+Receiving", "Receiving" or "Fail"</p></td></tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
<p><a href="#tabreqstatereqtrans"><b>Table 17</b></a> refers to
|
|
some but not all of the existing HTTP/1.1 <a href="#RFC2616">[RFC 2616]</a> status codes. In addition to these status codes,
|
|
HTTP provides an open-ended mechanism for supporting status
|
|
codes defined by HTTP extensions (see RFC 2817 <a href="#RFC2817">[RFC 2817]</a>
|
|
for a registration mechanism for new status codes). HTTP status
|
|
codes are divided into status code classes as described in
|
|
HTTP <a href="#RFC2616">[RFC 2616]</a>, section 6.1.1. The SOAP HTTP binding
|
|
follows the rules of any HTTP application which means that an
|
|
implementation of the SOAP HTTP binding must understand the
|
|
class of any status code, as indicated by the first digit, and
|
|
treat any unrecognized response as being equivalent to the x00
|
|
status code of that class, with the exception that an
|
|
unrecognized response must not be cached.</p>
|
|
|
|
<div class="note"><p class="prefix"><b>Note:</b></p><p>There may be elements in the HTTP infrastructure
|
|
configured to modify HTTP response entity bodies for
|
|
4xx and 5xx status code responses. For example, some
|
|
HTTP origin servers have such a feature as
|
|
a configuration option. This behavior may interfere with
|
|
the use of 4xx and 5xx status code responses carrying SOAP
|
|
fault messages in HTTP and it is recommended that such behavior
|
|
be disabled for resources accepting SOAP/HTTP requests.
|
|
If the rewriting behavior cannot be disabled, SOAP/HTTP
|
|
cannot be used in such configurations.</p></div>
|
|
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="http-reqbindrecstate"></a>7.5.1.3 Sending+Receiving</h5>
|
|
|
|
<p>In the "Sending+Receiving" state
|
|
(<a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> only), the transmission of the
|
|
request message and receiving of the response message is completed.
|
|
Only in the case that a status code 200 is received,
|
|
the response message is assumed to contain a SOAP envelope serialized
|
|
according to the rules for carrying SOAP messages in the media type
|
|
given in the Content-Type header field.</p>
|
|
|
|
<p>The response MAY be of content type other than
|
|
"application/soap+xml". Such usage is considered
|
|
non-normative, and accordingly is not modeled in the state machine.
|
|
Interpretation of such responses is at the discretion of the
|
|
receiver.
|
|
Similarly, receipt of any response entity-body with a status code of 202
|
|
is not normative. If such an unexpected response is of type
|
|
"application/soap+xml", then SOAP processing of that
|
|
response is beyond the scope of the specification for this binding.</p>
|
|
|
|
</div>
|
|
|
|
<div class="div4">
|
|
|
|
|
|
<h5><a name="http-reqbindrecstate2"></a>7.5.1.4 Receiving</h5>
|
|
|
|
<p>In the "Receiving" state (<a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a> only), receiving of the response message is
|
|
completed. Only in the case of status code 200,
|
|
the response message is assumed to contain a SOAP
|
|
envelope serialized according to the rules for carrying SOAP
|
|
messages in the media type given in the Content-Type header
|
|
field.</p>
|
|
|
|
<p>The response MAY be of content type other than
|
|
"application/soap+xml". Such a result is particularly
|
|
likely when a SOAP request sent with a <code>http://www.w3.org/2003/05/soap/features/web-method/Method</code> of
|
|
"GET" is directed (intentionally or otherwise) to a
|
|
non-SOAP HTTP server. Such usage is considered non-normative, and
|
|
accordingly is not modeled in the state machine. Interpretation of
|
|
such responses is at the discretion of the receiver.
|
|
Similarly, receipt of any response entity-body with a status code of 202
|
|
is not normative. If such an unexpected response is of type
|
|
"application/soap+xml", then SOAP processing of that
|
|
response is beyond the scope of the specification for this binding.</p>
|
|
|
|
</div>
|
|
|
|
|
|
<div class="div4">
|
|
<h5><a name="http-reqsuccfail"></a>7.5.1.5 Success and Fail</h5>
|
|
|
|
<p>"Success" and "Fail" are the terminal states of the
|
|
Request-Response and SOAP-Response MEPs. Control over the
|
|
message exchange context returns to the local SOAP node.</p>
|
|
|
|
<p>If the "success" state has been reached and if a SOAP envelope has been
|
|
received, then the local node is a SOAP Receiver as defined in SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a> section
|
|
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#senderreceiverconcepts">Message Sender and Receiver Concepts</a>, and in particular MUST obey the
|
|
requirement of section
|
|
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#soapnodes">SOAP Nodes</a> to
|
|
process the message according to the SOAP Processing Model (see <a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#msgexchngmdl">SOAP Processing Model</a>).</p>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
<div class="div3">
|
|
<h4><a name="http-bindrespnode"></a>7.5.2 Behavior of Responding SOAP Node</h4>
|
|
|
|
<p>The overall flow of the behavior of a responding SOAP node
|
|
follows a state machine description consistent with either <a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> or
|
|
<a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a> (differences are indicated as necessary). The following subsections describe each state
|
|
in detail.</p>
|
|
|
|
<div class="div4">
|
|
<h5><a name="http-respbindreceive"></a>7.5.2.1 Init</h5>
|
|
|
|
<p>In the "Init" state, the binding waits for
|
|
the start of an inbound request message. <a href="#tabresstateinitfaults"><b>Table 18</b></a> describes the errors that a responding
|
|
SOAP node might generate while in the "Init" state. In
|
|
this state no SOAP message has been received, therefore the SOAP node
|
|
cannot generate a SOAP fault.</p>
|
|
|
|
<a name="tabresstateinitfaults"></a><table border="1">
|
|
<caption>Table 18: Errors generated in the Init state</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th valign="top" rowspan="1" colspan="1">Problem with Message</th>
|
|
<th valign="top" rowspan="1" colspan="1">HTTP Status Code</th>
|
|
<th valign="top" rowspan="1" colspan="1">HTTP Reason Phrase
|
|
(informative)</th>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">Malformed Request Message</td>
|
|
<td valign="top" rowspan="1" colspan="1">400</td>
|
|
<td valign="top" rowspan="1" colspan="1">Bad request</td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">HTTP Method is neither POST nor GET</td>
|
|
<td valign="top" rowspan="1" colspan="1">405</td>
|
|
<td valign="top" rowspan="1" colspan="1">Method Not Allowed</td>
|
|
</tr>
|
|
<tr>
|
|
<td valign="top" rowspan="1" colspan="1">Unsupported message encapsulation method</td>
|
|
<td valign="top" rowspan="1" colspan="1">415</td>
|
|
<td valign="top" rowspan="1" colspan="1">Unsupported Media</td>
|
|
</tr>
|
|
</tbody>
|
|
</table>
|
|
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="http-respbindprocess"></a>7.5.2.2 Receiving</h5>
|
|
|
|
<p>In the "Receiving" state, the binding
|
|
receives the request and any associated message and waits for the
|
|
start of a response message to be available. <a href="#tabresstaterecheads"><b>Table 19</b></a> describes the HTTP response header fields
|
|
generated by the responding SOAP node. <a href="#tabresstatereccodes"><b>Table 20</b></a> describes the HTTP status codes associated
|
|
with SOAP faults that can be generated by the responding SOAP node.</p>
|
|
|
|
<a name="tabresstaterecheads"></a><table border="1">
|
|
<caption>Table 19: HTTP Response Headers Fields</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">Field</th>
|
|
<th rowspan="1" colspan="1">Value</th></tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">Status line</td>
|
|
<td rowspan="1" colspan="1"><p>If a SOAP Envelope response is available in <code>http://www.w3.org/2003/05/soap/mep/OutboundMessage</code> then 200, or set according to <a href="#tabresstatereccodes"><b>Table 20</b></a> if a SOAP
|
|
fault was generated. Otherwise, if no such SOAP envelope is provided, then 202.</p></td></tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><p>Content-Type header field</p></td>
|
|
<td rowspan="1" colspan="1"><p>If Status line is 200, then the media type of the response body, see <a href="#http-intro"><b>7.1 Introduction</b></a> for a description of permissible media
|
|
types. If status line is other than 200, then the Content-Type header is not sent.</p></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1"><p>Additional header fields</p></td>
|
|
<td rowspan="1" colspan="1"><p>Generated in accordance with the rules for the binding-specific
|
|
expression of any optional features in use for this message
|
|
exchange. For example, a Content-Encoding header field (see HTTP <a href="#RFC2616">[RFC 2616]</a>, section 14.11) may be used to express an optional
|
|
compression feature.</p></td>
|
|
</tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">HTTP Entity Body</td>
|
|
<td rowspan="1" colspan="1"><p>Only if status line is 200, the SOAP message serialized according to the rules for carrying SOAP
|
|
messages in the media type given by the Content-Type header field. Rules
|
|
for carrying SOAP messages in "application/soap+xml" are
|
|
given in <a href="#ietf-draft"><b>A. The application/soap+xml Media Type</b></a>.</p></td>
|
|
</tr>
|
|
</tbody></table>
|
|
<p> </p>
|
|
|
|
<a name="tabresstatereccodes"></a><table border="1">
|
|
<caption>Table 20: SOAP Fault to HTTP Status Mapping</caption>
|
|
<tbody>
|
|
<tr>
|
|
<th rowspan="1" colspan="1">SOAP Fault</th>
|
|
<th rowspan="1" colspan="1">HTTP Status Code</th>
|
|
<th rowspan="1" colspan="1">HTTP Reason Phrase (informative)</th></tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">env:VersionMismatch</td>
|
|
<td rowspan="1" colspan="1">500</td>
|
|
<td rowspan="1" colspan="1">Internal server error</td></tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">env:MustUnderstand</td>
|
|
<td rowspan="1" colspan="1">500</td>
|
|
<td rowspan="1" colspan="1">Internal server error</td></tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">env:Sender</td>
|
|
<td rowspan="1" colspan="1">400</td>
|
|
<td rowspan="1" colspan="1">Bad request</td></tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">env:Receiver</td>
|
|
<td rowspan="1" colspan="1">500</td>
|
|
<td rowspan="1" colspan="1">Internal server error</td></tr>
|
|
<tr>
|
|
<td rowspan="1" colspan="1">env:DataEncodingUnknown</td>
|
|
<td rowspan="1" colspan="1">500</td>
|
|
<td rowspan="1" colspan="1">Internal server error</td></tr>
|
|
</tbody></table>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="http-respbindrespond"></a>7.5.2.3 Receiving+Sending</h5>
|
|
|
|
<p>In the "Receiving+Sending" state (<a href="#singlereqrespmep"><b>6.2 SOAP Request-Response Message Exchange Pattern</b></a> only) the binding completes receiving of the
|
|
request message and transmission of the response message.</p>
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="http-respbindrespond2"></a>7.5.2.4 Sending</h5>
|
|
|
|
<p>In the "Sending" state (<a href="#soapresmep"><b>6.3 SOAP Response Message Exchange Pattern</b></a> only) the binding completes transmission of the response message.</p>
|
|
|
|
</div>
|
|
|
|
<div class="div4">
|
|
<h5><a name="http-respsuccfail"></a>7.5.2.5 Success and Fail</h5>
|
|
|
|
<p>"Success" and "Fail" are the terminal states for the
|
|
Request-Response and SOAP-Response MEPs. From the point-of-view of
|
|
the local node this message exchange has completed.</p>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
|
|
<div class="div2">
|
|
<h3><a name="seccond"></a>7.6 Security Considerations</h3>
|
|
|
|
<p>The SOAP
|
|
HTTP Binding (see <a href="#soapinhttp"><b>7. SOAP HTTP Binding</b></a>) can be considered as
|
|
an extension of the HTTP application protocol. As such, all of the
|
|
security considerations identified and described in section 15 of
|
|
the HTTP specification <a href="#RFC2616">[RFC 2616]</a>
|
|
apply to the SOAP HTTP Binding in
|
|
addition to those described in SOAP 1.2 Part 1 <a href="#SOAP-PART1">[SOAP Part 1]</a>
|
|
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427/#secconsiderations">Security Considerations</a>.
|
|
Implementors of the SOAP HTTP Binding should
|
|
carefully review this material.</p>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="refs"></a>8. References</h2>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="refs-norm"></a>8.1 Normative References</h3>
|
|
|
|
<dl>
|
|
|
|
<dt class="label"><a name="SOAP-PART1"></a>[SOAP Part 1] </dt><dd>
|
|
<a href="http://www.w3.org/TR/2007/REC-soap12-part1-20070427"><cite>SOAP Version 1.2 Part 1: Messaging Framework (Second Edition)</cite></a>,
|
|
Martin Gudgin, Marc Hadley, Noah Mendelsohn, Jean-Jacques Moreau,
|
|
Henrik Frystyk Nielsen, Anish Karmarkar, Yves Lafon, Editors.
|
|
World Wide Web Consortium, 27 April 2007.
|
|
This version is http://www.w3.org/TR/2007/REC-soap12-part1-20070427.
|
|
The <a href="http://www.w3.org/TR/soap12-part1/">latest version</a> is
|
|
available at http://www.w3.org/TR/soap12-part1/.</dd>
|
|
|
|
<dt class="label"><a name="RFC2616"></a>[RFC 2616] </dt><dd>
|
|
<a href="http://www.ietf.org/rfc/rfc2616.txt"><cite>Hypertext
|
|
Transfer Protocol -- HTTP/1.1</cite></a>, R. Fielding,
|
|
J. Gettys, J. C. Mogul, H. Frystyk Nielsen, P. Leach,
|
|
L. Masinter and T. Berners-Lee,
|
|
Editors.
|
|
IETF, June 1999.
|
|
This RFC is available at http://www.ietf.org/rfc/rfc2616.txt.</dd>
|
|
|
|
<dt class="label"><a name="RFC2119"></a>[RFC 2119] </dt><dd>
|
|
<a href="http://www.ietf.org/rfc/rfc2119.txt"><cite>Key words for
|
|
use in RFCs to Indicate Requirement Levels</cite></a>, S. Bradner,
|
|
Editor.
|
|
IETF, March 1997.
|
|
This RFC is available at http://www.ietf.org/rfc/rfc2119.txt.</dd>
|
|
|
|
<dt class="label"><a name="XMLSchemaP1"></a>[XML Schema Part 1] </dt><dd>
|
|
<a href="http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/"><cite>
|
|
XML Schema Part 1:
|
|
Structures Second Edition</cite></a>, David Beech, Murray Maloney,
|
|
Henry S. Thompson, and Noah Mendelsohn, Editors.
|
|
World Wide Web Consortium, 28 October 2004.
|
|
This version is http://www.w3.org/TR/2004/REC-xmlschema-1-20041028/
|
|
The <a href="http://www.w3.org/TR/xmlschema-1/">latest version</a> is
|
|
available at http://www.w3.org/TR/xmlschema-1/.</dd>
|
|
|
|
<dt class="label"><a name="XMLSchemaP2"></a>[XML Schema Part 2] </dt><dd>
|
|
<a href="http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/"><cite>
|
|
XML Schema Part 2:
|
|
Datatypes Second Edition</cite></a>,
|
|
Ashok Malhotra and Paul V. Biron, Editors.
|
|
World Wide Web Consortium, 28 October 2004.
|
|
This version is http://www.w3.org/TR/2004/REC-xmlschema-2-20041028/.
|
|
The <a href="http://www.w3.org/TR/xmlschema-2/">latest version</a> is
|
|
available at http://www.w3.org/TR/xmlschema-2/.</dd>
|
|
|
|
<dt class="label"><a name="RFC3986"></a>[RFC 3986] </dt><dd>
|
|
<a href="http://www.ietf.org/rfc/rfc3986.txt"><cite>Uniform Resource
|
|
Identifiers (URI): Generic Syntax</cite></a>, T. Berners-Lee,
|
|
R. Fielding and L. Masinter, Editors.
|
|
IETF, January 2005.
|
|
<em>Obsoletes: <span id="RFC2396">RFC 2396</span>,
|
|
<span id="RFC2732">RFC 2732</span></em>.
|
|
This RFC is available at http://www.ietf.org/rfc/rfc3986.txt.</dd>
|
|
|
|
<dt class="label"><a name="XMLNS"></a>[Namespaces in XML] </dt><dd>
|
|
<a href="http://www.w3.org/TR/2006/REC-xml-names-20060816"><cite>
|
|
Namespaces in
|
|
XML (Second Edition)</cite></a>, Tim Bray, Dave Hollander,
|
|
Andrew Layman, and Richard Tobin, Editors.
|
|
World Wide Web Consortium, 16 August 2006.
|
|
This version is http://www.w3.org/TR/2006/REC-xml-names-20060816.
|
|
The <a href="http://www.w3.org/TR/REC-xml-names">latest version</a> is
|
|
available at http://www.w3.org/TR/REC-xml-names.</dd>
|
|
|
|
<dt class="label"><a name="XML"></a>[XML 1.0] </dt><dd>
|
|
<a href="http://www.w3.org/TR/2006/REC-xml-20060816"><cite>Extensible
|
|
Markup Language (XML) 1.0 (Fourth Edition)</cite></a>, Jean Paoli,
|
|
Eve Maler, Tim Bray, <em>et. al.</em>, Editors.
|
|
World Wide Web Consortium, 16 August 2006.
|
|
This version is http://www.w3.org/TR/2006/REC-xml-20060816.
|
|
The <a href="http://www.w3.org/TR/REC-xml">latest version</a> is
|
|
available at http://www.w3.org/TR/REC-xml.</dd>
|
|
|
|
<dt class="label"><a name="XMLInfoSet"></a>[XML InfoSet] </dt><dd>
|
|
<a href="http://www.w3.org/TR/2004/REC-xml-infoset-20040204"><cite>XML
|
|
Information Set (Second Edition)</cite></a>, Richard Tobin and
|
|
John Cowan, Editors.
|
|
World Wide Web Consortium, 04 February 2004.
|
|
This version is http://www.w3.org/TR/2004/REC-xml-infoset-20040204.
|
|
The <a href="http://www.w3.org/TR/xml-infoset">latest version</a> is
|
|
available at http://www.w3.org/TR/xml-infoset.</dd>
|
|
|
|
<dt class="label"><a name="RFC3023"></a>[RFC 3023] </dt><dd>
|
|
<a href="http://www.ietf.org/rfc/rfc3023.txt"><cite>XML Media Types</cite></a>
|
|
M. Murata, S. St.Laurent, D. Kohn, Editors.
|
|
IETF, January 2001.
|
|
This RFC is available at http://www.ietf.org/rfc/rfc3023.txt.</dd>
|
|
|
|
<dt class="label"><a name="soap-media-type"></a>[RFC 3902] </dt><dd>
|
|
<a href="http://www.ietf.org/rfc/rfc3902.txt"><cite>
|
|
The "application/soap+xml" media type</cite></a>, M. Baker,
|
|
M. Nottingham, Editors.
|
|
IETF, September 2004.
|
|
This RFC is available at http://www.ietf.org/rfc/rfc3902.txt.</dd>
|
|
|
|
</dl>
|
|
|
|
</div>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="refs-inform"></a>8.2 Informative References</h3>
|
|
|
|
<dl>
|
|
<dt class="label"><a name="soap11"></a>[SOAP 1.1] </dt><dd>
|
|
<a href="http://www.w3.org/TR/2000/NOTE-SOAP-20000508/"><cite>Simple Object
|
|
Access Protocol (SOAP) 1.1</cite></a>,
|
|
Don Box, David Ehnebuske, Gopal
|
|
Kakivaya, Andrew Layman, Noah Mendelsohn, Henrik Nielsen,
|
|
Satish Thatte, Dave Winer, Editors.
|
|
DevelopMentor, IBM, Microsoft, Lotus Development Corp.,
|
|
UserLand Software, Inc., 30 July 2003.
|
|
This version is http://www.w3.org/TR/2000/NOTE-SOAP-20000508/.</dd>
|
|
|
|
<dt class="label"><a name="SOAP-PART0"></a>[SOAP Part 0] </dt><dd>
|
|
<a href="http://www.w3.org/TR/2007/REC-soap12-part0-20070427"><cite>SOAP Version 1.2 Part 0: Primer (Second Edition)</cite></a>,
|
|
Nilo Mitra, Yves Lafon, Editors.
|
|
World Wide Web Consortium, 27 April 2007.
|
|
This version is http://www.w3.org/TR/2007/REC-soap12-part0-20070427.
|
|
The <a href="http://www.w3.org/TR/soap12-part0/">latest version</a> is
|
|
available at http://www.w3.org/TR/soap12-part0/.</dd>
|
|
|
|
|
|
<dt class="label"><a name="CommentArchive"></a>[XMLP Comments] </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>
|
|
|
|
<dt class="label"><a name="DiscussionArchive"></a>[XMLP Dist-App] </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="XMLPCharter"></a>[XMLP Charter] </dt><dd>XML Protocol Charter (See <a href="http://www.w3.org/2005/07/XML-Protocol-Charter">http://www.w3.org/2005/07/XML-Protocol-Charter</a>.)</dd>
|
|
|
|
<dt class="label"><a name="RFC2045"></a>[RFC 2045] </dt><dd>
|
|
<a href="http://www.ietf.org/rfc/rfc2045.txt"><cite>
|
|
Multipurpose Internet Mail Extensions (MIME) Part One:
|
|
Format of Internet Message Bodies
|
|
</cite></a>, N. Freed, N. Borenstein, Editors.
|
|
IETF, November 1996.
|
|
This RFC is available at http://www.ietf.org/rfc/rfc2045.txt.</dd>
|
|
|
|
<dt class="label"><a name="RFC2026"></a>[RFC 2026] </dt><dd>
|
|
<a href="http://www.ietf.org/rfc/rfc2026.txt"><cite>
|
|
The Internet Standards Process -- Revision 3</cite></a>,
|
|
S. Bradner, Editor.
|
|
IETF, October 1996.
|
|
This RFC is available at http://www.ietf.org/rfc/rfc2026.txt.</dd>
|
|
|
|
<dt class="label"><a name="RFC2817"></a>[RFC 2817] </dt><dd>
|
|
<a href="http://www.ietf.org/rfc/rfc2817.txt"><cite>
|
|
Upgrading to TLS Within HTTP/1.1</cite></a>,
|
|
R. Khare, S. Lawrence, Editors.
|
|
IETF, May 2000.
|
|
This RFC is available at http://www.ietf.org/rfc/rfc2817.txt.</dd>
|
|
|
|
<dt class="label"><a name="RFC3987"></a>[RFC 3987] </dt><dd>
|
|
<a href="http://www.ietf.org/rfc/rfc3987.txt"><cite>
|
|
Internationalized Resource Identifiers (IRIs)
|
|
</cite></a>,
|
|
M. Duerst, Editors.
|
|
IETF, January 2005.
|
|
This RFC is available at http://www.ietf.org/rfc/rfc3987.txt.</dd>
|
|
|
|
<dt class="label"><a name="CharMod"></a>[CharMod] </dt><dd>
|
|
<a href="http://www.w3.org/TR/2005/REC-charmod-20050215/"><cite>
|
|
Character Model for the World Wide Web 1.0: Fundamentals</cite></a>,
|
|
Martin J. Dürst, François Yergeau, Richard Ishida, Misha Wolf,
|
|
Tex Texin, Editors.
|
|
World Wide Web Consortium, 15 February 2005.
|
|
This version is http://www.w3.org/TR/2005/REC-charmod-20050215/.
|
|
The <a href="http://www.w3.org/TR/charmod/">latest version</a> is
|
|
available at http://www.w3.org/TR/charmod/.</dd>
|
|
|
|
</dl>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
</div>
|
|
|
|
|
|
|
|
|
|
<div class="back">
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="ietf-draft"></a>A. The "application/soap+xml" Media Type</h2>
|
|
|
|
<p>The original contents of this section have been superceded by RFC3902<a href="#soap-media-type">[RFC 3902]</a>.</p>
|
|
|
|
</div>
|
|
|
|
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="namemap"></a>B. Mapping Application-Defined Names to XML Names</h2>
|
|
|
|
<p>This appendix details an algorithm for taking an
|
|
application-defined name, such as the name of a variable or
|
|
field in a programming language, and mapping it to the Unicode
|
|
characters that are legal in the names of XML elements and
|
|
attributes as defined in Namespace in XML <a href="#XMLNS">[Namespaces in XML]</a></p>
|
|
|
|
|
|
|
|
<h5>Hex Digits</h5><table class="scrap" summary="Scrap"><tbody><tr valign="baseline"><td><a name="hexDigit"></a>[5] </td><td><code>hexDigit</code></td><td> ::= </td><td><code>[0-9A-F]</code></td></tr></tbody></table>
|
|
|
|
<div class="div2">
|
|
|
|
<h3><a name="namemap-rules"></a>B.1 Rules for Mapping Application-Defined Names to XML Names</h3>
|
|
|
|
<ol>
|
|
|
|
<li><p>An XML Name has two parts: <var>Prefix</var> and
|
|
<var>LocalPart</var>. Let
|
|
<var>Prefix</var> be determined per the rules and constraints
|
|
specified in Namespaces in XML <a href="#XMLNS">[Namespaces in XML]</a>.</p></li>
|
|
|
|
<li><p>Let <var>T</var> be a name in an application, represented as
|
|
a sequence of characters encoded in a particular character encoding.
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>Let <code>M</code> be the implementation-defined function for
|
|
transcoding of the characters used in the application-defined
|
|
name to an equivalent string of Unicode characters.
|
|
</p>
|
|
<div class="note"><p class="prefix"><b>Note:</b></p><p>Ideally, if this transcoding is from a
|
|
non-Unicode encoding, it should be both reversible and Unicode
|
|
Form C normalizing (that is, combining sequences will be in
|
|
the prescribed canonical order). It should be noted that some
|
|
transcodings cannot be perfectly reversible and that Normalization Form C (NFC)
|
|
normalization may alter the original sequence in a few
|
|
cases (see Character Model for the World Wide Web <a href="#CharMod">[CharMod]</a>). To
|
|
ensure that matching names continue to match after mapping,
|
|
Unicode sequences should be normalized using Unicode
|
|
Normalization Form C.
|
|
</p></div>
|
|
<div class="note"><p class="prefix"><b>Note:</b></p><p>This transcoding is explicitly to Unicode
|
|
scalar values ("code points") and not to any particular
|
|
character encoding scheme of Unicode, such as UTF-8 or UTF-16.
|
|
</p></div>
|
|
<div class="note"><p class="prefix"><b>Note:</b></p><p>Note: Properly formed surrogate pair
|
|
sequences must be converted to their respective scalar values
|
|
("code points") [That is, the sequence U+D800 U+DC00 should be
|
|
transcoded to the character U+10000]. If the transcoding
|
|
begins with a Unicode encoding, non-conforming (non-shortest
|
|
form) UTF-8 and UTF-16 sequences must be converted to their
|
|
respective scalar values.
|
|
</p></div>
|
|
<div class="note"><p class="prefix"><b>Note:</b></p><p>The number of characters in <var>T</var> is not
|
|
necessarily the same as the number of characters in <code>M</code>, because
|
|
transcoding may be one-to-many or many-to-one. The details of
|
|
transcoding may be implementation-defined. There may be (very
|
|
rarely) cases where there is no equivalent Unicode
|
|
representation for <var>T</var>; such cases are not covered here.
|
|
</p></div>
|
|
</li>
|
|
|
|
<li><p>Let <var>C</var> be the sequence of Unicode
|
|
scalar values (characters) represented by <code>M(T)</code></p>
|
|
</li>
|
|
|
|
<li><p>Let <var>N</var> be the number of characters in
|
|
<var>C</var>. Let <var>C</var><sub>1</sub>,
|
|
<var>C</var><sub>2</sub>, ..., <var>C</var><sub>N</sub> be the
|
|
characters of <var>C</var>, in order from most to least
|
|
significant (logical order).</p>
|
|
</li>
|
|
<li>
|
|
<p>For each <var>i</var> between 1 (one) and
|
|
<var>N</var>, let <var>X</var><sub>i</sub> be the Unicode
|
|
character string defined by the following rules:
|
|
</p>
|
|
|
|
<p>Case:</p>
|
|
<ol>
|
|
|
|
<li><p>If <var>C</var><sub>i</sub> is undefined (that
|
|
is, some character or sequence of characters as defined in
|
|
the application's character sequence <var>T</var> contains
|
|
no mapping to Unicode), then <var>X</var><sub>i</sub> is
|
|
implementation-defined.</p>
|
|
</li>
|
|
|
|
<li><p>If <var>i</var><=<var>N</var>-1 and
|
|
<var>C</var><sub>i</sub> is "_" (U+005F LOW LINE) and
|
|
<var>C</var><sub>i+1</sub> is "x" (U+0078 LATIN SMALL LETTER
|
|
X), then let <var>X</var><sub>i</sub> be "_x005F_".
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>If <var>i</var>=1, and <var>N</var>>=3, and
|
|
<var>C</var><sub>1</sub> is "x" (U+0078 LATIN
|
|
SMALL LETTER X) or "X" (U+0058 LATIN CAPITAL
|
|
LETTER X), and <var>C</var><sub>2</sub> is "m" (U+006D LATIN
|
|
SMALL LETTER M) or "M" (U+004D LATIN CAPITAL
|
|
LETTER M), and <var>C</var><sub>3</sub> is "l" (U+006C LATIN
|
|
SMALL LETTER L) or "L" (U+004C LATIN CAPITAL
|
|
LETTER L) (in other words, a string three letters or longer
|
|
starting with the text "xml" or any
|
|
re-capitalization thereof),
|
|
then if <var>C</var><sub>1</sub> is
|
|
"x" (U+0078 LATIN SMALL LETTER X)
|
|
then let <var>X</var><sub>1</sub> be
|
|
"_x0078_"; otherwise, if
|
|
<var>C</var><sub>1</sub> is "X"
|
|
(U+0058 LATIN CAPITAL LETTER X) then let
|
|
<var>X</var><sub>1</sub> be "_x0058_".
|
|
</p>
|
|
</li>
|
|
|
|
<li><p>If <var>C</var><sub>i</sub> is not a valid XML
|
|
NCName character (see Namespaces in XML <a href="#XMLNS">[Namespaces in XML]</a>) or if
|
|
<var>i</var>=1 (one) and <var>C</var><sub>1</sub> is not a
|
|
valid first character of an XML NCName then:</p>
|
|
|
|
<p>Let <var>U<sub>1</sub></var>, <var>U<sub>2</sub></var>,
|
|
... , <var>U<sub>6</sub></var> be the six hex digits
|
|
<b>[PROD: <a href="#hexDigit">5</a>]</b> such
|
|
that <var>C<sub>i</sub></var> is "U+"
|
|
<var>U<sub>1</sub></var> <var>U<sub>2</sub></var>
|
|
... <var>U<sub>6</sub></var> in the Unicode scalar value.</p>
|
|
|
|
<p>Case:</p>
|
|
|
|
<ol>
|
|
|
|
<li>
|
|
|
|
<p>If <var>U<sub>1</sub></var>=0,
|
|
<var>U<sub>2</sub></var>=0, <var>U<sub>3</sub></var>=0, and
|
|
<var>U<sub>4</sub></var>=0, then let
|
|
<var>X<sub>i</sub></var>="_x"
|
|
<var>U<sub>5</sub></var>
|
|
<var>U<sub>6</sub></var> "_".</p>
|
|
|
|
<p>This case implies that
|
|
<var>C<sub>i</sub></var> is a character in the Basic
|
|
Multilingual Plane (Plane 0) of Unicode and can be
|
|
wholly represented by a single UTF-16 code point sequence
|
|
U+<var>U<sub>5</sub></var><var>U<sub>6</sub></var>.</p>
|
|
</li>
|
|
|
|
<li>
|
|
|
|
<p>Otherwise, let <var>X<sub>i</sub></var> be
|
|
"_x" <var>U<sub>1</sub></var>
|
|
<var>U<sub>2</sub></var>
|
|
<var>U<sub>3</sub></var> <var>U<sub>4</sub></var>
|
|
<var>U<sub>5</sub></var>
|
|
<var>U<sub>6</sub></var> "_".</p>
|
|
</li>
|
|
|
|
</ol>
|
|
|
|
</li>
|
|
|
|
<li><p>Otherwise, let <var>X<sub>i</sub></var> be
|
|
<var>M<sub>i</sub></var>. That is, any character in <var>X</var> that is a
|
|
valid character in an XML NCName is simply copied.</p></li>
|
|
|
|
</ol>
|
|
</li>
|
|
|
|
|
|
<li>
|
|
<p>Let <var>LocalPart</var> be the character string
|
|
concatenation of <var>X<sub>1</sub></var>, <var>X<sub>2</sub></var>,
|
|
... , <var>X<sub>N</sub></var> in order from most to least significant.</p>
|
|
</li>
|
|
|
|
<li>
|
|
<p>Let XML Name be the QName per Namespaces in XML <a href="#XMLNS">[Namespaces in XML]</a></p>
|
|
</li>
|
|
|
|
</ol>
|
|
</div>
|
|
<div class="div2">
|
|
<h3><a name="namemap-ex"></a>B.2 Examples</h3>
|
|
|
|
<div class="exampleOuter">
|
|
<div class="exampleInner"><pre>
|
|
Hello world -> Hello_x0020_world
|
|
Hello_xorld -> Hello_x005F_xorld
|
|
Helloworld_ -> Helloworld_
|
|
|
|
x -> x
|
|
xml -> _x0078_ml
|
|
-xml -> _x002D_xml
|
|
x-ml -> x-ml
|
|
|
|
Ælfred -> Ælfred
|
|
άγνωστος -> άγνωστος
|
|
ᜉᜅᜎᜈ -> _x1709__x1705__x170E__x1708_
|
|
ᏙᏚᎥ -> _x13D9__x13DA__x13A5_
|
|
</pre></div>
|
|
</div>
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="encschema"></a>C. Using W3C XML Schema with SOAP Encoding (Non-Normative)</h2>
|
|
|
|
<p>
|
|
As noted in <a href="#enctypename"><b>3.1.4 Computing the Type Name Property</b></a> SOAP graph nodes are
|
|
labeled with type names, but conforming processors are not required to perform
|
|
validation of encoded SOAP messages.</p>
|
|
|
|
<p>These sections
|
|
describe techniques that can be used when validation with W3C
|
|
XML schemas is desired for use by SOAP applications. Any errors
|
|
or faults resulting from such validation are beyond those
|
|
covered by the normative Recommendation; from the perspective of
|
|
SOAP, such faults are considered to be application-level
|
|
failures.
|
|
</p>
|
|
<div class="div2">
|
|
|
|
<h3><a name="validmin"></a>C.1 Validating Using the Minimum Schema</h3>
|
|
<p>
|
|
Although W3C XML schemas are conventionally exchanged in the
|
|
form of schema documents (see XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1]</a>), the schema
|
|
Recommendation is built on an abstract definition of schemas,
|
|
to which all processors need to conform. The schema
|
|
Recommendation provides that all such schemas include
|
|
definitions for a core set of built in types, such as
|
|
integers, dates, and so on (see XML Schema <a href="#XMLSchemaP1">[XML Schema Part 1]</a>,
|
|
<a href="http://www.w3.org/TR/2001/REC-xmlschema-1-20010502/#Simple_Type_Definitions">Built-in Simple Type Definition</a>).
|
|
Thus, it is possible to discuss validation of a SOAP
|
|
message against such a minimal schema, which is the one that
|
|
would result from providing no additional definitions or
|
|
declarations (i.e., no schema document) to a schema processor.
|
|
</p>
|
|
|
|
<p>
|
|
The minimal schema provides that any well formed XML document
|
|
will validate, except that where an xsi:type is provided, the
|
|
type named must be built in, and the corresponding element must be
|
|
valid per that type. Thus, validation of a SOAP 1.2 message using a
|
|
minimal schema approximates the behavior of the built-in types
|
|
of SOAP 1.1.
|
|
</p>
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="validenc"></a>C.2 Validating Using the SOAP Encoding Schema</h3>
|
|
|
|
<p>
|
|
Validation against the minimal schema (see <a href="#validmin"><b>C.1 Validating Using the Minimum Schema</b></a>) will not succeed where encoded graph nodes
|
|
have multiple inbound edges. This is because
|
|
elements representing such graph nodes will carry <code>id</code>
|
|
<em>attribute information items</em> which are not legal
|
|
on elements of type "xs:string",
|
|
"xs:integer" etc. The SOAP Encoding of such graphs MAY be validated
|
|
against the <a href="http://www.w3.org/2003/05/soap-encoding">SOAP Encoding schema</a>.
|
|
In order for the encoding to validate, edge labels, and
|
|
hence the
|
|
[local name] and [namespace name] properties of the
|
|
<em>element information items</em>, need to match those
|
|
defined in the SOAP Encoding schema. Validation of the encoded
|
|
graph against the SOAP Encoding schema would result in the
|
|
type name property of the nodes in the graph being assigned
|
|
the relevant type name.
|
|
</p>
|
|
|
|
</div>
|
|
<div class="div2">
|
|
|
|
<h3><a name="validschema"></a>C.3 Validating Using More Specific Schemas</h3>
|
|
|
|
<p>
|
|
It may be that schemas could be constructed to describe the encoding of
|
|
certain graphs. Validation of the encoded graph against such a schema would
|
|
result in the type name property of the graph nodes being assigned the
|
|
relevant type name. Such a schema can also supply default or fixed values
|
|
for one or more of the <code>itemType</code> , <code>arraySize</code> or
|
|
<code>nodeType</code> <em>attribute
|
|
information items</em>; the values of such defaulted attributes affect the
|
|
deserialized graph in the same manner as if the attributes had been
|
|
explicitly supplied in the message. Errors or inconsistencies thus
|
|
introduced (e.g. if the value of the attribute is erroneous or inappropriate)
|
|
should be reported as application-level errors; faults from the
|
|
"http://www.w3.org/2003/05/soap-encoding"
|
|
namespace should be reported only if the normative parts of this
|
|
specification are violated.
|
|
</p>
|
|
|
|
</div>
|
|
</div>
|
|
|
|
<div class="div1">
|
|
|
|
<h2><a name="id2279382"></a>D. Acknowledgements (Non-Normative)</h2>
|
|
|
|
<p>This document is the work of the W3C XML Protocol Working Group.</p>
|
|
|
|
<p>Participants in the Working Group are (at the time of writing, and by
|
|
alphabetical order): Glen Daniels (Sonic Software, formerly of Macromedia),
|
|
Vikas Deolaliker (Sonoa Systems, Inc.),
|
|
Chris Ferris (IBM, formerly of Sun Microsystems),
|
|
Marc Hadley (Sun Microsystems),
|
|
David Hull (TIBCO Software, Inc.),
|
|
Anish Karmarkar (Oracle),
|
|
Yves Lafon (W3C),
|
|
Jonathan Marsh (WSO2),
|
|
Jeff Mischkinsky (Oracle),
|
|
Eric Newcomer (IONA Technologies),
|
|
David Orchard (BEA Systems, formerly of Jamcracker),
|
|
Seumas Soltysik (IONA Technologies),
|
|
Davanum Srinivas (WSO2),
|
|
Pete Wenzel (Sun Microsystems, formerly of SeeBeyond).
|
|
</p>
|
|
|
|
<p>Previous participants were: Yasser alSafadi (Philips Research),
|
|
Bill Anderson (Xerox),
|
|
Vidur Apparao (Netscape),
|
|
Camilo Arbelaez (webMethods),
|
|
Mark Baker (Idokorro Mobile, Inc., formerly of Sun Microsystems),
|
|
Philippe Bedu (EDF (Electricite De France)),
|
|
Olivier Boudeville (EDF (Electricite De France)),
|
|
Carine Bournez (W3C),
|
|
Don Box (Microsoft Corporation, formerly of DevelopMentor),
|
|
Tom Breuel (Xerox),
|
|
Dick Brooks (Group 8760),
|
|
Winston Bumpus (Novell, Inc.),
|
|
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),
|
|
Dave Cleary (webMethods),
|
|
Ugo Corda (Xerox),
|
|
Paul Cotton (Microsoft Corporation),
|
|
Fransisco Cubera (IBM),
|
|
Jim d'Augustine (Excelon Corporation),
|
|
Ron Daniel (Interwoven),
|
|
Doug Davis (IBM),
|
|
Ray Denenberg (Library of Congress),
|
|
Paul Denning (MITRE Corporation),
|
|
Frank DeRose (TIBCO Software, Inc.),
|
|
Mike Dierken (DataChannel),
|
|
Andrew Eisenberg (Progress Software),
|
|
Brian Eisenberg (DataChannel),
|
|
Colleen Evans (Sonic Software),
|
|
John Evdemon (XMLSolutions),
|
|
David Ezell (Hewlett Packard),
|
|
James Falek (TIBCO Software, Inc.),
|
|
David Fallside (IBM),
|
|
Eric Fedok (Active Data Exchange),
|
|
Daniela Florescu (Propel),
|
|
Dan Frantz (BEA Systems),
|
|
Michael Freeman (Engenia Software),
|
|
Dietmar Gaertner (Software AG),
|
|
Scott Golubock (Epicentric),
|
|
Tony Graham (Sun Microsystems),
|
|
Mike Greenberg (IONA Technologies),
|
|
Rich Greenfield (Library of Congress),
|
|
Martin Gudgin (Microsoft Corporation, formerly of DevelopMentor),
|
|
Hugo Haas (W3C),
|
|
Mark Hale (Interwoven),
|
|
Randy Hall (Intel),
|
|
Bjoern Heckel (Epicentric),
|
|
Frederick Hirsch (Zolera Systems),
|
|
Gerd Hoelzing (SAP AG),
|
|
Erin Hoffmann (Tradia Inc.),
|
|
Steve Hole (MessagingDirect Ltd.),
|
|
Mary Holstege (Calico Commerce),
|
|
Jim Hughes (Fujitsu Limited),
|
|
Oisin Hurley (IONA Technologies),
|
|
Yin-Leng Husband (Hewlett Packard, formerly of Compaq),
|
|
John Ibbotson (IBM),
|
|
Ryuji Inoue (Matsushita Electric Industrial Co., Ltd.),
|
|
Scott Isaacson (Novell, Inc.),
|
|
Kazunori Iwasa (Fujitsu Limited),
|
|
Murali Janakiraman (Rogue Wave),
|
|
Mario Jeckle (DaimlerChrysler Research and Technology),
|
|
Eric Jenkins (Engenia Software),
|
|
Mark Jones (AT&T),
|
|
Jay Kasi (Commerce One),
|
|
Jeffrey Kay (Engenia Software),
|
|
Suresh Kodichath (IONA Technologies),
|
|
Richard Koo (Vitria Technology Inc.),
|
|
Jacek Kopecky (Systinet),
|
|
Alan Kropp (Epicentric),
|
|
Julian Kumar (Epicentric),
|
|
Peter Lecuyer (Progress Software),
|
|
Tony Lee (Vitria Technology Inc.),
|
|
Michah Lerner (AT&T),
|
|
Bob Lojek (Intalio Inc.),
|
|
Henry Lowe (OMG),
|
|
Brad Lund (Intel),
|
|
Matthew MacKenzie (XMLGlobal Technologies),
|
|
Michael Mahan (Nokia),
|
|
Murray Maloney (Commerce One),
|
|
Richard Martin (Active Data Exchange),
|
|
Noah Mendelsohn (IBM, formerly of Lotus Development),
|
|
Alex Milowski (Lexica),
|
|
Kevin Mitchell (XMLSolutions),
|
|
Nilo Mitra (Ericsson),
|
|
Ed Mooney (Sun Microsystems),
|
|
Jean-Jacques Moreau (Canon),
|
|
Dean Moses (Epicentric),
|
|
Highland Mary Mountain (Intel),
|
|
Don Mullen (TIBCO Software, Inc.),
|
|
Rekha Nagarajan (Calico Commerce),
|
|
Raj Nair (Cisco Systems),
|
|
Masahiko Narita (Fujitsu Limited),
|
|
Mark Needleman (Data Research Associates),
|
|
Art Nevarez (Novell, Inc.),
|
|
Henrik Nielsen (Microsoft Corporation),
|
|
Mark Nottingham (BEA Systems, formerly of Akamai Technologies),
|
|
Conleth O'Connell (Vignette),
|
|
Kevin Perkins (Compaq),
|
|
Doug Purdy (Microsoft Corporation),
|
|
Jags Ramnaryan (BEA Systems),
|
|
Andreas Riegg (DaimlerChrysler Research and Technology),
|
|
Vilhelm Rosenqvist (NCR),
|
|
Herve Ruellan (Canon),
|
|
Marwan Sabbouh (MITRE Corporation),
|
|
Waqar Sadiq (Vitria Technology Inc.),
|
|
Rich Salz (Zolera Systems),
|
|
Krishna Sankar (Cisco Systems),
|
|
Jeff Schlimmer (Microsoft Corporation),
|
|
George Scott (Tradia Inc.),
|
|
Shane Sesta (Active Data Exchange),
|
|
Lew Shannon (NCR),
|
|
John-Paul Sicotte (MessagingDirect Ltd.),
|
|
Miroslav Simek (Systinet),
|
|
Simeon Simeonov (Macromedia),
|
|
Aaron Skonnard (DevelopMentor),
|
|
Nick Smilonich (Unisys),
|
|
Soumitro Tagore (Informix Software),
|
|
James Tauber (Bowstreet),
|
|
Anne Thomas Manes (Sun Microsystems),
|
|
Lynne Thompson (Unisys),
|
|
Patrick Thompson (Rogue Wave),
|
|
Jim Trezzo (Oracle),
|
|
Asir Vedamuthu (webMethods),
|
|
Mike Vernal (Microsoft Corporation),
|
|
Randy Waldrop (WebMethods),
|
|
Fred Waskiewicz (OMG),
|
|
David Webber (XMLGlobal Technologies),
|
|
Ray Whitmer (Netscape),
|
|
Volker Wiechers (SAP AG),
|
|
Stuart Williams (Hewlett Packard),
|
|
Yan Xu (DataChannel),
|
|
Amr Yassin (Philips Research),
|
|
Susan Yee (Active Data Exchange),
|
|
Jin Yu (MartSoft Corp.).
|
|
</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>
|