Sky's blog

我和我追逐的梦

常用链接

统计

其他链接

友情链接

最新评论

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后测试通过,最后赶在移动的时间期限前完成了测试,大家不用互相推责任了。

posted on 2007-12-05 16:49 sky ao 阅读(4415) 评论(8)  编辑  收藏 所属分类: web

评论

# re: namespace对axis解析xml请求的影响 2007-12-05 18:19 专注java开源

:)  回复  更多评论   

# re: namespace对axis解析xml请求的影响 2007-12-06 08:16 pig

有趣有趣,不过还是要问下是axis1还是axis2呢?多谢博主  回复  更多评论   

# re: namespace对axis解析xml请求的影响[未登录] 2007-12-06 16:04 cerulean

很有启发~~
也想问一下是axis1还是axis2?  回复  更多评论   

# re: namespace对axis解析xml请求的影响 2008-10-10 11:38 顺序没关系吧



我们都不安WSDL 生成代码`` 都用报文 直接拼  回复  更多评论   

# re: namespace对axis解析xml请求的影响 2009-05-30 14:58 郑永明

学习
真在用axis2写服务  回复  更多评论   

# re: namespace对axis解析xml请求的影响 2009-08-19 20:42 xxwinnie

不明白啊~ 为什么要手动拼呢?
不过我现在用的是自动生成,结果出现namespace不匹配。
我用的是axis2,想实现UDDI v3的标准~  回复  更多评论   

# re: namespace对axis解析xml请求的影响 2009-08-19 21:32 sky ao

为什么要手动拼呢?

这个问题要问cx这个伟大的公司了,上面的回复你都看到了,"我们都不安WSDL 生成代码`` 都用报文 直接拼",他们就喜欢这样做,有什么办法?

我做服务器端,他们做客户端,他们就是喜欢这么来,还动不动就拿势力压人。无耻之极,完全没有做技术的人和公司应该有的那种认真和严谨。

虽然事情过去2年了,但是依然记忆犹新,呵呵,基本不对国内电信相关的技术公司抱什么希望了,基本都是乱来。  回复  更多评论   

# re: namespace对axis解析xml请求的影响 2013-11-27 10:44 11

这垃圾肯定是华为的吧,,哈哈  回复  更多评论   


只有注册用户登录后才能发表评论。


网站导航: