引言

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

ZDNet 最近報道說，“ Gartner 預(yù)言到了 2008 年，至少 60% 的企業(yè)將使用 SOA 作為創(chuàng)建任務(wù)苛刻的應(yīng)用程序和過程的“指導(dǎo)原則”。

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

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

第二，需要進(jìn)行范例的替換，以便更好的區(qū)分 SOA 的兩個關(guān)鍵角色之間的截然不同的需求：服務(wù)提供者和服務(wù)消費(fèi)者。第三，假設(shè)為一個企業(yè)或者業(yè)務(wù)線構(gòu)建的應(yīng)用程序，現(xiàn)在必須被提升到一個供應(yīng)鏈中使用，并且公開給合作伙伴，這些合作伙伴可能組合、聯(lián)合和封裝應(yīng)用程序到一個新的應(yīng)用程序中。這是服務(wù)生態(tài)系統(tǒng)或者服務(wù)價值網(wǎng)的概念。

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

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

Service-Oriented Architecture ：概念模型

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

圖 1 是一個顯示了這些關(guān)系的元模型。


圖 1 ： SOA 架構(gòu)樣式的概念模型

1.JPG
架構(gòu)樣式和原理

定義 SOA 的架構(gòu)樣式描述了一系列模式和指導(dǎo)方針來創(chuàng)建 松耦合，依賴業(yè)務(wù) 的服務(wù)，由于描述、實現(xiàn)和綁定之間關(guān)系的分離，為新業(yè)務(wù)跡象和機(jī)會提供了空前的靈活性。

SOA 是企業(yè)級的 IT 架構(gòu)，用來按需連接資源。在 SOA 中，資源對于價值網(wǎng)、企業(yè)、業(yè)務(wù)線內(nèi)的參與者時可用的（典型的是在一個企業(yè)內(nèi)或多個企業(yè)之間跨越多個應(yīng)用程序）。它由一系列依賴業(yè)務(wù)的 IT 服務(wù)組成，這些服務(wù)共同滿足了組織的業(yè)務(wù)流程和目標(biāo)。你可以將這些服務(wù)設(shè)計成合成的應(yīng)用程序并且通過標(biāo)準(zhǔn)協(xié)議來調(diào)用它們，如下面的 圖 2 所示。

服務(wù)是一種有具體服務(wù)描述的軟件資源（可發(fā)現(xiàn)）。服務(wù)消費(fèi)者可以搜索、綁定和調(diào)用服務(wù)描述。服務(wù)提供者實現(xiàn)服務(wù)描述的功能并且向服務(wù)消費(fèi)者提供所需的服務(wù)質(zhì)量。理論上服務(wù)應(yīng)該統(tǒng)一由公布的方針來管理，并且因此支持動態(tài)的 可配置架構(gòu)樣式 。


圖 2: SOA 的屬性

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

你可以在內(nèi)部業(yè)務(wù)單元之間或者在業(yè)務(wù)伙伴之間的價值鏈之間以 不規(guī)則的實現(xiàn)模式 來重用此服務(wù)。不規(guī)則的實現(xiàn)引用了架構(gòu)樣式的能力來在他的交互模型中通過合成的方式來應(yīng)用與參與者關(guān)聯(lián)的模式和角色。你可以在架構(gòu)中的一層上應(yīng)用它，也可以在貫穿企業(yè)架構(gòu)的多個層上來應(yīng)用它。在項目之間，它可以通過統(tǒng)一的、概念上可升級的方式在價值鏈內(nèi)部的業(yè)務(wù)單元和業(yè)務(wù)伙伴之間。

上下文

在本文中，我介紹了鑒定、指定和實現(xiàn)的高級別的行為和一些基于服務(wù)建模的構(gòu)件。基于服務(wù)的建模是基于服務(wù)的分析和設(shè)計（ SOAD ）過程，來建模、分析、設(shè)計和生產(chǎn)依賴業(yè)務(wù)分析、過程和目標(biāo)的 SOA 。

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

作為一個示例，我們假設(shè)你正在開發(fā)一個項目，并且目標(biāo)是將一部分具有自服務(wù)帳目系統(tǒng)的銀行業(yè)務(wù)線移植到 SOA 上。

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

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

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

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

