SOA簡介

內容簡介

SOA是英文Service-Oriented Architecture，即服務導向架構的縮寫。這個詞彙最近一兩年頻頻出現在各種技術期刊上。但是一直以來對於SOA到底是什麼一直沒有明確的回答；SOA有什麼特點？適合用於解決哪些問題？與其他的技術有什麼區別與聯絡？Web Service和SOA又是什麼關係？SOA的出現對於軟體架構設計有什麼影響？本文將就上面提到的這些問題，嘗試根據作者自己的理解給出SOA的定義；總結出SOA特有的三個基本特徵；然後以HTTP協議為例對這些特徵進行解釋；最後簡要的說明SOA對今後軟體架構設計可能帶來的影響。

SOA定義

下面是作者給SOA下的一個定義：SOA是指為瞭解決在Internet環境下業務整合的需要，通過串連能完成特定任務的獨立功能實體實現的一種軟體系統架構。從這個定義中我希望表達的前提有下面兩點：

１）軟體系統架構： SOA不是一種語言，也不是一種具體的技術而是一種軟體系統架構，它嘗試給出在特定環境下推薦採用的一種架構，從這個角度上來說，它更像一種模式(Pattern)。因此它與很多已有的軟體技術比如物件導向技術，是互補的而非互斥的。它們分別面向不同的應用情境，用來滿足不同的特定需求。

２）SOA的使用範圍：需求決定同時也限制功能。SOA並不是包治百病的萬靈單，它最主要的應用場合在於解決在Internet環境下的不同商業應用之間的業務整合問題。在下面我們會詳細討論Internet的各種特點是如何決定了SOA的特點，這裡我們只需要先簡單回顧一下Internet環境區別於Intranet環境的幾個特點：ａ）大量異構系統並存，電腦硬體工作方式不同，作業系統不同、程式設計語言也不同；ｂ）大量、頻繁的資料轉送仍然速度緩慢並且不穩定；ｃ）版本升級無法完成，我們根本就無法知道互連網上有哪些機器直接或者間接的使用某個服務。

基於上面的前提，下面就讓我們一起看一下SOA的基本特徵。

SOA三大基本特徵 獨立的功能實體

在Internet這樣鬆散的使用環境中，任何訪問請求都有可能出錯，因此任何企圖通過Internet進行控制的結構都會面臨嚴重的穩定性問題。SOA非常強調架構中提供服務的功能實體的完全獨立自主的能力。傳統的組件技術，如.NET Remoting， EJB，COM或者CORBA，都需要有一個宿主(Host或者Server)來存放和管理這些功能實體；當這些宿主運行結束時這些組件的壽命也隨之結束。這樣當宿主本身或者其它功能部分出現問題的時候，在該宿主上啟動並執行其它應用服務就會受到影響。

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

大資料量低頻率訪問

對於.NET Remoting，EJB或者XML-RPC這些傳統的分散式運算模型而言，他們的服務提供都是通過函數調用的方式進行的，一個功能的完成往往需要通過用戶端和伺服器來回很多次函數調用才能完成。在Intranet的環境下，這些調用給系統的響應速度和穩定性帶來的影響都可以忽略不計，但是在Internet環境下這些因素往往是決定整個系統是否能正常工作的一個關鍵決定因素。因此SOA系統推薦採用大資料量的方式一次性進行資訊交換。

基於文本的訊息傳遞

由於Internet中大量異構系統的存在決定了SOA系統必須採用基於文本而非二進位的訊息傳遞方式。在COM、CORBA這些傳統的組件模型中，從伺服器端傳往用戶端的是一個二進位編碼的對象，在用戶端通過調用這個對象的方法來完成某些功能；但是在Internet環境下，不同語言，不同平台對資料、甚至是一些基礎資料型別 (Elementary Data Type)定義不同，給不同的服務之間傳遞對象帶來的很大困難。由於基於文本的訊息本身是不包含任何處理邏輯和資料類型的，因此服務間只傳遞文本，對資料的處理依賴於接收端的方式可以幫忙繞過相容性這個的大泥坑。

此外，對於一個服務來說，Internet與區域網路最大的一個區別就是在Internet上的版本管理極其困難，傳統軟體採用的升級方式在這種鬆散的分布式環境中幾乎無法進行。採用基於文本的訊息傳遞方式，資料處理端可以只選擇性的處理自己理解的那部分資料，而忽略其它的資料，從而得到的非常理想的相容性。

HTTP協議：一個典型的SOA實現

每一項新技術都是在一些舊的技術基礎上發展出來的。正如XML根本思想來自於在60年代就已經出現的早期標記性語言一樣，SOA雖然這兩年才出現，但是它所表達的觀念應該說在網路這種分布式系統結構出現不久就已經廣泛應用了。例如我們最熟悉的HTTP協議就是一個非常典型的SOA架構設計。HTTP協議的工作過程簡單敘述如下：

