将 SOA 引入 Office 應用程式桌面

摘要：當今的企業都希望将 SOA 作為一種公開其應用程式和資料以便于使用者使用的方法。現在，使用現有開發工具在這些服務上建構解決方案非常容易。通過使用 SOAP 或 WSDL 之類的标準，不同的供應商可以提供在這些服務上進行公開和開發的工具。但是，當企業開發了一些解決方案之後，問題就開始暴露出來。本文将重點說明一些最常見的問題。

簡介

當今的企業都希望将 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 服務。還有一個描述所有服務和解決方案的中央庫。用戶端将基于它們的權限下載下傳該中繼資料的子集，以将其作為所需的執行基礎。

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 設計服務時，您應該記住，您是在建構使用者使用的服務，是以您希望公開對使用者有意義的資料和方法。

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

•	實體 — 您可以将實體視為一個對使用者有特殊意義并且可供使用者操作的業務對象。實體的示例可以是客戶、定單或機會。它們都有一些資料與之相關聯，并且從使用者的角度來看，它們是可以操作的。例如，客戶實體可能包含與特定客戶（名稱、位址、位置等）相關聯的資料，以及允許使用者操作實體的方法，例如，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 技術之上建構，它還為新的解決方案提供了一個安全且無需部署的環境。