?? soapdoc2.html
字號:
<b>int</b> ns1__getQuote(<b>char</b> *symbol, <b>float</b> &Result); <br />
<b>int</b> ns2__getQuote(<b>char</b> *ticker, <b>char</b> *&quote);
</td></tr></table><br></i>
The namespace prefix is separated from the remote method names by a pair of underscores (<i>__</i>) by convention.
<p>This example enables a client program to connect to a (hypothetical) Stock Quote service with remote methods that can only be
distinghuished by their namespaces. Consequently, two different namespace prefixes have been used as part of the remote method
names.
<p>The namespace prefix convention can also be applied to <i><b>class</b></i> declarations that contain SOAP compound values
that share the same name but have different namespaces that refer to different XML schemas. For example:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0D0B0"><tr><td><i>
<b>class</b> <font color="#FF0000">e__Address</font> // an electronic address <br />
{ <br />
char *email; <br />
char *url; <br />
}; <br />
<b>class</b> <font color="#0000FF">s__Address</font> // a street address <br />
{ <br />
char *street; <br />
int number; <br />
char *city; <br />
};
</td></tr></table><br></i>
The namespace prefix is separated from the data type names by a pair of underscores (<i>__</i>) by convention.
<p>An instance of <i><font color="#FF0000">e__Address</font></i> is encoded by the generated serializer for this type as an Address element with namespace prefix <i><font color="#FF0000">e</font></i>:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0B0D0"><tr><td><tt>
<<font color="#FF0000">e:Address</font> xsi:type="<font color="#FF0000">e:Address</font>"> <br />
<email xsi:type="string">me@home</email> <br />
<url xsi:type="string">www.me.com</url> <br />
</<font color="#FF0000">e:Address</font>>
</td></tr></table><br></tt>
While an instance of <i><font color="#0000FF">s__Address</font></i> is encoded by the generated serializer for this type as an Address element with namespace prefix <i><font color="#0000FF">s</font></i>:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0B0D0"><tr><td><tt>
<<font color="#0000FF">s:Address</font> xsi:type="<font color="#0000FF">s:Address</font>"> <br />
<street xsi:type="string">Technology Drive</street> <br />
<number xsi:type="int">5</number> <br />
<city xsi:type="string">Softcity</city> <br />
</<font color="#0000FF">s:Address</font>>
</td></tr></table><br></tt>
The namespace mapping table of the client program must have entries for <i><font color="#FF0000">e</font></i> and <i><font color="#0000FF">s</font></i> that refer to the XML schemas of the data types:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0D0B0"><tr><td><i>
<b>struct</b> Namespace namespaces[] = <br />
{ ... <br />
{"<font color="#FF0000">e</font>", "http://www.me.com/schemas/electronic-address"}, <br />
{"<font color="#0000FF">s</font>", "http://www.me.com/schemas/street-address"}, <br />
...
</td></tr></table><br></i>
This table is required to be part of the client application to allow access by the serializers and deserializers of the data types at run time.
<p> <h4><a name="tth_sEc5.1.4">5.1.4</a> <font color="#0000FF">Some SOAP Encoding Considerations</font></h4><a name="sec:encoding"></a>
<p>Many SOAP services require the explicit use of XML schema types in the SOAP payload. The default encoding, which is also adopted
by the gSOAP stub and skeleton compiler, assumes SOAP encoding. This can be easily changed by using <i><b>typedef</b></i> definitions in
the header file input to the gSOAP compiler. The type name defined by a <i><b>typedef</b></i> definition corresponds to an XML schema
type and may include an optional namespace prefix. For example, the following <i><b>typedef</b></i> declarations, when part of the header
file input to the gSOAP compiler, defines various built-in XML schema types implemented as primitive C/C++ types:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0D0B0"><tr><td><i>
// Contents of header file: <br />
... <br />
<b>typedef</b> <b>char</b> *xsd__string; // encode xsd__string value as the <span class="roman"><tt>xsd:string</tt></span> schema type <br />
<b>typedef</b> <b>char</b> *xsd__anyURI; // encode xsd__anyURI value as the <span class="roman"><tt>xsd:anyURI</tt></span> schema type <br />
<b>typedef</b> <b>float</b> xsd__float; // encode xsd__float value as the <span class="roman"><tt>xsd:float</tt></span> schema type <br />
<b>typedef</b> <b>long</b> xsd__int; // encode xsd__int value as the <span class="roman"><tt>xsd:int</tt></span> schema type <br />
<b>typedef</b> <b>bool</b> xsd__boolean; // encode xsd__boolean value as the <span class="roman"><tt>xsd:boolean</tt></span> schema type <br />
<b>typedef</b> <b>unsigned</b> <b>long</b> <b>long</b> xsd__positiveInteger; // encode xsd__positiveInteger value as the <span class="roman"><tt>xsd:positiveInteger</tt></span> schema type<br />
...
</td></tr></table><br></i>
This simple mechanism informs the gSOAP compiler to generate serializers and deserializers that explicitly encode and decode the
primitive C++ types as built-in primitive XML schema types when the <i>typedef</i>ed type is used in the parameter signature of a
remote method (or when used nested within structs, classes, and arrays). At the same time, the use of <i><b>typedef</b></i>
does not force any recoding of a C++ client or Web service application as the internal C++ types used by the application
are not required to be changed (but still have to be primitive C++ types, see Section <a href="#sec:primclass">8.2.2</a> for alternative class
implementations of primitive XML schema types which allows for the marshalling of polymorphic primitive SOAP types).
<p> <h4><a name="tth_sEc5.1.5">5.1.5</a> <font color="#0000FF">Example</font></h4><a name="sec:example3"></a>
<p>Reconsider the <i>getQuote</i> example, now rewritten with explicit XML schema types to illustrate the effect:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0D0B0"><tr><td><i>
// Contents of file "getQuote.h": <br />
<b>typedef</b> <b>char</b> *<font color="#FF0000">xsd__string</font>; <br />
<b>typedef</b> <b>float</b> <font color="#0000FF">xsd__float</font>; <br />
<b>int</b> <font color="#00FF00">ns1__getQuote</font>(<font color="#FF0000">xsd__string</font> <font color="#FF00FF">symbol</font>, <font color="#0000FF">xsd__float</font> &<font color="#00FFFF">Result</font>);
</td></tr></table><br></i>
This header file is compiled by the gSOAP stub and skeleton compiler and the compiler generates source code for the function
<i>soap_call_ns1__getQuote</i>, which is identical to the ``old'' proxy:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0D0B0"><tr><td><i>
<b>int</b> soap_call_ns1__getQuote(<b>struct</b> soap *soap, <b>char</b> *URL, <b>char</b> *action, <b>char</b> *symbol, <b>float</b> &Result);
</td></tr></table><br></i>
The client application does not need to be rewritten and can still call the proxy using the ``old'' parameter signature. In contrast to
the previous implementation of the stub however, the encoding and decoding of the data types by the stub has been changed to
explicitly use the schema types.
<p>For example, when the client application calls the proxy, the proxy produces a SOAP request with <tt>xsd:string</tt>:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0B0D0"><tr><td><tt>
... <br />
<SOAP-ENV:Body> <br />
<<font color="#00FF00">ns1:getQuote</font>><<font color="#FF00FF">symbol</font> xsi:type="<font color="#FF0000">xsd:string</font>">AOL</<font color="#FF00FF">symbol</font>> <br />
</<font color="#00FF00">ns1:getQuote</font>> <br />
</SOAP-ENV:Body> <br />
...
</td></tr></table><br></tt>
The service response is:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0B0D0"><tr><td><tt>
... <br />
<soap:Body> <br />
<<font color="#00FF00">n:getQuote</font>Response xmlns:n='urn:xmethods-delayed-quotes'> <br />
<<font color="#00FFFF">Result</font> xsi:type='<font color="#0000FF">xsd:float</font>'>41.81</<font color="#00FFFF">Result</font>> <br />
</<font color="#00FF00">n:getQuote</font>Response> <br />
</soap:Body> <br />
...
</td></tr></table><br></tt>
The validation of this service response by the stub routine takes place by matching the namespace URIs that are bound to the
<tt>xsd</tt> namespace prefix. The stub also expects the <tt>getQuoteResponse</tt> element to be associated with namespace URI
<tt>urn:xmethods-delayed-quotes</tt> through the binding of the namespace prefix <tt>ns1</tt> in the namespace mapping table. The
service response uses namespace prefix <tt>n</tt> for the <tt>getQuoteResponse</tt> element. This namespace prefix is bound to the same
namespace URI <tt>urn:xmethods-delayed-quotes</tt> and therefore the service response is assumed to be valid. The response is
rejected and a SOAP fault is generated if the namespace URIs do not match.
<p> <h4><a name="tth_sEc5.1.6">5.1.6</a> <font color="#0000FF">How to Change the Response Element Name</font></h4><a name="sec:response"></a>
<p>There is no explicit standard convention for the response element name in SOAP, although it is recommended that the response
element name is the method name ending with ``<tt>Response</tt>''. For example, the response element of <tt>getQuote</tt> is
<tt>getQuoteResponse</tt>.
<p>The response element name can be specified explicitly using a <i><b>struct</b></i> or <i><b>class</b></i> declaration in the header file. The
<i><b>struct</b></i> or <i><b>class</b></i> name represents the SOAP response element name used by the service. Consequently, the output
parameter of the remote method must be declared as a field of the <i><b>struct</b></i> or <i><b>class</b></i>. The use of a <i><b>struct</b></i> or a
<i><b>class</b></i> for the service response is fully SOAP 1.1 compliant. In fact, the absence of a <i><b>struct</b></i> or <i><b>class</b></i>
indicates to the gSOAP compiler to automatically generate a <i>struct</i> for the response which is internally used by a stub.
<p> <h4><a name="tth_sEc5.1.7">5.1.7</a> <font color="#0000FF">Example</font></h4><a name="sec:example4"></a>
<p>Reconsider the <i>getQuote</i> remote method specification which can be rewritten with an explicit declaration of a SOAP response
element as follows:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0D0B0"><tr><td><i>
// Contents of "getQuote.h": <br />
<b>typedef</b> <b>char</b> *<font color="#FF0000">xsd__string</font>; <br />
<b>typedef</b> <b>float</b> <font color="#0000FF">xsd__float</font>; <br />
<b>struct</b> <font color="#FFFF00">ns1__getQuoteResponse</font> {<font color="#0000FF">xsd__float</font> <font color="#00FFFF">Result</font>;}; <br />
<b>int</b> <font color="#00FF00">ns1__getQuote</font>(<font color="#FF0000">xsd__string</font> <font color="#FF00FF">symbol</font>, <b>struct</b> <font color="#FFFF00">ns1__getQuoteResponse</font> &r);
</td></tr></table><br></i>
The SOAP request is the same as before:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0B0D0"><tr><td><tt>
... <br />
<SOAP-ENV:Body> <br />
<<font color="#00FF00">ns1:getQuote</font>><<font color="#FF00FF">symbol</font> xsi:type="<font color="#FF0000">xsd:string</font>">AOL</<font color="#FF00FF">symbol</font>> <br />
</<font color="#00FF00">ns1:getQuote</font>> <br />
</SOAP-ENV:Body> <br />
...
</td></tr></table><br></tt>
The difference is that the service response is required to match the specified <i>getQuoteResponse</i> name and its namespace URI:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0B0D0"><tr><td><tt>
... <br />
<soap:Body> <br />
<<font color="#FFFF00">n:getQuoteResponse</font> xmlns:n='urn:xmethods-delayed-quotes'> <br />
<<font color="#00FFFF">Result</font> xsi:type='<font color="#0000FF">xsd:float</font>'>41.81</<font color="#00FFFF">Result</font>> <br />
</<font color="#FFFF00">n:getQuoteResponse</font>> <br />
</soap:Body> <br />
...
</td></tr></table><br></tt>
This use of a <i><b>struct</b></i> or <i><b>class</b></i> enables the adaptation of the default SOAP response element name and/or namespace URI when required.
<p>Note that the <i><b>struct</b></i> (or <i><b>class</b></i>) declaration may appear within the function prototype declaration. For example:
<br><br><table border=0 width="100%" cellpadding="8" bgcolor="#B0D0B0"><tr><td><i>
// Contents of "getQuote.h": <br />
<b>typedef</b> <b>char</b> *<font color="#FF0000">xsd__string</font>; <br />
<b>typedef</b> <b>float</b> <font color="#0000FF">xsd__float</font>; <br />
<b>int</b> <font color="#00FF00">ns1__getQuote</font>(<font color="#FF0000">xsd__string</font> <font color="#FF00FF">symbol</font>, <b>struct</b> <font color="#FFFF00">ns1__getQuoteResponse</font> {<font color="#0000FF">xsd__float</font> <font color="#00FFFF">Result</font>;} &r);
</td></tr></table><br></i>
This example combines the declaration of the response element of the remote method with the function prototype of the remote method.
<p> <h4><a name="tth_sEc5.1.8">5.1.8</a> <font color="#0000FF">How to Specify Multiple Output Parameters</font></h4><a name="sec:multiple"></a>
<p>The gSOAP stub and skeleton compiler uses the convention that the <b>single output parameter</b> of a remote method is the <b>
last parameter</b> of the function prototype declaration in a header file. All other parameters are considered input parameters of the remote method. To specify a remote method
with <b>multiple output parameters</b>, a <i><b>struct</b></i> or <i><b>class</b></i> must be declared ?? 快捷鍵說明
復制代碼
Ctrl + C
搜索代碼
Ctrl + F
全屏模式
F11
切換主題
Ctrl + Shift + D
顯示快捷鍵
?
增大字號
Ctrl + =
減小字號
Ctrl + -