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