１）用戶端，通常是通過瀏覽器，向伺服器端以文本的方式發送一個請求，索取一個Web頁面；

２）伺服器端接收到這個請求之後，根據請求的內容進行處理並且返回一個符合HTML文法的文本；

３）用戶端接收到伺服器端的響應文本後調用本地的程式，通常還是瀏覽器，把返回的HTML文本的內容展現出來。

下面來看一下HTTP協議如何滿足了SOA的特點：

• 獨立的功能實體：作為伺服器端的Web伺服器是絕對不會因為用戶端的狀況變化而改變的，它總是非常穩定的按照自己的內在邏輯運行，響應外部的請求，管理自己的資源和資料。這裡一個非常好的例子就是Web伺服器對緩衝(Cache)的處理，很多Web伺服器為了提高效能都或多或少的對資料進行緩衝，但是快取資料、重新整理資料這些於用戶端完全無關的操作完全由伺服器端獨立完成，完全不受用戶端的影響。
• 大資料量低頻率訪問：對於一個HTTP請求來說，用戶端與伺服器之間訪問的邊界非常簡單：就是一個請求，一個響應，沒有任何其它的資訊往返。無論用戶端申請的網頁上除了文字之外還有什麼資訊，對於用戶端來說，它發出的請求只是簡單的告訴Web伺服器它所需要的網頁的位置；至於為了產生這個網頁，伺服器端是否需要訪問資料庫，執行Servlet或者其它的CGI程式對用戶端而言，都是完全透明的。
• 基於文本的訊息傳遞：迄今為止相容性最好的系統可能就是HTTP協議支撐的大部分的web應用了，我們可以在Windows平台下用IE查看互連網上一個Linux＋Apache伺服器上的由Perl指令碼自動產生的網頁。這裡的關鍵就是所有內容都是以格式化的文本方式傳遞的，不管Perl指令碼如何執行，只要它的輸出是符合HTML規範的網頁，就可以被用戶端的瀏覽器解釋。而由於不同的作業系統上對於相同的HTML的解釋遵循相同的規範，因此不同作業系統下仍然能夠看到一致的使用者介面。

我們上面基本描述了SOA作為一種軟體架構有哪些特點，下面讓我們一起看看Web Service與SOA的關係。

SOA於Web Service

Web Service是就現在而言最適合實現SOA的一些技術的集合，事實上最近SOA的火爆在很大程度上歸功於Web Service標準的成熟和應用的普及為廣泛的實現SOA架構提供了基礎。下面讓我們看看Web Service中的各種協議是如何互相工作來滿足SOA所需的特點的：

• 獨立的功能實體：通過UDDI的目錄尋找，我們可以動態改變一個服務的提供方而無需影響用戶端的應用程式配置。所有的訪問都通過SOAP訪問進行，只要WSDL介面封裝良好，外界用戶端是根本沒有辦法直接存取伺服器端的資料的。

• 大資料量低頻率訪問：通過使用WSDL和基於文本(Literal)的SOAP請求，我們可以實現能一次性接收大量資料的介面。這裡需要著重指出的是SOAP請求分文本方式和遠程調用(RPC)兩種方式，正如上文已經提到的，採用遠程調用方式的SOAP請求並不符合這點要求。但是令人遺憾的是現有的大多數SOAP請求採用的仍然是遠程調用(RPC)方式，在某些平台上，例如IBM WebSphere的早期版本，甚至沒有提供文本方式的SOAP支援。
• 基於文本的訊息傳遞：Web Service所有的通訊是通過SOAP進行的，而SOAP是基於XML的，不同版本之間可以使用不同的DTD或者XML Schema加以辨別和區分。因此只需要我們為不同的版本提供不同的處理就可以輕鬆實現版本控制的目標。

SOA對於軟體架構設計的影響

無論您現在的系統是否牽涉到基於Internet的業務整合，採用SOA推薦的架構都對提高您系統的擴充性有很大協助，下面是在系統中引入SOA後需要在軟體架構方面做出的改變：

• 使用基於文本方式的SOAP調用，擺脫遠程調用中出現的函數參數類型等與資料無關的資訊，保證所有SOAP傳遞的都是有意義的商業資料。依賴於Schema，而不是類定義對這些資料進行解釋。
• 傳統的三層Web應用將可能變成四層結構：傳統意義上的商業邏輯層將被進一步劃分為存放每個會話(Session)資訊的客戶邏輯層和與狀態無關Sateless的SOA層。

總結

本文根據作者自己對SOA的理解給出了SOA的定義，總結了SOA的三點特徵並且簡要的從程式員的角度指出SOA的出現對於軟體架構設計的影響，希望本文能協助您對SOA有較為深入的理解。