SOA進化之SOA的根源(1)

本文審視XML、Web服務及SOA間的關系，并解釋廠商和標準組織如何從那些持續浮現的Web服務規范中形成奇妙的競爭與協同競技場。然后我們從應用架構簡短歷史的敘述著手來對過去的二十年作一個總結。

　　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服務與面向服務原則)。

　　3.2. 比較SOA與客戶-服務器架構

　　幾乎在任何環境中，只要有一段軟件從另一個請求或接收信息，都能夠被稱為“客戶-服務器?！睅缀趺恳粋€不同的應用架構都曾存在(包括 SOA)一種客戶-服務器的交互元素。然而，行業術語“客戶-服務器架構”通常是指特殊的前一代環境，期間客戶端與服務器扮演了特定的角色，并有清晰的實現特征。

　　客戶-服務器架構簡史

　　初期龐大的主機授予組織嚴格的計算方式，通常被視作是客戶-服務器架構稚形。這些環境，其中龐大的主機后端伺服瘦客戶端，被看作單層客戶-服務器架構(圖2)。

　　　　

圖2. 一個典型的單層客戶端服務器架構

　　主機系統天然支持同步及異步通信。后一種方法主要用于讓服務器連續不斷地接收來自終端的字符，以響應個別的擊鍵事件。只在某種條件下服務器才會響應。

　　雖然它仍有殘留痕跡，但是當兩層客戶-服務器的變化設計在80年代后期出現時，主機作為最初的統治計算平臺開始衰退。

　　這個新方法引入了委派邏輯、以及處理職責下發到單個工作站的概念，導致了胖客戶的誕生。受圖形用戶界面(GUI)創新的進一步支持，兩層客戶-服務器被認為是前進了一大步，并在90年早期持續統治了IT界數年之久。

　　這個架構的通常配置包含多個胖客戶端，每一個都有自己到中心數據庫服務器連接?？蛻舳塑浖绦写罅刻幚?，包括所有的展現相關及多數的數據訪問邏輯(圖3)。一個或多個服務器通過累積可擴展的關系型數據庫管理系統，促進了這些客戶端。

　　　　

圖3. 典型的兩層客戶-服務器架構

　　讓我們通過單獨地和將它們與SOA的相應部分作比較兩種方式，來看一看兩層客戶-服務器架構的主要特征。

應用邏輯

客戶-服務器環境將大多數應用邏輯放到客戶端軟件中。這導致龐大的程序連同后端資源來一起來控制用戶體驗。分布式業務規則是一個例外。一個流行趨勢是將嵌入的和維護的業務規則與數據關聯，放入數據庫的存儲過程與觸發器之內。這略微抽象了一組來自客戶端的業務邏輯，并簡化了數據訪問編程。盡管如此，客戶端還是承擔著所有的展示任務。

當代面向服務解決方案中的展現層會有所不同。任何軟件片段若有能力依照所需的服務契約進行SOAP消息交換，都可歸為服務請求者。同時通常也期望請求者能提供服務，展現層的設計完全開放并對應特定的解決方案需求。

在服務器環境內，存在關于應用邏輯如何駐留與分布的選擇權。這些選擇權不排除數據庫觸發器和存儲過程。同時，面向服務設計的原則開始起作用，通常指導劃分自治處理邏輯的單元。這促進了特定設計品質，比如服務無狀態化及協同性，還有可組合性及復用性。

另外，常有這些處理邏輯單元在SOA內不屬于任何解決方案的情形。這也支持了促進復用以及跨越應用邊界的松散耦合這一終極目標。

原文轉自：http://www.kjueaiud.com