認清面向服務架構（SOA）的本來面目

軟體業從最初的面向過程、面向對象，到後來的面向元件、面向內建，直到現在的面向服務，走過了一條螺旋上升的曲線。其實，自從上世紀70年代提出“軟體危機”，誕生軟體工程學科以來，為了徹底擺脫軟體系統開發泥潭，一直也沒有放棄努力。

　　在經典軟體工程理論中，不管是瀑布方法還是原型方法，都是從需求分析做起，一步一步建構起形形色色的軟體系統。但是，需求變更像一個揮之不去的陰影，時刻伴随着系統左右。每一個實際應用系統的開發者都飽嘗了在系統進入開發階段、測試階段，甚至上線階段遭遇應接不暇的需求變更的極端痛苦。客戶将變更的需求視為bug(錯誤)是測試上線階段的主要問題。

　　如何解決這一問題?能否來一場軟體開發和架構的革命?SOA架構的提出，就是被人看成這樣的一場革命。其實質就是要将系統模型與系統實作分割開來。

　　1.定義

　　SOA并不是一個新概念，有人就将CORBA和DCOM等元件模型看成SOA架構的前身。早在1996年，Gartner Group就已經提出了SOA的預言，不過那個時候僅僅是一個“預言”，當時的軟體發展水準和資訊化程度還不足以支撐這樣的概念走進實質性應用階段。到了近一兩年，SOA的技術實作手段漸漸成熟了。在BEA、IBM等軟體巨頭的極力推動下，才得以慢慢風行起來。Gartner為SOA描述的願景目标是實作實時企業(Real-Time Enterprise)。

　　關于SOA，目前尚未有一個統一的、業界廣泛接受的定義。一般認為:SOA，面向服務的架構是一個元件模型，它将應用程式的不同功能單元----服務(service)，通過服務間定義良好的接口和契約(contract)聯系起來。接口采用中立的方式定義，獨立于具體實作服務的硬體平台、作業系統和程式設計語言，使得建構在這樣的系統中的服務可以使用統一和标準的方式進行通信。這種具有中立的接口定義(沒有強制綁定到特定的實作上)的特征稱為服務之間的松耦合。

　　從這個定義中，我們看到下面兩點:

　　·軟體系統架構: SOA不是一種語言，也不是一種具體的技術，更不是一種産品，而是一種軟體系統架構，它嘗試給出在特定環境下推薦采用的一種架構，從這個角度上來說，它其實更像一種架構模式(Pattern)，是一種理念架構，是人們面向應用服務的解決方案架構。

　　·服務(service)是整個SOA實作的核心。SOA架構的基本元素是服務，SOA 指定一組實體(服務提供者、服務消費者、服務系統資料庫、服務條款、服務代理和服務契約)，這些實體詳細說明了如何提供和消費服務。遵循 SOA 觀點的系統必須要有服務，這些服務是可互操作的、獨立的、子產品化的、位置明确的、松耦合的并且可以通過網絡查找其位址。

　　2.SOA三種角色的關系

　　服務是一個自包含的、無狀态(stateless)的實體，可以由多個元件組成。它通過事先定義的界面響應服務請求。它也可以執行諸如編輯和處理事務(transaction)等離散性任務。服務本身并不依賴于其他函數和過程的狀态。用什麼技術實作服務，并不在其定義中加以限制。

　　服務提供者(service provider)提供符合契約(contract)的服務，并将它們釋出到服務代理。

　　服務請求者(service consumer)也叫服務使用者，它發現并調用其他的軟體服務來提供商業解決方案。從概念上來說，SOA 本質上是将網絡、傳輸協定和安全細節留給特定的實作來處理。服務請求者通常稱為用戶端，但是，也可以是終端使用者應用程式或别的服務。

　　服務代理者(service broker)作為儲存庫、電話黃頁或票據交換所，産生由服務提供者釋出的軟體接口。