SOA 的一個架構(gòu)模板

SOA 的一個抽象觀點將它描述為與業(yè)務(wù)過程結(jié)合在一起的合成服務(wù)的部分分層架構(gòu)。 圖 3 呈現(xiàn)了這種類型的架構(gòu)。

服務(wù)和組建之間的關(guān)系是，企業(yè)級的組件（大粒度的企業(yè)或者業(yè)務(wù)線組件）實現(xiàn)該服務(wù)并且負(fù)責(zé)提供它們的功能和維持它們的服務(wù)質(zhì)量。通過組合這些公開的服務(wù)到合成的應(yīng)用程序，就可以支持業(yè)務(wù)過程流。綜合的架構(gòu)通過使用 Enterprise Service Bus （ ESB ）支持這些服務(wù)、組件和流程的路由、中介和轉(zhuǎn)化。為了服務(wù)質(zhì)量和非功能性的需求，必須監(jiān)視和管理已經(jīng)部署的服務(wù)。


圖 3 ： SOA 層

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

這里是為你的 SOA 架構(gòu)文檔設(shè)計的模板：

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

現(xiàn)在，讓我們更加仔細(xì)的描述一下每一層以及每一層之間的合成。

層 1 ：操作系統(tǒng)層。 本層包含現(xiàn)有的自定義構(gòu)建的應(yīng)用程序，也叫做 遺留 系統(tǒng)，包含現(xiàn)有的 CRM 和 ERP 打包應(yīng)用程序，以及 較舊的 基于對象的系統(tǒng)實現(xiàn)，還有業(yè)務(wù)智能應(yīng)用程序。 SOA 的復(fù)合層架構(gòu)可以利用現(xiàn)有的系統(tǒng)并且用基于服務(wù)的集成技術(shù)來集成它們。

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

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

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

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

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

層 7 ： QoS 。 這一層提供了監(jiān)視，管理和維持諸如安全，性能和可用性等 QoS 的能力。這是一個通過 sense-and-respond 機(jī)制和監(jiān)測 SOA 應(yīng)用程序健康的工具來進(jìn)行的后臺處理過程，包括 WS-Management 和其他相關(guān)協(xié)議的所有的重要的標(biāo)準(zhǔn)實現(xiàn)以及為 SOA 實現(xiàn)服務(wù)質(zhì)量的標(biāo)準(zhǔn)。

通過什么步驟來進(jìn)行基于服務(wù)的建模和架構(gòu)

本節(jié)描述了如何利用遺留的投資，來 聯(lián)合 自頂向下的，業(yè)務(wù)驅(qū)動的手段和自底向上的手段。

基于服務(wù)的建模手段提供了建模、分析、設(shè)計技術(shù)和活動來定義 SOA 的基礎(chǔ)。它通過在 SOA 的每一層定義元素以及在每一層作嚴(yán)格的架構(gòu)決策來起到幫助作用。它通過聯(lián)合服務(wù)鑒別的自頂向下、業(yè)務(wù)驅(qū)動方式和通過利用遺留資產(chǎn)和系統(tǒng)引導(dǎo)服務(wù)鑒別來實現(xiàn)這一點。

這樣，高級別的業(yè)務(wù)過程功能性為大粒度的服務(wù)更加的具體化。小粒度的服務(wù) -- 這些可以幫助實現(xiàn)高級別的服務(wù) -- 通過檢查遺留功能性和決定如何創(chuàng)建適配器、封裝器，或者組合遺留系統(tǒng)來具體化系統(tǒng)內(nèi)經(jīng)常調(diào)用的期望功能性可以來鑒別。

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

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

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

基于服務(wù)的建模：服務(wù)的分析和設(shè)計

迄今為止，我已經(jīng)通過描述 SOA 設(shè)定了階段。我同樣展示了要想構(gòu)建 SOA ，你需要在你 SOA 的每個層中做關(guān)鍵架構(gòu)決策，并且你的設(shè)計必須反映一系列依賴業(yè)務(wù)的服務(wù)和關(guān)于他們?nèi)绾瓮ㄟ^編排來合成到應(yīng)用程序的決策。

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

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


