WebServices開發(fā)體會和項目教訓

1、去年，在一個大型項目(1500w)中用到Web Services，現(xiàn)在項目進入了尾聲，所以對以前的開發(fā)經(jīng)歷做一個總結(jié)。 我想大家一定會問？為什么你們項目中要用到Web Services，因為客戶有如下需求： 1、客戶要求項目用C/S架構(gòu)，并且服務器端是IBM那一套：WebSphere AppServerDB2AIX5.3RS/6000。 2、最終用戶上報數(shù)據(jù)，因為網(wǎng)絡原因，譬如Modem上網(wǎng)，可以離線操作，等填寫了幾十張報表后，可以一次提交。同時，在登錄時，可以將服務端數(shù)據(jù)同步到本地Access或MSSQL數(shù)據(jù)庫，這樣提高客戶端響應速度。 3、由于有些報

2、表以后可能需要修改，或添加一些新報表，又不想重新開發(fā)，這樣客戶那邊工作人員可以通過客戶端自定義。 如果有以上需求，我想大家應該都比較認同這種異構(gòu)分布式解決方案：客戶端用C# .Net開發(fā)，通過Web Services調(diào)用服務器端Java組件。 其實，上面的解決方案太過于理想，最后我們不得不面對殘酷的現(xiàn)實：三種客戶端中的兩種最后被迫改為B/S。 在項目中，我主要負責Web Services和服務器端組件開發(fā)中所遇到的種種問題，相當于技術(shù)支持吧，以及部分模塊的開發(fā)。 以下是我們開發(fā)中遇到的實際問題，雖然最終都一一解決，但遇到了幾個無法突破的瓶頸：客戶端不穩(wěn)定

3、，客戶端響應遲緩，后期測試和維護困難巨大。 一、異構(gòu)平臺的Web Services兼容性 開發(fā)過程中，我們用Axis做Web Services引擎，Tomcat做容器。因為我們只有IBM提供的RAD6.0的60天試用版。該工具超級占內(nèi)存，用內(nèi)置的WebSphere開發(fā)測試極其緩慢，嚴重影響開發(fā)效率，經(jīng)過我初期試用后，基本廢棄了。推薦項目組二三十開發(fā)人員用Lomboz eclipse3.12開發(fā)，基本滿意。 由于Axis是一個嵌入式引擎，所以可以將其打包到最終的WebSphere AppServer（WAS）上，也就是說，我們沒有用到WAS提供的Web Servic

4、es引擎，這引出了后面會談到的一個問題：Web Services安全性怎么部署？ 用Axis時，Axis一直都有一個bug或是說缺陷，官方文檔也詳細注明，只是我們當時沒有發(fā)現(xiàn)而走了很多彎路：用Axis發(fā)布的Web Services給.net客戶端調(diào)用時，必須用RPC風格，不能用Web Services標準的跨平臺風格Document，而后者是Lomboz axis插件的默認方式。也就是說，我們發(fā)布的Web Services總是莫名其妙的不好用。我們用JBuilder2007自帶的Axis插件發(fā)布，竟然非常順利。 二、Web Services開發(fā)中服務器端組件問題 

5、我們服務器端開發(fā)，是用SpringHibernate，在Spring的Service層上再封裝一層，也就是façade模式了，該façade直接發(fā)布為Web Services，必須經(jīng)過這個轉(zhuǎn)換，一是因為性能，二是因為Hibernate的復雜Model對象，在wsdl描述后，被.net客戶端識別有些問題，List、Map也會有問題，總之這些對象太復雜了，我們包裝成簡單的VO對象。 另外一個問題是，我們的service方法，如果直接給WebWork這樣的框架在服務端用的的話，是不會出問題，當提供給.net客戶端用時，就會出現(xiàn)lazy loading的錯誤，因為.net

6、客戶端不能接收Proxy對象，必須將數(shù)據(jù)全部load出來，但這時Hibernate的session已經(jīng)關(guān)閉。項目組很多人遇到這些問題，最后大家不約而同的全部用eager模式，導致了最后的惡果：嚴重的的性能問題。由于我不是leader，所以當時這個問題發(fā)現(xiàn)了，也沒法要求別人，畢竟很大的一個團隊。 切身體會：一個團隊，如果不熟悉Hibernate就隨便上，技術(shù)風險非常大。Hibernate帶來的開發(fā)效率，是以團隊成員掌握它為前提。 當然，性能問題不只是由Hibernate引起，Web Services本身的性能也非常嚴重：XML的序列化和反序列化耗時，XML文件的膨脹導致的網(wǎng)絡

