IT界出現的最新術語SOA，是服務型架構（service oriented architecture）的縮寫。它是如今IT經理、系統集成商和IT供應商的最常掛在嘴邊的詞，然而只有很少的經理、集成商或供應商知道它到底是什么。SOA其實不是一種產品，技術或者體系結構，它只是一種應用軟件一體化的概念。這一點制造業的專業人士應該知道，因為他們常常被要求將他們的系統與其它系統界面通過ESB(企業服務總線)主干網，以SOA 模式連接起來。ESB是軟件、路由信息、緩沖請求和回應的連接通道，而SOA則限定了通過這條通道的內容。

　　最早的SOA 概念是希望任何應用軟件的界面都應該具備一定的商業用途，比如可以處理一個購貨訂單或者進行庫存的實物清算。只要開始服務就可以自動完成整套相關的商業流程。舉一個例子，有一項可以提供“為到達的貨物分配一個庫存容器號碼”的服務。這項服務用物質化的ID標簽，為庫存的容器分配一個號碼。因此，它的SOA界面可能就是被稱為“AssignStorageContainerID. （分配庫存容器ID）”的服務。它通過那個分配號碼的應用軟件與ESB相連。當分配ID時，程序有可

　　能同時執行其他的工作，例如記錄任務；專項儲存庫存號碼資料以備貨物到達時能及時調用；以及將容器的狀態標記為“使用中”。

　　SOA的設立基于6個假設的前提：系統是松散耦合的；界面交換是非物質的；程序具有RPC(remote procedure call遠程功能呼叫)功能；界面基于消息；消息使用XML 數據；以及界面支持同步或不同步兩種數據傳輸形式。

　　當一個系統工作時不會對另一系統產生較大程度，而同時服務的實施在幕后進行時，系統被認為是松散耦合的。而非物質的界面并沒有固定的形式，每次使用的其實只是被交換的數據，而不是隱藏在背后的服務提供商的知識和經驗。RPC 功能就是程序運行起來就像一個本地函數或者子程序調用那般簡單，使用者完全不必理會界面信息的任何細節。一個基于信息的界面通過ESB在程序間傳送消息；這些消息基于XML 數據，而非可展開的文件或某種專用的二進制語言。服務可能是同步的，即發送請求然后等待即時回應。同樣的，當服務請求發出后，程序繼續處理另一個過程，稍后再做出回應，這時服務是不同步的。

　　這些簡單的SOA 概念很難在現有的系統里實現。關鍵是為系統提供的服務確定適當的程度和類型。服務可以是精細型的，也就是執行諸如改變某一數據要素；也可以是粗放型的，即可處理重要復雜的商務過程的服務。可以想見，粗放型的服務是比較受歡迎的SOA 應用類型；當然，在很多情況下，精細型服務也是不可或缺的。

　　制造團隊應該幫助企業認清他們的系統需要實現的服務是粗放型還是精細型的，以方便其做出決定。通常會使用到SOA模式的商業流程主要集中在物質管理、物流控制，包括原材料、設備和人員的運轉等。粗放型服務主要針對生產、測試、維護等主要流程，而精細型服務則主要處理與材料、設備和人員相關的具體信息。必須強調一點：SOA不是一個隨處可用的解決辦法；要實現SOA必須要很好地理解生產制造在企業供應鏈里所起的作用。

　　在任何領域中，語義都非常重要，而在SOA中更是如此。由于 SOA涉及多個團隊和組織，因此就相關術語達成一致至關重要。

　　在任何領域中，語義都非常重要，而在SOA中更是如此。由于 SOA涉及多個團隊和組織，因此就相關術語達成一致至關重要。本系列將帶著您開始SOA之旅，為您定義各種基礎術語和它們背后的重要概念。您將了解 SOA領域中需要理解并用于溝通的各個詞匯。對于每個術語，將說明它在 SOA領域中有何重要性、在這種情況下的含義、相關的標準有哪些以及與其他術語的區別如何。

　　在文中，您將探索各種術語和技術，它們有的與在高抽象級別(分析)下設計 SOA有關，另一些則涉及如何推進到較低的抽象級別(設計)，后一種級別的下面緊接著代碼級。

　　關于組織方式的說明

