Web服務帶來了什麼?

Web服務帶來了什麼?

柴曉路

2002-3-8

電子商務應用的挑戰

隨着Internet的興起，部署在Web上的應用隨着Internet的深入人心，而不斷髮展。當Web應用已經走入人們的日常工作和生活的時候，人們發現在Web應用和傳統桌面應用(比如企業內部管理系統、辦公自動化系統等)之間存在着連接的鴻溝，人們不得不重複地將數據從Web應用遷移到傳統桌面應用，或從傳統桌面應用將數據遷移到Web應用，其中的遷移操作基本都要通過人的操作來完成，這成爲了阻礙Web應用進入主流工作流的一個巨大的障礙。計算機的應用是要追求信息的自動化處理，然而，目前的應用狀況，則使人們不得不在自動化的流程之間摻加上若干的人工步驟，這會在不同程度上降低人們使用計算機系統的積極性。

舉個例子，某個公司通過Web提供了一個在線產品定購系統，這個公司的某一個客戶找到了這個在線產品定購系統，在Web表單中輸入了訂單，同時在瀏覽器裏獲得了訂單確認的響應。由於這個客戶的公司內部使用了企業管理系統，應內部管理的需要，他還不得不同時把這個訂單確認從瀏覽器裏面複製出來，然後手工地填入企業內部管理系統的相應界面上，以使得內部系統中的事務能夠正常流轉。此時這個用戶事實上將信息重複輸入了兩遍，對用戶而言無論如何是一件厭煩的事情，從計算機系統的角度來看，這完全可以避免。

目前，大多數電子商務的應用在處理購買者、供應商、Marketplace和服務提供者之間的連接方式上各不相同。如何將這些應用方便地低代價地連接在一起，從而實現大範圍的跨企業實體的商務應用系統的應用系統級別的互聯，這是擺在開發人員面前的一大問題。不同的應用(尤其是不同企業的)開發語言不同、部署平臺不同、通訊協議也可能不同，對外交換的數據格式更是可能有着巨大的差異。如何去面對語言差異、平臺差異、協議差異、數據結構的差異所帶來的複雜的系統集成的挑戰是解決這個問題的關鍵。

 <?xml:namespace prefix = o ns = "urn:schemas-microsoft-com:office:office" />

XML & Web服務, 消除差異的持續努力

從1998年開始發展的XML技術及其相關技術是嘗試解決這些差異的初步嘗試。XML技術的提出，其初衷是爲了改善HTML的無結構化的狀況而造成的全球Web信息的結構混亂。XML規範的開發小組爲了使得全球Web信息能夠邁向結構化的方向，基於強大的SGML語言，制訂了XML 1.0的規範。最初，XML的應用的確是關注在信息發佈領域，大量的使用XML/XSLT技術的網站紛紛出現，以證明XML在信息發佈領域的優越性。之後，隨着XSL規範的不斷成熟，XML技術從信息發佈領域延伸到傳統的電子出版領域，而基於Web的信息發佈也正式成爲了電子出版的形式之一：網絡媒體出版。

然而，另一方面，由於XML的處理器(Parser，一般爲DOM獲或SAX)在各種平臺上都分別交互開發人員使用，大家不約而同地發現，使用XML在不同的異構系統之間交換數據是一件那麼方便的事情：首先，XML格式具備描述各種類型數據的能力；其次，使用DOM/SAX對XML進行處理，開發人員可以節省開發通常需要的文件格式處理的模塊，DOM/SAX爲XML處理封裝了一套有效的方法；再次，XML、DOM是W3C規範，大家都會遵循規範，在不同平臺的處理方式是完全一致的。因此，很快，XML就成爲了應用範圍極爲廣泛的數據交換的工具。隨着應用XML進行數據交換的理念不斷深入人心，另兩個XML相關的規範也慢慢被引入到使用XML進行數據交換的領域裏來，開發人員使用XSLT實現不同XML數據交換格式的互相轉換，同時利用XML Schema對XML數據交換格式進行數據建模，由於它們都是基於XML的，同時平臺工具不斷更新以支持這些新規範，以使得數據層集成(數據交換)的應用得以在技術的強大後盾的支持下，不斷推廣。目前使用XML進行數據交換已經成爲計算機軟件領域，尤其是電子商務應用領域的標準技術模式。

XML解決了在不同平臺/系統之間的數據結構/模式的差異，使得數據層在XML技術的支持下，統一了起來。

對於全球電子商務所提出的廣泛的電子商務應用集成和交互而言，光有數據層的集成是不夠的。數據層的集成能力，使交互的雙方能夠彼此瞭解對方所發送過來的數據，但是數據應當由哪個應用、按照何種方式、使用何種上下文來實施處理，處理完了應當返回何種處理結果等等處理語義都無法通過數據層的集成來完成。大家可能會想到，我在數據中包含指定的應用、指定的處理語義，然後再將這個數據包傳給對等方，對等系統接收到這個數據後，分析出發送方期望的應用和處理語義，然後再實施真正的數據處理，並按照發送方的要求返回處理結果。這，正是Web服務雛形的應用模式。

