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

回頁首

SOA 的一個架構模板

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

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

圖 3：SOA 層

對于每一層，你都必須做設計和架構決定。因此，為了幫助用文件說明你的 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 因素>
   1. <我們如何確保使用服務的客戶端系統級的一致性（SLA）和服務質量（QoS）？>
   2. 安全問題和決策
   3. 性能問題和決策
   4. 技術和標準的局限性以及決策
   5. 服務的監控和管理

?

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

層 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 實現服務質量的標準。