7、傳輸，HTTP的無狀態(tài)導致網(wǎng)絡IO性能。切身體會：如果系統(tǒng)必須用分布式，而不是追求所謂的SOA架構(gòu)，Web Services應該是下下策，因為還有很多協(xié)議和方式可以選擇：IIOP、RMI、Hessian、burlap、RPC，另外，做系統(tǒng)集成還有Message方式。 Web Services開發(fā)中其它問題比較少，因為Web Services本身不用編程，只是部署的事情，開發(fā)工具和服務器會自動為我們做，我們只需要理解SOAP引擎的原理和使用就夠了，真的遇到問題，可以通過Axis的TcpMonitor監(jiān)視SOAP數(shù)據(jù)包。 開發(fā)過程中，.net客戶端那邊，VSStudio做得很智

8、能，它會根據(jù)wsdl文件生成我們所要的一切，當然，wsdl文件的變化，會導致VSStudio重新生成所有的類和接口，也很耗時，并且容易出問題。 三、Web Services的安全問題 當時解決Web Services安全問題，花了我將近一個月的時間，主要是學習和處理如下四個問題： XML和Web Services安全規(guī)范 WAS的 Web Services引擎的安全部署 Axis和參考的Xfire引擎的Web Services安全 .net客戶端WSE3.0的安全以及和WAS的通訊 最后這些問題基本上都解決了，不過還是沒有用

9、上，因為在我們已經(jīng)開發(fā)的幾種客戶端和服務器端部署上很麻煩，還要測試，另外，客戶也沒法驗收這個啊。 當然，我們還回避了一個嚴肅的問題：我們的Web Services是發(fā)布在Axis引擎上，還沒有移植到WAS的Web Services引擎，而發(fā)布在這個平臺，必須有RAD這類開發(fā)工具支持，幾乎沒法手動做。WAS引擎的Web Services安全配置異常復雜：我們當時只配置了Authentication和Integration，沒有做Encryption，但完全夠用。我當時用Sun的NetBean開發(fā)工具發(fā)布了一下Web Serivces，也是挺好用的，不過沒有配置安全。順便說一下，Sun的

10、web Services引擎jwsdp2.0設計有點類似于EJB容器，很不好用，移植性特差。 我們當時用Axis引擎是1.3版本，而該版并不支持標準的OASIS的WS-Security，只有到2.0版才開始，而且?guī)缀醵际鞘謱懪渲梦募?#160;WAS的Web Services安全配置，對照IBM的紅皮書，不是很難，但很復雜，安全相關(guān)的xml代碼都好幾百行，好幾個文件。配置過程中，和.net客戶端通訊時遇到一個問題，怎么也不能互通，但.net和.net客戶端可以互通，Java和Java客戶端也可以互通,最后我通過攔截soap包,找到了解決辦法: 必須手動更改 后的v3，IBM工具生成

11、的是v1，這是標準不兼容引起的，因為當時RAD是04年底,而微軟的WSE3.0比較新。后來發(fā)現(xiàn)這篇文章有相似的經(jīng)歷：url2005/04/13/7315.aspx /url 在處理Web Services安全過程中，我通過emule和IBM網(wǎng)站下載了上10本這方面的書籍，我覺得以下資料對我?guī)椭畲螅?#160;Axis的若干文檔：Reference、developers-guide、architecture-guide等，非常詳細 IBM的紅皮書：WebSphere Version 6 Web Services Handbook Development and Deploy

12、ment.pdf、WebSphere Application Server V6 Security Handbook.pdf，它專門講述了Web Services安全的原理和具體配置，非常深入淺出。 Securing Web Services with WS-Security：這本書很理論化，但我認為非常好，雖然Amazon排行不高。 WSE3.0的MSDN文檔。四、開發(fā)過程中的的溝通問題 這應該不是一個技術(shù)問題，而是一個軟件開發(fā)方法學的問題，但對整個軟件開發(fā)過程影響極大。 我們面對的現(xiàn)實：.net客戶端開發(fā)人員不懂服務器端Java，服務器端Java開發(fā)

13、人員不懂.net。 除了技術(shù)壁壘外，還有業(yè)務銜接性的問題，因為我們不是縱向分模塊開發(fā)，而橫向開發(fā)的前提是我們服務器端開發(fā)人員很熟悉業(yè)務，知道客戶端需要的接口，但實際上，業(yè)務主要由客戶端推動。所以，兩端的開發(fā)人員都遇到很大的溝通壁壘。 從技術(shù)的角度表達就是：客戶端開發(fā)人員需要的接口，服務器端開發(fā)人員不清楚；服務器端開發(fā)人員也不知道怎么把握粒度。譬如，有個updateUser方法，但更新用戶信息時，可能需要更新很多信息：用戶信息、用戶角色、用戶所屬組.。loadUser時也有同樣的按需加載問題。 當然，從技術(shù)角度，開發(fā)Web Serivces有Bottom-up和To

