發生在我身上的實際故事，最后發現和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后測試通過，最后趕在移動的時間期限前完成了測試，大家不用互相推責任了。