軟件業從最初的面向過程、面向對象，到后來的面向組件、面向集成，直到現在的面向服務，走過了一條螺旋上升的曲線。其實，自從上世紀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) 的方法相比。它們都有特定的結構化接口，并且返回結構化的響應。完全同方法一樣，特定操作的執行可能涉及調用附加的操作。
·服務:代表操作的邏輯分組。服務可以分層，以降低耦合度和復雜性。一個服務的粒度(granularity)大小也與系統的性能息息相關。粒度太小，會增加服務間互操作通訊的開銷;粒度太大，又會影響服務面對需求變化的敏捷性。
·業務流程:為實現特定業務目標而執行的一組長期運行的動作或活動。業務流程通常包括多個業務調用。
在SOA中，業務流程包括依據一組業務規則按照有序序列執行的一系列操作。操作的排序、選擇和執行稱為服務或流程編排。典型的情況是調用已編排服務來響應業務事件。從建模的觀點來看，由此帶來的挑戰是如何描述設計良好的操作、服務和流程抽象的特征以及如何系統地構造它們。這些涉及服務建模、特征抽取的問題已經成為現階段人們關注的焦點。
