作者：王昱
摘要：本文介紹了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的生命周期是：
-
實現一個Web Services，使其能夠接受和響應SOAP消息（現在有很多工具都可以幫助實現）。
-
撰寫一個WSDL文件用于描述此Web Services。（現在有很多工具可以自動生成WSDL文件）。
-
將此WSDL發布到UDDI上。
-
其他的應用程序（客戶端）從UDDI上搜索到你的WSDL。
-
根據你的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比較適合用于下列形式的應用：
要在Internet上創建基于二進制協議的RMI/IIOP的應用，一般都會遇上一個大麻煩--防火墻?？蛻舳藶g覽器極大可能在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應用的性能，需要對整個系統做全盤的考慮。一般來說，有以下幾點需要注意：
-
Web Services的顆粒度
選擇Web Services的顆粒度是提高Web Services應用的性能的主要手段。因為Web Services使用的傳輸協議為HTTP或SMTP等，這些協議都是面向無狀態的連接協議，每一個請求都要建立一個新的連接。因此Web Services的調用不能象數據庫JDBC（ODBC）接口一樣可以進行精細而復雜的方法調用（例如，先獲得Connection，再獲得結果集，然后一行一行獲取結果）。Web Services比較適用于大顆粒度的應用，在一個調用中便獲得所有的信息（比如說銀行之間的轉帳，在一次調用中就將包括金額和認證等所有的信息都傳輸過去）。
-
謹慎使用XML接口
系統之間的接口可以使用XML，這樣可以增加系統的靈活性；但不要使用XML作為系統內部的接口，因為這不會帶來任何好處，盡量使用二進制作為系統內部的接口，避免不必要的XML文檔的解析和效驗；在處理XML的時候，盡快將XML轉換成內部對象，XML的傳遞只會增加系統的開銷。
-
最大可能性使用CACHE
當有些信息是只讀的，或者在一段時間內保持不變，就可以使用CACHE。無論是客戶端的CACHE還是服務器端的CACHE，都能大大提高系統的性能
總結
一旦Web Services得到更加廣泛的應用，使得各種服務可以動態查找和定位，這樣就提供了不同設備之間各種各樣的信息交互方式，將會大大改變商業運做的模式和信息交流的風格。
你可以使用別人已經成熟的功能來使自己提供更好的服務，例如google，它的搜索引擎可以通過Web Services來訪問。這就意味著在你的系統中可以方便的嵌入使用google的強大搜索功能，而不論你的系統是運行在什么平臺上，使google的搜索引擎成為你系統的一部分，（請參考http://www.google.com/apis/）。站在別人的肩膀上，畢竟要看得遠些！
面對Web Services，你現在可以不行動，但你一定要準備好！