管理
客戶-服務器時代終結的一個重要原因在于相關分發的大量維護成本的增加，以及跨工作站應用邏輯的維護。因為每一個客戶裝載有應用代碼，每一次應用更新都要對所有的工作站重新分發軟件。在較大型的環境中，這造成了高度繁重的管理流程。
維護問題跨越了用戶端和服務器端�？蛻艄ぷ髡臼芴囟ōh境問題的支配，因為不同的工作站會安裝不同的軟件程序，或者可能購買不同的硬件廠商。更有甚者，還增加了對服務器端數據庫的要求，特別是當客戶-服務器應用拓展到更大的用戶基礎時。
因為面向服務的解決方案會有不同的請求者，它們還要受到來自客戶端維護的挑戰。同時其分布式后端要適應應用及數據庫服務器的擴展性，會引入新的管理需求。例如，一旦SOA發展為服務復用并成為多服務組合的一部分，服務器資源與服務接口的管理會需要強大的管理工具，包括私用注冊的使用。
3.3. 比較SOA與分布式互聯網架構
這似乎有點自相矛盾，如果SOA可被視作分布式互聯網架構的一種形式，同時我們初期建立早先類型的分布式架構也可被設計為SOA。盡管如此，且盡管現在的分布式環境可能已經深深地受到了面向服務原則的影響，SOA這樣的變化仍舊是罕見的。故而在此所提供的比較是將傳統的分布式互聯網架構作為其最常被設計的風格出現。
分布式互聯網架構簡史
為了對付兩層客戶服務器架構相關的成本與限制問題，構建基于構件應用的概念成為主流。多層客戶-服務器架構浮出水面，將單獨的客戶程序分解成構件設計，成為符合面向對象的不同擴展。
在構件中不同的分布式應用邏輯(一些仍駐留在客戶端，其他在服務器上)，減少了大量邏輯都集中部署在服務器端的令人頭痛的問題。服務器端構件，現在集中于應用服務器，從而可共享數據庫連接管理池，減輕數據庫并發訪問的負擔(圖4)。一個單連接就可輕易滿足多用戶要求。
圖4. 典型的多層客戶-服務器架構。
獲取這些效益的代價是復雜性的增加，并且最終轉換為從部署問題到開發和管理過程的費用和努力。構建多樣化處理能力的構件，并發請求比直接為單個用戶開發一個可執行程序更困難，而且問題多多。
另外，替代客戶-服務器數據庫連接的是客戶-服務器遠程程序調用(RPC)連接。象CORBA與DCOM這樣的RPC技術，準許客戶工作站與服務器構件間進行遠程通信。出現了類似客戶-服務器架構的問題，包括資源及永久連接。增加這個新的維護是由于引入了中間件層。比如，在大型環境中對于應用服務器及事務監控需要特別關注。
隨著萬維網在90年代中后期成為一個計算技術的可用媒介，多層客戶-服務器環境開始組成互聯網技術。最重要的成就是軟件構件被瀏覽器所替代。這個變化不僅從根本上改變(且限制)了用戶界面設計，實際上還把100%的應用邏輯移到了服務器端 (圖5)。
圖5. 典型的分布式互聯網架構
分布式互聯網架構也引入了一個新的物理層，Web服務器。這導致HTTP替代了專有的RPC協議而用于工作站與服務器間的通信。RPC的角色被限制到促成遠程Web與應用服務器間的通信。
從90年代后期2000年中期，分布式互聯網架構對于定制開發的企業解決方案而言，代表了事實上的計算平臺�；跇嫾娜粘＞幊碳夹g及日益復雜的中間件，最終減少了一些整體復雜性。
那么，這個熟悉而又相似的架構該如何與SOA相比較呢?且看分布式互聯網架構與SOA特征部分。
注意：
盡管多層客戶-服務器在其所有權內是一個獨特的架構，我們不提供它與SOA之間的比較。大多數在客戶-服務器及分布式互聯網架構的比較中升級的問題，掩蓋了將在多層客戶-服務器與SOA的比較中討論的問題。
文章來源于領測軟件測試網 http://www.kjueaiud.com/
