程序師世界是廣大編程愛好者互助、分享、學習的平台,程序師世界有你更精彩!
首頁
編程語言
C語言|JAVA編程
Python編程
網頁編程
ASP編程|PHP編程
JSP編程
數據庫知識
MYSQL數據庫|SqlServer數據庫
Oracle數據庫|DB2數據庫
 程式師世界 >> 編程語言 >> .NET網頁編程 >> 關於.NET >> Web Services開發體會和在項目中的教訓

Web Services開發體會和在項目中的教訓

編輯:關於.NET

如果有以上需求,我想大家應該都比較認同這種異構分布式解決方案:客戶端用C# .Net開發,通過Web Services調用服務器端Java組件。服務器組件測試一次,起容器特慢,而且客戶端調用也慢。

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

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

  2、最終用戶上報數據,因為網絡原因,譬如Modem上網,可以離線操作,等填寫了幾十張報表後,可以一次提交。同時,在登錄時,可以將服務端數據同步到本地Access或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,所以當時這個問題發現了,也沒法要求別人,畢竟很大的一個團隊。

  切身體會:一個團隊,如果不熟悉Hibernate就隨便上,技術風險非常大。Hibernate帶來的開發效率,是以團隊成員掌握它為前提。

  當然,性能問題不只是由Hibernate引起,Web Services本身的性能也非常嚴重:XML的序列化和反序列化耗時,XML文件的膨脹導致的網絡傳輸,HTTP的無狀態導致網絡IO性能。切身體會:如果系統必須用分布式,而不是追求所謂的SOA架構,Web Services應該是下下策,因為還有很多協議和方式可以選擇:IIOP、RMI、Hessian、burlap、RPC,另外,做系統集成還有Message方式。

  Web Services開發中其它問題比較少,因為Web Services本身不用編程,只是部署的事情,開發工具和服務器會自動為我們做,我們只需要理解SOAP引擎的原理和使用就夠了,真的遇到問題,可以通過Axis的TcpMonitor監視SOAP數據包。

  開發過程中,.Net客戶端那邊,VSStudio做得很智能,它會根據wsdl文件生成我們所要的一切,當然,wsdl文件的變化,會導致VSStudio重新生成所有的類和接口,也很耗時,並且容易出問題。

  三、Web Services的安全問題

  當時解決Web Services安全問題,花了我將近一個月的時間,主要是學習和處理如下四個問題:

  XML和Web Services安全規范

  WAS的 Web Services引擎的安全部署

  Axis和參考的Xfire引擎的Web Services安全

  .Net客戶端WSE3.0的安全以及和WAS的通訊

  最後這些問題基本上都解決了,不過還是沒有用上,因為在我們已經開發的幾種客戶端和服務器端部署上很麻煩,還要測試,另外,客戶也沒法驗收這個啊。

  當然,我們還回避了一個嚴肅的問題:我們的Web Services是發布在Axis引擎上,還沒有移植到WAS的Web Services引擎,而發布在這個平台,必須有RAD這類開發工具支持,幾乎沒法手動做。WAS引擎的Web Services安全配置異常復雜:我們當時只配置了Authentication和Integration,沒有做Encryption,但完全夠用。我當時用Sun的NetBean開發工具發布了一下Web Serivces,也是挺好用的,不過沒有配置安全。順便說一下,Sun的web Services引擎jwsdp2.0設計有點類似於EJB容器,很不好用,移植性特差。

  我們當時用Axis引擎是1.3版本,而該版並不支持標准的OASIS的WS-Security,只有到2.0版才開始,而且幾乎都是手寫配置文件。

  WAS的Web Services安全配置,對照IBM的紅皮書,不是很難,但很復雜,安全相關的XML代碼都好幾百行,好幾個文件。配置過程中,和.net客戶端通訊時遇到一個問題,怎麼也不能互通,但.net和.Net客戶端可以互通,Java和Java客戶端也可以互通,最後我通過攔截soap包,找到了解決辦法: 必須手動更改http://docs.oasis-open.org/wss/2004/01/oasis-200401-wss-x509-token-profile-1.0#X509v3 後的v3,IBM工具生成的是v1,這是標准不兼容引起的,因為當時RAD是04年底,而微軟的WSE3.0比較新。後來發現這篇文章有相似的經歷:http://pluralsight.com/blogs/kirillg/archive/2005/04/13/7315.ASPx

  在處理Web Services安全過程中,我通過emule和IBM網站下載了上10本這方面的書籍,我覺得以下資料對我幫助最大:

  Axis的若干文檔:Reference、developers-guide、architecture-guide等,非常詳細

  IBM的紅皮書:《WebSphere Version 6 Web Services Handbook Development and Deployment.pdf》、《WebSphere Application Server V6 Security Handbook.pdf》,它專門講述了Web Services安全的原理和具體配置,非常深入淺出。

  《Securing Web Services with WS-Security》:這本書很理論化,但我認為非常好,雖然Amazon排行不高。

  WSE3.0的MSDN文檔。

  四、開發過程中的的溝通問題

  這應該不是一個技術問題,而是一個軟件開發方法學的問題,但對整個軟件開發過程影響極大。

  我們面對的現實:.net客戶端開發人員不懂服務器端Java,服務器端Java開發人員不懂.Net。

  除了技術壁壘外,還有業務銜接性的問題,因為我們不是縱向分模塊開發,而橫向開發的前提是我們服務器端開發人員很熟悉業務,知道客戶端需要的接口,但實際上,業務主要由客戶端推動。所以,兩端的開發人員都遇到很大的溝通壁壘。

  從技術的角度表達就是:客戶端開發人員需要的接口,服務器端開發人員不清楚;服務器端開發人員也不知道怎麼把握粒度。譬如,有個updateUser方法,但更新用戶信息時,可能需要更新很多信息:用戶信息、用戶角色、用戶所屬組….。loadUser時也有同樣的按需加載問題。

  當然,從技術角度,開發Web Serivces有Bottom-up和Top-down兩種開發模式。我們選擇了前者,也是最常見的方式,也許用後者更適合我們的項目:從定義的wsdl文件開始,客戶端和服務器端開發都遵循它。但問題是:我們怎麼確定wsdl,也就是我們所要求的接口,因為我們自己對業務都不是很熟。

  五、客戶端和服務端開發測試方法

  我們當時做得很笨,也最直接:等服務器端組件發布完畢後,通知客戶端開發人員,然後客戶端開發人員通過VSStudio提供的Web Services生成工具,根據Axis發布的wsdl文件,生成所需的.Net對象,然後像本地調用一樣使用。

  但問題是:

  wsdl隨時都在變,這意味著客戶端生成的組件總在變化,經常出現編譯錯誤。

  客戶端開發過程中遇到的問題,一會是客戶端自己,一會是服務器端組件:我要的方法包含的信息不夠啊。

  服務器組件測試一次,起容器特慢,而且客戶端調用也慢。

  我們的測試,最後走入了一個怎樣的泥潭:譬如測試一張報表,都是在客戶端手工填寫,然後觀察服務器端日志和響應。有人會問,用LoadRunner或Function Tester這類自動測試工具不就ok了嗎?我都用過,它們對Web UI確實好用,後者對Swing客戶端也好用,但對.Net客戶端,像是不太現實。

  另外,Debug非常困難,因為它要求兩端開發人員必須在一起密切配合。

  我自己認為的解決方案,但未必真的好用:

  服務器端Service方法必須寫單元測試TestCase,可能代碼量非常大,測試好後方發布為Web Services。

  同時,服務器端提供同一套接口的Mock實現,供客戶端開發測試,解決並行開發的問題。

  六、其它問題

  當然,上面的幾點,具體到細節,我都省略了,總之問題非常非常多:技術問題、管理問題、方法和過程問題。

  特別提的一點是,我們幾乎開發了兩套“業務層+持久化”解決方案,因為離線客戶端也用了NHibernate持久化,這樣導致開發測試工作量巨大,就說一點吧:兩邊同步是通過打包的sql語句,通過SOAP傳輸,但Access和DB2的sql有不兼容問題,如果要兼容,就會以犧牲性能和靈活性為代價。

  另外,我們寫項目建議書時很被動,但也沒辦法,因為有好幾家公司競爭。對我們影響極大的幾個問題:

  1、IBM的WAS比起WebLogic Server易用性差遠了,導致部署時極其耗時。而且還有一些bug,譬如連接池資源,當時不得不和IBM工程師咨詢。實際上,我們只用到強大的WAS的一個非常小的部分:Web容器。

  2、我們沒有針對WAS的開發工具RAD。但說實話,那試用版的RAD也是一個字:慢,而且安裝時超級大,約4個G。而且和我們已經在用的版本控制工具VSS沒法集成。

  3、項目的C/S架構不是很合理,就是原來客戶的B/S架構,也運行挺好的,而且用ASP,跑在一個pc server上。我們一定程度上為了技術而技術。最後也達不到客戶需求:性能+穩定。

  4、自定義報表最後沒有投入使用,只是一個半成品。本來自定義報表就很難,要是容易,一個軟件外行人員,就可以把表現層到持久化輕松搞定,那一般MIS開發人員不要失業了,MDA也沒那麼強。很多OA平台一直在解決這個問題,也沒有發現特別好用的。我們做技術調研期間試過MS的InfoPath和Adobe Designer,以及Excel Server,都不能滿足需求。

  當然,這個子系統只是我們那個龐大系統的一個部分。上面也就算我做的一點點總結吧,也是教訓啊!不過,從個人角度考慮,學到的東西還是很多的。

  這個子系統花去了我們將近200個人月,如果說那浪費的部分,估計至少是100個人月的工作量。是什麼導致?從我這篇文章只能窺其一角,因為整個系統涉及CMS、OA、BI、E-commerce、GIS、IM、MIS。我自己總結一下,有以下原因:

  1、項目建議書空洞,不切實際:公司也很無奈,客戶也不成熟。

  2、需求調研後的需求分析閉門造車:客戶的合同是分階段,我們上交需求說明書後付20%款,上交設計書後又付20%。全一個瀑布開發,雖然按RUP文檔寫。到半年後的實際開發時,發現很多需求都不合理。

  3、整個過程都沒有和客戶溝通,到最後開發完畢才讓客戶看,那時客戶也懵了:這不是我要的產品啊。改呀,改呀,熬夜啊。

  4、項目團隊整體技術實力薄弱,當時調來做Java開發的人員,只有少數幾個以前做Java,大多數是臨時學。想起那Hibernate使用,心寒啊。另外,WAS問題、AIX問題在產品環境下都出來了:系統不穩定、宕機。

  5、整個開發階段流程沒有把握好,像項目規范、測試方法、日志、版本控制,這些後期都出現了,而且非常嚴重。就說那日志吧,最後出問題都不知道怎麼查,日志一遍混亂。

  6、缺乏做大項目經驗,整個系統架構都比較松散,項目開始時很多都不知從何入手,也很倉促。

  7、項目持續一年多,人都換了幾批了,工作交接很大問題。

  1. 上一頁:
  2. 下一頁:
Copyright © 程式師世界 All Rights Reserved