很老的文章了，不知道有人貼過沒有：Web服務發展中的一些問題

web|web服務|問題 Web服務發展中的一些問題


日期: 2001年10月10日    

  
以前從來沒有產生過如此激動人心的協議. 但是僅僅是不停的念叨諸如SOAP, WSDL, 和UDDI--定義Web 服務的三種協議--之類的縮減語並不能讓組件軟體結構和通用的XML整合的想法成為現實. 要使Web服務開始工作, 與之相關的協議必須被重新定義, 相應的開發工具也必須被發布出來, 而IT經理和開發人員中必須來一場文化革命.

特別是微軟和IBM在交流Web服務所能帶來的好處方面發揮了另人驚訝的卓有成效的作用--可重用的軟體組件, 企業間容易的整合過程, 等等. 雖然實際的Web服務的實現還處在實驗階段,新聞界已經使這些高層的概念深入人心. 作為反對人物的開發人員卻有不同的看法. 對於Web服務, 他們有很多不滿的地方.

下面是開發人員對於Web 服務的通常的一些反對意見. 其中的一些已經得到了很好的解決但是也有一些沒有:

安全和認證. 在對Web 服務的所有反對意見中, 這兩點最先出現而且出現得最多. 幸運的是, 當你在處理敏感的資料的時候, SSL, 這種老的Web 解決方案, 能夠很好的避免XML訊息被截獲. 但是在伺服器上認證XML 檔案是另外一回事. 有不下十種的認證方案--它們分別由不同的標準委員會提出--希望能夠通過數位簽章和類似的技術來解決這個問題, 但這些標準要穩定下來尚需時日.

事務完成. 當多個交易方同時交易的時候--就象在一個供貨鏈中發生的那樣--事務的處理過程是長時間的, 而且會很複雜. 必須找到一種方法來監視複雜的事務以便處理過程的每一個部分都被標識出來. 有幾種不同的標準, 包括安全的斷言標記語言(Secure Assertion Markup Language), 商業事務協議, 和IBM公司的可靠HTTP, 致力於解決這個問題, 但是各標準化協會還沒有同意其中的任何一個.

效能. 對於這個問題壓根就沒有好答案. 基於HTTP的XML 根本就不是高效能的解決方案. 而且如果使用處於;這些協議頂端的安全性通訊協定, 那麼使用者想要伺服器對一個特定的動作很快的作出響應是不可能的--比方說信用卡的驗證--高延時的問題會使Web 服務在一段時間內被限制在企業內的工程和自動的B2B交易處理項目裡.

增加的依靠性. 如果多個應用程式是基於同一個Web 服務, 對這個Web服務的改變可能使多個應用程式發生錯誤. 相似的, 個別的Web 服務的大量使用必須被小心的監視起來, 確保相應的硬體被正確的升級. 就象任何的組件架構一樣, Web 服務組件必須為通用的用途者開發, 也就是說程式員必須估計出許多應用都要用的功能.

容量和可靠性. Web 連線比已經比以前更加可靠了, 但是當你調用防火牆外的組件的時候, 你必須忍受更低的上行速度. 你還不得不信任通過XML API訪問的組件, 把它們完全看作是黑盒子. 在公司之間必須建立起老套的信任關係, 然後才可以接受使用其它人的Web 服務的風險.

額外的開發工作. 系個人都希望以正確的方式開發應用程式: 完整的開發文檔, 時時想著代碼最大程度的被重用. 但是在現實世界裡, 項目必須在確定的時間完成並且有一定的經費限制. 第一次從Web服務元件建立應用程式會需要額外的工作和時間. 不管怎樣, 許多IT 經理不想僅僅為了獲得以後才能實現的代碼重用的好處而使項目拖下去. 因為同樣的原因, 一個IT 經理將能夠正常工作的應用程式"組件化"的可能性也是非常小的, 即使將它們分割成Web 服務組件能為其它的應用帶來好處.

但是沒有一個困難能真正擋住它的腳步. 實際上, 我所訪問過的開發人員都同意Web 服務發展的大方向而且許多還正在為實驗性的程式工作.

由於對Web 服務所需的時間和工作量有了更現實的估計--以及對Web 服務的限制的更清晰的理解--也許這種很有前途的技術不會象許多其它的技術那樣遭受過高的期待.