Web服務(wù)走向何方？

申請(qǐng)免費(fèi)試用、咨詢電話：400-8352-114

Web服務(wù)走向何方？

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

一、革新之潮流

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

二、解決應(yīng)用集成面臨的難題

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

對(duì)Web服務(wù)的進(jìn)一步改進(jìn)將要如何進(jìn)行呢？在回答這個(gè)問(wèn)題之前，必須先理解Web服務(wù)的應(yīng)用情況。更準(zhǔn)確地說(shuō)，是想象一下Web服務(wù)的應(yīng)用情況，因?yàn)楫?dāng)前實(shí)際使用的基于Web服務(wù)的應(yīng)用還不是很多。

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

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

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

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

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

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

四、結(jié)束語(yǔ)

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

到目前為止，復(fù)合式Web服務(wù)還只顯現(xiàn)了一個(gè)輪廓，最終的情形到底會(huì)怎么樣，現(xiàn)在還無(wú)從得知。但可以肯定的是，現(xiàn)在就為迎接復(fù)合式Web服務(wù)做好準(zhǔn)備是明智的。這樣，當(dāng)它們最終到來(lái)時(shí)，你就不會(huì)措手不及了。