clant

3.3. 比較 SOA 與分布式互聯(lián)網(wǎng)架構(gòu)

這似乎有點(diǎn)自相矛盾，如果 SOA 可被視作分布式互聯(lián)網(wǎng)架構(gòu)的一種形式，同時(shí)我們初期建立早先類型的分布式架構(gòu)也可被設(shè)計(jì)為 SOA 。盡管如此，且盡管現(xiàn)在的分布式環(huán)境可能已經(jīng)深深地受到了面向服務(wù)原則的影響， SOA 這樣的變化仍舊是罕見的。故而在此所提供的比較是將傳統(tǒng)的分布式互聯(lián)網(wǎng)架構(gòu)作為其最常被設(shè)計(jì)的風(fēng)格出現(xiàn)。

分布式互聯(lián)網(wǎng)架構(gòu)簡史

為了對(duì)付兩層客戶服務(wù)器架構(gòu)相關(guān)的成本與限制問題，構(gòu)建基于構(gòu)件應(yīng)用的概念成為主流。多層客戶 - 服務(wù)器架構(gòu)浮出水面，將單獨(dú)的客戶程序分解成構(gòu)件設(shè)計(jì)，成為符合面向?qū)ο蟮牟煌瑪U(kuò)展。

在構(gòu)件中不同的分布式應(yīng)用邏輯（一些仍駐留在客戶端，其他在服務(wù)器上），減少了大量邏輯都集中部署在服務(wù)器端的令人頭痛的問題。服務(wù)器端構(gòu)件，現(xiàn)在集中于應(yīng)用服務(wù)器，從而可共享數(shù)據(jù)庫連接管理池，減輕數(shù)據(jù)庫并發(fā)訪問的負(fù)擔(dān)（ 圖 4 ）。一個(gè)單連接就可輕易滿足多用戶要求。

圖 4. 典型的多層客戶 - 服務(wù)器架構(gòu)。

獲取這些效益的代價(jià)是復(fù)雜性的增加，并且最終轉(zhuǎn)換為從部署問題到開發(fā)和管理過程的費(fèi)用和努力。構(gòu)建多樣化處理能力的構(gòu)件，并發(fā)請求比直接為單個(gè)用戶開發(fā)一個(gè)可執(zhí)行程序更困難，而且問題多多。

另外，替代客戶 - 服務(wù)器數(shù)據(jù)庫連接的是客戶 - 服務(wù)器遠(yuǎn)程程序調(diào)用（ RPC ）連接。象 CORBA 與 DCOM 這樣的 RPC 技術(shù)，準(zhǔn)許客戶工作站與服務(wù)器構(gòu)件間進(jìn)行遠(yuǎn)程通信。出現(xiàn)了類似客戶 - 服務(wù)器架構(gòu)的問題，包括資源及永久連接。增加這個(gè)新的維護(hù)是由于引入了中間件層。比如，在大型環(huán)境中對(duì)于應(yīng)用服務(wù)器及事務(wù)監(jiān)控需要特別關(guān)注。

隨著萬維網(wǎng)在 90 年代中后期成為一個(gè)計(jì)算技術(shù)的可用媒介，多層客戶 - 服務(wù)器環(huán)境開始組成互聯(lián)網(wǎng)技術(shù)。最重要的成就是軟件構(gòu)件被瀏覽器所替代。這個(gè)變化不僅從根本上改變（且限制）了用戶界面設(shè)計(jì)，實(shí)際上還把 100% 的應(yīng)用邏輯移到了服務(wù)器端 （ 圖 5 ）。

圖 5. 典型的分布式互聯(lián)網(wǎng)架構(gòu)

分布式互聯(lián)網(wǎng)架構(gòu)也引入了一個(gè)新的物理層， Web 服務(wù)器。這導(dǎo)致 HTTP 替代了專有的 RPC 協(xié)議而用于工作站與服務(wù)器間的通信。 RPC 的角色被限制到促成遠(yuǎn)程 Web 與應(yīng)用服務(wù)器間的通信。

從 90 年代后期 2000 年中期，分布式互聯(lián)網(wǎng)架構(gòu)對(duì)于定制開發(fā)的企業(yè)解決方案而言，代表了事實(shí)上的計(jì)算平臺(tái)。基于構(gòu)件的日常編程技術(shù)及日益復(fù)雜的中間件，最終減少了一些整體復(fù)雜性。

那么，這個(gè)熟悉而又相似的架構(gòu)該如何與 SOA 相比較呢？且看分布式互聯(lián)網(wǎng)架構(gòu)與 SOA 特征部分。

注意