　　以下列出的術語并不是按照字母順序排列的，同時也未按照其重要性進行排列。相反，我們將按照構建塊的方式對其進行組織。本文是以服務概念為基礎的，為了定義其他術語，它們對與特定原則有關的概念進行分組，如本文中的分析 和設計。

　　分析和設計

　　分析和設計的內容包括若干活動，通過這些活動，可根據功能和非功能需求集來指定初始的 IT 體系結構。其他一些活動也可作為分析和設計的基礎，這些活動對初始的體系結構加以細化，使抽象級別由分析級進入設計級，這一細化程度足以讓開發人員生成和編寫出實現代碼。

　　SOA分析和設計也可以指以下術語中的一個或多個：

　　服務建模

　　面向服務的分析和設計

　　面向服務的建模和體系結構 (SOMA)

　　Rational Unified Process for Service-Oriented Modeling and Architecture (RUP SOMA)

　　分析會在較高的(概念級)抽象級別上對將要構建的系統進行描述。分析的輸入是一組需求和現有的資產(或是應用程序或系統)。輸出則是對需要構建的各個方面的描述。分析對 SOA來說是至關重要的，因為通過分析，可以在服務標識期間使 IT 與業務保持一致。分析結果將作為輸入在設計中使用。

　　設計會描述將要構建的系統，更重要的是，它還會對如何構建加以描述。

　　大多數體系結構工作是在分析和設計的工作流中、在項目的細化階段執行的。

　　面向服務的分析和設計利用了分析和設計原則(如面向對象的開發或基于組件的開發中的原則)。例如，您也許還記得所謂的面向對象的分析和設計 (OOAD)。不過，必須注意的是，SOA的工作重點始終在于服務(而不是對象或組件)。

　　注意：分析級模型常會發展為設計級模型，所以對于分析和設計而言只有一套 RUP 原則。

　　面向服務的分析和設計工作的主要輸出是一個服務模型(即先前所說的服務規范)和一個設計模型，服務模型記錄了面向服務的系統中所有重要的體系結構部件，而設計模型則進一步闡述了服務模型應如何實現的細節。這兩個模型對 SOA設計進行了全面說明，開發者可以據此明白無誤地執行這一實現。

　　在下列各部分中將描述相關任務，為您介紹面向服務的分析和設計的相關術語。

　　注意：術語標識 和規范 適用于基于組件的開發中，而術語規范 和實現 則是由通用建模語言 (Unified Modeling Language, UML) 定義的。這三個術語構成了 RUP SOMA 的核心活動(術語的含義未變)。

　　服務標識

　　服務標識 是核心的面向服務的分析活動。服務標識的目的是將各個分組的概念化服務及其操作標識出來。

　　這些經過標識的服務對于業務而言是有意義的，業務需要這些服務。事實上，業務分析師會幫助軟件架構師進行這項工作。下一部分將介紹服務設計原則，您會了解到對服務邏輯分組的需求、對服務及其操作的業務命名的需求。這些都是在服務標識期間決定的，其間使用了多種技術，RUP SOMA 中描述的那些技術也包括在內。

　　我們來深入了解一下：

　　自頂向下方法

　　業務體系結構工作從一組業務目標開始，標識出一個或多個應予關注的業務流程，這在 SOA中是非常典型的。通過業務建模工作，可能會出現已經過設計的業務流程(即未來的流程)，對于正在設計中的系統，它們可以被視為功能性的需求。

　　自頂向下方法旨在分解業務元素(主要是業務流程和用例)，然后將它們細化為適合服務的粒度。在使用自頂向下方法的過程中，您通常要在業務任務中標識出各種服務操作。這種做法的好處在于，您可以確保標識的服務與業務保持一致。

　　自底向上方法

　　自底向上方法旨在分析現有的 IT 資產(如遺留的應用程序和系統)，找出可以作為服務公開的功能，以便重用它們。

　　重用是 SOA的一個重要組成部分，對于 SOA的成功是極為關鍵的。您可能知道，遺留應用程序(即已經部署的應用程序)是您的公司最寶貴的資產，應該加以利用。例如，自底向上方法將分析現有的信息管理系統 (IMS) 事務或 COBOL 程序。

　　對于自底向上的分析，有一句忠告：您必須謹慎從事，不要盲目地公開現有的 IT 功能。例如，用于創建、讀取、更新、刪除 (CRUD) 數據的各項服務的粒度可能太小，無法與業務保持一致。