　　這三種 SOA 參與者:服務提供者、服務代理者以及服務請求者通過 3 個基本操作:釋出(publish)、查找(find)、綁定(bind)互相作用。服務提供者向服務代理者釋出服務。服務請求者通過服務代理者查找所需的服務，并綁定到這些服務上。服務提供者和服務請求者之間可以互動。

　　所謂服務的無狀态，是指服務不依賴于任何事先設定的條件，是狀态無關的(state-free)。在SOA架構中，一個服務不會依賴于其他服務的狀态。 它們從用戶端接受服務請求。因為服務是無狀态的，它們可以被編排(orchestrated)和序列化(sequenced)成多個序列 (有時還采用流水線機制) ，以執行商業邏輯。編排指的是序列化服務并提供資料處理邏輯。但不包括資料的展現功能。

　　3.SOA特征

　　基于上面讨論，我們給出SOA的下面一些特征:

　　·服務的封裝(encapsulation)。将服務封裝成用于業務流程的可重用元件的應用程式函數。它提供資訊或簡化業務資料從一個有效的、一緻的狀态向另一個狀态的轉變。封裝隐藏了複雜性。服務的API保持不變，使得使用者遠離具體實施上的變更。

　　·服務的重用(reuse)。服務的可重用性設計顯著地降低了成本。為了實作可重用性，服務隻工作在特定處理過程的上下文(context)中，獨立于底層實作和客戶需求的變更。

　　·服務的互操作(interoperability)。互操作并不是一個新概念。在CORBA、DCOM、web service中就已經采用互操作技術了。在SOA中，通過服務之間既定的通信協定進行互操作。主要有同步和異步兩種通信機制。SOA提供服務的互操作特性更利于其在多個場合被重用。

　　·服務是自治的(Autonomous)功能實體。服務是由元件組成的組合子產品，是自包含和子產品化的。

　　SOA非常強調架構中提供服務的功能實體的完全獨立自主的能力。傳統的元件技術，如.NET Remoting， EJB，COM或者CORBA，都需要有一個宿主(Host或者Server)來存放和管理這些功能實體;當這些宿主運作結束時這些元件的壽命也随之結束。這樣當宿主本身或者其它功能部分出現問題的時候，在該宿主上運作的其它應用服務就會受到影響。

　　SOA架構中非常強調實體自我管理和恢複能力。常見的用來進行自我恢複的技術，比如事務處理(Transaction)，消息隊列(Message Queue)，備援部署(Redundant Deployment)和叢集系統(Cluster)在SOA中都起到至關重要的作用。

　　·服務之間的松耦合度(Loosly Coupled)。服務請求者到服務提供者的綁定與服務之間應該是松耦合的。這就意味着，服務請求者不知道提供者實作的技術細節，比如程式設計語言、部署平台，等等。服務請求者往往通過消息調用操作，請求消息和響應，而不是通過使用 API 和檔案格式。

　　這個松耦合使會話一端的軟體可以在不影響另一端的情況下發生改變，前提是消息模式保持不變。在一個極端的情況下，服務提供者可以将以前基于遺留代碼(例如，COBOL)的實作完全用基于 Java 語言的新代碼取代，同時又不對服務請求者造成任何影響。這種情況是真實的，隻要新代碼支援相同的通信協定。

　　·服務是位置透明的(location transparency)。服務是針對業務需求設計的。需要反應需求的變化，即所謂靈活(agility)設計。要想真正實作業務與服務的分離。就必須使得服務的設計和部署對使用者來說是完全透明的。也就是說，使用者完全不必知道響應自己需求的服務的位置，甚至不必知道具體是哪個服務參與了響應。

　　4.三個抽象級

　　從概念上講，SOA 中有三個主要的抽象級别:

　　·操作:代表單個邏輯工作單元(LUW)的事務。執行操作通常會導緻讀、寫或修改一個或多個持久性資料。SOA 操作可以直接與面向對象 (OO) 的方法相比。它們都有特定的結構化接口，并且傳回結構化的響應。完全同方法一樣，特定操作的執行可能涉及調用附加的操作。