將SOA引入Office應用程序桌面

簡介

當今的企業都希望將 SOA 作為一種公開其應用程序和數據以便于用戶使用的方法。通過采用 SOA，企業資產（例如，業務流程應用程序或后端系統）可以由在這些資產公開的服務上構建的各種解決方案/應用程序使用。在這里，您可以將企業視為一組公開數據集或功能集并在其后封裝業務邏輯的服務。

現在，使用現有開發工具在這些服務上構建解決方案非常容易。通過使用 SOAP 或 WSDL 之類的標準，不同的供應商可以提供在這些服務上進行公開和開發的工具。

當企業開發了一些解決方案之后，問題就開始暴露出來。以下是一些最常見的問題：

1.解決方案只能使用一次。它們只能與一個或一組預先定義的服務進行通信，并且解決方案本身難以重用。更改服務后需要重新構建/重新部署解決方案。

2.對服務所公開的內容的理解取決于人們的想法，而不是服務定義本身。當前的標準只涵蓋了如何獲得那些服務。

3.很難將不同的服務集合在一起。既沒有預先定義的聚合機制，也沒有關于一個服務如何與另一個服務相聯系（服務彼此之間不了解）的定義。

4.按照大多數常見的用戶標準來說，解決方案 UI 難以實現，而且通常很槽糕（除非進行巨額投資）。這是因為難以在一次性解決方案中模擬當前的應用程序 UI。

5.大多數用戶都相當熟悉 Office 套件（Word、Excel、Outlook 等）之類的應用程序，但是當設計出一個新的應用程序/解決方案后，需要對他們進行培訓，從而增加了此類部署的成本。

由于上述原因，我們需要一個在現有服務之上構建解決方案的更好的機制。

元數據方法

目前，Web 服務公開了許多有關如何使用服務的信息，但在說明提供了哪種類型的信息或功能方面，卻提供了非常少的幫助。Web 服務通常會公開 WSDL，因此工具可以輕松地查明 Web 服務公開了哪些方法和參數，但是，至于在那些方法后定義了哪些業務實體、甚至這些方法可能會影響后端系統等方面，卻提供了非常少的提示（例如，不會告知某個方法將更新后端系統）?？雌饋?，WSDL 似乎不能充分表示當今服務所公開的內容。

我們推薦一組新的元數據，它可以與某個服務相關聯，并說明該服務的用戶（解決方案開發人員）將需要了解的內容。在這個新的元數據中，我們將公開以下概念：

1.實體 — 將封裝一組數據或功能的抽象業務或用戶定義。例如，我們可以有一個客戶實體。

2.視圖 — 與某個實體相關聯的架構，它描述有關該實體的數據子集。例如，對于客戶實體，我們可以擁有多個視圖，例如，客戶聯系信息或客戶財務信息。每個視圖都符合特定的架構，它是給定上下文的實體表示形式。

3.關系 — 實體/視圖可以與其他內容關聯，這些關系應該在此元數據中描述。例如，客戶實體可能與定單實體相關聯。關系允許實體之間的導航，這只需執行元數據描述即可。然后，關系將描述如何從一個實體進入另一個實體。

4.引用 — 引用是指向一組信息的常用方式。它是一個架構，表示檢索一段數據所需的最小信息集，例如，用于檢索客戶的客戶 ID。您可以用多種方式檢索一段信息，例如，可以按名稱、ID、SSN 等檢索客戶。

5.操作 — 這是給定實體/視圖可以操作的方法。您可以將GetCustomer、UpdateCustomer 或 ReleaseOrder 看作此類操作的示例。

描述現有服務的元數據只能解決一半問題。另一半（在這些服務上開發的解決方案）還需要元數據描述。我們相信，通過考慮最終用戶可以執行的操作，您可以構建大多數解決方案。這些操作是在服務實體/視圖上構建的，并在其上提供可操作性?？蛻舨僮骺隙〞幸粋€顯示其數據的操作，可能還有一個更新數據的操作。操作說明應該將從服務檢索的數據鏈接到將使用它的 UI 或解決方案功能。

信息橋框架

信息橋框架 (IBF) 就是 Microsoft 對上述挑戰和元數據方法作出的回答。IBF 允許您通過 Office 應用程序連接 LOB 和后端系統，以及通過元數據方法在 Web 服務上創建解決方案。IBF 可以實現以下操作：

1.為服務創建元數據描述

2.創建用于在服務上構建解決方案/應用程序的元數據基礎結構

3.跨解決方案的高度可重用性

4.解決方案的輕松維護和部署

5.與 Office 應用程序的高度集成

6.只需對現有 Office 用戶進行簡單的培訓

信息橋體系結構

IBF 體系結構（如圖 1 所示）包含以下組件：