然而，此時，如何在數據中指定應用，如何將應用指派與真實的部署在平臺上的應用程序映射起來，如何包裝返回結果都需要開發人員自己來指定，這有些類似於原先未使用標準數據描述格式而進行數據交換的場合。

Web服務系列技術則是架構在在XML技術的基礎上，爲在平臺層解決掉這些應用層集成所不可避免的問題而提出的開放式的技術架構。

Web服務的體系架構與Web應用的N層架構是類似的，不同點在於最上層的面向瀏覽器的Web Server被面向程序(Web Service Client)的Web服務所取代。而使用Web服務的程序可以是桌面應用程序，同樣也可以是另一個Web服務。圖1給出了Web服務的一個通同的簡單的體系架構模式。

 

<?xml:namespace prefix = v ns = "urn:schemas-microsoft-com:vml" />

圖1  Web服務的體系架構

 

構築Web服務的Web服務技術家族的主要成員有XML Schema、SOAP、WSDL和UDDI，它們都是完全基於新一代Internet種子技術XML的。XML Schema爲在不同系統(Web服務)之間交換數據而提供了一個核心的跨平臺數據建模工具。SOAP爲在不同系統之間實施平臺無關的交互定義了一套基本的元規則和跨平臺消息機制，SOAP是Web服務體系中服務交互的基礎架構。WSDL則是Web服務接口界面的跨平臺描述工具，依靠WSDL，Web服務的交互界面就能被系統自動處理。UDDI則是在動態服務集成解決方案中的首次嘗試。這組技術使得底層平臺對應用交互透明，應用的互操作能力得到了前所未有的提升。它們組成了第一代的Web服務技術。

 

使用Web服務技術

既然Web服務技術是針對應用層集成交互的跨平臺的技術框架，我們就來看看原先有哪些應用模式無法實現或很難實現，使用了Web服務技術之後就變成可以實現或容易實現了。

在本文中，我將主要考察三個領域：

§         EAI，企業應用集成

§         B2Bi以及在線服務集成

§         以Internet作爲整個後臺服務的桌面應用

 

EAI, 企業應用集成

在很多大型企業中，隨着企業業務的成長，ERP、CRM、SCM等企業應用被逐個部署，對於大多數企業來說，處於投資、技術和應用領域的考慮，一般不同的應用可能會使用不同廠商所提供的產品。此時，每個應用都有其自己特有的基礎架構，這些應用在部署、更改和維護上的代價都異常高昂。企業不得不爲每套應用配置特有的專業技術人員，並保持與不同技術供應商或解決方案供應商的密切聯繫。同時這些應用即不能被方便地繼承，也不能隨着企業商務的規模擴展而方便地實現應用的規模擴展。

我們很清楚地認識到，即使是隻有一個電子商務應用，其創建、維護和定製的代價及複雜度就已經是如此驚人了。何況要涉及多個這樣的應用，其代價之高是可想而知的。

讓我們來考察當企業部署若干個這樣的電子商務應用的情形：

第一個應用，企業的爲之付出的總的費用應該是該應用的開發和部署費用、以及運營時態的維護和更新費用。第二個應用，應用的開發和部署費用是一樣的，但是企業需要爲之花費額外的集成費用，同時由於整個企業應用環境變得更加複雜，其運營時態的維護和更新費用可能呈指數形式增加。同樣，當第三個、第四個應用被部署後，企業所支出的費用可能是高得驚人。

這樣的電子商務應用的實際運營狀況非但無法令企業商務規模迅速增長，甚至會造成相反的影響作用，因爲此時，IT部門不得不僱傭更多的員工並花費更多的資金來管理這些複雜而紛亂的應用，並維護多種承載應用的基礎架構。

我們知道，在傳統EAI技術中，應用A要和應用B進行集成，那麼應用A要爲應用B編寫一個集成適配器、同樣應用B也要爲應用A編寫一個集成適配器。當情況更復雜一些，有三個應用存在的時候，那麼每個應用需要分別爲另兩個應用分別編寫集成適配器。這簡直是企業內部從事應用集成的技術人員的噩夢。當然在這些領域裏，也是有一些通用的集成手段，比如IBM的MQ Series之類的解決方案，對於每個應用來說只要編寫一個集成適配器就可以應用技術框架完成集成了，然而，這類技術手段往往只能在一個公司的產品中使用，或者是在使用相同類型平臺的場合下使用，不具備通用性。

