??????????????????????????????????????????????????????? ?Web Services帶來了什么
???????????????????????????????????????????????????????????????????????????????????????????????作者：王昱

摘要：本文介紹了 Web Services 的起源和基本原理，分析了在企業應用中 Web Services 帶來的沖擊和變革，指出了 Web Services 的一些優缺點以及如何正確地應用 Web Services.

無論是在計算機雜志還是在 Internet 上，目前最熱門的話題莫過于“ Web Services” 。各個平臺之間的鋒爭，各個新產品的發布，眾多新標準的制訂，大都和 Web Services 有關。

我的一些朋友是這樣的一些人，他們總是用著最新的平臺，嘗試著最新的技術，他們喜歡變化，喜歡流行，用他們自己的話說，新技術創造新生活！可是，當我的一個朋友，帶領他們一個部門的開發人員，花了兩個月的，將他們內部的管理系統用 Web Services 重新設計和實現了一遍，卻發現在實際使用的情況下，系統性能非常糟糕。他提出了這樣一個問題：是不是 Web Services 現在還處于實驗和市場炒作時期，根本沒有進入實用的階段？簡單的回答是： Web Services 不是萬能的，它有它的應用范圍和優勢劣勢。

Web Services 的起源

Web 應用的巨大成功和不斷發展，使其滲透到商業領域和個人生活的各個方面。人們只要使用瀏覽器，就可以享受到各種各樣的 Web 服務，例如網上購物，網上交易，網絡游戲，預定車票，網上聊天和交友等等。與此同時，由于 Web 技術所帶來的優勢（統一的客戶端和較好的維護性），使一些傳統的應用紛紛轉型到 BS 結構上。

然而，在發展中，逐步暴露了一些問題。所有這些 Web 頁面都是為人準備的，是讓人去閱讀，去輸入，去判斷。因此各種反映視覺效果的內容占用了大量的網絡帶寬，例如各種圖片，字體信息，文字排版樣式等。而真正含有高價值的一些信息，被深深埋在這些顯示信息中，很難被其他應用和程序所使用。更重要的是，各種 web 服務之間缺少交互和通訊的機制。

程序之間的互相通訊很重要嗎？簡單舉一個例子。

假設你經常去國外出差，在你回國以后，第一件事就是費用報銷了。而你們公司有這樣的財務規定，所有的報銷款，都按報銷當天的外匯比價進行結算。因此在你填寫報銷單的時候必須先填寫每一筆在各個國家的花消，然后上網查出當天的外匯比價，填寫到報銷單上。剩下的事情也許不用你做了，你的報銷單填寫工具會自動進行換算和統計。

覺得有什么不妥嗎？作為 IT 公司的員工，也許都有一個特點，計算機能做的事情，盡量要計算機去做。外匯比價的查詢可以讓計算機自動去做嘛！然而，讓你的程序自動去網頁上查找指定的外匯比價可不是一件容易的事。因為這些網頁是給人閱讀的，人眼和大腦的反應速度有多快，它們可以從一整頁信息中快速定位到你所要的內容，而且無論網頁怎樣變化和改版都不會帶來太大的影響。而應用程序想要做同樣的事就差得太遠了。因此，現在需要的是專門為應用程序制定的 Web 服務。

隨著應用程序之間通訊的需求越來越大，這就需要制定統一的標準和協議。 HP 公司是最先提出這個觀點的公司，他們制定了有關“ e-Speak” 的標準來保證應用程序之間的交互，并聲稱將成為下一代 Internet 信息交互的標準。而隨后， MicroSoft 意識到此計劃的美好前景，便推出了 .Net 戰略； IBM 很快就發布了 Web Services Toolkit(WSTK) ，和 Web Services Development Environment(WSDE) ，申明對 Web Services 的全力支持。與此同時， Oracle 也開發出自己的 Dynamic Services ，并和 Oracle 8i Release 2 集成在一起。在這以后， W3C 統一制定了 Web Services 的各種標準。而 SUN 公司在宣布了自己的 Web Services 的框架以后，將 Web Services 的標準溶入 J2EE 的環境，使 Web Services 有了廣泛支持的基礎和平臺。

Web Services 的基本原理

