namespace對axis解析xml請求的影響

發生在我身上的實際故事，最後發現和axis解析xml時的處理機制有關，namespace的有無會影響xml解析的方式，簡單的說就是有namespace按照元素名解析，沒有namespace則按照index下標的順序來解析。

中間驚險，一一道來，做技術的不容易啊。

這個市公司的一個大專案，使用web service，我負責伺服器端的開發，其他廠商開發客戶端。好說，axis上，幾個月下來，設計/開發/測試一路ok，就進移動研究院準備最後的入網測試了。
和我們一起聯合測試的cx公司，報告說發現錯誤，經查詢是伺服器端解析他們發過來的請求失敗，出現異常java.lang.NumberFormatException。非常鬱悶，按說不大可能，程式碼是從wsdl檔案自動生成的，怎麼可能出這種低階錯誤，而且我們自己反覆測試都透過。於是想辦法抓包，發現他們的報文如下：

'>

格式怪怪的，對照標準的報文：

D0001
13660000001
MDN
WEBMAIL
0
0
SUPER

發現他們的請求多了一個 0100欄位，試著去掉，解析就透過了。於是通知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退化為文字。難道是格式的問題？對照了一下，發現少了這裡的namespace，試著將cx的報文加上這個namespace，然後用指令碼工具提交測試，伺服器端解析ok" target="_blank" rel="nofollow">">這裡的namespace，試著將cx的報文加上這個namespace，然後用指令碼工具提交測試，伺服器端解析ok。

這下問題明朗了，可以發現是這樣的規律,axis在解析時發現沒有namespace，就按照順序來解析：

wsdl標準順序 實際報文順序 最終解析出來內容
--〉 serviceCode=
WEB<source> --〉 source=WEB
YXZZY --〉 alias=YXZZY<source>

於是長出一口氣，又趕緊寫了封新郵件，解釋清楚終於將責任踢給cx了．真是驚險。平時哪裡會遇到這樣格式不規範的報文，這次長見識了．cx終於不再堅持了，增加了namespace後測試透過，最後趕在移動的時間期限前完成了測試，大家不用互相推責任了。
亂來害死人