使用Web服務，通過鬆散的應用集成，一個企業可以僅僅實現EAI的一個子集，即能取得實效。與之相反，EAI要實現一個全盤的方案，來緊密的集成和聯繫支持公司業務的所有的系統和應用。在公司內部不同的業務系統和技術單體中可能需要花費數年的持續的努力，高投資以及爲之配備的充實的資源。Web服務，以這樣一種鬆散的服務捆綁集合形式(也可以說是一個特別得解決方案)，能夠快速、低代價地開發、發佈、發現和動態綁定應用。

現有的主要關注於應用集成的EAI解決方案將不得不因此而改變。在將來，包裝好的應用程序將使用如XML、SOAP、WSDL和UDDI技術來把他們的函數或方法作爲Web服務的界面來顯示。因此，EAI解決方案將不得不提供一個對服務集成的廣泛的支持，而不僅僅是應用集成。

 

B2Bi以及在線服務集成

有了EAI作爲廣泛集成的基礎，B2Bi(B2B Integration)就可以提上日程了，EAI是B2Bi的基礎，一般來說，只有自身企業的內部管理系統真正實現了彼此地互聯，企業與企業之間的集成纔是有意義的，否則，業務數據更本不可能直接流動起來，跨企業的事務也不可能被真正實施。

從技術的角度來看，同樣，先EAI後B2Bi也是適合企業信息系統的發展路線的，相對而言，企業內部的應用相對企業外部的應用而言，對於企業的技術人員更爲熟悉，應用新技術的難度從而較低，通過在企業內部實施Web服務集成，這將使企業內使用和實施Web服務的IT技術人員熟悉Web服務技術，當企業將來使用Web服務進行B2Bi項目的時候，將會有助於項目的有效進行。在Intranet內控制、管理、尋找、執行和維護Web服務相對來說也比通過企業防火牆在Internet上使用Web服務更爲容易。進一步來說，它將幫助企業來比較和鑑別，使用標準化和相對便宜的Web服務解決方案相對於昂貴的傳統的EAI解決方案到底是不是對提高企業的產出率更有幫助。

B2Bi是爲了加強企業的競爭能力而實施的項目，因此它具有以下目標：

§         減少商務活動的開支

§         減少進入電子商務的成本

§         提供更加簡便的用戶操作工具

§         提高數據的完整性和可訪問性

§         適當的安全和控制

§         提供可擴展和可控制技術

§         與現有的應用系統相集成

§         利用開放標準

§         全球可部署以及可維護

 

XML Web服務正是符合這些目標的有力工具。在商業Web上，不同的公司使用着不同應用即部署平臺，對於一個公司而言，其業務夥伴將會很多，如果爲了和每個業務夥伴進行應用集成，使用傳統的技術就必須通過交流和每個業務夥伴達成一致，並分別就通信協議、消息格式、數據模型分別進行實施，其效率顯而易見地低下。而如果採用Web服務技術，開發人員將自身待集成的應用包裝成Web服務，使用WSDL描述這些包裝好的Web服務，並按需要將這些Web服務及其描述發佈到Web服務的註冊中心中取以供查詢，同時所有的這些工作都可以使用支持規範的工具來完成。此時，企業之間的集成就轉變爲Web服務的對接，開發人員可以通過UDDI API來查詢Web服務的註冊中心或者與業務夥伴的技術人員進行交流，獲取對方的Web服務的WSDL描述文檔，然後通過平臺工具自動將WSDL描述文檔裝載到自己的開發平臺中，並生成相應的接口，同時開發人員可以使用XML Schema的工具快速地理解應用交互需要使用的數據結構，然後在自己的應用中引入剛剛使用平臺工具生成的調用接口和數據結構，使用SOAP技術與對方的Web服務進行交互，從而完成B2B應用集成。

B2B集成這個概念可以延伸入所有在線服務的彼此集成，比如企業自己的系統就能夠和公共的金融服務、海關服務、第三方物流服務、網上商店等等連接在一起，將原來需要依靠紙張的聯繫轉換成電子的方式，並且，其系統的實施仍然能夠使企業只要維護一個技術團隊：”Web Services Enabling”的技術團隊。

 

以Internet作爲整個後臺服務的桌面應用

在企業應用領域之外，個人應用領域同樣是一個非常大的應用領域，同時其形成的影響力是有過之而無不及的。在過去，以Web爲服務的桌面應用已經有了相當的應用，比如：

§         大家使用的非常頻繁的即時訊息軟件，包括MSN Messenger、Yahoo! Messenger、ICQ、OICQ等，它們以部署在Web上的訊息服務器爲後臺服務，完成不同終端之間的消息互通。

§         股市行情軟件客戶端，代表性的有證券之星等，他們依靠不斷地從在線行情服務器上同步下載行情數據以提供服務。