圖 4 ：基于服務(wù)建模的活動
 3.JPG 3.JPG

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

上面描述的活動可以被描述為在基于服務(wù)的建模和架構(gòu)方法內(nèi)流動，如下面的 圖 5 所示。

圖 5 ：基于服務(wù)的建模和架構(gòu)方法
4.JPG

基于服務(wù)的建模和架構(gòu)過程包含三個主要的步驟：服務(wù)，組件和流程（典型地，服務(wù)的編排）的鑒別，指定和實現(xiàn)。

Service 鑒別

這個過程由域分解、現(xiàn)有資產(chǎn)分析和目標(biāo)服務(wù)建模的自頂向下、自底向上、中間向外技術(shù)的聯(lián)合組成。在 自頂向下視圖中 ，業(yè)務(wù)用例的藍(lán)圖提供了業(yè)務(wù)服務(wù)的規(guī)范。這個自頂向下的過程作為 域分解 來被引用，域分解由業(yè)務(wù)領(lǐng)域到它的功能區(qū)域和子系統(tǒng)的分解組成，包含它的流程或過程分解成過程、自過程和高級別業(yè)務(wù)用例。很多情況下，這些用例是公開在企業(yè)邊緣的業(yè)務(wù)服務(wù)，或者在貫穿業(yè)務(wù)線企業(yè)邊界內(nèi)所用的非常好的候選。

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

中間向外視圖 由 目標(biāo)服務(wù)建模 組成，來驗證和發(fā)現(xiàn)自頂向下或自底向上的服務(wù)鑒別手段中沒有捕捉到的其他服務(wù)。它將服務(wù)連結(jié)到目標(biāo)和子目標(biāo)、關(guān)鍵性能指示和尺度。

服務(wù)分級和分類

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

子系統(tǒng)分析

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

組件指定

在下面的主要活動中，實現(xiàn)服務(wù)的組件的細(xì)節(jié)將指定：

  • 數(shù)據(jù)
  • 規(guī)則
  • 服務(wù)
  • 可配置概要
  • 變更

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

服務(wù)分配

服務(wù)分配包括分派服務(wù)到目前鑒別的子系統(tǒng)。這些子系統(tǒng)具有實現(xiàn)了他們所公布的功能的企業(yè)組件。你經(jīng)常會簡單化假定，子系統(tǒng)同企業(yè)組件有一對一的聯(lián)系。 結(jié)構(gòu)化組件 在你使用模式來構(gòu)造 企業(yè)組件 時會通過以下幾點的聯(lián)合的形式出現(xiàn)：

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

服務(wù)分配同樣由服務(wù)的指派和在 SOA 層中實現(xiàn)他們的組件組成。組件和服務(wù)向 SOA 層中的分配是一個關(guān)鍵的任務(wù)，需要關(guān)鍵架構(gòu)決策的文件和決議，這些決策不僅僅同應(yīng)用程序架構(gòu)有關(guān)系，也同在運(yùn)行時設(shè)計和用來支持 SOA 實現(xiàn)的技術(shù)操作架構(gòu)有關(guān)的。

服務(wù)實現(xiàn)

這個步驟指出實現(xiàn)給定服務(wù)的軟件必須被選擇或者自定義構(gòu)建。其他可用的選項包括使用 Web 服務(wù)來集成、轉(zhuǎn)化、訂閱和外購不同功能。在這個步驟中，你決定哪個遺留系統(tǒng)模塊用來實現(xiàn)給定的服務(wù)，以及哪個服務(wù)將從基礎(chǔ)來構(gòu)建。服務(wù)的其他實現(xiàn)決策不同于業(yè)務(wù)功能包括：服務(wù)的安全、管理和監(jiān)視。

事實上，項目趨向于利用任意數(shù)量的相應(yīng)的努力來滿足關(guān)閉的機(jī)會窗口。因此，我推薦并行的管理三個流。

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

結(jié)束語

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

我提到了，對于服務(wù)鑒別，自頂向下、自底向上和跨部分、目標(biāo)模型分析三種手段的結(jié)合非常重要。接下來我關(guān)注了一下服務(wù)指定和實現(xiàn)的主要活動。

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

?