本文討論了基於服務的建模和架構的重要部分，以及構建面向服務體系結構（SOA）所需的分析和設計的關鍵活動。作者着重強調了選擇鑑別、制定和實現 服務所需的技術，它們的 流程和組合，以及實現和確保 SOA 所需的服務質量的企業級 組件。
目前，關於由 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 架構樣式的概念模型
|
|
定義 SOA 的架構樣式描述了一系列模式和指導方針來創建 鬆耦合，依賴業務的服務，由於描述、實現和綁定之間關係的分離，爲新業務跡象和機會提供了空前的靈活性。
SOA 是企業級的 IT 架構，用來按需連接資源。在 SOA 中，資源對於價值網、企業、業務線內的參與者時可用的（典型的是在一個企業內或多個企業之間跨越多個應用程序）。它由一系列依賴業務的 IT 服務組成，這些服務共同滿足了組織的業務流程和目標。你可以將這些服務設計成合成的應用程序並且通過標準協議來調用它們，如下面的 圖 2所示。
服務是一種有具體服務描述的軟件資源（可發現）。服務消費者可以搜索、綁定和調用服務描述。服務提供者實現服務描述的功能並且向服務消費者提供所需的服務質量。理論上服務應該統一由公佈的方針來管理，並且因此支持動態的 可配置架構樣式。
圖 2: SOA 的屬性
靈活的業務通過靈活的 IT 系統可以實現，主要通過接口、實現和 SOA 提供的綁定（協議）的分離，基於新業務需求，允許在及時給定的點延期 選擇 服務提供者，（功能和非功能（例如，性能、安全、可伸縮性等）需求）。
你可以在內部業務單元之間或者在業務夥伴之間的價值鏈之間以 不規則的實現模式來重用此服務。不規則的實現引用了架構樣式的能力來在他的交互模型中通過合成的方式來應用與參與者關聯的模式和角色。你可以在架構中的一層上應用它，也可以在貫穿企業架構的多個層上來應用它。在項目之間，它可以通過統一的、概念上可升級的方式在價值鏈內部的業務單元和業務夥伴之間。
|
|
在本文中，我介紹了鑑定、指定和實現的高級別的行爲和一些基於服務建模的構件。基於服務的建模是基於服務的分析和設計（SOAD）過程，來建模、分析、設計和生產依賴業務分析、過程和目標的 SOA。
首先我將看一下你想要構建什麼，也就是 SOA 和它的層。接下來我將通過討論創建 SOA 所需主要的活動和技術來描述如何構建 SOA。
作爲一個示例，我們假設你正在開發一個項目，並且目標是將一部分具有自服務帳目系統的銀行業務線移植到 SOA上。
爲了移植到 SOA，你需要一些超出服務建模的附加元素。它們包括：
- 採用和成熟模型。在 SOA 和 Web 服務的採用上你的企業處在那個成熟的相對級別上？採用的每個不同的級別都與它自己的唯一的要求。
- 評估。你有一些領導者嗎？你已經涉足 Web 服務了嗎？作爲結果的架構好到什麼程度？你應該繼續維持同樣的方向嗎？這將衡量企業 SOA 嗎？你已經考慮了所有應該考慮的事情了嗎？
- 策略和規劃活動。你如何規劃到 SOA 的移植？你需要考慮的步驟、工具、方法、技術、標準和培訓是什麼？你的路線圖和遠景是什麼？你如何達到目的？計劃是什麼？
- 管理方法。現有的 API 和能力是否應該變成服務？如果不是，哪個是符合條件的？每個服務都應該以通過某種方式爲業務帶來價值爲目的來創建。你如何樣毫無妨礙的來管理這些過程？
- 實行最佳實踐。什麼是可靠和經過測試的方式來實現安全，確保性能，遵從互操作性標準，設計來作改變？
上面的關於移植到 SOA 和實現以後附加活動的討論應該得到它們自己的文章，本系列中我將在隨後的列中接觸到這個。目前，讓我們假設你爲項目定義了範圍，並且決定了集中在什麼地方：已經定義了一個焦點，用來將現有的系統或服務轉化到一系列新的系統和服務。現在你可以開始基於服務建模來構建你的基於服務的架構。
|
|
SOA 的一個抽象觀點將它描述爲與業務過程結合在一起的合成服務的部分分層架構。 圖 3 呈現了這種類型的架構。
服務和組建之間的關係是，企業級的組件（大粒度的企業或者業務線組件）實現該服務並且負責提供它們的功能和維持它們的服務質量。通過組合這些公開的服務到合成的應用程序，就可以支持業務過程流。綜合的架構通過使用 Enterprise Service Bus（ESB）支持這些服務、組件和流程的路由、中介和轉化。爲了服務質量和非功能性的需求，必須監視和管理已經部署的服務。
圖 3：SOA 層
對於每一層，你都必須做設計和架構決定。因此，爲了幫助用文件說明你的 SOA，你可能應該創建文檔，由每個層相應的部分所組成。
這裏是爲你的 SOA 架構文檔設計的模板：
- 範圍 <此架構適用於企業的哪個領域>
- 操作系統層
- 打包的應用程序
- 自定義應用程序
- 架構決策
- 企業組件層
- 企業組件支持的功能範圍
- <這個企業組件支持業務領域、目標和過程>
- 關於控制的決策
- <作爲這個客戶端組織內部企業組件來選擇某物的標準>
- 架構決策
- 服務層
- 服務分類表
- 架構決策
- 業務過程和合成層
- 業務過程可以表現爲舞蹈編排（choreographies）
- 架構決策
- <哪一個過程需要編排在舞蹈編排裏面以及哪一個鑲嵌在應用程序裏面？>
- 訪問或者表現層
- <證明這層中 Web 服務和 SOA 的含意；即便要。例如，在用戶接口級別上調用 Web 服務的 portlet 的使用，以及在此層機能上的含意。>
- 集成層
- <包含 ESB 因素>
- <我們如何確保使用服務的客戶端系統級的一致性（SLA）和服務質量（QoS）？>
- 安全問題和決策
- 性能問題和決策
- 技術和標準的侷限性以及決策
- 服務的監控和管理
- 描述和決策
層 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：基於服務建模的活動
圖 4顯示了通過提供者和消費者的每個角色來管理的活動。注意，提供者的活動是消費者活動的父集（例如，提供者同樣參與服務鑑別、分類等）。在許多情況下，角色的區別來自如下的事實，消費者指定他們想要的服務，經常的搜索它，並且一旦他們確信和他們尋找的服務規範相匹配，並且是由服務提供者提供，他們就會根據需要綁定和調用服務。提供者需要依次發佈他們想要支持的服務；即在功能方面，更重要的是在消費者所需的 QoS 方面。這個在消費者和提供者之間的隱含的契約可能在 SLA 方面成熟爲明確的契約；自動的或者通過業務和合法區域來處理。
上面描述的活動可以被描述爲在基於服務的建模和架構方法內流動，如下面的 圖 5 所示。
圖 5：基於服務的建模和架構方法
基於服務的建模和架構過程包含三個主要的步驟：服務，組件和流程（典型地，服務的編排）的鑑別，指定和實現。
這個過程由域分解、現有資產分析和目標服務建模的自頂向下、自底向上、中間向外技術的聯合組成。在 自頂向下視圖中，業務用例的藍圖提供了業務服務的規範。這個自頂向下的過程作爲 域分解來被引用，域分解由業務領域到它的功能區域和子系統的分解組成，包含它的流程或過程分解成過程、自過程和高級別業務用例。很多情況下，這些用例是公開在企業邊緣的業務服務，或者在貫穿業務線企業邊界內所用的非常好的候選。
在過程的 從下到上的部分或者 現有系統分析中，現有的系統被分析和選擇作爲可行的候選，來爲支持業務過程的底層服務功能性實現提供低消耗的解決方案。在這個過程中，你分析和利用了來自遺留和打包應用程序的 API、事務和模塊。在有些情況下，爲了支持服務的功能重新模塊化現有的資產需要遺留系統的組件化。
中間向外視圖由 目標服務建模組成，來驗證和發現自頂向下或自底向上的服務鑑別手段中沒有捕捉到的其他服務。它將服務連結到目標和子目標、關鍵性能指示和尺度。
這個活動在服務被指定時開始。將服務分級爲服務層次是非常重要的，反映了服務的複合或者不規則的本性：服務可以也應該由良好粒度的組建和服務組成，分級幫助決定合成和分層，以及基於層次的相互依賴服務的協同構建。同樣，它幫助減輕服務增值綜合症，這種症狀中，越來越多的小粒度的服務被定義、設計和部署，卻缺乏控制，導致了主要的性能、可伸縮性和管理問題。更加重要的是，服務增值未能提供服務，這些服務對業務是非常有用的。
這個活動獲取上面域分解過程中發現的子系統，並且指定子系統之間的相互依賴和流程。它同樣將域分解過程中鑑別的用例作爲子系統接口上公開的服務。子系統的分析包含創建對象模型來表現內部工作方式，以及所包含的公開服務並且實現它們的子系統設計。這時，“子系統”的設計結構將實現爲大粒度組件實現構造，在下面的活動中實現服務。
在下面的主要活動中，實現服務的組件的細節將指定：
- 數據
- 規則
- 服務
- 可配置概要
- 變更
服務分配包括分派服務到目前鑑別的子系統。這些子系統具有實現了他們所公佈的功能的企業組件。你經常會簡單化假定，子系統同企業組件有一對一的聯繫。 結構化組件在你使用模式來構造企業組件時會通過以下幾點的聯合的形式出現：
- 中介體
- Facade
- 規則對象
- 可配置概要
- 工廠
這個步驟指出實現給定服務的軟件必須被選擇或者自定義構建。其他可用的選項包括使用 Web 服務來集成、轉化、訂閱和外購不同功能。在這個步驟中，你決定哪個遺留系統模塊用來實現給定的服務，以及哪個服務將從基礎來構建。服務的其他實現決策不同於業務功能包括：服務的安全、管理和監視。
事實上，項目趨向於利用任意數量的相應的努力來滿足關閉的機會窗口。因此，我推薦並行的管理三個流。
自頂向下的域分解（過程建模和分解，基於變更的分析，方針和業務規則分析，領域特定行爲建模（使用語法和圖表））是同供組件化（模塊化）和服務公開候選的現有遺留資產的分析並行控制。爲了獲得項目背後的業務意圖和使服務同業務意圖密切合作，目標服務建模可以來控制。
|
|
本文中，我以基於服務架構、它的層和架構決策的相關類型的基礎知識來開始。接下來，我通過一種方法，描寫了基於服務建模的活動，以及從服務消費者和提供者角度來看活動的重要性（服務代理將在後面的文章中涉及到）。這種方式爲決定基於服務架構的三個基礎方面提供了在分析和設計活動方面詳細的指導：服務，流程和實現服務的組件。我還描述了一個模板，你可以用它來在 SOA 的每個層上爲你的架構進行決策。
我提到了，對於服務鑑別，自頂向下、自底向上和跨部分、目標模型分析三種手段的結合非常重要。接下來我關注了一下服務指定和實現的主要活動。
這一系列的下一篇文章中，我將應用該方法到帳戶管理的空領域中，並且用例子來描述每個步驟。除鑑別、指定和實現之外，我還將討論基於服務建模手段的其餘活動，包含用來支持完整的 SOA 生命週期的部署、監視、管理和控制。
作者希望象下面這些尊敬的同事和朋友致謝，感謝他們寶貴的建議和反饋（無特定順序）：Luba Cherbakov，Kerrie Holley，George Galambos，Sugandh Mehta，David Janson，Shankar Kalyana，Ed Calunzinski，Abdul Allam，Peter Holm，Krishnan Ramachandran，Jenny Ang，Jonathan Adams，Sunil Dube，Ralph Wiest，Olaf Zimmerman，Emily Plachy，Kathy Yglesias-Reece，以及 David Mott。
- 您可以參閱本文在 developerWorks 全球站點上的 英文原文。
- 閱讀這篇文章“ 面向服務的分析與設計原理”，（developerWorks，2004 年 6 月）獲取關於 SOA 項目的學科間建模手段的信息。
- 閱讀“ 模式：基於服務的架構和 Web 服務”紅皮書，SG24-6303-00，2004 年 4 月，Endrei M.， et al。
- 訪問 WebServices.Org ™ 來查找關於 Goal-oriented approach to enterprise component identification and specification 的更多信息，Communications of the ACM，2002 年 10 月，K. Levi，A. Arsanjani。
- 獲取 Ali Arsanjani，James J. Alpigini 和 Hussein Zedan 所著的 Externalizing Component Manners to Achieve Greater Maintainability through a Highly Re-Configurable Architectural Style 。Proceedings of the ICSM: 628-. IEEE Press 2002。
- 閱讀 Patterns: Implementing an SOA with the Enterprise Service Bus“紅皮書，SG24-6346-00，August 2004，Martin Keen，Susan Bishop，Alan Hopkins，Sven Milinski， Chris Nott， Rick Robinson， Jonathan Adams， Paul Verschueren。
- 使用 快速啓動 Web 服務訪問 Web 服務知識、工具和技能，它提供了最新的基於 Java 的軟件開發工具和來自 IBM 的中間件（試用版），以及在線教程和文章和在線技術論壇。
- 通過參與 developerWorks blogs 來加入到 developerWorks 社區。
- 訪問 Developer Bookstore 以獲取綜合性的技術圖書列表，其中包括數以百計的 Web 服務主題。
- 想獲取更多信息嗎？developerWorks 的 SOA 與 Web 服務專區擁有許多提供信息的文章和關於如何開發 Web 服務應用程序的入門級、中級的和高級教程。