盡管多層客戶 - 服務(wù)器在其所有權(quán)內(nèi)是一個(gè)獨(dú)特的架構(gòu)，我們不提供它與 SOA 之間的比較。大多數(shù)在客戶 - 服務(wù)器及分布式互聯(lián)網(wǎng)架構(gòu)的比較中升級(jí)的問題，掩蓋了將在多層客戶 - 服務(wù)器與 SOA 的比較中討論的問題。

應(yīng)用邏輯

除了一些罕見的應(yīng)用以專有擴(kuò)展的方式嵌入到瀏覽器中以外，分布式互聯(lián)網(wǎng)應(yīng)用將其所有應(yīng)用邏輯放在了服務(wù)器端。甚至客戶端腳本想要執(zhí)行在網(wǎng)頁上的一個(gè)事件響應(yīng)，都要從 Web 服務(wù)器基于初始的 HTTP 請求來下載。沒有客戶工作站上保存的邏輯，整個(gè)解決方案都是集中式的。

從而強(qiáng)調(diào)了：

• 應(yīng)用邏輯應(yīng)當(dāng)如何被分割
• 被分割的處理邏輯應(yīng)當(dāng)駐留在何處
• 處理邏輯應(yīng)當(dāng)如何交互

從一個(gè)物理的角度來看，面向服務(wù)架構(gòu)與分布式互聯(lián)網(wǎng)架構(gòu)非常相似。提供者邏輯駐留于服務(wù)器端而被分割成單獨(dú)的單元。其中差異由剛剛所列三個(gè)主要設(shè)計(jì)原則所決定。

傳統(tǒng)的分布式應(yīng)用包含了駐留于一個(gè)或多個(gè)應(yīng)用服務(wù)器上的一系列的構(gòu)件。構(gòu)件設(shè)計(jì)為不同粒度的功能，依賴于所執(zhí)行的任務(wù)，以及它們被其他任務(wù)或應(yīng)用的復(fù)用范圍。駐留于相同服務(wù)器的構(gòu)件通過專有 API 通信，按照它們暴露的公共接口來調(diào)用。 RPC 協(xié)議被用于實(shí)現(xiàn)跨越服務(wù)器邊界的通信。這有可能通過使用代表遠(yuǎn)程構(gòu)件的本地代理存根來實(shí)現(xiàn)（ 圖 6 ）。

圖 6 構(gòu)件通信依賴于代理存根

在設(shè)計(jì)時(shí)，預(yù)期的交互構(gòu)件將與其他一起考慮 --- 如此強(qiáng)烈以致實(shí)際對(duì)其他物理構(gòu)件的引用可嵌入到程序代碼內(nèi)。這個(gè)設(shè)計(jì)時(shí)水平的依賴是緊耦合的形式。這樣的稍許處理相對(duì)于試圖在運(yùn)行時(shí)定位所需構(gòu)件的浪費(fèi)而言是有效的。然而，嵌入式耦合導(dǎo)致綁定構(gòu)件網(wǎng)絡(luò)，一旦實(shí)現(xiàn)，不易更改。

當(dāng)代 SOA 依然使用并依賴于構(gòu)件。然而，整個(gè)建模方法現(xiàn)在會(huì)考慮創(chuàng)建封裝一些或所有構(gòu)件的服務(wù)。這些服務(wù)根據(jù)面向服務(wù)原則而設(shè)計(jì)，并且策略性地定位及暴露特定的功能集。同時(shí)這個(gè)功能可由構(gòu)件提供，也可源自遺留系統(tǒng)及其他資源，象來自其它套裝軟件產(chǎn)品的適配器接口，或者甚至是數(shù)據(jù)庫。

在服務(wù)內(nèi)包裝功能的目標(biāo)是經(jīng)由一個(gè)開放的、標(biāo)準(zhǔn)化的接口暴露功能 --- 而不用關(guān)心用于實(shí)現(xiàn)底層邏輯的技術(shù)。標(biāo)準(zhǔn)化的接口支持置于 SOA 核心的開放通信框架。而且，使用 Web 服務(wù)建立了松散耦合的環(huán)境，其中也運(yùn)行著相對(duì)設(shè)計(jì)的分布式應(yīng)用。如果設(shè)計(jì)得當(dāng)，松散耦合的服務(wù)支持組合模型，允許單個(gè)的服務(wù)參與集合的設(shè)計(jì)。這引入了持續(xù)的復(fù)用與擴(kuò)展機(jī)會(huì)。

有關(guān)分布式應(yīng)用邏輯的設(shè)計(jì)與行為的另一個(gè)重要轉(zhuǎn)變在于服務(wù)如何交換信息。當(dāng)傳統(tǒng)構(gòu)件提供方法時(shí)，一旦被激活，就發(fā)送與接受參數(shù)數(shù)據(jù)，而 Web 服務(wù)通過 SOA P 消息通信。即使 SOA P 支持 RPC 風(fēng)格的消息結(jié)構(gòu)，大多數(shù)面向服務(wù)的 Web 服務(wù)設(shè)計(jì)卻依賴于文檔風(fēng)格的消息。（這一重要差別在后面探究。）