§         理財軟件，比如Microsoft的Money 2002，以及基本可以通過所有的美國的銀行的在線服務獲得個人的帳目數據。

對於這些應用而言，提供服務的實體與使用服務的實體要麼是一家公司(前兩者)，要麼是一對一的簽署協議，構建一對一連接協議(後者)，雖然從模式上，這已經是“Web服務”應用模式了，然而，其中的那些“Web服務”都是非開放的，除自己的客戶端，或私下達成協議的客戶端應用外，其他桌面應用是無法使用這些服務的。

即使，有些桌面應用的開發人員通過反向工程獲取了某些服務的使用方式，由於那些服務是非開放的，一旦那些服務的接口有所改變(大多並非惡意的)，那麼桌面應用的代碼就不得不進行相應的升級。

然而，如果那些在線服務都使用Web服務技術進行重新包裝之後，對於桌面應用的開發而言，其中的一種開發模式就如同我們前面在EAI集成中提到的那樣，需要將描述Web服務的WSDL文檔裝載入開發環境，然後生成調用接口，並集成入代碼。在運行時，Web服務的接口是有可能改變的，當接口改變後，Web服務調用失敗，此時，桌面應用應當有能力再一次獲取WSDL文檔，重新生成調用接口，並與代碼進行綁定。也就是說，Web服務技術賦予了應用動態綁定的能力，而不象以前僅僅具備靜態綁定的能力。此外，桌面應用還可以選擇去查詢Web服務的註冊中心(比如UDDI Business Registry)，獲取其需要的Web服務，然後分別一一動態綁定，並實施調用。當這些技術特性被應用到我們先前討論的幾個應用中，我們就會發現：

§         大家可以使用單一的即時訊息軟件，該軟件可以聯入MSN Messenger Service、Yahoo! Messenger Service、ICQ Service等等，用戶只需要使用一個客戶端，就可以和任意的即時訊息終端進行消息互通。

§         很多股市分析軟件都可以在線使用股市行情服務的數據更新服務，將數據下載到本地後實施分析，用戶的選擇頓時增加了很多，同時軟件開發商的分工也更明確了。

§         理財軟件能夠動態地去搜索UDDI註冊中心，獲取所有銀行的在線查賬服務，從而爲用戶提供更爲即時的服務。

 

我們的機遇

我們知道，Web服務技術仍是一個新興的發展中的技術，然而無數跡象表明，Web服務將是未來應用架構的一個極爲重要的模式。先入纔有優勢，如何看好這個方向，沒有什麼理由讓它閒置在一邊，拱手讓給國外的企業慢慢進入並輕而易舉地奪取中國的市場。對於目前中國的現狀而言，在Web服務領域，有這樣一些機遇在等待着我們：

1.      Web服務開發商，Web服務技術提供商。隨着Web服務的深入人心，會有越來越多的應用採用Web服務架構，開發Web服務的需求將不斷增加，中國背景的應用需要由本地的公司參與，完全依靠國外大公司是無法滿足本土化的需求的。

2.      大型企業EAI/B2Bi的Web服務實踐。對於大型企業而言，與海外供應商、銷售商的業務關係的保持和良性發展是不可迴避的問題，雖然在國內的商務環境裏，B2B是否會成功仍然有待考證，然而在國際領域，不進行B2B集成就無法直面競爭，甚至可以說你不加入B2B集成環境，就沒有參與國際商業活動的准許證。

3.      公共Web應用的Web服務改造。對於很多有一定使用率但使用率有限的Web應用，可以考慮進行Web服務包裝，同時開放給軟件開發者使用，通過桌面軟件交付給用戶使用。可以考慮用戶向桌面軟件提供商購買軟件、桌面軟件提供商向服務提供商按服務使用率交納費用這樣的模式。

當然，除了這些，還有很多其他的機遇，想想PC剛出現的時候，想想Internet剛出現的時候，新的模式盡在默默地孕育中。

 

當前的努力

爲了使Web服務能真正體現它所承諾的語言無關、平臺無關、協議無關的互操作性，使得兩大Web服務應用平臺.NET和J2EE能夠無縫地完成應用集成。2002年2月，以IBM、Microsoft爲首的一些業界巨頭成立了WS-I.org(Web Services Interoperability Organization)，專注於建立能完全消除影響互操作性的平臺差異的機制，爲Web服務規範的實現提供各種樣例和範本，使得開發人員消除對規範理解的二義性的存在，爲Web服務的互操作性奠定紮實的基礎。此外，UDDI.org、W3C.org的各個工作組都在緊鑼密鼓地進行規範的開發，各大技術提供商都在按照規範不停地在自己的主流平臺上增加相應的Web服務支持。圍繞着Web服務，大家都在努力地爭取搶得先機，爭取在Web服務領域領先一步，在發展中佔據有利的位置。我們相信，Web服務的春天正在來臨。