clant

3.3. 比較 SOA 與分布式互聯網架構

這似乎有點自相矛盾，如果 SOA 可被視作分布式互聯網架構的一種形式，同時我們初期建立早先類型的分布式架構也可被設計為 SOA 。盡管如此，且盡管現在的分布式環境可能已經深深地受到了面向服務原則的影響， SOA 這樣的變化仍舊是罕見的。故而在此所提供的比較是將傳統的分布式互聯網架構作為其最常被設計的風格出現。

分布式互聯網架構簡史

為了對付兩層客戶服務器架構相關的成本與限制問題，構建基于構件應用的概念成為主流。多層客戶 - 服務器架構浮出水面，將單獨的客戶程序分解成構件設計，成為符合面向對象的不同擴展。

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

圖 4. 典型的多層客戶 - 服務器架構。

獲取這些效益的代價是復雜性的增加，并且最終轉換為從部署問題到開發和管理過程的費用和努力。構建多樣化處理能力的構件，并發請求比直接為單個用戶開發一個可執行程序更困難，而且問題多多。

另外，替代客戶 - 服務器數據庫連接的是客戶 - 服務器遠程程序調用（ RPC ）連接。象 CORBA 與 DCOM 這樣的 RPC 技術，準許客戶工作站與服務器構件間進行遠程通信。出現了類似客戶 - 服務器架構的問題，包括資源及永久連接。增加這個新的維護是由于引入了中間件層。比如，在大型環境中對于應用服務器及事務監控需要特別關注。

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

圖 5. 典型的分布式互聯網架構

分布式互聯網架構也引入了一個新的物理層， Web 服務器。這導致 HTTP 替代了專有的 RPC 協議而用于工作站與服務器間的通信。 RPC 的角色被限制到促成遠程 Web 與應用服務器間的通信。

從 90 年代后期 2000 年中期，分布式互聯網架構對于定制開發的企業解決方案而言，代表了事實上的計算平臺。基于構件的日常編程技術及日益復雜的中間件，最終減少了一些整體復雜性。

那么，這個熟悉而又相似的架構該如何與 SOA 相比較呢？且看分布式互聯網架構與 SOA 特征部分。

注意

盡管多層客戶 - 服務器在其所有權內是一個獨特的架構，我們不提供它與 SOA 之間的比較。大多數在客戶 - 服務器及分布式互聯網架構的比較中升級的問題，掩蓋了將在多層客戶 - 服務器與 SOA 的比較中討論的問題。

應用邏輯

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

從而強調了：

• 應用邏輯應當如何被分割
• 被分割的處理邏輯應當駐留在何處
• 處理邏輯應當如何交互

從一個物理的角度來看，面向服務架構與分布式互聯網架構非常相似。提供者邏輯駐留于服務器端而被分割成單獨的單元。其中差異由剛剛所列三個主要設計原則所決定。

傳統的分布式應用包含了駐留于一個或多個應用服務器上的一系列的構件。構件設計為不同粒度的功能，依賴于所執行的任務，以及它們被其他任務或應用的復用范圍。駐留于相同服務器的構件通過專有 API 通信，按照它們暴露的公共接口來調用。 RPC 協議被用于實現跨越服務器邊界的通信。這有可能通過使用代表遠程構件的本地代理存根來實現（ 圖 6 ）。

圖 6 構件通信依賴于代理存根

在設計時，預期的交互構件將與其他一起考慮 --- 如此強烈以致實際對其他物理構件的引用可嵌入到程序代碼內。這個設計時水平的依賴是緊耦合的形式。這樣的稍許處理相對于試圖在運行時定位所需構件的浪費而言是有效的。然而，嵌入式耦合導致綁定構件網絡，一旦實現，不易更改。

當代 SOA 依然使用并依賴于構件。然而，整個建模方法現在會考慮創建封裝一些或所有構件的服務。這些服務根據面向服務原則而設計，并且策略性地定位及暴露特定的功能集。同時這個功能可由構件提供，也可源自遺留系統及其他資源，象來自其它套裝軟件產品的適配器接口，或者甚至是數據庫。

在服務內包裝功能的目標是經由一個開放的、標準化的接口暴露功能 --- 而不用關心用于實現底層邏輯的技術。標準化的接口支持置于 SOA 核心的開放通信框架。而且，使用 Web 服務建立了松散耦合的環境，其中也運行著相對設計的分布式應用。如果設計得當，松散耦合的服務支持組合模型，允許單個的服務參與集合的設計。這引入了持續的復用與擴展機會。