a) 一個封裝了 LOB 或后端系統并與 IBF 兼容的 Web 服務。我們將在下一部分（設計和開發 IBF 解決方案）中討論兼容問題。

b) 一個包含服務和解決方案元數據的元數據庫（元數據服務）。該庫可將自身導出為提供對元數據的訪問的 Web 服務。還有一個描述所有服務和解決方案的中央庫?？蛻舳藢⒒谒鼈兊臋嘞?STRONG>下載該元數據的子集，以將其作為所需的執行基礎。

c) IBF 客戶端引擎。這最后一個組件包含兩個獨特的組件：

a. 在需要時從元數據服務下載元數據并保留它的本地緩存的引擎。它還可以理解元數據，并基于當前的上下文執行元數據。它執行所有與 UI 不相關的操作，例如，SOAP 調用、轉換等。該組件是 UI 不可知的。

b. UI 引擎，它是了解應用程序寄宿在何處（Word、Excel 等）的部分，而且它將呈現 UI，并提供特定于宿主應用程序的服務。它能夠在宿主應用程序上創建一個抽象層，因此用 IBF 構建的解決方案不需要了解宿主應用程序之間的差異。

d) 元數據設計器是一個基于 Visual Studio 的工具，它允許編輯元數據并將其導入元數據服務。

圖 1. IBF 體系結構

設計和開發信息橋解決方案

在設計 IBF（信息橋框架）解決方案時，您必須將它分為三個截然不同的塊（如圖 2 所示）。一方面，您需要描述與 IBF 兼容的 Web 服務，該服務封裝了您要提供給最終用戶的后端應用程序功能。另一方面，您需要設計要提供給解決方案用戶的 UI 和體驗。最后一步是鏈接您使用 IBF 元數據構建的服務和 UI 解決方案。通過分開這三個階段，您可以為其中的每個階段分配不同的資源，然后以單獨的方式操作，只需在它們共享的界面（或公共架構）上保持一致即可。

創建與 IBF 兼容的服務

IBF 需要可以提供數據以及與您的解決方案所需的數據進行交互的服務。IBF 目前支持兩種類型的服務：Web 服務和 CLR 組件。Web 服務是公開后端數據最常用的方法，大多數 IBF 示例都將它們用于服務描述。如果您需要使數據脫機或者緩存（出于性能原因）CLR 實現，也是可以的。

在為 IBF 設計服務時，您應該記住，您是在構建用戶使用的服務，因此您希望公開對用戶有意義的數據和方法。

圖 2.IBF 解決方案的三個不同的塊

在構建這些服務時，您還需要知道幾個概念：

• 實體 — 您可以將實體視為一個對用戶有特殊意義并且可供用戶操作的業務對象。實體的示例可以是客戶、定單或機會。它們都有一些數據與之相關聯，并且從用戶的角度來看，它們是可以操作的。例如，客戶實體可能包含與特定客戶（名稱、地址、位置等）相關聯的數據，以及允許用戶操作實體的方法，例如，UpdateCustomerInformation 或 SendEmailToCustomer。它可能還是一個通過關系(例如，CustomerOrders 或 CustomerOpportunities)到其他實體的起始點。

• 視圖 — IBF 可以用不同的視圖來分割實體。視圖是與實體有關的信息子集。對于一個客戶，您可能有客戶聯系信息視圖和客戶財務視圖。

• 引用 — IBF 中的引用是唯一標識一個實體/視圖實例的一段信息。對于前面的示例，引用可以是客戶 ID 或客戶名稱（如果它允許您唯一標識客戶）。

• 關系 — 某些實體/視圖之間具有關系，我們構建的元數據應該描述這些關系。一個示例是客戶與定單，因為您可以將客戶與其定單相關聯，以及將定單與其客戶相關聯。

基于前面的概念，在您構建服務時，您應該識別三種不同的方法：

• Get — get 方法允許您通過傳遞 Reference 來為實體/視圖檢索數據。一個示例是名為 GetCustomerContactInformation 的方法，它將接受客戶 ID Reference 參數。

• Put — 這是一個允許您通過更新后端系統來修改實體/視圖內容的方法。它接受兩個輸入：對要更新的實體/視圖的引用，以及要更新的數據。

• Act — 該方法允許執行與獲得/更新實體/視圖無關的操作，或者跨多個實體執行操作。

如果您理解了這些概念，就可以圍繞它們來構建服務。服務將公開一組類型為 Get/Put/Act 的方法，為此還將為引用和視圖（由 Get 操作返回的數據）定義架構。

為了完成服務，還必須公開描述前面解釋的概念的 IBF 元數據。IBF 提供了可以從 Web 服務自動生成元數據的工具，這樣您就可以通過標注圍繞實體/視圖公開的方法來增加元數據，并將它們映射到正確的引用。

創建 UI 組件

