引言

目前，關于由 Service-oriented Architectures （ SOA ）和它的 Web 服務實現所表現的時機有許多傳言 -- 有一些是有事實根據的，但是一些卻沒有什么事實依據。分析家已經預言，博學者已經聲稱，教授已經講演，公司已經匆忙的賣他們的產品，作為 SOA 產品 -- 經常失去 SOA 不是一個產品的要點。它是業務和 IT 之間的橋梁，通過一系列使用一些設計原則、模式和技術的依賴于業務的 IT 服務來實現。

ZDNet 最近報道說，“ Gartner 預言到了 2008 年，至少 60% 的企業將使用 SOA 作為創建任務苛刻的應用程序和過程的“指導原則”。

開發和實現 SOA 有很大的需求。因此如果 SOA 不僅僅和產品和幫助實現它的標準相關（比如通過 Web 服務），那么為了實現 SOA 你還需要什么附加的元素嗎？ 基于服務的建模 需要其他的行為和構件，這些在傳統的基于對象的分析和設計（ OOAD ）中是不存在的。“ 基于服務的分析和設計的元素 ”這篇文章描述了一些最初的原因，解釋了為什么你需要 OOAD 之外更多的內容。它同樣描述了業務流程管理或企業架構（ EA ）和 OOAD 為什么不是管理分析和設計的適當手段。同樣，在 IBM Redbook 中名為 “ 模式：Service-Oriented Architecture 和 Web Services ”的文章中，我舉例說明了基于服務的建模方法的主要活動。

然而，你還需要重視一些額外的重要的需要考慮的事項。首先，目前的 OOAD 方法沒有定位 SOA 三個重要的元素： 服務 ， 流 ，和實現服務的 組件 。你同樣需要可以明確定位鑒別、制定和實現服務所需的技術和過程，它們的流程和組合，以及實現和確保所需服務質量的企業級組件。

第二，需要進行范例的替換，以便更好的區分 SOA 的兩個關鍵角色之間的截然不同的需求：服務提供者和服務消費者。第三，假設為一個企業或者業務線構建的應用程序，現在必須被提升到一個供應鏈中使用，并且公開給合作伙伴，這些合作伙伴可能組合、聯合和封裝應用程序到一個新的應用程序中。這是服務生態系統或者服務價值網的概念。

這是僅從“分布式對象”的一個微小的進步。它是關于通過網絡作用創造的價值：例如，當合作伙伴利用了 Amazon.com 與 Google 搜索的聯合，并且與 eBay 服務結合在一起，來構建他們自己的混合解決方案。或者當旅行社深入到機票預訂系統，并且與汽車租賃公司以及賓館相互協調，更新他們的記錄并且將旅行計劃發送到你的電子檔案中。無論什么樣的應用程序，你如果想成功地創建 SOA ，需要的都不僅僅是好的工具和標準。你需要一些規范的步驟來支持你的 SOA 生命周期；用來分析、設計、實現服務、流程和組件的技術。因此，對于任何對企業應用程序開發感興趣的人來講，理解基于服務的建模和架構中包含的細節步驟是非常重要的。

在我詳細描述這些步驟以前，我們首先應理解你打算要做什么： 什么是 SOA ，以及它看起來像是什么？ 在定義了 SOA 后面的概念和觀點以后，我將描述 SOA 的層和你如何去記錄每個層中的關鍵架構決策，這些層幫助你為 SOA 構建藍圖，這些 SOA 正是那些你試圖同一系列實現了 SOA 服務、流程和組件集成以及出現的項目、業務線、企業級成果和價值鏈所需要的。

Service-Oriented Architecture ：概念模型

這個概念基于一種架構樣式，該樣式在三個主要參與者之間定義了交互模型：服務提供者，公布服務描述并且實現服務，服務消費者，他既可以使用統一資源標記符（ URI ）來直接使用服務描述，也可以在服務注冊中心來查找服務描述并且綁定和調用服務。服務代理提供和維護服務注冊中心，然而現在并沒有通用公共注冊中心。

圖 1 是一個顯示了這些關系的元模型。


圖 1 ： SOA 架構樣式的概念模型

1.JPG
架構樣式和原理

定義 SOA 的架構樣式描述了一系列模式和指導方針來創建 松耦合，依賴業務 的服務，由于描述、實現和綁定之間關系的分離，為新業務跡象和機會提供了空前的靈活性。

