skydream

发生在我身上的实际故事，最后发现和axis解析xml时的处理机制有关，namespace的有无会影响xml解析的方式，简单的说就是有namespace按照元素名解析，没有namespace则按照index下标的顺序来解析。

中间惊险，一一道来，做技术的不容易啊。

这个市公司的一个大项目，使用web service，我负责服务器端的开发，其他厂商开发客户端。好说，axis上，几个月下来，设计/开发/测试一路ok，就进移动研究院准备最后的入网测试了。
和我们一起联合测试的cx公司，报告说发现错误，经查找是服务器端解析他们发过来的请求失败，出现异常 java.lang.NumberFormatException。非常郁闷，按说不大可能，代码是从wsdl文件自动生成的，怎么可能出这种低级错误，而且我们自己反复测试都通过。于是想办法抓包，发现他们的报文如下：

<env:Envelope xmlns:env='http://schemas.xmlsoap.org/soap/envelope/'>
<env:Header/>
<env:Body>
<ssoRegister>
<Version>0100</Version>
<OpCode>D0001</OpCode>
<UID>13689000001</UID>
<UIDType>SYSUSER</UIDType>
<Service>WEBADMIN</Service>
<LocalZone>5</LocalZone>
<Province>0</Province>
<Privilege>SUPER</Privilege>
</ssoRegister>
</env:Body>
</env:Envelope>

格式怪怪的，对照标准的报文：

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:soapenc="http://schemas.xmlsoap.org/soap/en
coding/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<ssoRegister xmlns="http://system.chinamobile.com">
<OpCode>D0001</OpCode>
<UID>13660000001</UID>
<UIDType>MDN</UIDType>
<Service>WEBMAIL</Service>
<LocalZone>0</LocalZone>
<Province>0</Province>
<Privilege>SUPER</Privilege>
</ssoRegister>
</soapenv:Body>
</soapenv:Envelope>

发现他们的请求多了一个 <Version>0100</Version>字段，试着去掉，解析就通过了。于是通知cx公司修改，同时提示他们说他们的格式不够标准，xsd的namespace很多都没有写。当时就奇怪，从现象看似乎axis是按照index/下标顺序来解析xml,因为多了一个 version,因此后面的字段都顺推了一位,造成用"WEBMAIL"的值来作为LocalZone解析，而localzone是int类型，所以解析失败，出现异常：java.lang.NumberFormatException.

有些奇怪axis怎么会这样解析xml，当时忙也无暇细想。继续测试中又发现另外一个接口出现问题，cx公司的soap请求的xml字段顺序和wsdl文件规定的顺序不一致，造成数据解析出来内容错乱。晕倒，细问才知道cx公司不是按照wsdl来自动生成代码，也不依照wsdl文件的格式要求，而是很奇怪的以协议附件中的soap请求示例为基准（很荒谬的事情，这还是电信级别的软件开发方式，想不通）。偏偏协议在一个接口上wsdl和示例的顺序不一致，造成这个问题。

之后就是非技术的扯皮了，总之cx公司坚持他们的正确性和合理性，非逼我们公司修改服务器端做法。细的不说了，俺们技术人员不懂也不该去关注，黑暗的内幕。由于那个协议的内容是俺修改的（前人离职了），这个出问题的地方就是我陆续修订的，于是责任就压到我身上了，当时那个郁闷啊。写了封邮件准备给领导，将事情说清楚，认错并承认是俺的责任......惨就一个字。就在邮件发出去之后，突然想到，恩，怎么老是按照index解析呢,axis没有这么笨吧？用测试脚本又测试了一下，没有问题，再看soap 报文，惊奇的发现顺序也是有差异的，但是怎么服务器端就能正确解析呢？

灵光一动，想起cx的报文格式来了，他们的格式非常的不规范，简直就粗糙到极点了，当时我们几个研发还说笑，说他们肯定是手工拼凑文本，将 soap/web service退化为http + xml，然后再将xml退化为文本。难道是格式的问题？对照了一下，发现少了<*** xmlns="http://system.chinamobile.com">这里的namespace，试着将cx的报文加上这个 namespace，然后用脚本工具提交测试，服务器端解析ok。

这下问题明朗了，可以发现是这样的规律,axis在解析时发现没有namespace，就按照顺序来解析：

wsdl标准顺序 实际报文顺序 最终解析出来内容
<ServiceCode> <Alias></Alias> --〉 serviceCode=
<Source> <Source>WEB</Source> --〉 source=WEB
<Alias> <ServiceCode>YXZZY</ServiceCode> --〉 alias=YXZZY

于是长出一口气，又赶紧写了封新邮件，解释清楚终于将责任踢给cx了．真是惊险。平时哪里会遇到这样格式不规范的报文，这次长见识了．cx终于不再坚持了，增加了namespace后测试通过，最后赶在移动的时间期限前完成了测试，大家不用互相推责任了。