　　SOA的反思：SOA架構的本質

　　我一直在反思SOA到底是什么，是一種什么樣的架構。雖然了解到一些基于SOA構架的產品，但總覺得依然“隔著一層紙”，并不清楚什么才是真正的SOA架構。

　　年初的時候，寫過一篇名為“國內EAI正當時，BPM為時尚早，Workflow持續增長，SOA依然概念”的Blog日志。那個時候，我認為SOA還依然是個很“虛”的概念。而現在，我只能說：Sorry，那時候的我，錯了。SOA已經不再是概念，而是一個實實在在的構架了。

　　在寫完那篇帖子之后，我一直在反思SOA到底是什么，是一種什么樣的架構。因為在在TIBCO中國研發中心工作的原因，可以接觸到TIBCO的一些最新的SOA產品。

　　雖然了解到一些基于SOA構架的產品，但總覺得依然“隔著一層紙”，并不清楚什么才是真正的SOA架構。

　　很多時候，我依然會認為SOA構架只是滿足把應用暴露成Service(或者說是WebService)，以SOAP等之類的消息進行信息的傳輸，以及基于Service之間的一些業務邏輯的整合應用(比如BPEL)等。

　　我相信，這樣的困惑，在國內很多中間件產品、應用產品中都存在，在很多國內的開發人員、架構師心中也存在。

　　昨天，有幸參加了CSDN主辦的“SOA產業鏈及未來企業軟件趨勢”研討會，收獲不小。參見昨天寫的blog隨感“參加“SOA產業鏈及企業軟件趨勢研討會”的感想”。經過那些專家們(毛新生、Tiger、李勇、梁耀文等)的解惑，對SOA是一種什么樣的構架，有了一些更深刻的認識。

　　但說真的，如果不是目前在TIBCO中國研發中心工作的經歷，以及所接觸到一些國外最新產品構架的巨變，僅憑昨天的聽講，也很難把握毛先生他們所說的那些SOA理念。

　　具體昨天有哪些重要的理念就不在重復的敘述了，參看“參加“SOA產業鏈及企業軟件趨勢研討會”的感想”，里面有詳細的敘述。

　　今天只談反思：SOA架構的本質。

　　剛剛看到一篇新聞，講的是SAP代號為A1S的新產品軟件設計方法，參見“新聞分析：解密代號A1S”。這和昨天研討會上，SAP的李勇先生，所闡述的一些觀點很類似：SAP的產品在往SOA架構遷移中，經歷了三個大的步驟：第一步，提供更好的服務層面的容器或平臺的支持;第二步，把業務抽象成服務，確切地說，是抽象業務對象(Business Object);第三步，把面向垂直或水平層面的各個產品，基于業務對象進行整合。

　　事實上，這就包含了昨天各個專家所闡述的SOA架構的本質：一切圍繞業務對象(Business Object)或業務模型(Business Model)，至于“服務”，只是這些業務模型暴露出來的形式，因為以統一的服務形式暴露出來，更便于不同供應商和客戶之間的信息交互。

　　在Gartner十年前提出SOA概念的時候(1996年)，尚沒有web service技術。SOA架構的本質，并不是說把你的應用或者組件包裝成Service就是SOA，而是說，你需要基于一種構架，能夠讓你的產品能夠更適應“業務敏捷性(Business Agility)”。但是這種業務敏捷性僅僅是一家提供商或產品是很難滿足的，肯定需要各個不同的供應商協助完成，不同的產品之間能夠比較容易的進行消息交互。這樣的靈活度肯定不是傳統的基于消息的EAI產品所能夠滿足的，需要一種新的協議或標準來支撐。—— 當Web Service誕生之后，所有的大廠商都發現這是一種非常符合他們需求的技術。

　　但是服務的本質，是在后端能夠提供一套“業務模型”。而制成這種業務模型或業務對象構建的技術，正好就是前幾年所熱炒的“模型驅動構架(Model-Driven-Architecture)”。事實上，現在各大廠商都在基于這個構架在轉變自己的產品構架，BEA，IBM，TIBCO都在進行著這樣的巨變。

　　在回頭想想我們常說的“SOA真理三角”：數據(Data)——組件架構(Component Architecture)——組合(Composition)。因為幾乎所有的業務模型最終需要被“業務對象+業務組件”反映出來，而它們之間需要進行一系列的組合和交互，來滿足業務的處理。

