發(fā)生在我身上的實際故事，最后發(fā)現(xiàn)和axis解析xml時的處理機制有關(guān)，namespace的有無會影響xml解析的方式，簡單的說就是有namespace按照元素名解析，沒有namespace則按照index下標(biāo)的順序來解析。
中間驚險，一一道來，做技術(shù)的不容易啊。
這個市公司的一個大項目，使用web service，我負責(zé)服務(wù)器端的開發(fā)，其他廠商開發(fā)客戶端。好說，axis上，幾個月下來，設(shè)計/開發(fā)/測試一路ok，就進移動研究院準(zhǔn)備最后的入網(wǎng)測試了。
和我們一起聯(lián)合測試的cx公司，報告說發(fā)現(xiàn)錯誤，經(jīng)查找是服務(wù)器端解析他們發(fā)過來的請求失敗，出現(xiàn)異常java.lang.NumberFormatException。非常郁悶，按說不大可能，代碼是從wsdl文件自動生成的，怎么可能出這種低級錯誤，而且我們自己反復(fù)測試都通過。于是想辦法抓包，發(fā)現(xiàn)他們的報文如下：
<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>
格式怪怪的，對照標(biāo)準(zhǔn)的報文：
<?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>
發(fā)現(xiàn)他們的請求多了一個 <Version>0100</Version>字段，試著去掉，解析就通過了。于是通知cx公司修改，同時提示他們說他們的格式不夠標(biāo)準(zhǔn)，xsd的namespace很多都沒有寫。當(dāng)時就奇怪，從現(xiàn)象看似乎axis是按照index/下標(biāo)順序來解析xml,因為多了一個version,因此后面的字段都順推了一位,造成用"WEBMAIL"的值來作為LocalZone解析，而localzone是int類型，所以解析失敗，出現(xiàn)異常：java.lang.NumberFormatException.
有些奇怪axis怎么會這樣解析xml，當(dāng)時忙也無暇細想。繼續(xù)測試中又發(fā)現(xiàn)另外一個接口出現(xiàn)問題，cx公司的soap請求的xml字段順序和wsdl文件規(guī)定的順序不一致，造成數(shù)據(jù)解析出來內(nèi)容錯亂。暈倒，細問才知道cx公司不是按照wsdl來自動生成代碼，也不依照wsdl文件的格式要求，而是很奇怪的以協(xié)議附件中的soap請求示例為基準(zhǔn)（很荒謬的事情，這還是電信級別的軟件開發(fā)方式，想不通）。偏偏協(xié)議在一個接口上wsdl和示例的順序不一致，造成這個問題。
之后就是非技術(shù)的扯皮了，總之cx公司堅持他們的正確性和合理性，非逼我們公司修改服務(wù)器端做法。細的不說了，俺們技術(shù)人員不懂也不該去關(guān)注，黑暗的內(nèi)幕。由于那個協(xié)議的內(nèi)容是俺修改的（前人離職了），這個出問題的地方就是我陸續(xù)修訂的，于是責(zé)任就壓到我身上了，當(dāng)時那個郁悶啊。寫了封郵件準(zhǔn)備給領(lǐng)導(dǎo)，將事情說清楚，認錯并承認是俺的責(zé)任......慘就一個字。就在郵件發(fā)出去之后，突然想到，恩，怎么老是按照index解析呢,axis沒有這么笨吧？用測試腳本又測試了一下，沒有問題，再看soap 報文，驚奇的發(fā)現(xiàn)順序也是有差異的，但是怎么服務(wù)器端就能正確解析呢？
靈光一動，想起cx的報文格式來了，他們的格式非常的不規(guī)范，簡直就粗糙到極點了，當(dāng)時我們幾個研發(fā)還說笑，說他們肯定是手工拼湊文本，將soap/web service退化為http + xml，然后再將xml退化為文本。難道是格式的問題？對照了一下，發(fā)現(xiàn)少了<*** xmlns="http://system.chinamobile.com">這里的namespace，試著將cx的報文加上這個namespace，然后用腳本工具提交測試，服務(wù)器端解析ok。
這下問題明朗了，可以發(fā)現(xiàn)是這樣的規(guī)律,axis在解析時發(fā)現(xiàn)沒有namespace，就按照順序來解析：
wsdl標(biāo)準(zhǔn)順序 實際報文順序 最終解析出來內(nèi)容
<ServiceCode> <Alias></Alias> --〉 serviceCode=
<Source> <Source>WEB</Source> --〉 source=WEB
<Alias> <ServiceCode>YXZZY</ServiceCode> --〉 alias=YXZZY
于是長出一口氣，又趕緊寫了封新郵件，解釋清楚終于將責(zé)任踢給cx了．真是驚險。平時哪里會遇到這樣格式不規(guī)范的報文，這次長見識了．cx終于不再堅持了，增加了namespace后測試通過，最后趕在移動的時間期限前完成了測試，大家不用互相推責(zé)任了。