14、p-down兩種開發(fā)模式。我們選擇了前者，也是最常見的方式，也許用后者更適合我們的項目：從定義的wsdl文件開始，客戶端和服務器端開發(fā)都遵循它。但問題是：我們怎么確定wsdl，也就是我們所要求的接口，因為我們自己對業(yè)務都不是很熟。 五、客戶端和服務端開發(fā)測試方法 我們當時做得很笨，也最直接：等服務器端組件發(fā)布完畢后，通知客戶端開發(fā)人員，然后客戶端開發(fā)人員通過VSStudio提供的Web Services生成工具，根據(jù)Axis發(fā)布的wsdl文件，生成所需的.net對象，然后像本地調(diào)用一樣使用。 但問題是： wsdl隨時都在變，這意味著客戶端生成的組件總在變

15、化，經(jīng)常出現(xiàn)編譯錯誤。 客戶端開發(fā)過程中遇到的問題，一會是客戶端自己，一會是服務器端組件：我要的方法包含的信息不夠啊。 服務器組件測試一次，起容器特慢，而且客戶端調(diào)用也慢。 我們的測試，最后走入了一個怎樣的泥潭：譬如測試一張報表，都是在客戶端手工填寫，然后觀察服務器端日志和響應。有人會問，用LoadRunner或Function Tester這類自動測試工具不就ok了嗎？我都用過，它們對Web UI確實好用，后者對Swing客戶端也好用，但對.net客戶端，像是不太現(xiàn)實。 另外，Debug非常困難，因為它要求兩端開發(fā)人員必須在一起密切配合。 我

16、自己認為的解決方案，但未必真的好用： 服務器端Service方法必須寫單元測試TestCase，可能代碼量非常大，測試好后方發(fā)布為Web Services。 同時，服務器端提供同一套接口的Mock實現(xiàn)，供客戶端開發(fā)測試，解決并行開發(fā)的問題。 六、其它問題 當然，上面的幾點，具體到細節(jié)，我都省略了，總之問題非常非常多：技術(shù)問題、管理問題、方法和過程問題。 特別提的一點是，我們幾乎開發(fā)了兩套“業(yè)務層持久化”解決方案，因為離線客戶端也用了NHibernate持久化，這樣導致開發(fā)測試工作量巨大，就說一點吧:兩邊同步是通過打包的sql語句，通過SOAP傳

17、輸，但Access和DB2的sql有不兼容問題，如果要兼容，就會以犧牲性能和靈活性為代價。 另外，我們寫項目建議書時很被動，但也沒辦法，因為有好幾家公司競爭。對我們影響極大的幾個問題： 1、IBM的WAS比起WebLogic Server易用性差遠了，導致部署時極其耗時。而且還有一些bug，譬如連接池資源，當時不得不和IBM工程師咨詢。實際上，我們只用到強大的WAS的一個非常小的部分：Web容器。 2、我們沒有針對WAS的開發(fā)工具RAD。但說實話，那試用版的RAD也是一個字：慢，而且安裝時超級大，約4個G。而且和我們已經(jīng)在用的版本控制工具VSS沒法集成。 

18、;3、項目的C/S架構(gòu)不是很合理，就是原來客戶的B/S架構(gòu)，也運行挺好的，而且用asp，跑在一個pc server上。我們一定程度上為了技術(shù)而技術(shù)。最后也達不到客戶需求：性能穩(wěn)定。 4、自定義報表最后沒有投入使用，只是一個半成品。本來自定義報表就很難，要是容易，一個軟件外行人員，就可以把表現(xiàn)層到持久化輕松搞定，那一般MIS開發(fā)人員不要失業(yè)了，MDA也沒那么強。很多OA平臺一直在解決這個問題，也沒有發(fā)現(xiàn)特別好用的。我們做技術(shù)調(diào)研期間試過MS的InfoPath和Adobe Designer，以及Excel Server，都不能滿足需求。當然，這個子系統(tǒng)只是我們那個龐大系統(tǒng)的一個部分。上面也就算我做的一點點總結(jié)吧，也是教訓啊！不過，從個人角度考慮，學到的東西還是很多的。 這個子系統(tǒng)花去了我們將近200個人月，如果說那浪費的部分，估計至少是100個人月的工作量。是什么導致？從我這篇文章只能窺其一角，因為整個系