Web Services開發體會和項目教訓

　　Web Services開發體會和項目教訓  軟件測試

　　去年，在一個大型項目(1500w)中用到Web Services，現在項目進入了尾聲，所以對以前的開發經歷做一個總結。

　　我想大家一定會問?為什么你們項目中要用到Web Services，因為客戶有如下需求：

　　1、客戶要求項目用C/S架構，并且服務器端是IBM那一套：WebSphere AppServer+DB2+AIX5.3+RS/6000。

　　2、最終用戶上報數據，因為網絡原因，譬如Modem上網，可以離線操作，等填寫了幾十張報表后，可以一次提交。同時，在登錄時，可以將服務端數據同步到本地Aclearcase/" target="_blank" >ccess或MSSQL數據庫，這樣提高客戶端響應速度。

　　3、由于有些報表以后可能需要修改，或添加一些新報表，又不想重新開發，這樣客戶那邊工作人員可以通過客戶端自定義。

　　如果有以上需求，我想大家應該都比較認同這種異構分布式解決方案：客戶端用C# .Net開發，通過Web Services調用服務器端Java組件。

　　其實，上面的解決方案太過于理想，最后我們不得不面對殘酷的現實：三種客戶端中的兩種最后被迫改為B/S。

　　在項目中，我主要負責Web Services和服務器端組件開發中所遇到的種種問題，相當于技術支持吧，以及部分模塊的開發。

　　以下是我們開發中遇到的實際問題，雖然最終都一一解決，但遇到了幾個無法突破的瓶頸：客戶端不穩定，客戶端響應遲緩，后期測試和維護困難巨大。

　　一、異構平臺的Web Services兼容性

　　開發過程中，我們用Axis做Web Services引擎，Tomcat做容器。因為我們只有IBM提供的RAD6.0的60天試用版。該工具超級占內存，用內置的WebSphere開發測試極其緩慢，嚴重影響開發效率，經過我初期試用后，基本廢棄了。推薦項目組二三十開發人員用Lomboz eclipse3.12開發，基本滿意。

　　由于Axis是一個嵌入式引擎，所以可以將其打包到最終的WebSphere AppServer(WAS)上，也就是說，我們沒有用到WAS提供的Web Services引擎，這引出了后面會談到的一個問題：Web Services安全性怎么部署?

　　用Axis時，Axis一直都有一個bug或是說缺陷，官方文檔也詳細注明，只是我們當時沒有發現而走了很多彎路：用Axis發布的Web Services給.net客戶端調用時，必須用RPC風格，不能用Web Services標準的跨平臺風格Document，而后者是Lomboz axis插件的默認方式。也就是說，我們發布的Web Services總是莫名其妙的不好用。我們用JBuilder2007自帶的Axis插件發布，竟然非常順利。

　　二、Web Services開發中服務器端組件問題

　　我們服務器端開發，是用Spring+Hibernate，在Spring的Service層上再封裝一層，也就是façade模式了，該façade直接發布為Web Services，必須經過這個轉換，一是因為性能，二是因為Hibernate的復雜Model對象，在wsdl描述后，被.net客戶端識別有些問題，List、Map也會有問題，總之這些對象太復雜了，我們包裝成簡單的VO對象。

　　另外一個問題是，我們的service方法，如果直接給WebWork這樣的框架在服務端用的的話，是不會出問題，當提供給.net客戶端用時，就會出現lazy loading的錯誤，因為.net客戶端不能接收Proxy對象，必須將數據全部load出來，但這時Hibernate的session已經關閉。項目組很多人遇到這些問題，最后大家不約而同的全部用eager模式，導致了最后的惡果：嚴重的的性能問題。由于我不是leader，所以當時這個問題發現了，也沒法要求別人，畢竟很大的一個團隊。

原文轉自：http://www.kjueaiud.com