引言
96年Gartner提出SOA，目的是讓企業業務更加敏捷，軟件系統變得更有彈性，使企業能快速響應需求的變化，這樣的目的是有當時背景的。經濟全球化要求企業的業務具備更大的靈活性，比以往能更快地響應市場變化，業務快速變化則要求軟件系統具備更大的彈性，而對於企業已經普遍存在的遺留系統來說，這無疑是辦不到的，不但辦不到，而且遺留系統本身還存在信息孤島問題。從資源利用的角度，企業爲實現利益最大化，遺留系統的問題需要解決，新建系統的彈性更需要解決，就在這樣的環境下SOA被提出來，而且越炒越熱，從最初基於SOA思想的實現原則、架構模型、參考模型等等一路走來，直到目前的編程模型。OSOA在今年2月份將SCA標準提交給OASIS，到2009年初，SCA將由現在的行業標準變成真正的國際標準。而企業對SOA寄予厚望，同樣對SOA的投資也越來越龐大，如IBM現在每年在SOA上的投入多達10億美元。SOA正由幕後真正的走到臺前。
SOA曾經也默默無聞
SOA提出後，限於當時的環境與技術，僅停留在思想層面，直至2003年前後，WebServices異常火爆，SOA纔在應用層面有了一片實驗田，但SOA成了WebServices的上層模型，幾乎等同於WebServices。2003年到2005年，SUN JCP也在醞釀着被稱爲SOA切入點的JBI，作爲ESB構建的核心標準，但IBM與BEA卻在歷次投票中均棄權，理由是JBI不能真正實現SOA，結果JBI在日後也逐漸銷聲匿跡，雖然ESB仍然被認爲是SOA的重要組成。而在2005底，業內四大巨頭IBM、BEA、ORACLE、SAP共同發起成立了OSOA廠商聯盟，致力於開發語言中立的SOA編程模型，並且隨着SUN在2006年7月份的加入，OSOA廠商已達18家，SOA編程模型，SCA與SDO，成爲實現SOA的行業事實標準。
到底該如何理解SOA
有人認爲SOA並不是什麼新概念，從RPC、IPC直至分佈式計算的CORBA、DCOM等，幾乎都帶有SOA的影子，只是實現角度與方式的差別。那麼SOA到底該如何理解？其本質究竟有何吸引人之處？從誕生到成長，SOA被賦予太多的使命與含義，以至長時間裏SOA都不能準確定義，直到今天，才漸漸清晰。
開始的時候，SOA只是個方法，是個架構模型
開始的很長一段時間裏，SOA只是個方法，是指導企業實現業務敏捷性及建設彈性軟件系統的架構模型，引用Bloomberg 的SOA實現原則：
1、 業務驅動服務，服務驅動技術。
2、 業務敏捷是基本的業務需求。
3、 一個成功的SOA總在變化之中。
可以看出，SOA的核心圍繞着業務敏捷性展開。業務敏捷性是指企業對變更快速而有效地響應、並且利用變更來得到競爭優勢的能力。在當下越來越激烈的市場競爭中，企業爲了生存決不會放棄任何能夠提高自身競爭實力的機會，業務敏捷性也是如此。實現業務敏捷性首先要求業務本身就具備敏捷性，業務本身就能夠對變更快速而有效的響應，這其實是企業管理建設上考慮的事情，涉及到如何使企業信息流通通暢、業務流程重組優化、資源合理配置等等一系列問題，最本質的作法是企業從自身來發現問題所在並改正。
業務具備敏捷性後，接下來考慮的纔是通過彈性軟件系統來更好的表達業務敏捷性，這應該屬於軟件方法論的範疇，而這當中的探索可以說歷經了軟件的整個發展過程，一直探尋的本質其實是信息世界與現實世界間映射關係的建設，也就是如何用軟件系統更好的表達現實當中的業務，即現在大家經常說的業務建模。
那麼到底如何能夠用軟件系統來更好的表達現實當中的業務呢？我相信這將會是業內永久的話題。從結構化方法，面向對象方法，直到現在的面向服務方法，隨着計算機硬件及網絡的發展，世界經濟環境的發展，軟件系統本身也在不斷的發展變化，但其目標卻一直沒有變化過，那就是更好的描述現實世界並且提升。
SOA秉承的也是這一目標，只是更多了一個考慮：如何應對出現的各種變化，而這些變化主要集中在兩個方面：現實世界的發展變化、軟件系統本身的發展變化。現實世界的不斷變化，要求軟件系統能夠適應這種變化，軟件系統本身也在不斷地發展變化，要求新建軟件系統能夠兼顧遺留軟件系統，而只有建設自身就在不斷變化的軟件系統，才能應對現實世界的不斷變化，只有建設技術實現無關的軟件系統，才能實現新建軟件系統與遺留軟件系統的兼顧。引用一句很有哲理的話就是：世界上唯一不變的就是變化。這就是SOA要解決的問題。變化是軟件系統建設決不可迴避的問題。
SOA的本質還是業務建模，服務只是業務模型的形式
從上面可以看出，SOA架構模型的本質其實還是業務建模，側重於爲應對變化而需要敏捷性的業務建模，至於服務只是業務模型暴露出來的形式，以統一的服務形式描述業務模型。業務的變化是在模型內部的變化，業務敏捷性反映在業務建模的敏捷性上，而服務則解決敏捷業務間的互操作問題。由此可以看出服務只是業務的包裝形式，這種形式只要可以解決互操作問題，而可以不問形式到底是什麼。這就是爲什麼有人說：從RPC、IPC直至分佈式計算的CORBA、DCOM等，幾乎都帶有SOA的影子。從SOA架構模型來理解，它們只是服務的形式，服務形式發展歷史上經歷的技術成熟階段的產物。目前階段的SOA肯定也不會是終極形式，只能說是到目前爲止最爲成熟的形式而已。
話題說到這裏，其實應該是分爲兩個話題了，那就是：具有業務敏捷性的業務建模與技術形式最爲成熟的服務。
第一個話題在目前其實也是有成熟的國際標準化組織在推動的，這就是OMG下的MDA，ModelDriver Architecture，面向服務架構，這也是目前的熱門話題，並且已經出現了研究分支，如DSM，Domain Specific Modeling，領域特定建模。這裏涉及到一個軟件生產力的問題，從彙編語言到Basic語言，軟件生產力提高了400%，而從Basic往後，如C++、Java，軟件生產力提高不足20%，究其原因何在：抽象程度不夠，而業務建模被認爲是提高抽象程度的有效手段。業務建模從另外的角度看仍然具備絕對的重要性。鑑於這篇文章的主題是關於SOA的話題，這個話題我們暫且不表。
但在這裏，筆者認爲需要提到一點的是：爲實現業務敏捷性，業務建模與服務形式存在交叉，即當業務模型以統一的服務形式暴露出來後，便可以通過組裝模型組裝具有統一服務形式的業務模型，以期實現更大範圍的業務敏捷性，這也是目前SOA研究範疇中非常重要的部分，即以統一的服務形式爲基礎，通過組裝模型，實現更大範圍的業務敏捷性。SOA架構模型包含以統一的服務形式爲基礎通過組裝模型實現更大範圍的業務建模。
在這裏還需要提到一點的是，2005年前後出現的針對遺留系統的整合技術，筆者認爲只是一種過渡技術，是SOA服務形式探索道路上的階段性產物。整合解決的是軟件系統間的互聯互通問題，而SOA的組裝模型並不侷限於此，所以兩種技術針對遺留系統的解決方案也不盡相同：組裝必須首先以遺留系統的服務化改造爲基礎，然後以統一的服務形式進行組裝，而整合則無此必要步驟。在這裏筆者也不展開來討論了。
服務的特徵
那麼技術形式最爲成熟的服務到底是一個什麼樣子呢？截至目前爲止，這一服務形式還在研究與制定當中，這裏不能妄下結論。但服務所具備的特徵卻是在業界有共同認識的。服務具備的特徵歸納爲如下幾點：
1、 服務自治。自治隱藏了服務封裝、服務具備明確的邊界且獨立運行的特點。服務接口是服務與外界交流溝通的唯一途徑，通過服務接口封裝服務的內部實現，通過服務接口發佈服務自己具有的功能，通過服務接口實現服務間的調用，而並不依賴環境上下文，服務接口以內的變化絕對不會影響到接口以外，接口以外的變化也不會影響到接口以內，而服務接口使用統一的表達形式，描述服務具備的功能性與非功能性的能力與特點及服務使用方式，服務接口是服務與外界的明確邊界。服務接口以內則獨立地維護與運行。
2、 服務鬆耦合。鬆耦合隱藏了服務位置透明、基於傳輸協議的消息交換等特點。有人認爲鬆耦合應該從多個緯度來理解，因爲鬆耦合在這些緯度上均有表現。這些緯度包括：
a) 時間，時間上的鬆耦合可以使交互雙方不必在同一時間進行通訊，即服務使用者發出請求即可，服務提供者發出回覆即可。
b) 位置，位置上的鬆耦合可以使交互雙方在不作任何改變的情況下而適應雙方可能在物理地址的變化。
c) 接口，接口上的鬆耦合使交互雙方可以綁定到特定接口，也可以綁定到通用接口，如果是通用接口，所有該接口的使用者都能與該接口的提供者進行通訊。
d) 查找，查找上的鬆耦合使服務使用者可以通過明確的物理或邏輯位置來找到服務提供者並使用它，也可以通過在註冊機構或目錄服務中查找來匹配服務提供者並使用它。
e) 其他緯度還包括：類型、版本、基數等等，Carlos Perez的文章均有提到。
3、 服務互操作。互操作隱藏了服務環境異構、服務複用等特點，服務使用服務接口作爲邊界隔離服務內部的環境異構，通過多協議接口實現服務間通訊協議的環境異構，從而實現異構環境下服務互操作，並以此爲基礎實現服務複用。
以上只是歸納總結了服務所具備的主要特徵，當然服務肯定也存在其他特徵，但這裏不再累述。
從上面的分析可以看出，SOA架構模型是指導企業實現業務敏捷性的指導原則與建設彈性軟件系統進行體系結構設計的方法。在方法論層面，SOA無疑是贏得了衆多的喝彩。
順應發展潮流的SOA參考模型與SOA參考架構
於是在2006年10月，OASIS發佈了SOA參考模型，雖然僅是個指導企業實現SOA的抽象框架，且在實際SOA實現中起不到多少具體作用，但卻是在思想認識上第一次旗幟鮮明的進行了統一，其積極意義不言而喻。
SOA參考模型回答的是：SOA是什麼等這樣的問題，它秉承了業內對SOA的普遍認識，統一了SOA相關術語及其語義，同時明確了SOA各組成部分間的關係，爲企業SOA實踐提供了系統的理論指導。
接下來，在SOA參考模型的基礎之上，在2007年年內，預計OASIS會提出SOA參考框架，所以在目前階段SOA參考模型更多的是解釋SOA的概念與組成，而未來的SOA參考架構則側重於SOA如何實現。OASIS標準起草委員會負責人JamesBryce Clark談到：SOA參考架構不是一種標準，更多的將會是以實例的方式來指導SOA實踐。
SOA不是WebServices
SOA在方法論上逐漸成熟成爲轉向應用的充要條件，而WebServices的適時出現，促成了SOA的初次體驗。在SOA的發展歷程上不得不提的便是WebServices。曾經在很長一段時間裏，WebServices被認爲就是SOA，而歷史走到今天，回過頭來再看，SOA卻不是WebServices，而且二者也已漸行漸遠。
WebServices可以追溯到HP在上世紀90年代末期的分佈式計算研究項目，E-Speak，使用Http協議提供XML數據，將互聯網系統作爲電子服務。緊接着出現的是XML-RPC與ebXML，前者由UserLand領導，後者則由OASIS與UN/CEFACT共同開發和維護，他們都在探索一種技術中立的、基於分佈式計算解決互聯互通互操作問題的方案。這些技術其實是WebServices發展道路上的必然產物。
SOAP可以視爲XML-RPC的升級，改善了Verbosity與Data Typing，同樣出自UserLand，並於1999年下半年正式發佈。而IBM、MicroSoft、Ariba等廠商在早期WIDL、SDL、SCL、DISCO、NASSL、ADS等規範的基礎上最終形成了WebServices描述語言WSDL和WebServices通用描述、發現與集成協議UDDI。這樣WebServices協議棧中主要協議都已形成。2001年4月，W3C WebServices研討會，WSWS，正式召開，討論WebServices發展規劃，如何構建WebServices協議棧，包括Qos、安全、流程及事務等標準，這標誌着WebServices標準化正式開始。
但隨着2000年以科技股爲代表的納斯達克股市的崩盤和互聯網泡沫的破滅，業內艱難時期來臨，企業爲生存而掙扎，直到2002年，情況纔有所好轉。在這期間，唯一能打動客戶的方案無疑就是是如何節約成本，而這正是WebServices所具備的優點：成本低廉的集成方案。所以這一時期被認爲是WebServices的黃金時期，至2003年，WebServices更火爆異常。
但IT界獨有的快節奏卻也使WebServices的問題早早暴露：協議棧並不能保證互操作，並且標準化也不能降低異構環境下系統間的差異，WebServices成本低廉的集成方案更難以降低業務變化的長期成本。到後來，WebServices組織分化，各自發布並維護標準、規範，標準化組織主要有兩個，分別是W3C與OASIS，前者發佈了SOAP與WSDL，後者則負責維護UDDI，業內廠商聯盟WS-I，則致力於解決環境異構下標準互操作問題。
SOA不是WebServices，首先因爲SOA早於WebServices出現，如上面提到的，SOA在開始的很長時間裏只是個方法，並且致力於解決業務敏捷性，所以SOA極力尋找一種技術中立的實現，至90年代末期，即WebServices協議棧標準開始形成，並且基於被各大廠商認爲會成爲理想消息協議的XML，所以在那個時期，業內認爲WebServices就是SOA。但SOA解決業務敏捷性的目標是沒有變過的，所以當後來WebServices基於標準的集成方案並不能達成SOA業務敏捷性目標的時候，二者的分開便是不可避免的了。所以會有人說：WebServices只是目前最適合實現SOA的技術。而SOA卻不是WebServices。WebServices基於標準的應用編程接口，缺乏SOA的鬆耦合、位置透明等特徵，更不能實現業務敏捷性，並且WebServices服務難以管理。
JBI插曲
在2003年到2005年，SUN JCP也在醞釀着被稱爲SOA切入點的JBI，作爲ESB構建的核心標準，但IBM與BEA卻在歷次投票中均棄權，理由是JBI不能真正實現SOA。緊接着2005年底，IBM、BEA、ORACLE、SAP等共同發起成立了OSOA廠商聯盟，制定SCA與SDO規範，其中SCA就是針對IBM、BEA認爲不能實現SOA的JBI的，所以JBI的沒落不可避免，而目前SOA編程模型，SCA與SDO，已然是行業事實標準了。
SOA編程模型
SOA編程模型從業務需求出發，以開放的服務組件與動態交互技術爲基礎，將鬆耦合的服務組件快速組裝成業務流程，完成業務活動，從而實現軟件系統業務敏捷性。而SCA與SDO則是相互關聯的規範，SCA關注業務邏輯，SDO側重於業務數據。
SCA主要描述面向服務的計算環境裏服務組件與組裝模型的實現方法，強調服務組件與平臺及服務組件之間的關聯，並描述怎樣通過已有的技術、平臺甚至組件來實現服務組件，確定統一、通用的服務組件接口及其語義，建立服務組件間鬆耦合的交互環境，並定義服務組件組裝模型。開放的服務組件與服務組件組裝模型技術獨立、平臺獨立、語言獨立，廠商們可以在不同平臺上使用不同技術和語言來實現。
服務組件組裝模型的目標是融合實現服務組件以及實現服務組件間訪問方法的廣泛技術。對於服務組件而言，不僅涉及不同的編程語言，而且也涉及到這些編程語言的架構及運行環境。對於訪問方法而言，組裝模型允許使用常用的通訊與訪問技術，包括WebServices，消息及RPC等。組裝模型允許使用多種技術來實現，包括Java，C++，Bpel，Php，Javascript，Xquery，Sql等。
服務組件組裝模型組裝起來的應用系統，既可以包括全新定製的服務組件，也可以包括存在於現有系統中的業務邏輯。這些現有的業務邏輯，作爲應用系統的一部分而進行復用。組裝模型涉及了服務組件的組裝和服務組件的創建，並且也涵蓋了現有應用系統功能的複用。
SDO則是高度抽象的業務數據模型，主要描述業務數據對象及其內部各種粒度的數據對象之間的關聯，以統一的方式訪問或操作不同類型的數據源，並進行持久化。SDO提供連接器，可以通過不同方式且環境透明地與多種數據源交互，目前已支持的數據源有關係數據庫、XML文檔及其它，同時還提供諸如連接池、緩存、斷開連接時數據訪問等高級特性。另外，SDO還提供中介轉換器，可以根據業務語義定義完整的業務模式，並提供對象圖表，與連接器交互，完成數據持久化工作。SDO可以充分提高數據管理的效率。
從上面的分析可以看出，SOA編程模型從較高的抽象層次上對SOA架構模型做了技術中立的實現，並從業務驅動的角度，以簡潔、通用且技術開放的服務組件及組裝方式更貼切的表達業務需求，使開發人員脫離開底層技術實現的細節，更多的關注於業務邏輯的分析設計，而軟件系統架構卻不失開放性、靈活性等等特徵，在業務數據處理方面則以統一的方式管理多種類型的數據源，充分提高數據管理的效率。
SOA不僅是技術範疇，更是商業戰略，是幫助企業不斷進化的途徑，用以構建以解決業務問題爲中心的軟件系統，旨在全面幫助企業充分利用現有IT資產，提高效率、降低成本、實現業務敏捷性與創新。
OSOA在今年2月份將SCA標準提交給OASIS，到2009年初，SCA將由現在的行業標準變成真正的國際標準。
SOA的新技術之爭悄然進行
2006年底，SDO2.1發佈，2007年3月，SCA1.0發佈，標誌着SOA實現真正提上日程，而業內各大巨頭早已着手於SOA實現。
IBM推出SOA產品包括其ESB、基於WebSphere的Process Server與Business Modeler、Rational產品等。BEA也將其三個主要產品線，Aqualogic、WebLogic和Tuxedo，調整爲基於SOA架構的MicroServicesArchitecture。Oracle推出SOA Suite包括Fusion Middleware、BPEL、ESB、RulesEngine等衆多產品。
新一輪的新技術競爭早已悄然開始，而SOA無疑將會引領下個十年。