有關分布式應用邏輯的設計與行為的另一個重要轉變在于服務如何交換信息。當傳統構件提供方法時，一旦被激活，就發送與接受參數數據，而 Web 服務通過 SOA P 消息通信。即使 SOA P 支持 RPC 風格的消息結構，大多數面向服務的 Web 服務設計卻依賴于文檔風格的消息。（這一重要差別在后面探究。）

消息也是結構化的并盡可能是自足的。通過使用 SOA P 報頭，消息內容可以伴隨闃寬泛的元信息、處理指導以及策略規則。與純粹構件世界內的數據交換相比較， SOA 所用的通訊框架更加復雜、更加龐大，并且更易導致少數的個別傳輸。

最后，盡管也普遍強調復用傳統的分布式設計方法， SOA 可通過促進解決方案未知服務的創建鼓勵復用以及深層次的跨應用協同。

應用處理

不管什么平臺、構件都代表了最大部分的應用邏輯并因此負責大多數的處理。然而，因為用于構件間通信的技術不同于完成服務間通信的技術，處理需求也是如此。

分布式互聯網架構促進專有通信協議的使用，象用于遠程數據交換的 DCOM 和廠商實現的 CORBA 。當這些技術遭遇歷史性挑戰時，它們相對是有效可靠的，特別是一旦有主動連接時。它們能夠支持有狀態和無狀態構件的創建，主要影響同步數據交換（一些平臺支持異步通信，但并未普遍使用）。

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

在面向服務應用環境中，因為 SOA P 服務器的網絡能夠有效代替 RPC 風格的通信通道，導致系統開銷成為一個重要的設計問題。文檔與消息建模規約及校驗邏輯的布置策略是重要因素，形成了面向服務架構的傳輸層。

這個通訊框架促進了自治服務的創建，支持寬泛的消息交換模式。盡管完全支持同步通信，但還是鼓勵異步模式，因為它們提供了由通信最小化而帶來的進一步優化的機會。深入支持無狀態服務是不同語境的管理可采取的措施，包括使用 WS-* 規范，如 WS- 協調與 WS-BPEL ，還有定制解決方案。

技術

分布式互聯網架構背后的技術在過去幾年內經歷了幾個階段。初始架構包含有構件、服務器端腳本以及原生的 Web 技術，比如 HTML 與 HTTP 。中間件方面的進步，允許增加處理能力及事務控制。 XML 的出現引入了復雜的數據表達，實際上提供了經由互聯網協議傳輸的東西。后來 Web 服務的可用性允許分布式互聯網應用跨越專有平臺的邊界。

因為許多當前的分布式應用使用了 XML 與 Web 服務，有可能這些解決方案背后的技術與那些基于 SOA 的沒有太大不同。雖然一個明顯的區別在于當代 SOA 將有可能構建在 XML 數據表達與 Web 服務技術平臺技術之上。除了互聯網核心技術集和構件的使用，沒有被傳統的互聯網應用所統治的技術。因此， XML 與 Web 服務對于分布式互聯網架構而言是可選的，但對于當代 SOA 不是。

安全

當應用邏輯散布于多個物理邊界時，實現象鑒權與授權這樣的基本安全措施變得更加困難。

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

SOA 通過引入對安全如何組合以及對應用的大規模改變，從而遠離了這個模型。由于嚴重依賴 WS- 安全框架所建立的擴展和概念，在 SOA 中所用的安全模型在通訊層面上強調安全邏輯的安置。 SOA P 消息提供的報送區塊中可存入安全邏輯。那樣，無論消息在何方，安全也就隨之而至。這個方法需要個體自治和服務間的松散耦合，同時一個服務可完全維持在無狀態的范圍。

管理

維護基于構件的應用包括跟蹤單個構件實例、本地及遠程通信問題，監控服務器資源需求，當然，還有標準化的數據庫管理任務。分布式互聯網架構進一步引入了 Web 服務器，同時解決方案執行時還需要關注額外的物理環境。因為客戶 --- 不管本地的還是外部的組織 --- 使用 HTTP 連接到這些解決方案， Web 服務器就成為正式的第一接觸點。因此它必須設計成可擴展的 --- 這一需求已導致 Web 服務器機器資源池的創建。

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

其他維護任務，象資源管理（類似于構件管理），同樣需要。然而，為了更好地促進復用性及可組合性，對于企業構建大量的 Web 服務而言，管理基礎設施的一個很有用部分是私有注冊。 UDDI 是一個標準化的技術，用于標準化地注冊接口，能夠手工或程序化地訪問發現服務描述。