Web Services 是通過一系列標準和協議來保證程序之間的動態連接。其中最基本的協議包括： SOAP, WSDL, UDDI

• SOAP: 是“ Simple Object Access Protocol” 的縮寫， SOAP 是消息傳遞的協議，它規定了 Web Services 之間是怎樣傳遞信息的。簡單的說， SOAP 規定了：
  1. 傳遞信息的格式為 XML 。這就使 Web Services 能夠在任何平臺上，用任何語言進行實現。
  2. 遠程對象方法調用的格式。規定了怎樣表示被調用對象以及調用的方法名稱和參數類型等。
  3. 參數類型和 XML 格式之間的映射。這是因為，被調用的方法有時候需要傳遞一個復雜的參數，例如，一個 Person 對象。怎樣用 XML 來表示一個對象參數，也是 SOAP 所定義的范圍。
  4. 異常處理以及其他的相關信息 .

• WSDL: 是“ Web Services Description Language” 的縮寫 . 意如其名 ,WSDL 是 Web Services 的定義語言。當你實現了某種服務的時候 ( 如 , 股票查詢服務 ), 為了讓別的程序調用 , 你必須告訴大家你的服務的接口 . 例如 , 服務名稱，服務所在的機器名稱，監聽端口號，傳遞參數的類型 , 個數和順序 , 返回結果的類型等等 . 這樣別的應用程序才能調用你的服務。 WSDL 協議就是規定了有關 Web Services 描述的標準。

• UDDI: 是 Universal Description, Discovery, and Integration 的縮寫。簡單說， UDDI 用于集中存放和查找 WSDL 描述文件，起著目錄服務器的作用。

如上圖，一個 Web Services 的生命周期是：

1. 實現一個 Web Services ，使其能夠接受和響應 SOAP 消息（現在有很多工具都可以幫助實現）。

2. 撰寫一個 WSDL 文件用于描述此 Web Services 。（現在有很多工具可以自動生成 WSDL 文件）。

3. 將此 WSDL 發布到 UDDI 上。

4. 其他的應用程序（客戶端）從 UDDI 上搜索到你的 WSDL 。

5. 根據你的 WSDL ，客戶端可以編寫程序（現在有很多工具可以自動生成調用程序）調用你的 Web Services 。

Web Services 的缺點

由于是基于 XML 的應用， Web Services 與生俱來地在擁有 XML 帶來的一切優勢的同時，不可避免地繼承了 XML 所帶來的一些限制。

• Web Services 通常需要大量的 CPU 資源。因為 XML 數據要經過多步處理才能被系統使用。首先是效驗（ validate ），檢查它的格式是否符合 XML 的規范，以及根據應用程序定義（ DTD 或 Schema ）檢查是否符合語義上的規范；然后還要進行解析（ parse ），從 XML 文檔分解出單個的元素；最后還要轉換成應用程序所需要的二進制表達（例如，把“ 12” 轉換成整型 12 的二進制表示）。

• Web Services 還意味著占用較多的內存資源。在進行 XML 解析的時候，會產生大量的臨時內存對象。特別是在處理 DOM 對象的時候。這些大量的臨時對象對于象 JAVA 這類自動回收內存的語言和系統其實是一種負擔，大量的臨時對象將會使系統每隔一段時間就會進行內存回收，從而降低系統的性能。當然，現在有的 Web Services 的產品（如 axis ）采用了 SAX 技術，大大減少了內存的占用量。詳細信息請參考：（ http://xml.apache.org/axis/index.html ）。

• 網絡資源的消耗也是 Web Services 應用的一些限制。因為基于 XML 數據的傳遞通常數據量要比二進制的協議（如 RMI/IIOP ）要大的多。這種額外的消耗在網絡資源比較緊張或網絡傳輸比較頻繁的應用中會產生一定的影響。

除了 XML 帶來的限制， Web Services 本身也具有一些缺點：