　　在SOA聯盟組織的SDO和SCA標準，正是用于解決數據和組件模型描述的問題，這方面幾乎所有的EAI廠商都加盟進來了，IBM、BEA、IONA、Oracle、SAP、Sybase、TIBCO、Software AG等等，這其中好包含國內的普元軟件。

　　SOA 從概念到行動

　　真實的SOA世界距離我們還有多遠?今天，盡管SOA還沒有一個準確的定義，但IT公司們已經將其變成了觸手可及的商業科技工具，在商業引擎的驅動下，利用這些工具部署SOA已經成為商業科技企業的現實。

　　真實的SOA世界距離我們還有多遠?四五年前，SOA還只是一個空洞的概念，缺乏產品和技術標準的支持，企業只能視其為鏡花水月;今天，盡管SOA還沒有一個準確的定義，但IT公司們已經將其變成了觸手可及的商業科技工具，人們不必再泛泛而談SOA的未來，在商業引擎的驅動下，利用這些工具部署SOA已經成為商業科技企業的現實。

　　國際商業機器公司(IBM)、畢益輝系統有限公司(BEA System)、甲骨文公司(Oracle)、微軟公司(Microsoft)等走在了SOA浪潮的前列。這些主流中間件廠商最早認識到SOA在未來平臺技術中的超然地位，并且不遺余力地推動SOA技術的發展。如果說前兩年這些廠商還停留在SOA概念的炒作階段，那么，在經歷了數年的研發和測試以后，從2005年開始，他們已經陸續推出各自的SOA策略、架構以及產品，真正將SOA推動到可部署階段。

　　“SOA是BEA公司非常重要的戰略。”BEA中國公司技術總監喻思成用“非常重要”形容SOA在BEA公司技術戰略中的地位。就在上個月，BEA公司已經正式公布了他們最新的中間件軟件品牌—AquaLogic，這條新產品線提供了全面的管理環境，幫助開發者使用開放的Web服務標準和工具創造所謂的SOA架構。而在此之前，已經有很多開發者基于 BEA公司的WebLogic Platform為企業開發SOA。BEA公司產品市場總監比爾•羅斯(Bill Roth)表示，與WebLogic Platform不同的是，AquaLogic的目標使用群體更集中于類似思愛普軟件系統公司SAP、甲骨文公司的咨詢顧問這樣的人群，對于這些咨詢顧問而言，配置應用系統并創造商業價值比寫軟件代碼更有意思。

　　IBM公司則基于SOA理念提出了“整合”戰略，希望通過建立基于開放標準的、統一的、高效的、易于管理的IT基礎平臺，通過SOA與Workplace客戶端技術(WCT)，實現企業IT前臺—用戶端、后臺服務器的整合，從而靈活地配制企業的內外部IT資源，使企業在市場需求、市場機遇或競爭威脅出現時能夠迅速響應，成為能夠真正隨需應變的企業。“SOA相當于隨需應變的DNA。”IBM公司WebSphere軟件副總裁桑蒂•卡特(Sandy Carter)在接受《信息周刊》專訪時如此評價。

　　在產品方面，IBM公司的信使軟件WebSphere MQ提供了對SOA的支持。今年5月，IBM公司公布了信使軟件的最新6.0版本和WebSphere Business Integration(WBI)Server Express版本軟件。新版WebSphere MQ軟件可以幫助企業顯著降低日常頻繁發生在操作系統與應用之間的數據交換成本，如人工譯碼、文件傳輸及端到端的方案等成本。新版WBI Server Express則包括了集成現有應用的新適配器，通過使用向導驅動(Wizard-Driven)的業務規則提供了業務靈活性，并簡化了基于Web的遠程部署。此外，IBM還提供了Rational測試工具，用來幫助開發客戶基于SOA的數據應用。

　　微軟公司的未來操作系統長角(Longhorn)已經公布了部分技術細節，微軟公司高級副總裁埃里克•魯德(Eric Rudder)透露，長角系統提供了一個安全可靠的Web服務體系架構，能夠方便地與互聯網上的其他系統進行交互。以前實現這樣的功能，需要編寫多達5.62萬行代碼，但如今，只需要3行代碼就行了。

