namespace对axis解析xml请求的影响

    发生在我身上的实际故事，最后发现和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后测试通过，最后赶在移动的时间期限前完成了测试，大家不用互相推责任了。

精彩!长见识了!谢谢楼主的分享!soap消息的格式规范很重要啊!

呵呵，难得你把这么久的帖子顶出来。

上面的故事，技术方面的东西没有什么，但是整个事情的过程比较有意思。这个项目详细的俺不好透露，但是这个真的是移动总的大东东，结果可以看到cx公司是用什么方式在开发/测试web service。简直令人发指......

经历了这些，才真正明白，为什么在中国技术人员想创业成功那么难，做技术的在公司地位那么低。

那个cx公司的开发人员真够.....,想不通一个webservice客户端有这么纠缠人的吗，客户端自动生成，请求发送都不需要干涉报文，而且他们自己没有遵循标准。同情楼主，跟这些人共事。

不算共事吧，其实他们和我们公司是竞争对手，最大的竞争对手。所以处处为难，动不动就利用他们在移动总的关系压我们，呵呵。这次的事情如果不是我最后发现是namespace的问题，那么极有可能对方又将责任压到我们公司头上，你可以想像我当时写那封承认是我工作失误的邮件时要承受多大的压力，

至于他们怎么会会把一个简单的web service搞的那么复杂，倒是远出乎我的意料。web service/soap就今天而言，早就是烂街了的技术，绝对不算新技术或者高难技术，至于搞的那么复杂吗？将soap退化为http + xml，然后将xml退化为text文本，再用代码手工拼接text，这个开发方式也太原始了

这还算好呀，我们也是这样。。
cx公司很多的都是别的公司的外包人员在搞，水平参差，思想也不一样，好在最后解决了。