• 到目前為止， Web Services 還可以說是一種無狀態（ stateless ）的服務。
  所謂 stateless 就意味著不保存客戶端服務調用者的任何信息。這是由 Web Services 的本質所決定的。 Web Services 在本質上是要為應用程序之間提供數據通訊的標準，為企業應用之間動態地提供大顆粒度的服務，所以 Web Services 并不適合于非常精細的基于會話的方法調用以及復雜的事務（ transaction ）處理之中。
  也許有人會對我這點提出異議！因為，現在有很多 Web Services 的產品（如 WASD ），不但可以保存 session 的信息，使服務成為有狀態（ stateful ）的服務，而且還實現了 remote interface ，可以在 Web Services 的會話中傳遞遠程對象的句柄，讓客戶端可以操縱遞遠程對象（詳細信息請參考： http://www.systinet.com ）。原理上說，這并不難實現，因為在 XML 數據中，可以互相傳送任何數據，包括 sessionID 和 transactionID ，有了這些 ID ，從技術角度上說，實現有狀態（ stateful ）的服務和事務處理并不復雜。但是，這樣功能缺少標準的支持，當前版本的 WSDL 還無法表示這些復雜的服務。在企業內部，你可以任意使用這些特殊的功能，可以自己定義會話狀態的交互協議，因為服務者和服務調用者之間的通訊都在你的控制之中；然而要將這些服務發布到 Internet 上，其他的應用程序是無法根據標準去識別這些特殊功能。

• 數據綁定也存在一些不足。
  因為所有的數據傳遞都用 XML 格式，因此，需要在二進制數據和 XML 數據之間有個轉換。但是，并不是所有的二進制數據都能方便地用 XML 來表示，并不是所有的 JAVA 對象都能被 XML 所表示。因此，經常在轉換過程中會出現語義丟失的情況。

• 技術要求高，學習曲線較長。
  每一個 Web Services 的產品，都有豐富的工具，能夠根據 Web Services 的定義（如 WSDL 文件）方便地生成客戶端的程序；能夠將一般的服務程序，很容易就包裝成 Web Services 服務。因此，各個 Web Services 的產品都聲稱自己的平臺容易使用，根本不需要了解 XML ，也不需要了解什么 WSDL ， UDDI ， SOAP 就能使用發布 Web Services 。特別是一個朋友告訴我，他在什么都不了解的情況下，用 .NET 花了 15 分鐘就發布了一個 Web Services ！
  千萬不要醉心于這種簡便，這對于簡單的 Demo 也許是對的，可是對于真正意義上嚴肅的應用，一定要了解 Web Services 的各個方面，設計整體結構和解決方案，還要根據具體的應用調整性能。所有這些都需要對 Web Services 知識的全面掌握。

什么應用適合Web Services

Web Services 這么多的缺點是不是讓你很泄氣？其實，已經有很多成功的 Web Services 的應用和越來越多的開發商的加盟，證明 Web Services 一定會成為新一代 WEB 信息通訊的主流。經過不斷的發展， Web Services 一定能克服自身的弱點，得到更廣泛的應用。但就目前來說， Web Services 比較適合用于下列形式的應用：

• 基于 WAN 和 Internet 的應用

要在 Internet 上創建基于二進制協議的 RMI/IIOP 的應用，一般都會遇上一個大麻煩 -- 防火墻。客戶端瀏覽器極大可能在 ISP 防火墻后，大多數防火墻都只能允許和外部的 HTTP 連接，因此想要 ISP 防火墻后的客戶端能和防火墻外的 RMI/IIOP 的應用端口進行連接的話，就要改變 ISP 的安全策略，讓客戶端能夠連接除了 80 以外的其他端口。可是當運行 RMI/IIOP 的應用的服務器為了安全也在防火墻之后的 DMZ 中的話，那這個連接就更加復雜了，要跨越兩個防火墻。
而 Web Services 由于使用的是 HTTP 協議，傳遞的是純文本的 XML 數據，因此擁有穿透防火墻的良好性能。

• 基于異構平臺的應用

XML 語言本身就是跨平臺、跨語言的數據表示方法，在加上通用的 HTTP 等協議，使得 Web Services 天生就適用于基于異構平臺的應用。如果你的客戶端包含了各種不同的平臺，例如，你希望你的服務即可以被 JAVA 程序所調用，又可以由 VB 和 COM 程序所調用。你有兩種選擇：一種是為不同的平臺提供相應的 API ，還要為不同的語言提供 API ；如果提供 Web Services ，所有平臺和語言都可以調用了！

