ONVIF/gSoap依赖关系及问题
- ONVIF是一组服务规范，标准參考
- gSoap是一套基于实现SOAP通信接口的工具链
即是，当我们须要訪问ONVIF的Web Service或实现对ONVIF部分的支持；基于C/C++开发，则须要借助gSoap生成这之间的交互接口调用的代码。
gSoap生成代码
wsdl2h
将服务接口描写叙述转换为soapcpp2的转换规则，生成中间头文件。
通常我们前期会选择实现部分服务标准；因此这期间生成的兴许多为改动这次生成中间产物.h，而不会一切又一次生成。
soapcpp2
这次是将中间定义转换为实现代码，以供C/C++使用；基本上此过程生成的产物不作特殊处理。由于生成体积庞大，不利于维护改动；而尽量查问题是查找源头或开发逻辑。
ONVIF开发遇到问题
在ONVIF开发过程中最先最常会遇到的问题就是
- 调用失败，解析出错
- 遇到soap_dom_element类型
以下就着重看看这两类问题的有效处理方式。
规避服务实际扩展带来的解析报错
针对第一个问题，大部分这类问题都说明服务响应的结构不规范，导致解析失败。(比方我遇到的就是雄迈的IPC，在ODT測试GetCapabilities时失败)
通常服务提供商基本服务是可以保证的，问题主要会出如今其扩展结构中。这就是ONVIF标准定义的xsd__anyType
扩展结构当然一般都是可选字段，此时我们忽略不使用就可以（仅仅要不影响我们应用需求），观看gsoap生成代码以及终于改动实践我发现，可选字段我们能够选择忽略，这样恰好就规避掉了这情况带来的解析报错，往往一个调用引发的错误，是会导致应用逻辑的决策。
忽略操作，这时候我须要将soapcpp2中间规则的.h中找到对应结构描写叙述的地方，细致查看该字段假设是Optional，则凝视忽略掉便是。又一次用soapcpp2工具处理生成新的代码完毕。
将 xsd__anyType改动成指定解析结构
对于这个，最常见的就是我们要处理ONVIF对于Event通知的时候，默认生成的都是soap_dom_element这类型结构，假设类型复杂，我们会非常难为，须要好深层的遍历实属刁难。但好在对于Event这类实现也是根据规范来实现的，基本填充的内容都标准结构类型。因此我们仅仅要解析出对应的结构信息就能够方便我程序开发使用。
此处參考ONVIF Event消息解析。
总之，这样一来我们将更方便更好的使用gsoap协助我们的开发工作，估计下一篇内容会往使用gsoap手动序列化，从而突破仅仅用工具生成庞大量代码。由于生成代码都是规则化可视的，假设窥得当中要领，则很有利于我们简化依赖和为生成代码瘦身。这对于程序发行使用是很有利的。