Web服務走向何方？

申請免費試用、咨詢電話：400-8352-114

Web服務走向何方？

分布式計算技術的發(fā)展從來沒有停止。就在你慶幸自己熟悉了如何設計分布式應用時，新的理論出現(xiàn)了，設計方法也隨之改變。與此同時，從理論研究到理論在標準、商品化產(chǎn)品上應用之間，也存在一定的時間差。當你開始應用最新的發(fā)展成果時，下一次重大發(fā)展已經(jīng)在研究和醞釀之中了。

一、革新之潮流

當前，用來構造Web服務的工具和規(guī)范仍有待進一步完善；盡管如此，即使在最原始的Web服務構造方法獲得廣泛應用之前，人們也已經(jīng)開始審視Web服務的局限，探討更有效的應用構造方法。Java通過JCP（Java Community Process）下面一個未見報道的工作組駕駛著這一輪的革新，即JSR-159 Java Process Component API。這個在2001年12月才組建的JSR最終會得出什么結論，仍有待觀察?，F(xiàn)在能夠看到的只有一個規(guī)范需求說明。然而，過去幾年中分布式計算研究的課題是該工作組的基礎，而且隨著在實踐經(jīng)驗的基礎上技術的不斷改進，研究課題也將一直繼續(xù)。
分布式計算支持多種應用開發(fā)模式。應用之間能夠利用預先確定的協(xié)議，通過字節(jié)流實現(xiàn)通信。通信過程可以模式化成為過程調(diào)用，從而形成遠程過程調(diào)用（RPC）機制。不同的網(wǎng)絡服務可以視為帶有不同方法的對象，在此基礎上，我們得到了RPC的面向?qū)ο缶幊贪姹?，即遠程方法調(diào)用（RMI）。在應用中，組件之間的耦合可以是寬松的，也可以是緊密的；組件之間的消息傳遞可以是同步的，也可以是異步的。以隊列形式緩沖的消息可以通過可靠的傳輸機制傳遞到任何可能的接收者，通過消息中包含的各種事件，應用的行為可以得到有效的控制。分布式計算應用可以按照多種途徑組合和分拆。不過，除了科學計算領域的并行處理之外，當前的趨勢是，應用各個組件之間的耦合應當盡量地寬松，從而提高組件的可重用性，方便組件的集成。這種趨勢引導我們走向Web服務。在Web服務環(huán)境下，組件耦合的寬松程度達到了最大化（實際上不再相互耦合），組件具有最好的可重用性。同時，由于在Web服務環(huán)境下，通信依賴于平臺中立的XML消息，因此組件的集成也比以前更加容易。
從根本上看，Web服務本身沒有提供什么新的東西。從某種意義上來說，它只是一次從側面對原有技術的革新。以前曾經(jīng)有過分布式對象系統(tǒng)，但它的設計意圖不是針對多個系統(tǒng)的相互通信。曾幾何時，即使對于同一個系統(tǒng)，來自不同廠商的不同實現(xiàn)也不能相互操作（還記得IIOP之前的CORBA嗎？）。你要么保證在所有應用開發(fā)中使用單一的分布式對象系統(tǒng)，要么使用某種起連接作用的橋式工具，聽任應用的性能和可靠性由于使用橋接工具而降低。即使兩個建立在不同對象系統(tǒng)基礎上的服務在功能上完全符合應用的需求，試圖讓它們在同一個應用之內(nèi)運行也會面臨極大的風險。

二、解決應用集成面臨的難題

人們期望Web服務能夠解決所有應用集成過程中出現(xiàn)的問題。盡管Web服務的設計意圖并不是完全被當作分布式對象使用，但它們也沒有提供一種全新的編程模式。雖然所有服務之間的通信都以XML格式的消息為基礎，但調(diào)用服務的基本途徑主要還是RPC。在分布式計算技術發(fā)展的這一階段，之所以要提出Web服務，是因為原有的技術無法實現(xiàn)多個系統(tǒng)的相互協(xié)作，繼續(xù)向前發(fā)展已經(jīng)很困難。有了Web服務，集成分布式應用中的各個組件就有了一個公共的框架，無需再考慮每一個組件的具體實現(xiàn)方式。

對Web服務的進一步改進將要如何進行呢？在回答這個問題之前，必須先理解Web服務的應用情況。更準確地說，是想象一下Web服務的應用情況，因為當前實際使用的基于Web服務的應用還不是很多。

