还是以计算器为例,重新使用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编码的消息中。