SOA 是企業級的 IT 架構，用來按需連接資源。在 SOA 中，資源對于價值網、企業、業務線內的參與者時可用的（典型的是在一個企業內或多個企業之間跨越多個應用程序）。它由一系列依賴業務的 IT 服務組成，這些服務共同滿足了組織的業務流程和目標。你可以將這些服務設計成合成的應用程序并且通過標準協議來調用它們，如下面的 圖 2 所示。

服務是一種有具體服務描述的軟件資源（可發現）。服務消費者可以搜索、綁定和調用服務描述。服務提供者實現服務描述的功能并且向服務消費者提供所需的服務質量。理論上服務應該統一由公布的方針來管理，并且因此支持動態的 可配置架構樣式 。


圖 2: SOA 的屬性

1.JPG靈活的業務通過靈活的 IT 系統可以實現，主要通過接口、實現和 SOA 提供的綁定（協議）的分離，基于新業務需求，允許在及時給定的點延期 選擇 服務提供者 ，（功能和非功能（例如，性能、安全、可伸縮性等）需求）。

你可以在內部業務單元之間或者在業務伙伴之間的價值鏈之間以 不規則的實現模式 來重用此服務。不規則的實現引用了架構樣式的能力來在他的交互模型中通過合成的方式來應用與參與者關聯的模式和角色。你可以在架構中的一層上應用它，也可以在貫穿企業架構的多個層上來應用它。在項目之間，它可以通過統一的、概念上可升級的方式在價值鏈內部的業務單元和業務伙伴之間。

上下文

在本文中，我介紹了鑒定、指定和實現的高級別的行為和一些基于服務建模的構件。基于服務的建模是基于服務的分析和設計（ SOAD ）過程，來建模、分析、設計和生產依賴業務分析、過程和目標的 SOA 。

首先我將看一下你想要構建什么，也就是 SOA 和它的層。接下來我將通過討論創建 SOA 所需主要的活動和技術來描述如何構建 SOA 。

作為一個示例，我們假設你正在開發一個項目，并且目標是將一部分具有自服務帳目系統的銀行業務線移植到 SOA 上。

為了移植到 SOA ，你需要一些超出服務建模的附加元素。它們包括：

  • 采用和成熟模型。在 SOA 和 Web 服務的采用上你的企業處在那個成熟的相對級別上？采用的每個不同的級別都與它自己的唯一的要求。
  • 評估。你有一些領導者嗎？你已經涉足 Web 服務了嗎？作為結果的架構好到什么程度？你應該繼續維持同樣的方向嗎？這將衡量企業 SOA 嗎？你已經考慮了所有應該考慮的事情了嗎？
  • 策略和規劃活動。你如何規劃到 SOA 的移植？你需要考慮的步驟、工具、方法、技術、標準和培訓是什么？你的路線圖和遠景是什么？你如何達到目的？計劃是什么？
  • 管理方法。現有的 API 和能力是否應該變成服務？如果不是，哪個是符合條件的？每個服務都應該以通過某種方式為業務帶來價值為目的來創建。你如何樣毫無妨礙的來管理這些過程？
  • 實行最佳實踐。什么是可靠和經過測試的方式來實現安全，確保性能，遵從互操作性標準，設計來作改變？

除了本文中描述的鑒別、制定和實現之外，基于服務的建模方法還包含了支持完整 SOA 生命周期的部署、監視、管理和控制所需的技術。

上面的關于移植到 SOA 和實現以后附加活動的討論應該得到它們自己的文章，本系列中我將在隨后的列中接觸到這個。目前，讓我們假設你為項目定義了范圍，并且決定了集中在什么地方：已經定義了一個焦點，用來將現有的系統或服務轉化到一系列新的系統和服務。現在你可以開始基于服務建模來構建你的基于服務的架構。

SOA 的一個架構模板

SOA 的一個抽象觀點將它描述為與業務過程結合在一起的合成服務的部分分層架構。 圖 3 呈現了這種類型的架構。

服務和組建之間的關系是，企業級的組件（大粒度的企業或者業務線組件）實現該服務并且負責提供它們的功能和維持它們的服務質量。通過組合這些公開的服務到合成的應用程序，就可以支持業務過程流。綜合的架構通過使用 Enterprise Service Bus （ ESB ）支持這些服務、組件和流程的路由、中介和轉化。為了服務質量和非功能性的需求，必須監視和管理已經部署的服務。


圖 3 ： SOA 層

