這似乎有點自相矛盾，如果
SOA
可被視作分布式互聯(lián)網架構的一種形式，同時我們初期建立早先類型的分布式架構也可被設計為
SOA
。盡管如此，且盡管現(xiàn)在的分布式環(huán)境可能已經深深地受到了面向服務原則的影響，
SOA
這樣的變化仍舊是罕見的。故而在此所提供的比較是將傳統(tǒng)的分布式互聯(lián)網架構作為其最常被設計的風格出現(xiàn)。
分布式互聯(lián)網架構簡史
為了對付兩層客戶服務器架構相關的成本與限制問題，構建基于構件應用的概念成為主流。多層客戶
-
服務器架構浮出水面，將單獨的客戶程序分解成構件設計，成為符合面向對象的不同擴展。
在構件中不同的分布式應用邏輯（一些仍駐留在客戶端，其他在服務器上），減少了大量邏輯都集中部署在服務器端的令人頭痛的問題。服務器端構件，現(xiàn)在集中于應用服務器，從而可共享數據庫連接管理池，減輕數據庫并發(fā)訪問的負擔（
圖
4
）。一個單連接就可輕易滿足多用戶要求。
圖
4.
典型的多層客戶
-
服務器架構。
獲取這些效益的代價是復雜性的增加，并且最終轉換為從部署問題到開發(fā)和管理過程的費用和努力。構建多樣化處理能力的構件，并發(fā)請求比直接為單個用戶開發(fā)一個可執(zhí)行程序更困難，而且問題多多。
另外，替代客戶
-
服務器數據庫連接的是客戶
-
服務器遠程程序調用（
RPC
）連接。象
CORBA
與
DCOM
這樣的
RPC
技術，準許客戶工作站與服務器構件間進行遠程通信。出現(xiàn)了類似客戶
-
服務器架構的問題，包括資源及永久連接。增加這個新的維護是由于引入了中間件層。比如，在大型環(huán)境中對于應用服務器及事務監(jiān)控需要特別關注。
隨著萬維網在
90
年代中后期成為一個計算技術的可用媒介，多層客戶
-
服務器環(huán)境開始組成互聯(lián)網技術。最重要的成就是軟件構件被瀏覽器所替代。這個變化不僅從根本上改變（且限制）了用戶界面設計，實際上還把
100%
的應用邏輯移到了服務器端
（
圖
5
）。
圖
5.
典型的分布式互聯(lián)網架構
分布式互聯(lián)網架構也引入了一個新的物理層，
Web
服務器。這導致
HTTP
替代了專有的
RPC
協(xié)議而用于工作站與服務器間的通信。
RPC
的角色被限制到促成遠程
Web
與應用服務器間的通信。
從
90
年代后期
2000
年中期，分布式互聯(lián)網架構對于定制開發(fā)的企業(yè)解決方案而言，代表了事實上的計算平臺。基于構件的日常編程技術及日益復雜的中間件，最終減少了一些整體復雜性。
那么，這個熟悉而又相似的架構該如何與
SOA
相比較呢？且看分布式互聯(lián)網架構與
SOA
特征部分。
注意
盡管多層客戶
-
服務器在其所有權內是一個獨特的架構，我們不提供它與
SOA
之間的比較。大多數在客戶
-
服務器及分布式互聯(lián)網架構的比較中升級的問題，掩蓋了將在多層客戶
-
服務器與
SOA
的比較中討論的問題。
應用邏輯
除了一些罕見的應用以專有擴展的方式嵌入到瀏覽器中以外，分布式互聯(lián)網應用將其所有應用邏輯放在了服務器端。甚至客戶端腳本想要執(zhí)行在網頁上的一個事件響應，都要從
Web
服務器基于初始的
HTTP
請求來下載。沒有客戶工作站上保存的邏輯，整個解決方案都是集中式的。
從而強調了：
-
應用邏輯應當如何被分割
-
被分割的處理邏輯應當駐留在何處
-
處理邏輯應當如何交互
從一個物理的角度來看，面向服務架構與分布式互聯(lián)網架構非常相似。提供者邏輯駐留于服務器端而被分割成單獨的單元。其中差異由剛剛所列三個主要設計原則所決定。
傳統(tǒng)的分布式應用包含了駐留于一個或多個應用服務器上的一系列的構件。構件設計為不同粒度的功能，依賴于所執(zhí)行的任務，以及它們被其他任務或應用的復用范圍。駐留于相同服務器的構件通過專有
API
通信，按照它們暴露的公共接口來調用。
RPC
協(xié)議被用于實現(xiàn)跨越服務器邊界的通信。這有可能通過使用代表遠程構件的本地代理存根來實現(xiàn)（
圖
6
）。
圖
6
構件通信依賴于代理存根
在設計時，預期的交互構件將與其他一起考慮
---
如此強烈以致實際對其他物理構件的引用可嵌入到程序代碼內。這個設計時水平的依賴是緊耦合的形式。這樣的稍許處理相對于試圖在運行時定位所需構件的浪費而言是有效的。然而，嵌入式耦合導致綁定構件網絡，一旦實現(xiàn)，不易更改。
當代
SOA
依然使用并依賴于構件。然而，整個建模方法現(xiàn)在會考慮創(chuàng)建封裝一些或所有構件的服務。這些服務根據面向服務原則而設計，并且策略性地定位及暴露特定的功能集。同時這個功能可由構件提供，也可源自遺留系統(tǒng)及其他資源，象來自其它套裝軟件產品的適配器接口，或者甚至是數據庫。
在服務內包裝功能的目標是經由一個開放的、標準化的接口暴露功能
---
而不用關心用于實現(xiàn)底層邏輯的技術。標準化的接口支持置于
SOA
核心的開放通信框架。而且，使用
Web
服務建立了松散耦合的環(huán)境，其中也運行著相對設計的分布式應用。如果設計得當，松散耦合的服務支持組合模型，允許單個的服務參與集合的設計。這引入了持續(xù)的復用與擴展機會。
有關分布式應用邏輯的設計與行為的另一個重要轉變在于服務如何交換信息。當傳統(tǒng)構件提供方法時，一旦被激活，就發(fā)送與接受參數數據，而
Web
服務通過
SOA
P
消息通信。即使
SOA
P
支持
RPC
風格的消息結構，大多數面向服務的
Web
服務設計卻依賴于文檔風格的消息。（這一重要差別在后面探究。）
消息也是結構化的并盡可能是自足的。通過使用
SOA
P
報頭，消息內容可以伴隨闃寬泛的元信息、處理指導以及策略規(guī)則。與純粹構件世界內的數據交換相比較，
SOA
所用的通訊框架更加復雜、更加龐大，并且更易導致少數的個別傳輸。
最后，盡管也普遍強調復用傳統(tǒng)的分布式設計方法，
SOA
可通過促進解決方案未知服務的創(chuàng)建鼓勵復用以及深層次的跨應用協(xié)同。
應用處理
不管什么平臺、構件都代表了最大部分的應用邏輯并因此負責大多數的處理。然而，因為用于構件間通信的技術不同于完成服務間通信的技術，處理需求也是如此。
分布式互聯(lián)網架構促進專有通信協(xié)議的使用，象用于遠程數據交換的
DCOM
和廠商實現(xiàn)的
CORBA
。當這些技術遭遇歷史性挑戰(zhàn)時，它們相對是有效可靠的，特別是一旦有主動連接時。它們能夠支持有狀態(tài)和無狀態(tài)構件的創(chuàng)建，主要影響同步數據交換（一些平臺支持異步通信，但并未普遍使用）。
另一方面，
SOA
依賴基于消息的通信。包括負載有
XML
文檔的
SOA
P
消息序列化、傳輸及去序列化。處理步驟會包括將關系數據轉換成
XML
兼容結構、
XML
文檔預校驗以及隨后的傳輸、以及對所接收文檔進行解析和抽取。盡管已有所進步，譬如企業(yè)解析器及硬件的持續(xù)加速，大部分還是抱怨
SOA
P
比
RPC
通信明顯要慢一些。
在面向服務應用環(huán)境中，因為
SOA
P
服務器的網絡能夠有效代替
RPC
風格的通信通道，導致系統(tǒng)開銷成為一個重要的設計問題。文檔與消息建模規(guī)約及校驗邏輯的布置策略是重要因素，形成了面向服務架構的傳輸層。
這個通訊框架促進了自治服務的創(chuàng)建，支持寬泛的消息交換模式。盡管完全支持同步通信，但還是鼓勵異步模式，因為它們提供了由通信最小化而帶來的進一步優(yōu)化的機會。深入支持無狀態(tài)服務是不同語境的管理可采取的措施，包括使用
WS-*
規(guī)范，如
WS-
協(xié)調與
WS-BPEL
，還有定制解決方案。
技術
分布式互聯(lián)網架構背后的技術在過去幾年內經歷了幾個階段。初始架構包含有構件、服務器端腳本以及原生的
Web
技術，比如
HTML
與
HTTP
。中間件方面的進步，允許增加處理能力及事務控制。
XML
的出現(xiàn)引入了復雜的數據表達，實際上提供了經由互聯(lián)網協(xié)議傳輸的東西。后來
Web
服務的可用性允許分布式互聯(lián)網應用跨越專有平臺的邊界。
因為許多當前的分布式應用使用了
XML
與
Web
服務，有可能這些解決方案背后的技術與那些基于
SOA
的沒有太大不同。雖然一個明顯的區(qū)別在于當代
SOA
將有可能構建在
XML
數據表達與
Web
服務技術平臺技術之上。除了互聯(lián)網核心技術集和構件的使用，沒有被傳統(tǒng)的互聯(lián)網應用所統(tǒng)治的技術。因此，
XML
與
Web
服務對于分布式互聯(lián)網架構而言是可選的，但對于當代
SOA
不是。
安全
當應用邏輯散布于多個物理邊界時，實現(xiàn)象鑒權與授權這樣的基本安全措施變得更加困難。
在兩層客戶
-
服務器環(huán)境中，一個獨有的服務器端連接可輕易實現(xiàn)用戶論證及企業(yè)數據的傳輸安全。然而，當獨立的連接被移除時，而且要跨越不同的物理層傳播時，就需要新的安全方法。要確保信息的安全運輸及用戶憑證的識別、同時保留原始的安全語境，可用象委托和假冒這樣傳統(tǒng)的安全架構合成方法。加密也被加到其他廣泛而開放的
HTTP
協(xié)議方面，可在
Web
服務器之外傳送時受到保護。
SOA
通過引入對安全如何組合以及對應用的大規(guī)模改變，從而遠離了這個模型。由于嚴重依賴
WS-
安全框架所建立的擴展和概念，在
SOA
中所用的安全模型在通訊層面上強調安全邏輯的安置。
SOA
P
消息提供的報送區(qū)塊中可存入安全邏輯。那樣，無論消息在何方，安全也就隨之而至。這個方法需要個體自治和服務間的松散耦合，同時一個服務可完全維持在無狀態(tài)的范圍。
管理
維護基于構件的應用包括跟蹤單個構件實例、本地及遠程通信問題，監(jiān)控服務器資源需求，當然，還有標準化的數據庫管理任務。分布式互聯(lián)網架構進一步引入了
Web
服務器，同時解決方案執(zhí)行時還需要關注額外的物理環(huán)境。因為客戶
---
不管本地的還是外部的組織
---
使用
HTTP
連接到這些解決方案，
Web
服務器就成為正式的第一接觸點。因此它必須設計成可擴展的
---
這一需求已導致
Web
服務器機器資源池的創(chuàng)建。
企業(yè)級
SOA
典型地需要一個額外的運行時管理。通訊框架帶來的問題（特別是工作在異步交換模式時）會比基于
RPC
的數據交換的問題更不易發(fā)現(xiàn)。這是因為關于消息如何交換，存在太多的變化。
RPC
通信一般需要一個來自初始構件的響應，表明成功還是失敗。遇到一個失敗條件，就會拋出一個異常。通訊框架的異常處理可能更復雜而更不健壯。盡管
WS-*
擴展被定位于更好地處理這些情形，仍需努力保持高度管理。
其他維護任務，象資源管理（類似于構件管理），同樣需要。然而，為了更好地促進復用性及可組合性，對于企業(yè)構建大量的
Web
服務而言，管理基礎設施的一個很有用部分是私有注冊。
UDDI
是一個標準化的技術，用于標準化地注冊接口，能夠手工或程序化地訪問發(fā)現(xiàn)服務描述。