3.
SOA
的根源
(SOA
與過去架構的比較
)
我們現在實際地跳回時間軸看一看過去架構與
SOA
的差別。這是一項有趣的研究，
我們能夠看出
SOA
許多當代特征的起源。
3.1.
什么是架構？
自打有計算機處理的自動化解決方案方案起，技術架構就已存在。然而，在較老的環境中，解決方案直接建構于抽象的任務上，并規定其架構很少被執行。
隨著多層應用的崛起，應用交付的變異開始劇增。
IT
部門開始認識到需要定義標準化的基線應用，作為其他應用的模板。這個定義自然是抽象的，但明確地解釋了所有解決方案以這個模板為基礎，包括其技術、邊界、規則、限制及設計特征。這就產生了應用架構。
應用架構
應用架構對于應用開發團隊的意義，相當于藍圖對于建筑工團隊的意義。不同的組織印證不同水平的應用架構。一些保持了高水平，提供技術藍圖的抽象的物理及邏輯表達。另一些則包括更多的細節，類似通用數據模型，通信流程圖，應用范圍的安全需求，以及基礎設施方面。
對于一個組織而言有幾個不同的應用架構的情況是不希奇的。一個架構文檔典型地代表了不同的解決方案環境。例如，一個同時擁有
.NET
與
J2EE
解決方案的組織很有可能針對每一種有分別的應用架構規范。
任何應用級架構的關鍵部分在于它既要直接反映解決方案的需求，同樣又要考慮長期的、策略性的
IT
目標。正由于這個緣故，組織內的應用架構會伴以企業架構，并與其中居統治地位的一個保持一致。
企業架構
在較大的
IT
環境，關鍵在于需要控制并指導
IT
基礎設施。當有很多不同的應用架構共同存在的時候，且有時甚至要整合，底層的主機平臺變會復雜而繁重。因此，通常會創建一個控制規范，為企業內存在的所有異質形態的提供高層概述，同時給出支持基礎設施的定義。
繼續我們前一個類推，對于組織而言，企業架構規范相當于一個城市的城市規劃。因此，城市規劃與建筑藍圖間的關系，可與企業與應用架構規范間的關系相類比。
典型地，企業架構的變化直接影響應用架構，這是為什么架構規范通常由同一組人來維護。而且，企業架構經常包含組織長期技術和環境發展規劃。例如，階段性的目標有可能是要立足于這個規范來逐步淘汰過時的技術平臺。
最后，也可能會定義技術與策略背后的企業級安全度量。然而，這經常會被作為單獨的安全架構規范。
面向服務架構
簡單而言，面向服務架構跨越了企業與應用架構兩個領域。當被用于跨多解決方案的環境時，
SOA
所提供的潛在效益才能真正釋放。這個是對可復用和可協同服務的投資，并且充分利用基于廠商中立的通信平臺。這并不意味著企業必須變成面向服務。
SOA
所引入的特性及特征大部分都屬于這一范疇。
注意術語“
SOA
”并不意味著一個特殊的架構范圍。
SOA
可以是指一個應用架構，或是用于跨企業的技術架構的標準化方法。因為
SOA
天生的可組合性（意味著單個的應用層架構可由不同的擴展及技術組成），完全適用于超越
SOA
的組織。
請注意，如同前一章所解釋的，
Web
服務平臺提供了眾多實現
SOA
形式中的一個。它是本書專門研究的一種方法，但是還存在其他方法，比如由傳統的分布式平臺所提供的這些。術語方面有一點很重要，就是在后面章節中及整本書中所用的術語“
SOA
”是指在第
3章
所建立的當代
SOA
模型（基于
Web
服務與面向服務原則）。
幾乎在任何環境中，只要有一段軟件從另一個請求或接收信息，都能夠被稱為“客戶
-
服務器。”幾乎每一個不同的應用架構都曾存在（包括
SOA
）一種客戶
-
服務器的交互元素。然而，行業術語“客戶
-
服務器架構”通常是指特殊的前一代環境，期間客戶端與服務器扮演了特定的角色，并有清晰的實現特征。
客戶
-
服務器架構簡史
初期龐大的主機授予組織嚴格的計算方式，通常被視作是客戶
-
服務器架構稚形。這些環境，其中龐大的主機后端伺服瘦客戶端，被看作單層客戶
-
服務器架構（
圖
2
）。
圖
2.
一
個典型的單層客戶端服務器架構
主機系統天然支持同步及異步通信。后一種方法主要用于讓服務器連續不斷地接收來自終端的字符，以響應個別的擊鍵事件。只在某種條件下服務器才會響應。
雖然它仍有殘留痕跡，但是當兩層客戶
-
服務器的變化設計在
80
年代后期出現時，主機作為最初的統治計算平臺開始衰退。
這個新方法引入了委派邏輯、以及處理職責下發到單個工作站的概念，導致了胖客戶的誕生。受圖形用戶界面（
GUI
）創新的進一步支持，兩層客戶
-
服務器被認為是前進了一大步，并在
90
年早期持續統治了
IT
界數年之久。
這個架構的通常配置包含多個胖客戶端，每一個都有自己到中心數據庫服務器連接。客戶端軟件執行大量處理，包括所有的展現相關及多數的數據訪問邏輯（
圖
3
）。一個或多個服務器通過累積可擴展的關系型數據庫管理系統，促進了這些客戶端。
圖
3.
典型的兩層客戶
-
服務器架構
讓我們通過單獨地和將它們與
SOA
的相應部分作比較兩種方式，來看一看兩層客戶
-
服務器架構的主要特征。
應用邏輯
客戶
-
服務器環境將大多數應用邏輯放到客戶端軟件中。這導致龐大的程序連同后端資源來一起來控制用戶體驗。分布式業務規則是一個例外。一個流行趨勢是將嵌入的和維護的業務規則與數據關聯，放入數據庫的存儲過程與觸發器之內。這略微抽象了一組來自客戶端的業務邏輯，并簡化了數據訪問編程。盡管如此，客戶端還是承擔著所有的展示任務。
當代面向服務解決方案中的展現層會有所不同。任何軟件片段若有能力依照所需的服務契約進行
SOA
P
消息交換，都可歸為服務請求者。同時通常也期望請求者能提供服務，展現層的設計完全開放并對應特定的解決方案需求。
在服務器環境內，存在關于應用邏輯如何駐留與分布的選擇權。這些選擇權不排除數據庫觸發器和存儲過程。同時，面向服務設計的原則開始起作用，通常指導劃分自治處理邏輯的單元。這促進了特定設計品質，比如服務無狀態化及協同性，還有可組合性及復用性。
另外，常有這些處理邏輯單元在
SOA
內不屬于任何解決方案的情形。這也支持了促進復用以及跨越應用邊界的松散耦合這一終極目標。
應用處理
因為大部分客戶
-
服務器應用邏輯駐留于客戶端，客戶端工作站負責了大量的處理。
80/20
比率常被作為一個經驗法則，按此法則數據庫服務器承擔了
20%
的工作量。盡管如此，數據還是常常成為這些環境中的性能瓶頸。
有大用戶量的兩層客戶
-
服務器解決方案，通常需要每一客戶建立其自身的數據庫連接。通信可預期是異步的，而且這些連接是永久的（意味著它們需要通過用戶登錄并保持活動直至其退出應用）。專有數據庫連接是昂貴的，并且資源需求經常壓垮數據庫服務器，給所有用戶以可觀的反應時間。
另外，假定客戶被分配以主要的處理職責，他們常要求重要的資源。客戶端執行完全是有狀態的，并要消耗大量的固定
PC
內存。用戶工作站因此經常需要專門運行客戶端程序，以便所有可用資源能夠提供給應用。
SOA
中的處理是高度分布式的，每一服務都有一個清晰的功能邊界和相關的資源需求。在面向服務架構建模技術中，對于如何能夠定位及部署服務你有很多的選擇。
企業解決方案包含多個服務器時，每一個都裝有
Web
服務并支持中間件。因此，對于
SOA
而言沒有固定的比率。服務可根據需要分布，而且在決定物理部署配置時，性能需求是要考慮的因素之一。
服務與請求者間的通信可以是同步的或是異步的。這一靈活性允許進一步改進處理，特別是使用異步的消息模式時。另外，通過在消息中放入更多的智能，可獲得消息層面的語境管理選擇。這促進了無狀態的及自治的服務本性，并進一步經歷減少對狀態信息緩存的需要。
技術
客戶
-
服務器應用的出現促進了第四代
4GL
編程語言的使用，比如
Visual Basic
與
PowerBuilder
。這些開發環境充分利用了
Windows
操作系統所提供的能力，來創建更美觀豐富、更具交互性的用戶界面。盡管如此，傳統的第三代語言，比如
C++
，仍在使用，特別是對于有更嚴格的性能需求的解決方案。在后端，主流的數據庫廠商，象
Oracle
、
Informix
、
IBM
、
Sybase
與微軟，提供了強健的關系型數據庫管理系統，能夠管理多連接，同時提供了靈活的數據存儲及數據管理特性。
SOA
所用的技術集實際上并不象它所延展的那么多。舊版本的程序語言的更新版本，象
Visual Basic
，依舊能夠用于創建
Web
服務，且依舊可以使用傳統數據庫。盡管如此，
SOA
的技術版圖已經變得日漸不同。除了
Web
技術的標準集（
HTML
、
CSS
、
HTTP
等等），當代
SOA
一并帶來了建立
XML
數據表達架構的絕對需求，還有
SOA
P
通訊框架，以及服務架構所包含的永遠擴展的
Web
服務平臺。
安全
除了數據的存儲與管理以及嵌入存儲過程和觸發器中的業務規則，安全是經常在客戶
-
服務器架構的服務器層面集中處理的另一個部分。數據庫十分復雜，足以管理用戶帳戶及用戶組長，并將其分配到物理數據模型的個別部分。
安全也能夠客戶程序中控制，特別是當它與特定應用邏輯執行的業務規則相關聯時（譬如挑選用戶對部分用戶界面進行限制訪問）。另外，與操作系統級的安全協作可實現單點登錄，此時應用直接繼承操作系統的登錄賬戶信息。
盡管有人夸耀
SOA
的優勢，許多架構師卻羨慕客戶
-
服務器的安全性。企業數據經由單點鑒權而受到保護，建立了客戶端與服務器間的單一連接。在
SOA
的分布世界中，這是不可能的。安全變成一個重要而復雜的問題，與必需的安全措施程度直接相關。牽扯到許多典型技術，大多數包含在
WS-
安全框架中
。
管理
客戶
-
服務器時代終結的一個重要原因在于相關分發的大量維護成本的增加，以及跨工作站應用邏輯的維護。因為每一個客戶裝載有應用代碼，每一次應用更新都要對所有的工作站重新分發軟件。在較大型的環境中，這造成了高度繁重的管理流程。
維護問題跨越了用戶端和服務器端。客戶工作站受特定環境問題的支配，因為不同的工作站會安裝不同的軟件程序，或者可能購買不同的硬件廠商。更有甚者，還增加了對服務器端數據庫的要求，特別是當客戶
-
服務器應用拓展到更大的用戶基礎時。
因為面向服務的解決方案會有不同的請求者，它們還要受到來自客戶端維護的挑戰。同時其分布式后端要適應應用及數據庫服務器的擴展性，會引入新的管理需求。例如，一旦
SOA
發展為服務復用并成為多服務組合的一部分，服務器資源與服務接口的管理會需要強大的管理工具，包括私用注冊的使用。