2.JPG
對于每一層，你都必須做設計和架構決定。因此，為了幫助用文件說明你的 SOA ，你可能應該創建文檔，由每個層相應的部分所組成。

這里是為你的 SOA 架構文檔設計的模板：

  1. 范圍 < 此架構適用于企業的哪個領域 >
  2. 操作系統層
    1. 打包的應用程序
    2. 自定義應用程序
    3. 架構決策
  3. 企業組件層
    1. 企業組件支持的功能范圍
    2. < 這個企業組件支持業務領域、目標和過程 >
    3. 關于控制的決策
      1. < 作為這個客戶端組織內部企業組件來選擇某物的標準 >
    4. 架構決策
  4. 服務層
    1. 服務分類表
    2. 架構決策
  5. 業務過程和合成層
    1. 業務過程可以表現為舞蹈編排（ choreographies ）
    2. 架構決策
      1. < 哪一個過程需要編排在舞蹈編排里面以及哪一個鑲嵌在應用程序里面？ >
  6. 訪問或者表現層
    1. < 證明這層中 Web 服務和 SOA 的含意；即便要。例如，在用戶接口級別上調用 Web 服務的 portlet 的使用，以及在此層機能上的含意。 >
  7. 集成層
    1. < 包含 ESB 因素 >
    2. < 我們如何確保使用服務的客戶端系統級的一致性（ SLA ）和服務質量（ QoS ）？ >
    3. 安全問題和決策
    4. 性能問題和決策
    5. 技術和標準的局限性以及決策
    6. 服務的監控和管理
      1. 描述和決策

現在，讓我們更加仔細的描述一下每一層以及每一層之間的合成。

層 1 ：操作系統層。 本層包含現有的自定義構建的應用程序，也叫做 遺留 系統，包含現有的 CRM 和 ERP 打包應用程序，以及 較舊的 基于對象的系統實現，還有業務智能應用程序。 SOA 的復合層架構可以利用現有的系統并且用基于服務的集成技術來集成它們。

層 2 ：企業組件層。 本層由那些負責實現功能和保持公開服務 QoS 的企業組件組成。這些特殊的組件是企業和業務單元級支持的企業資產的受管理和控制的集合。 同企業范圍資產一樣，他們通過架構最佳實踐應用程序來負責確保 SLAs 的一致。大多數情況下，本層使用基于容器的技術，比如實現組件、負載均衡、高可用性和工作量管理的應用服務器。

層 3 ：服務層。 業務選擇來支持和公開的服務處在這一層。它們可以被 發現 或者直接靜態綁定，接下來被調用，或者可能的話，編排到合成服務中。這個服務公開層同樣提供了獲取企業范圍組件，業務單元特定組件，以及有些情況下，特定項目組建的機制，并且以服務描述的形式具體化了他們的接口子集。因此，企業組件使用它們接口提供的功能在運行時提供服務實現。在這一層的接口公開為一個服務描述，在這層中他們被公開以提供使用。他們可以獨立存在或者作為合成服務。

層 4 ：業務過程合成或編排層。 第三層中公開的服務的合成和編排在這一層中被定義。通過配合、編排，服務被綁定成一個流程，并且從而作為單獨的應用程序而共同作用。這些應用程序支持特殊的用例和業務過程。這里，可視的流程合成工具，比如 IBM? WebSphere? Business Integration Modeler 或者 Websphere Application Developer Integration Edition ，都可以用來設計應用程序流程。

層 5 ：訪問或表現層。 盡管這一層經常超出了圍繞 SOA 討論的范圍，但是它卻變得越來越有意義。在這里我描述它因為標準越來越集中，比如用于 Remote Portlets Version 2.0 的 Web 服務和其他技術，這些技術追求在應用程序接口或者表現層來利用 Web 服務。你可以把它作為將來的層用來滿足將來的解決方案的需求。注意到以下這兩點是非常重要的： SOA 將用戶接口從組件中分離出來；最終你需要提供從訪問路線到服務或者合成服務的端到端解決方案。

層 6 ：集成（ ESB ）。 這一層使服務可以集成，通過引入一系列可靠的性能的集合，比如智能路由，協議中介和其他轉化機制，經常被描述為 ESB （參閱 參考資料 ）。 Web Services Description Language （ WSDL ）制定了綁定，其包含提供服務的地址。另一方面， ESB 為集成提供了位置獨立機制。