• 需要強安全特性的應用

很多人都認為，安全性是 Web Services 的弱項。其實不然，經過不斷的完善和各種新的協議的出臺， Web Services 完全可以用于安全性很強的應用環境下。并且，由于 Web Services 使用 HTTP 協議進行傳輸，所以可以和容易就使用已經很成熟的基于 HTTP 的各種安全技術。

• EAI （企業應用集成）
  這是目前 Web Services 應用最看好的方向之一。大多數企業內部都有著各種各樣的應用系統，它們是在不同的領導在任期間，由不同的軟件開發商開發，因此運行在不同的平臺和系統上，系統的開發語言也各不相同。由于現代企業信息自動化要求的提高，各個系統之間的互動和相互通訊便提到日程上。因此，保護原有投資，重用遺留系統是當前很多中大型企業的重要任務。
  由于遺留系統的運行平臺是異構環境，因此企業應用集成的代價一般來說是很高的。但如果使用 Web Services 作為應用集成的手段，將會大大降低集成的消耗。 Web Services 與平臺和語言無關的特性，以及各種平臺和環境下的開發工具都是企業應用集成的利器。
  另外，在開發新的應用系統的時候，仍然需要考慮和其他系統的集成，需要考慮調用其他系統的功能，和被其他系統所調用。使用 Web Services 作為系統與外部交流的接口，能夠使新的系統和別的系統之間保持松耦合的關系，保持較高的可擴展性。

• 行業內部 B2B 應用
  行業內部的應用是 Web Services 的另外一個方向。因為在一個行業中，商業業務是很相似的，因此在行業內部很容易形成服務的標準，使所有的業內企業共同遵守；但怎樣實現服務和使用什么樣的系統，決定權在于各個企業自己。例如，電信運營商之間的結算服務，銀行之間的轉帳服務等都可以形成行業標準，以 WSDL 的形式公布出來。各個企業之間可以選擇不同的平臺進行服務的實現。

提高Web Services的性能

要想提高 Web Services 應用的性能，需要對整個系統做全盤的考慮。一般來說，有以下幾點需要注意：

1. Web Services 的顆粒度
   選擇 Web Services 的顆粒度是提高 Web Services 應用的性能的主要手段。因為 Web Services 使用的傳輸協議為 HTTP 或 SMTP 等，這些協議都是面向無狀態的連接協議，每一個請求都要建立一個新的連接。因此 Web Services 的調用不能象數據庫 JDBC （ ODBC ）接口一樣可以進行精細而復雜的方法調用（例如，先獲得 Connection ，再獲得結果集，然后一行一行獲取結果）。 Web Services 比較適用于大顆粒度的應用，在一個調用中便獲得所有的信息（比如說銀行之間的轉帳，在一次調用中就將包括金額和認證等所有的信息都傳輸過去）。

2. 謹慎使用 XML 接口
   系統之間的接口可以使用 XML ，這樣可以增加系統的靈活性；但不要使用 XML 作為系統內部的接口，因為這不會帶來任何好處，盡量使用二進制作為系統內部的接口，避免不必要的 XML 文檔的解析和效驗；在處理 XML 的時候，盡快將 XML 轉換成內部對象， XML 的傳遞只會增加系統的開銷。

3. 最大可能性使用 CACHE
   當有些信息是只讀的，或者在一段時間內保持不變，就可以使用 CACHE 。無論是客戶端的 CACHE 還是服務器端的 CACHE ，都能大大提高系統的性能

總結

一旦 Web Services 得到更加廣泛的應用，使得各種服務可以動態查找和定位，這樣就提供了不同設備之間各種各樣的信息交互方式，將會大大改變商業運做的模式和信息交流的風格。

你可以使用別人已經成熟的功能來使自己提供更好的服務，例如 google ，它的搜索引擎可以通過 Web Services 來訪問。這就意味著在你的系統中可以方便的嵌入使用 google 的強大搜索功能，而不論你的系統是運行在什么平臺上，使 google 的搜索引擎成為你系統的一部分，（請參考 http://www.google.com/apis/ ）。站在別人的肩膀上，畢竟要看得遠些！

面對 Web Services ，你現在可以不行動，但你一定要準備好！