簡單、基礎的Web服務不值得太多關注，它們就象是遠程過程調(diào)用，只是調(diào)用通過一個XML消息進行，且消息具有遵從SOAP或XML-RPC之類規(guī)范的特定格式。它們只是通用服務模型下的一些特例。從理論的角度來看，服務是對事件的響應，而這里的事件又具有消息的形式。類似于RPC系統(tǒng)的服務只響應一種類型事件，即一個指定了方法名字和一組參數(shù)的調(diào)用，調(diào)用可能要求返回一個結果。按照這種模式構造的應用面臨著與傳統(tǒng)RPC和RMI系統(tǒng)同樣的局限。過程調(diào)用需要昂貴的開銷，要求通過廣域網(wǎng)傳輸參數(shù)和返回值，與局域網(wǎng)相比，廣域網(wǎng)的延時高、帶寬小。如果調(diào)用是同步的，調(diào)用者還要等待調(diào)用返回。另外，這類調(diào)用的結果經(jīng)常是下一次遠程過程調(diào)用的輸入?yún)?shù)，從而導致數(shù)據(jù)在網(wǎng)絡上重復傳輸。而在通用服務模型下，服務能夠響應任意事件，從而支持更復雜、更高效的數(shù)據(jù)流程。

如果應用的多個組件不必由正在運行程序的主線程分別地、單獨地控制，那么，在把最終結果返回給主程序之前，處理的中間結果可以由一個組件傳遞給處理流程中的下一個組件。通過控制組件之間的輸入、輸出和調(diào)用流程，從幾個基本的組件出發(fā)可以構造出大量不同的函數(shù)。
這種思想與二十世紀七十年代導致實現(xiàn)Unix管道的思想屬于同一類型。不同之處在于，現(xiàn)在討論的不再是進程之間字節(jié)流的流程，我們現(xiàn)在面對的是網(wǎng)絡服務之間XML消息的流程。按照這種思路，Web服務被視為構造應用的基本模塊，為盡可能地提高重用性，這種思路要求程序員更小心地進行設計。在這個基礎上，Web服務趨向于復合式的Web服務，而不是各個服務孤立地存在。這里“復合”一詞源于離散數(shù)學。在離散數(shù)學中，復合兩個函數(shù)g(x)和f(x)得到g(f(x))。如果g和f是服務，它們的復合結果是把f服務的輸出作為輸入傳遞給g服務。

三、Web服務=可復合的函數(shù)

把Web服務視為可復合的函數(shù)能夠簡化分布式應用開發(fā)。理論上，新的服務可以作為一系列服務的有機組成部分方便地裝配，而且這個過程不需要任何編程工作?？梢暬ぞ吣軌虬讯鄠€服務按照合適的次序連接在一起，并生成實施復合操作所必需的消息代碼。至于這類工具是否能夠很快進入普通用戶手中，或者說服務復合是否具有足夠的吸引力達到廣泛應用的程度，目前還不能確定。然而，JSR-159工作組看來已經(jīng)相信，復合服務正是分布式組件技術發(fā)展的下一個目標。同一種思路，雖然那次是在模塊粒度不同的一個層次上應用，曾經(jīng)導致把Filter（過濾器）機制加入到Java Servlet 2.3 API。在Java平臺的發(fā)展中，我們不斷追求的就是盡可能地提高可重用性和盡可能地簡化應用開發(fā)，如果借用一個面向概念編程技術的術語，那么其途徑就是分離概念。

Java Process Component（JPC） API將建立在對象管理組織（OMG）的EDOC CCA規(guī)范的基礎上（其中EDOC是Enterprise Distributed Object Computing的縮寫，即企業(yè)分布式對象計算；CCA是Component Collaboration Architecture，即組件協(xié)作體系）。EDOC CCA規(guī)范已經(jīng)指出了復合服務組件框架的許多細節(jié)。JPC的目標是成為J2EE未來版本的標準組成部分，但它不會取代Java Servlet或者EJB。Java Web服務將繼續(xù)用現(xiàn)有的API構造，但JPC提供了一種把Servlet、JSP和EJB耦合到一個Process級組件里面的途徑。

JPC組件類似于在它之前的研究系統(tǒng)，比如Stanford的Paths框架，它也是事件驅(qū)動的。組件擁有輸入和輸出端口，數(shù)據(jù)流通道可通過輸入輸出端口建立，JPC容器負責管理事件遞送和數(shù)據(jù)流程。

四、結束語

如果你想要在自己的應用中使用可復合Web服務的一些概念，不必等到JPC全部完成。任何Web服務，即使它不遵從標準的API，都可以被另一個服務封裝。服務復合最常見的應用恐怕就是過濾器。想象一下，有一個無線應用需要訪問一些來自某個Web服務的數(shù)據(jù)，但該Web服務并不壓縮數(shù)據(jù)，從而延長了接收數(shù)據(jù)的等待時間。這時，你可以構造一個壓縮服務，任何來自其他Web服務的數(shù)據(jù)都可以經(jīng)由壓縮服務的處理再傳遞給無線應用。至于具體如何把壓縮服務和數(shù)據(jù)服務連接在一起，使它們看起來象單一的服務，這正是JCP力圖進行簡化的。

到目前為止，復合式Web服務還只顯現(xiàn)了一個輪廓，最終的情形到底會怎么樣，現(xiàn)在還無從得知。但可以肯定的是，現(xiàn)在就為迎接復合式Web服務做好準備是明智的。這樣，當它們最終到來時，你就不會措手不及了。