層 7 ： QoS 。 這一層提供了監視，管理和維持諸如安全，性能和可用性等 QoS 的能力。這是一個通過 sense-and-respond 機制和監測 SOA 應用程序健康的工具來進行的后臺處理過程，包括 WS-Management 和其他相關協議的所有的重要的標準實現以及為 SOA 實現服務質量的標準。

通過什么步驟來進行基于服務的建模和架構

本節描述了如何利用遺留的投資，來 聯合 自頂向下的，業務驅動的手段和自底向上的手段。

基于服務的建模手段提供了建模、分析、設計技術和活動來定義 SOA 的基礎。它通過在 SOA 的每一層定義元素以及在每一層作嚴格的架構決策來起到幫助作用。它通過聯合服務鑒別的自頂向下、業務驅動方式和通過利用遺留資產和系統引導服務鑒別來實現這一點。

這樣，高級別的業務過程功能性為大粒度的服務更加的具體化。小粒度的服務 -- 這些可以幫助實現高級別的服務 -- 通過檢查遺留功能性和決定如何創建適配器、封裝器，或者組合遺留系統來具體化系統內經常調用的期望功能性可以來鑒別。

最后，使用 針對服務的建模 ，你使用 跨部分 手段來削減候選的可能已經被確定的服務的絕對數量。一個比較明智的手段應該是首先按照自頂向下來做，接下來進行目標服務建模，最后是自底向上的現有資產的遺留分析。消息是：你將項目的范圍定義至一個可管理、實現的集合越快，你就能更快的通過聚焦在關鍵服務來公開組成 SOA 基礎的服務描述來實現價值。

這個功能性業務需求和遺留系統中現有投資利用的結合，為那些想要快速贏得和移植他們的企業到一個現代的 SOA 的組織提供了有效的解決方案。通過基于服務的集成的軟件應用程序的聯合因此變得具備可能性。

基于服務的集成是 Enterprise Application Integration （ EAI ）的一個進化，在 EAI 中，所有的連接通過位置透明的 ESB 概念被基于標準的鏈接替換，并提供了一系列靈活的路由、中介和轉化能力。

基于服務的建模：服務的分析和設計

迄今為止，我已經通過描述 SOA 設定了階段。我同樣展示了要想構建 SOA ，你需要在你 SOA 的每個層中做關鍵架構決策，并且你的設計必須反映一系列依賴業務的服務和關于他們如何通過編排來合成到應用程序的決策。

與對象不同，你在 SOA 中需要考慮兩個觀點；他們是服務消費者和服務提供者。服務代理目前不是主流，并且在后面的部分終將被涉及到。

SOA 的設計策略并不從“自底向上”開始，這是 Web 基于服務途徑常有的事情。你必須記住， SOA 更加有戰略意義，并更加依賴于業務。 Web 服務是 SOA 的巧妙實現。許多關鍵的活動和決策存在不僅僅影響集成架構，而且還影響企業和應用程序架構。他們包含兩個 圖 4 中描述的消費者和提供者的活動 .


圖 4 ：基于服務建模的活動
 3.JPG 3.JPG

圖 4 顯示了通過提供者和消費者的每個角色來管理的活動。注意，提供者的活動是消費者活動的父集（例如，提供者同樣參與服務鑒別、分類等）。在許多情況下，角色的區別來自如下的事實，消費者指定他們想要的服務，經常的搜索它，并且一旦他們確信和他們尋找的服務規范相匹配，并且是由服務提供者提供，他們就會根據需要綁定和調用服務。提供者需要依次發布他們想要支持的服務；即在功能方面，更重要的是在消費者所需的 QoS 方面。這個在消費者和提供者之間的隱含的契約可能在 SLA 方面成熟為明確的契約；自動的或者通過業務和合法區域來處理。

上面描述的活動可以被描述為在基于服務的建模和架構方法內流動，如下面的 圖 5 所示。

圖 5 ：基于服務的建模和架構方法
4.JPG

基于服務的建模和架構過程包含三個主要的步驟：服務，組件和流程（典型地，服務的編排）的鑒別，指定和實現。

Service 鑒別

這個過程由域分解、現有資產分析和目標服務建模的自頂向下、自底向上、中間向外技術的聯合組成。在 自頂向下視圖中 ，業務用例的藍圖提供了業務服務的規范。這個自頂向下的過程作為 域分解 來被引用，域分解由業務領域到它的功能區域和子系統的分解組成，包含它的流程或過程分解成過程、自過程和高級別業務用例。很多情況下，這些用例是公開在企業邊緣的業務服務，或者在貫穿業務線企業邊界內所用的非常好的候選。