消息也是結(jié)構(gòu)化的并盡可能是自足的。通過使用 SOA P 報(bào)頭，消息內(nèi)容可以伴隨闃寬泛的元信息、處理指導(dǎo)以及策略規(guī)則。與純粹構(gòu)件世界內(nèi)的數(shù)據(jù)交換相比較， SOA 所用的通訊框架更加復(fù)雜、更加龐大，并且更易導(dǎo)致少數(shù)的個(gè)別傳輸。

最后，盡管也普遍強(qiáng)調(diào)復(fù)用傳統(tǒng)的分布式設(shè)計(jì)方法， SOA 可通過促進(jìn)解決方案未知服務(wù)的創(chuàng)建鼓勵(lì)復(fù)用以及深層次的跨應(yīng)用協(xié)同。

應(yīng)用處理

不管什么平臺(tái)、構(gòu)件都代表了最大部分的應(yīng)用邏輯并因此負(fù)責(zé)大多數(shù)的處理。然而，因?yàn)橛糜跇?gòu)件間通信的技術(shù)不同于完成服務(wù)間通信的技術(shù)，處理需求也是如此。

分布式互聯(lián)網(wǎng)架構(gòu)促進(jìn)專有通信協(xié)議的使用，象用于遠(yuǎn)程數(shù)據(jù)交換的 DCOM 和廠商實(shí)現(xiàn)的 CORBA 。當(dāng)這些技術(shù)遭遇歷史性挑戰(zhàn)時(shí)，它們相對(duì)是有效可靠的，特別是一旦有主動(dòng)連接時(shí)。它們能夠支持有狀態(tài)和無狀態(tài)構(gòu)件的創(chuàng)建，主要影響同步數(shù)據(jù)交換（一些平臺(tái)支持異步通信，但并未普遍使用）。

另一方面， SOA 依賴基于消息的通信。包括負(fù)載有 XML 文檔的 SOA P 消息序列化、傳輸及去序列化。處理步驟會(huì)包括將關(guān)系數(shù)據(jù)轉(zhuǎn)換成 XML 兼容結(jié)構(gòu)、 XML 文檔預(yù)校驗(yàn)以及隨后的傳輸、以及對(duì)所接收文檔進(jìn)行解析和抽取。盡管已有所進(jìn)步，譬如企業(yè)解析器及硬件的持續(xù)加速，大部分還是抱怨 SOA P 比 RPC 通信明顯要慢一些。

在面向服務(wù)應(yīng)用環(huán)境中，因?yàn)?/span> SOA P 服務(wù)器的網(wǎng)絡(luò)能夠有效代替 RPC 風(fēng)格的通信通道，導(dǎo)致系統(tǒng)開銷成為一個(gè)重要的設(shè)計(jì)問題。文檔與消息建模規(guī)約及校驗(yàn)邏輯的布置策略是重要因素，形成了面向服務(wù)架構(gòu)的傳輸層。

這個(gè)通訊框架促進(jìn)了自治服務(wù)的創(chuàng)建，支持寬泛的消息交換模式。盡管完全支持同步通信，但還是鼓勵(lì)異步模式，因?yàn)樗鼈兲峁┝擞赏ㄐ抛钚』鴰淼倪M(jìn)一步優(yōu)化的機(jī)會(huì)。深入支持無狀態(tài)服務(wù)是不同語境的管理可采取的措施，包括使用 WS-* 規(guī)范，如 WS- 協(xié)調(diào)與 WS-BPEL ，還有定制解決方案。

技術(shù)

分布式互聯(lián)網(wǎng)架構(gòu)背后的技術(shù)在過去幾年內(nèi)經(jīng)歷了幾個(gè)階段。初始架構(gòu)包含有構(gòu)件、服務(wù)器端腳本以及原生的 Web 技術(shù)，比如 HTML 與 HTTP 。中間件方面的進(jìn)步，允許增加處理能力及事務(wù)控制。 XML 的出現(xiàn)引入了復(fù)雜的數(shù)據(jù)表達(dá)，實(shí)際上提供了經(jīng)由互聯(lián)網(wǎng)協(xié)議傳輸?shù)臇|西。后來 Web 服務(wù)的可用性允許分布式互聯(lián)網(wǎng)應(yīng)用跨越專有平臺(tái)的邊界。