　　此前，微軟已經推出了代號為Indigo的技術，這項技術據稱為合作伙伴建立新一代連接系統SOA鋪平了道路。Indigo既是.Net Framework 2.0的擴展，也是微軟公司推進SOA的最新舉措，更是對競爭對手，比如IBM公司和太陽計算機系統公司(Sun)等所提供的SOA方案的有力回應。“轉向SOA已經是不可抗拒的趨勢。” 埃里克•魯德這樣表態。

　　甲骨文公司的SOA策略與其“網格計算”戰略緊密結合在一起。目前，甲骨文公司在SOA領域最大的優勢來自其Enterprise Manager和 Application Server產品的覆蓋面。通過不斷收購和簽署授權協議，甲骨文公司已經建立了一系列相對完整的開發和部署工具，其中最著名的包括Oracle database 10g、Oracle Application Server 10g和Oracle JDeveloper 10g。“SOA的關鍵是要把應用變成組件，Jdeveloper很重要的作用就是通過調用BEPL圖形化工具，幫助客戶把程序打包成組件。”甲骨文公司大中國區應用服務器咨詢顧問總監雷振球透露。

　　SOA在影響中間件開發平臺的同時，也改變了傳統以應用為對象的開發方式，應用軟件提供商同樣必須適應SOA帶來的影響。今年年初， 思愛普軟件系統公司(SAP)表示說，他們將向企業提供“建設基于服務的架構”的服務—Enterprise Services Architecture Adoption Program (ESAP)。該服務向企業提供格式化的、逐步的服務，幫助企業解決建立以SOA為基礎的各類解決方案時產生的策略變動。

　　據SAP 公司預計，到2005年底，該公司旗下所有產品將會以NetWeaver 基礎軟件為核心來打造。在NetWeaver 2004中包含一個綜合性的組件設置，包括接口軟件、應用服務程序、集成工具、數據分析系統、工作流程序、標準數據管，另外還有一個開發平臺，所有這些都是基于SOA框架的。

　　不僅僅是SAP公司，大多數應用軟件開發商都將隨SOA而“舞”。事實上，很多開發商通過與平臺開發商建立合作關系，在平臺開發商提供的支持SOA的平臺上進行應用系統的開發。“很多中國的ISV(獨立軟件開發商)都已經開始了行動。而且，不但是針對國內市場需要，他們將來走向國際市場，也必須要采用SOA的發展方向。”雷振球提醒中國的ISV。

　　SOA所帶來的沖擊波已遠超出軟件業。企業計算芯片提供商、通信產品開發商等如今都開始規劃自己的SOA策略。英特爾公司去年推出了服務導向企業(Service Oriented Enterprise ，SOE)計劃，SOE計劃將移動計算、網格計算和可管理性元素融入同一框架之中，幫助IT經理利用這些技術來實現業務轉型。根據基于該計劃的英特爾企業平臺技術發展策略，英特爾公司↖ntel)2005年首先實現雙核處理器，以及“Silversvale”虛擬化分區技術;未來逐漸走向多核運算，虛擬化的范圍也逐漸擴展到存儲和I/O部件。

　　通信設備廠商亞美亞公司(Avaya)最近也發布了支持SOA的通信應用套件。這款名為Avaya Communication Manager 3.0的新產品是Avaya MultiVantage通信應用套件的核心部件。Avaya大中華區產品經理沈曉暉透露，Communication Manager 3.0采用了基于Web服務的開放式應用環境的架構，使開發者能夠便捷地創建下一代企業通信應用，把實時通訊的應用融入到企業業務應用中，從而提高企業業務運作的靈活性。“SOA架構為ISV提供了最簡單的接口，改變了原來開發的方式，從此，應用開發人員做Avaya產品的集成不再受到限制。”沈曉暉說，“這也許將改變我們傳統的生活方式。”

　　盡管已有可部署的SOA 產品和平臺出現，但這僅僅意味著開始。大部分企業將分階段采用SOA，而SOA的核心標準也將繼續演進。作為供應商們繼續投入大力研發的戰略性技術，在未來的一到兩年內，競爭狀況和針對明確的SOA要求推出的產品可能會發生巨大變化。另外，對于用戶而言，究竟應該選擇什么平臺或者什么產品，的確是應該三思而慎行。