本文作為SOA&RSA系列文章的第一篇，從總體上介紹了SOA實現的相關技術，以及RSA中對這些技術的支持與擴展。在后面的系列文章中，我們將對一些主要技術和工具做有針對性的具體介紹。
1 概述
面向服務的體系架構(Service Oriented Architecture, SOA)就是在分布式的環境中，將各種功能都以服務的形式提供給最終用戶或者其他服務。如今，企業級應用的開發都采用面向服務的體系架構來滿足靈活多變，可重用性高的需求。IBM Rational Software Architect（RSA）是一套設計與開發工具，它構建在開放的、可擴展的Eclipse3.0平臺之上，實現了多項行業最新標準，提供了靈活的插件擴展機制。借助UML2.0技術，它實現了模型驅動的軟件開發模式，可以幫助開發團隊創建更加強壯的軟件結構。
本文作為SOA&RSA系列文章的第一篇，從總體上介紹了SOA實現的相關技術，以及RSA中對這些技術的支持與擴展。在后面的系列文章中，我們將對一些主要技術和工具做有針對性的具體介紹。
2 面向服務的體系架構 - SOA
在經典軟件工程理論中，不管是瀑布方法還是原型方法，都是從需求分析做起，一步一步構建起形形色色的軟件系統。但是，需求變更像一個揮之不去的陰影，時刻伴隨著系統左右。每一個實際應用系統的開發者都飽嘗了在系統進入開發階段、測試階段，甚至上線階段遭遇應接不暇的需求變更的極端痛苦。如何解決這一問題？能否來一場軟件開發和架構的革命？SOA的提出，就是被人看成這樣的一場革命。其實質就是要將系統模型與系統實現分割開來。
2.1 什么是SOA
2.1.1 定義
SOA并不是一個新概念，有人就將CORBA和DCOM等組件模型看成SOA架構的前身。早在1996年，Gartner Group就已經提出了SOA的預言，不過那個時候僅僅是一個"預言"，當時的軟件發展水平和信息化程度還不足以支撐這樣的概念走進實質性應用階段。到了近一兩年，SOA的技術實現手段漸漸成熟了，在BEA、IBM等軟件巨頭的極力推動下，才得以慢慢風行起來。
關于SOA，目前尚未有一個統一的、業界廣泛接受的定義。一般認為：SOA，面向服務的架構是一個組件模型，它將應用程序的不同功能單元----服務（service），通過服務間定義良好的接口和契約（contract）聯系起來。接口采用中立的方式定義，獨立于具體實現服務的硬件平臺、操作系統和編程語言，使得構建在這樣的系統中的服務可以使用統一和標準的方式進行通信。這種具有中立的接口定義（沒有強制綁定到特定的實現上）的特征稱為服務之間的松耦合。
2.1.2 SOA中的特征
從SOA的定義中，我們看到兩點：
- 軟件系統架構： SOA不是一種語言，也不是一種具體的技術，更不是一種產品，而是一種軟件系統架構，它嘗試給出在特定環境下推薦采用的一種架構，從這個角度上來說，它其實更像一種架構模式(Pattern)，是一種理念架構，是人們面向應用服務的解決方案框架。
- 服務（service）是整個SOA實現的核心。SOA架構的基本元素是服務，SOA 指定一組實體（服務提供者、服務消費者、服務注冊表、服務條款、服務代理和服務契約），這些實體詳細說明了如何提供和消費服務。遵循 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）設計。要想真正實現業務與服務的分離。就必須使得服務的設計和部署對用戶來說是完全透明的。也就是說，用戶完全不必知道響應自己需求的服務的位置，甚至不必知道具體是哪個服務參與了響應。
2.2 SOA不等于web 服務
由于Web服務與SOA有著很多相同的技術特點，如：基于XML語言，符合SOAP、WSDL和UDDI標準等，很多人都認為下一代Web服務就是SOA。 Web服務可以用來實現SOA，但是如果沒有Web服務，企業照樣也可以很好地實現SOA。反之，即便是利用Web服務技術，也不一定能保證SOA的效果就更好。
Web服務與SOA關系如圖1所示。
Web服務是一套技術體系，可以用來建立應用解決方案，解決特定的消息通信和應用集成問題。隨著時間的推移，我們發現，這些技術在不斷發展、不斷成熟，也會更好地幫助你實現SOA。SOA是一種軟件架構，而不局限于某個技術的組合(例如Web服務)，它超越了技術范疇。在一個商業環境中，純粹的SOA是一種應用軟件架構，其中所有的功能都是相互獨立的服務模塊，通過完備定義的接口相互聯系起來。只要按照一定的順序來請求這些功能模塊所提供的服務，就可以形成完整的業務流程。正如IBM SOA技術和策略總監Mark Colan先生強調的那樣："Web服務的確是實現SOA一條最好的路，但不等同于SOA。"
SOA的靈活性將給企業帶來巨大的好處。如果把企業的IT架構抽象出來，將其功能以粗粒度的服務形式表示出來，每種服務都清晰地表示其業務價值，那么，這些服務的顧客（可能在公司內部，也可能是公司的某個業務伙伴）就可以得到這些服務，而不必考慮其后臺實現的具體技術。更進一步，如果顧客能夠發現并綁定可用的服務，那么在這些服務背后的IT系統能夠提供更大的靈活性。
但是，要得到這種靈活性，需要有一系列實現架構的新方法，這是一項艱巨的任務。企業架構設計師必須要變成"面向服務的架構設計師"，不僅要理解SOA，還要理解SOA的實踐。在架構實踐和最后得到的架構結果之間的區別非常微妙，也非常關鍵。那么目前SOA的實現技術究竟有哪些呢?
3 SOA的實現技術
3.1 實現SOA的核心技術 - web 服務
正如我們前面所講的，服務是整個SOA實現的核心，web服務相關技術自然成為實現SOA的首選。
- XML
XML 1.0 (可擴展標記語言，Extensible Markup Language) 標準是一個基于文本的 World Wide Web 組織 (W3C) 規范的標記語言。與 HTML 使用標簽來描述外觀和數據不同，XML 嚴格地定義了可移植的結構化數據。它可以作為定義數據描述語言的語言，如標記語法或詞匯、交換格式和通信協議。
- SOAP
簡單對象訪問協議 (Simple Object Access Protocol) 是一個基于XML的，用于在分布式環境下交換信息的輕量級協議。SOAP 在請求者和提供者對象之間定義了一個通信協議，這樣，在面向對象編程流行的環境中，該請求對象可以在提供的對象上執行遠程方法調用。因為SOAP是平臺無關和廠商無關的標準，因此盡管SOA并不必須使用SOAP，但在帶有單獨 IT基礎架構的合作伙伴之間的松耦合互操作中，SOAP仍然是支持服務調用的最好方法。
W3C SOAP 1.2規范在服務請求者和服務提供者之間定義使用XML格式的消息進行通信。將應用程序請求（在XML中）放入 SOAP 信封中（也是 XML ），并從請求者到提供者發送應用程序請求，提供者發回的響應也采用相同的形式。最近 SOAP 被稱為面向服務的架構協議 (Services-Oriented Architecture Protocol)。 SOAP的優點在于它完全和廠商無關，相對于平臺、操作系統、目標模型和編程語言可以獨立實現。另外，傳輸和語言綁定以及數據編碼的參數選擇都是由實現決定的。
- WSDL
Web服務描述語言 WSDL (Web Services Description Language) 是一個提供描述服務IDL標準方法的XML詞匯。Web 服務描述語言（WSDL）規范定義了一個 XML詞匯表，該詞匯表依照請求和響應消息，在服務請求者和服務提供者之間定義了一種契約。我們能夠將Web服務定義為軟件，這個軟件通過描述SOAP消息接口的 WSDL文檔來提供可重用的應用程序功能，并使用標準的傳輸協議來進行傳遞。
WSDL描述包含必要的細節,以便服務請求者能夠使用特定服務：
WSDL 是基于 XML 的，因此 WSDL 文檔是計算機可讀的（machine-readable）。這樣開發環境使用WSDL將集成服務的流程自動處理到請求者應用程序。例如 WebSphere Studio產生一個Java的代理對象，它能夠像本地對象一樣實現服務，但是實際上代理對象僅僅處理請求的創建和響應消息的解析。不管服務是否用Java、C#或者其他的語言實現，生成的Java代理對象都能夠從WSDL描述中調用任何的Web服務。實際上，WSDL不能像編程語言那樣描述實現細節。
- UDDI
統一描述、發現和集成 (Universal Description, Discovery and Integration) 規范提供了一組公用的 SOAP API，使得服務代理得以實現。UDDI為發布服務的可用性和發現所需服務定義了一個標準接口（基于 SOAP 消息）。UDDI 實現將發布和發現服務的 SOAP 請求解釋為用于基本數據存儲的數據管理功能調用。
為了發布和發現其他SOA服務，UDDI 通過定義標準的 SOAP 消息來實現服務注冊（Service Registry）。注冊是一種服務代理，它是在 UDDI 上需要發現服務的請求者和發布服務的提供者之間的中介。一旦請求者決定使用特定的服務，開發者通常借助于開發工具（如Microsoft Visual Studio .NET）并通過創建以發送請求并處理響應的方式訪問服務的代碼來綁定服務。
SOA不需要使用UDDI，但由于 UDDI 是建立在SOA上來完成自身工作的，所以UDDI是服務發現的一個好的解決方案。
3.2 SOA 基礎架構的關鍵組件 -企業服務總線（Enterprise Service Bus，ESB）
企業服務總線ESB（Enterprise Service Bus）是SOA架構的一個支柱技術。 作為一種消息代理架構它提供消息隊列系統，使用諸如SOAP或JMS (Java Message Service)等標準技術來實現。 有人把ESB描述成一種開放的、基于標準的消息機制，通過簡單的標準適配器和接口，來完成粗粒度應用（比如服務）和其他組件之間的互操作。
ESB的主要功能有：通信和消息處理、服務交互和安全性控制、服務質量和服務級別管理、建模、管理和自治、基礎架構智能等。ESB由中間件技術實現并作為支持 SOA 的一組基礎架構，支持異構環境中的服務、消息，以及基于事件的交互，并且具有適當的服務級別和可管理性。
SOA的原則可以描述如下：
- 利用顯式的與實現無關的接口來定義服務。
- 利用強調位置透明性和可互操作性的通信協議。
- 封裝可重用業務功能的服務的定義。
為了實現 SOA，應用程序和基礎架構都必須支持 SOA 原則。啟用 SOA 應用程序涉及到創建服務接口，服務接口可以直接也可以間接地通過使用適配器用于現有的或新的功能。從最基本的級別來看，啟用該基礎架構涉及到規劃功能來將服務請求路由和傳遞給正確的服務提供者。然而，基礎架構支持在不影響服務的客戶端的情況下由另一個服務實現替代原有的服務實現也是至關重要的。這不僅需要根據 SOA 原則指定服務接口，而且需要基礎架構允許客戶端代碼以獨立于所涉及的服務位置和通信協議的方式來調用服務。這樣的服務路由和替代是 ESB 的許多功能中的一部分。
ESB 支持這些服務交互功能，并提供集成的通信、消息傳遞以及事件基礎架構來支持這些功能。因此，它將當今正在使用的主要企業集成模式組合成一個實體。ESB 為 SOA 提供與企業需要保持一致的基礎架構，從而提供合適的服務級別和可管理性、以及異構環境中的操作。圖2顯示了ESB為SOA提供的基礎架構：
ESB 需要某種形式的服務路由目錄（service routing directory）來路由服務請求。然而，SOA 可能還有單獨的業務服務目錄（business service directory），其最基本的形式可能是設計時服務目錄，用于在組織的整個開發活動中實現服務的重用。Web 服務遠景在業務服務目錄和服務路由目錄的角色中都放置了一個 UDDI 目錄，因而使得可以動態發現和調用服務。這樣的目錄可以視為 ESB 的一部分；然而，在這樣的解決方案變得普遍之前，業務服務目錄可能與 ESB 是分離的。
Business Service Choreographer 的作用是通過若干業務服務來組合業務流程；因此，它將通過 ESB 調用服務，然后再次通過 ESB 將業務流程公開為客戶端可用的其他服務。然而，Business Service Choreographer 在編排業務流程和服務中所扮演的角色確定了這種業務工作流技術是一種與基礎架構技術 ESB 分離的技術。
最后，B2B Gateway 組件的作用是使兩個或多個組織的服務在受控且安全的方式下對彼此可用。這有助于查看這些連接到 ESB 的組件，但它們并不是 ESB 的一部分。雖然有一些網關技術可以提供適合于實現 B2B Gateway 組件和 ESB 的功能，但是 B2B Gateway 組件的用途是將其與 ESB 分離。事實上，這種用途可能需要附加的功能（如合作伙伴關系管理），這些功能不是 ESB 的一部分，并且不一定受到 ESB 技術的支持。
3.3 實現SOA的方法學 - 模型驅動的開發
SOA強調松散耦合，強調跨平臺集成，這與模型驅動的架構和開發不謀而合。模型驅動的架構和開發(Model Driven Architecture, MDA以及Model Driven Development, MDD)并沒有把業務模型和平臺無關模型分開來，而是把平臺無關模型做為起點。
MDA由提出CORBA的OMG模型提出。MDA認為架構設計師首先要對待創建的系統有一個形式化的UML的模型。MDA首先給出一個平臺無關的模型來表示系統的功能需求和use cases，根據系統搭建的平臺，架構設計師可以由這個平臺無關的模型得到平臺相關的模型，這些平臺相關模型足夠詳細，以至于可以用來直接生成需要的代碼。
基于MDA的思想，利用MDD方式，我們可以對SOA進行建模，在此基礎上，實現各種形式的模型轉換或擴展實現SOA.
4 RSA對SOA實現技術的支持
IBM 軟件開發平臺提供了對SOA 應用程序開發的最好支持。IBM 軟件開發平臺包含 Rational 產品家族、向導、模板、及構建應用程序的指南，Rational 開發工具是基于成功的并且非常受歡迎的 Eclipse 平臺，它不僅易用、靈活，而且在每一個開發進程中都可以使用外部開發環境。圖3顯示了基于 Eclipse 的 IBM Rational 產品體系。
Rational Software Modeler 提供了使用設計標準（比如統一建模語言，UML ）構建模型的能力。通過 Rational Software Modeler，可以將這些模型轉變為類和源代碼。關于Web 服務的開發，Rational Web Developer for WebSphere Software Version 6.0 提供了一種端對端的環境。利用它，不僅可以完成開發和測試，還可以通過 WebSphere Application Server 產品完成 Web 服務的部署。
Rational Software Architect, RSA涵蓋了RAD以及RSM的全部功能，提供了對基于模型的開發以及web應用開發的最好的支持。
4.1 對web服務開發的支持
RSA中包含了構建 Web 服務的專門工具，可以通過自頂向下，自底向上，為web服務建模等不同角度進行web服務的開發，提供了代碼編寫和完成應用程序的開發環境。還可以使用一些額外的工具（比如 IBM Rational Functional Tester），對應用程序進行測試，然后把它部署到 WebSphere 服務器平臺中。
首先，RSA提供了XML的編輯器，可以對XML進行圖形化的顯示和編輯，圖4顯示了對XML的圖形編輯界面及其對應的源代碼。
另外，在RSA中可以創建web service及其相關的多種資源，如圖5所示
當我們想將現有的資源，如Java Bean或者EJB作為web服務進行發布時，RSA中提供相應的支持，如圖6所示：
相反，如果我們想生成已有的WSDL對應的web服務實現代碼，也可以使用RSA中相應的工具，如圖7所示：
RSA中提供了Web服務瀏覽器，使得發現web服務變得更容易，同時，RSA提供了圖形界面對web服務的WSDL進行顯示和編輯。見圖8：
由于RSA提供了對UML2.0的支持，我們同樣可以根據對web服務建模，通過模型轉換來生成相應的web服務WSDL。如圖9所示：
RSA貫穿整個應用程序開發的生命周期，使得應用程序的設計更加輕松，更一致地將 SOA 應用程序的組件捆綁在一起。
RSA內嵌了WebSphere Application Server 6.0的運行環境，WAS 6.0中的SI-BUS實現了ESB，因此我們可以用RSA進行SOA、ESB的部署和測試。如圖10所示，可以在RSA上創建WAS 6.0的服務實例，并在此服務上部署ESB。
4.2 基于模型的開發與軟件資產重用
除了對web服務開發的支持，RSA還提供對UML2.0規范以及可重用資產規范(Reusable Asset Specification, RAS )的支持。這就使得基于模型的開發(Model Based Development, MDA) 和基于資產的開發(Asset Based Development, ABD)成為RSA最有優勢的兩大特征。這里我們只作簡單介紹，在本文的后續文章中，我們將對這些開發作詳細介紹。
4.2.1 支持UML2.0的MDA平臺
UML是實現MDA技術的一把鑰匙，它使得用MDA技術創建的所有應用程序都基于標準化的、平臺獨立的UML模型。通過將這一通用的、被普遍接受的建模標準作為杠桿，MDA使得開發人員可以創建能被輕便地訪問、天生具有良好的互操作性的應用程序。我們在前面提到，利用RSA可以對web服務建模，通過模型轉換生成web服務。
基于Eclipse平臺的RSA，提供各種模式(Pattern)，模板(Template)插件的開發，通過這些高可重用度的模式及模板，用戶只需要簡單的參數配置，就可以得到相應的模型，代碼及其他資源。圖11顯示了應用RSA模式生成新的模型，再基于新模型生成可部署的項目及代碼。
4.2.2 Recipe - 基于資產的開發（Asset Based Development）
RSA中的解決方案指導(Solution Guide)插件基于可重用資產規范對資產的創建，打包，發布，到重用提供了全方位的支持。可以將各種模式，模型及其他可重用資源作為資產導出，存入本地或遠程資產庫以便重用及共享，資產在資產庫中按照一定的方法進行分類，在RSA中使用資產庫瀏覽器對資產進行查找時一目了然。圖12是在可重用資產視圖中，瀏覽資產庫。
5 總結
在本文中，我們討論了面向服務體系架構的基本概念以及實現技術，并列出了IBM Rational產品RSA對實現SOA的技術的支持，在后續的文章中，我們將對本文中涉及的各項具體技術實現細節作詳細介紹。