因?yàn)樵S多當(dāng)前的分布式應(yīng)用使用了 XML 與 Web 服務(wù)，有可能這些解決方案背后的技術(shù)與那些基于 SOA 的沒有太大不同。雖然一個(gè)明顯的區(qū)別在于當(dāng)代 SOA 將有可能構(gòu)建在 XML 數(shù)據(jù)表達(dá)與 Web 服務(wù)技術(shù)平臺(tái)技術(shù)之上。除了互聯(lián)網(wǎng)核心技術(shù)集和構(gòu)件的使用，沒有被傳統(tǒng)的互聯(lián)網(wǎng)應(yīng)用所統(tǒng)治的技術(shù)。因此， XML 與 Web 服務(wù)對(duì)于分布式互聯(lián)網(wǎng)架構(gòu)而言是可選的，但對(duì)于當(dāng)代 SOA 不是。

安全

當(dāng)應(yīng)用邏輯散布于多個(gè)物理邊界時(shí)，實(shí)現(xiàn)象鑒權(quán)與授權(quán)這樣的基本安全措施變得更加困難。

在兩層客戶 - 服務(wù)器環(huán)境中，一個(gè)獨(dú)有的服務(wù)器端連接可輕易實(shí)現(xiàn)用戶論證及企業(yè)數(shù)據(jù)的傳輸安全。然而，當(dāng)獨(dú)立的連接被移除時(shí)，而且要跨越不同的物理層傳播時(shí)，就需要新的安全方法。要確保信息的安全運(yùn)輸及用戶憑證的識(shí)別、同時(shí)保留原始的安全語境，可用象委托和假冒這樣傳統(tǒng)的安全架構(gòu)合成方法。加密也被加到其他廣泛而開放的 HTTP 協(xié)議方面，可在 Web 服務(wù)器之外傳送時(shí)受到保護(hù)。

SOA 通過引入對(duì)安全如何組合以及對(duì)應(yīng)用的大規(guī)模改變，從而遠(yuǎn)離了這個(gè)模型。由于嚴(yán)重依賴 WS- 安全框架所建立的擴(kuò)展和概念，在 SOA 中所用的安全模型在通訊層面上強(qiáng)調(diào)安全邏輯的安置。 SOA P 消息提供的報(bào)送區(qū)塊中可存入安全邏輯。那樣，無論消息在何方，安全也就隨之而至。這個(gè)方法需要個(gè)體自治和服務(wù)間的松散耦合，同時(shí)一個(gè)服務(wù)可完全維持在無狀態(tài)的范圍。

管理

維護(hù)基于構(gòu)件的應(yīng)用包括跟蹤單個(gè)構(gòu)件實(shí)例、本地及遠(yuǎn)程通信問題，監(jiān)控服務(wù)器資源需求，當(dāng)然，還有標(biāo)準(zhǔn)化的數(shù)據(jù)庫管理任務(wù)。分布式互聯(lián)網(wǎng)架構(gòu)進(jìn)一步引入了 Web 服務(wù)器，同時(shí)解決方案執(zhí)行時(shí)還需要關(guān)注額外的物理環(huán)境。因?yàn)榭蛻?/span> --- 不管本地的還是外部的組織 --- 使用 HTTP 連接到這些解決方案， Web 服務(wù)器就成為正式的第一接觸點(diǎn)。因此它必須設(shè)計(jì)成可擴(kuò)展的 --- 這一需求已導(dǎo)致 Web 服務(wù)器機(jī)器資源池的創(chuàng)建。

企業(yè)級(jí) SOA 典型地需要一個(gè)額外的運(yùn)行時(shí)管理。通訊框架帶來的問題（特別是工作在異步交換模式時(shí)）會(huì)比基于 RPC 的數(shù)據(jù)交換的問題更不易發(fā)現(xiàn)。這是因?yàn)殛P(guān)于消息如何交換，存在太多的變化。 RPC 通信一般需要一個(gè)來自初始構(gòu)件的響應(yīng)，表明成功還是失敗。遇到一個(gè)失敗條件，就會(huì)拋出一個(gè)異常。通訊框架的異常處理可能更復(fù)雜而更不健壯。盡管 WS-* 擴(kuò)展被定位于更好地處理這些情形，仍需努力保持高度管理。

其他維護(hù)任務(wù)，象資源管理（類似于構(gòu)件管理），同樣需要。然而，為了更好地促進(jìn)復(fù)用性及可組合性，對(duì)于企業(yè)構(gòu)建大量的 Web 服務(wù)而言，管理基礎(chǔ)設(shè)施的一個(gè)很有用部分是私有注冊。 UDDI 是一個(gè)標(biāo)準(zhǔn)化的技術(shù)，用于標(biāo)準(zhǔn)化地注冊接口，能夠手工或程序化地訪問發(fā)現(xiàn)服務(wù)描述。