7.1.6 例子

还是以计算器为例，重新使用XSD类型来声明看有什么样的影响：

// Contents of file "calc.h"

typedef double xsd__double;

int ns2__add(xsd__double a, xsd__double b, xsd__double &Result);

当使用gSOAP soapcpp2工具处理该声明时，会生成函数 soap_call_ns2__add, C风格的声明如下：

int soap_call_ns2__add(struct soap *soap, char *URL, char *action, double a, double b, double& result);

客户端程序不需要重写就可以继续使用旧的C-style 函数声明。与之前实现的stub不同的是，现在的stub进行编码和反编码可以直接使用XSD类型了。

例如，当客户段调用proxy时，proxy产生一个SOAP请求，带有xsd:double类型：

...

<SOAP-ENV:Body>
  <ns2:add>
    <a xsi:type="xsd:double">1.0</a>
    <b xsi:type="xsd:double">2.0</b>
  </ns2:add>
</SOAP-ENV:Body>

...

服务器端返回的是：

<soap:Body>
<n:addResponse xmlns:n="urn:calc">
<result xsi:type="xsd:double">3.0</result>
</n:addResponse>
</soap:Body>

stub会对服务器的返回进行验证，通过匹配namespace的名字：

通过命名空间对应表中ns2与urn:calc的对应关系，stub期待addResponse节点元素属于urn:calc命名空间。而服务器响应使用前缀n作为addResponse节点的命名空间，刚好n就是urn:calc，因此服务器返回的结果是合法的。如果返回的xml格式不正确或者验证不通过，那么该返回值就会被丢弃，同时产生一个缺省值。对于返回值得验证级别可以通过SOAP_XML_STRICT标记来设置，但不推荐应用在SOAP RPC编码的消息中。