IBF 允許您的文檔包含指向后端數據的活動鏈接。這些文檔通過智能標記或者獲得文檔的附加架構，來包含有關要獲得哪些后端數據的信息。智能標記或架構中的元素節點將存儲有關要指向哪些后端信息的信息。根據前面有關如何創建 IBF 服務的主題中的討論，這些就是引用。例如，智能標記將包含對后端信息的引用。您的解決方案必須定義它希望這些智能標記如何插入文檔，對此 IBF 提供/推薦了幾種方法。您可以自動生成嵌入了智能標記的文檔（如果電子郵件/文檔由某些進程動態生成，這將十分有用）；您可以使用智能標記識別器基于正則表達式來檢測文本，或者在其中查找并動態插入智能標記；您還可以使用 IBF 中的內置搜索功能，讓用戶查找他們感興趣的信息實例，并允許用戶將它們粘貼到文檔中。

剩下的 UI 部分就是要顯示給用戶的部分。IBF 提供了一個窗格方法，該方法可以宿主可由解決方案提供程序完全定義的區域。IBF 支持 .NET CLR 控件和 HTML 區域（以及這些區域的菜單）。創建一個 UI 實際上就是創建一個控件，以及實現一個將數據插入控件的界面?？丶旧聿恍枰廊绾潍@得數據，以及數據來自哪里?？丶恍枰浪峁┑臄祿愋?。IBF 將在運行時動態實例化控件，并將正確的數據傳遞給控件。這就允許將數據的顯示與獲取數據的方式分離開來。根據前面的示例，您可以創建一個知道如何呈現客戶信息的控件（它理解客戶的架構，并且包含其名稱、地址等）。

創建解決方案元數據

創建 IBF 解決方案的最后一步就是，創建將服務描述與為其定義的 UI 元素相鏈接的元數據。為了讓您輕松地創建這些基于元數據的解決方案，IBF 提供了以下幾個概念：

• 操作 — 從用戶的觀點來看，這些是可執行單元，并且可以包含服務和 UI 方法/操作。在前面的示例中，您應該有一個 DisplayInformation 操作，它使用 CustomerContactInformation 上的服務實體/視圖，并將其鏈接到我們創建的、用于顯示客戶信息的用戶控件。

• 轉換 — 由于來自服務的數據和 UI 元素所需的數據可能不同，因此 IBF 允許您轉換數據。XSL 轉換、正則表達式或調用 CLR 組件都是受支持的數據轉換方式。

• 關系 — 您的解決方案可以具有除該服務提供的關系之外的關系，還可以跨服務了解關系。例如，我可以將一個舊式應用程序中的客戶與 CRM 系統中的客戶相關聯。

部署和安全

您可以將 IBF 視為元數據的中央庫，作為解決方案動態部署的服務描述和 UI 元素將由 IBF 客戶端組件使用。除了 IBF 客戶端以外，不需要在客戶端機器上安裝其他任何代碼/元數據。IBF 客戶端組件可以連接到相應的元數據服務，以獲得給定上下文所需的所有元數據和 UI 元素。在獲得元數據描述和 UI 元素后，IBF 客戶端組件將它們與服務方法調用一起執行，并根據需要來構建 UI 和用戶體驗。

由于 IBF 使用 CLR 組件進行 UI 呈現，因此它構建在 .NET 安全性之上，所有組件都動態下載并在本地緩存，并且在沙箱環境中執行，因而不會危害客戶端機器。如果您需要讓控件擁有更高級別的控制權，可以使用標準的 .NET 安全策略對這些控件進行簽名，并提升它們的權限。

它為您的企業解決方案提供了一個健壯且無需部署的環境。

小結

通過將服務層與 UI 層分開，并經由元數據將它們鏈接在一起，IBF 可以允許高度抽象和重用您的服務和 UI 組件。它提供了一個功能非常強大的平臺，用于指定企業中的后端資產，以及根據這些資產創建無需編碼即可鏈接或組合的解決方案。在元數據驅動的方法中，該元數據方法添加了許多靈活性，并允許根據客戶的情況進一步改進解決方案。IBF 提供了功能強大的 UI 結構，以幫助構建完整的 UI 體驗以及與 Office 應用程序的集成。通過在 .NET 技術之上構建，它還為新的解決方案提供了一個安全且無需部署的環境。

資源 有關 IBF 的詳細信息，請訪問以下站點： http://msdn.microsoft.com/ibframework。

關于作者Ricard Roma i Dalfo Microsoft Corporation ricardrd@microsoft.com

Ricard Roma i Dalfo 是信息橋框架項目的開發領導。他正致力于下一版本的 IBF，以及利用業務流程應用程序解決連接性問題。他曾經是 Office 小組的成員，并以各種開發角色協助發布了 Office 2000、XP 和 。他擁有加泰羅尼亞科技大學計算機科學碩士學位。

轉到原英文頁面