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

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

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

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

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

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

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

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

　　元數(shù)據(jù)方法

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

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

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

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

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

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

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

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

　　信息橋框架

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

　　1.為服務創(chuàng)建元數(shù)據(jù)描述

　　2.創(chuàng)建用于在服務上構建解決方案/應用程序的元數(shù)據(jù)基礎結構

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

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

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

　　6.只需對現(xiàn)有 Office 用戶進行簡單的培訓

　　信息橋體系結構

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

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

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

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

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

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

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

圖 1. IBF 體系結構

　　設計和開發(fā)信息橋解決方案

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

　　創(chuàng)建與 IBF 兼容的服務

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

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

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

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

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

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

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

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

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

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

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

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

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

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

　　創(chuàng)建 UI 組件

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

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

　　創(chuàng)建解決方案元數(shù)據(jù)

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

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

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

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

　　部署和安全

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

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

　　它為您的企業(yè)解決方案提供了一個健壯且無需部署的環(huán)境。