WebServices開發(fā)體會(huì)和項(xiàng)目教訓(xùn)

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

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

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

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

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

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

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

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

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

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

11、的是v1，這是標(biāo)準(zhǔn)不兼容引起的，因?yàn)楫?dāng)時(shí)RAD是04年底,而微軟的WSE3.0比較新。后來發(fā)現(xiàn)這篇文章有相似的經(jīng)歷：url2005/04/13/7315.aspx /url 在處理Web Services安全過程中，我通過emule和IBM網(wǎng)站下載了上10本這方面的書籍，我覺得以下資料對(duì)我?guī)椭畲螅?#160;Axis的若干文檔：Reference、developers-guide、architecture-guide等，非常詳細(xì) 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：這本書很理論化，但我認(rèn)為非常好，雖然Amazon排行不高。 WSE3.0的MSDN文檔。四、開發(fā)過程中的的溝通問題 這應(yīng)該不是一個(gè)技術(shù)問題，而是一個(gè)軟件開發(fā)方法學(xué)的問題，但對(duì)整個(gè)軟件開發(fā)過程影響極大。 我們面對(duì)的現(xiàn)實(shí)：.net客戶端開發(fā)人員不懂服務(wù)器端Java，服務(wù)器端Java開發(fā)

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

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

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

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

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

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