在過程的 從下到上的部分 或者 現有系統分析 中，現有的系統被分析和選擇作為可行的候選，來為支持業務過程的底層服務功能性實現提供低消耗的解決方案。在這個過程中，你分析和利用了來自遺留和打包應用程序的 API 、事務和模塊。在有些情況下，為了支持服務的功能重新模塊化現有的資產需要遺留系統的組件化。

中間向外視圖 由 目標服務建模 組成，來驗證和發現自頂向下或自底向上的服務鑒別手段中沒有捕捉到的其他服務。它將服務連結到目標和子目標、關鍵性能指示和尺度。

服務分級和分類

這個活動在服務被指定時開始。將服務分級為服務層次是非常重要的，反映了服務的復合或者不規則的本性：服務可以也應該由良好粒度的組建和服務組成，分級幫助決定合成和分層，以及基于層次的相互依賴服務的協同構建。同樣，它幫助減輕服務增值綜合癥，這種癥狀中，越來越多的小粒度的服務被定義、設計和部署，卻缺乏控制，導致了主要的性能、可伸縮性和管理問題。更加重要的是，服務增值未能提供服務，這些服務對業務是非常有用的。

子系統分析

這個活動獲取上面域分解過程中發現的子系統，并且指定子系統之間的相互依賴和流程。它同樣將域分解過程中鑒別的用例作為子系統接口上公開的服務。子系統的分析包含創建對象模型來表現內部工作方式，以及所包含的公開服務并且實現它們的子系統設計。這時，“子系統”的設計結構將實現為大粒度組件實現構造，在下面的活動中實現服務。

組件指定

在下面的主要活動中，實現服務的組件的細節將指定：

  • 數據
  • 規則
  • 服務
  • 可配置概要
  • 變更

消息和時間指定以及管理定義出現在這一步驟中。

服務分配

服務分配包括分派服務到目前鑒別的子系統。這些子系統具有實現了他們所公布的功能的企業組件。你經常會簡單化假定，子系統同企業組件有一對一的聯系。 結構化組件 在你使用模式來構造 企業組件 時會通過以下幾點的聯合的形式出現：

  • 中介體
  • Facade
  • 規則對象
  • 可配置概要
  • 工廠

服務分配同樣由服務的指派和在 SOA 層中實現他們的組件組成。組件和服務向 SOA 層中的分配是一個關鍵的任務，需要關鍵架構決策的文件和決議，這些決策不僅僅同應用程序架構有關系，也同在運行時設計和用來支持 SOA 實現的技術操作架構有關的。

服務實現

這個步驟指出實現給定服務的軟件必須被選擇或者自定義構建。其他可用的選項包括使用 Web 服務來集成、轉化、訂閱和外購不同功能。在這個步驟中，你決定哪個遺留系統模塊用來實現給定的服務，以及哪個服務將從基礎來構建。服務的其他實現決策不同于業務功能包括：服務的安全、管理和監視。

事實上，項目趨向于利用任意數量的相應的努力來滿足關閉的機會窗口。因此，我推薦并行的管理三個流。

自頂向下的域分解（過程建模和分解，基于變更的分析，方針和業務規則分析，領域特定行為建模（使用語法和圖表））是同供組件化（模塊化）和服務公開候選的現有遺留資產的分析并行控制。為了獲得項目背后的業務意圖和使服務同業務意圖密切合作，目標服務建模可以來控制。

結束語

本文中，我以基于服務架構、它的層和架構決策的相關類型的基礎知識來開始。接下來，我通過一種方法，描寫了基于服務建模的活動，以及從服務消費者和提供者角度來看活動的重要性（服務代理將在后面的文章中涉及到）。這種方式為決定基于服務架構的三個基礎方面提供了在分析和設計活動方面詳細的指導：服務，流程和實現服務的組件。我還描述了一個模板，你可以用它來在 SOA 的每個層上為你的架構進行決策。

我提到了，對于服務鑒別，自頂向下、自底向上和跨部分、目標模型分析三種手段的結合非常重要。接下來我關注了一下服務指定和實現的主要活動。

這一系列的下一篇文章中，我將應用該方法到帳戶管理的空領域中，并且用例子來描述每個步驟。除鑒別、指定和實現之外，我還將討論基于服務建模手段的其余活動，包含用來支持完整的 SOA 生命周期的部署、監視、管理和控制。

?