本文討論:
OBA 基礎
OBA 模式
Microsoft Office 和 LOB 集成
OBA 模式 的實際應用程序
本文使用了以下技術:
Visual Studio 2008
大型系統（如 SAP 和 PeopleSoft，以及其他綜合業務線 (LOB) 系統）對於成功管理所有類型的業務數據和流程至關重要。然 而，並非組織中的每個人都可以訪問這些系統，因此，其中的業務數據通常只提供給少數人。這經常導致 從系統外部抽取數據進行處理，從而造成業務數據源和使用這些數據的信息工作者之間脫節。
Office 業務應用程序 (OBA) 通過使用 Microsoft® Office 在 LOB 系統中的業務數據與信息工 作者之間架起橋梁來解決此問題。Office 功能使您能夠執行下列任務：通過自定義窗體區域和文件夾將 客戶關系管理 (CRM) 數據集成到 Microsoft Outlook® 中、將業務智能集成到 Microsoft Office SharePoint® Server (MOSS) 以查看銷售業績數據，甚至可以將 Microsoft Excel® 與財務數據 相集成以提供使用直接來自 LOB 系統的數據的預測模板等等。
為了解 OBA，您可以將其視為包括 下列三個主要部分的非常簡單的模型：LOB 系統、與 LOB 系統集成的自定義 Office 客戶端，以及同樣 與 LOB 系統集成的服務器組件（實質上是 MOSS）。請注意，在構建 OBA 時，您還可以利用其他 Microsoft 服務器產品，如 Exchange Server 2007、PerformancePointTM Server 2007 等。
從 體系結構角度而言，您將主要使用面向服務的體系結構 (SOA) 與 LOB 系統集成，但使用 OBA，您可以采 用多種方式將客戶端自定義為服務層接口。更有可能的是，您將使用 Visual Studio® Tools for Office (VSTO) 來完成此項工作。例如，圖 1 顯示了使用自定義功能區和自定義任務窗格的界面。兩種 界面均具有使用來自 SAP 的事件信息填充 Excel 2007 電子表格的服務層，而且兩者均使用 VSTO 3.0 0 （Visual Studio 2008 Professional 及更高版本中包括的 VSTO 最新版本）來構建。您還可以設計自己 的界面以使用 Microsoft Word 內容控件並將這些控件綁定到數據，或使用自定義工具欄、窗體區域或自 定義功能區來擴展 Outlook。有關如何自定義客戶端的詳細信息，請參閱“OBA 信息資源”側 欄。
Figure 1 集成 SAP 和 Excel 2007
使用 MOSS 2007，有多種選項可供您選擇。例如，您可以構建一個駐留不同類型 Web 部件的站點。 OBA 的常用 Web 部件包括業務數據目錄 (BDC) Web 部件（用於管理企業范圍內的實體及其相關服務或 ADO.NET 連接）、Excel 服務 Web 部件（用於將電子表格數據鏈接至 Web 部件）和關鍵績效指標 (KPI) Web 部件（用於提供績效指標）。當然，創建 Office 業務應用程序時還可以使用許多其他 Web 部件。 圖 2 顯示了 SharePoint 站點中的 BDC Web 部件和 Excel 服務 Web 部件。
Figure 2 BDC 和 Excel 服務 Web 部件
盡管可能性似乎無窮無盡，但下面將為您提供一些入門幫助。此幫助提供了七種核心的 OBA 解決方案 模式。接下來，我將向您介紹這些模式，並將其中之一實際應用於 OBA 設計及開發。
OBA 模式
OBA 模式的目標是顯示如何設計和開發 OBA、顯示在特定模式中可以使用哪些技術，以及闡述如 何著手開發 OBA。其中涉及的一些技術包括 OpenXML、MOSS 2007、Web 服務和 VSTO 3.0。
七種 核心模式中的某些模式還包含子模式。而且，因為 OBA 是利用 Office 平台的多個部件的復合應用程序 ，所以您將發現這些模式之間存在著某些關系。圖 3 中列出了七種模式及其各自的目標。
Figure 3 OBA Patterns
模式 說明 作為溝通渠道的 OBA 應用程序 顯示如 何將 LOB 應用程序功能擴展到更廣泛的用戶群體中。 文檔集成 提供關於如 何從 LOB 應用程序生成 Office 文檔以及在 Office 文檔中嵌入 LOB 數據的指南。 復合用戶界面 描述 Office 文檔或 SharePoint 網頁中多個應用程序用戶界面的組合。 補充文檔工作流 顯示如何通過工作流的使用來控制和監視以文檔為中心的 流程。 數據查找指導 以更簡單的方式提供與 LOB 系統業務數據的交互，以 顯示如何通過在多個 LOB 應用程序間搜索來發現數據。 協作站點 提供有關 如何借助非結構化人員協作來擴充結構化業務流程的指南。 應用程序生成的任務和通 知 顯示如何將 Outlook 用作接收和處理 LOB 應用程序生成的任務和警報的主要用戶界面。
每一種模式都代表單個模式，或者包含提供更多詳細指南的子模式。例如，“作為溝通渠道的 OBA 應用程序”包含兩種子模式（“直接集成”和“間接集成”），可提供 有關 SOA 與非 SOA 解決方案的具體指南。稍後，我將更加詳細地討論“作為溝通渠道的 OBA 應用 程序”。
模式另一個非常重要的方面在於：它們提供一些針對 Office 平台內含技術的指南 ，您可以利用這些技術開發 OBA。因此，舉例來說，“文檔集成”模式及其子模式提出 OpenXML、VSTO、BDC 或更為通用的文檔標記。圖 4 概述了構成七種核心 OBA 解決方案模式的子模式（ 如果有），以及在使用特定 OBA 模式設計 OBA 解決方案時所需的技術。
Figure 4 OBA Solution Patterns, Sub-Patterns, and Associated Technologies
模式 子模式 采用的技術 作為溝通渠道的 OBA 應 用程序 直接集成—在不使用服務的情況下，以自定義方式將業務數據傳送到復合 UI 的自 定義組件。間接集成—抽象化兩端之間通信的中間層；更加松散耦合、具有聲明性且面向服務。 VSTO MOSS 2007 BDC 文檔集成 應用程序生成的文檔—從 LOB 系統生成（使用服務器端批處理過程）。也可使用“直接集成”或“間接集成 ”。集成文檔—直接嵌入文檔的 LOB 系統數據（內容控件、命名區域）。 OpenXML VSTO BDC 文檔標記 復合用戶界面 上下文驅動的復合用戶界面—綁定 到事件和應用程序上下文（特定數據或用戶配置文件）的自定義 UI 組件。網格復合視圖—可連接 的 Web 部件，用於創建母版/詳細信息復合用戶界面（SharePoint 中的 BI 視圖）。RSS 和 Web 服務復 合—RSS 和 Web 服務的網格復合視圖。分析—數據分析儀表板的網格復合視圖。 Web 部件 VSTO（功能區、自定義任務窗格等）BDC Excel 服務和儀表板 補 充文檔工作流 LOB 初始化的文檔工作流—映射到工作流的文檔均經過轉換、增強或使用業 務數據進行填充。附加工作流功能嵌入在文檔中。協作文檔工作流—工作流是文檔容器的一部分， 其中涉及許多人員，並需要以結構化的方式與文檔進行協作。 Windows Workflow Foundation SharePoint 存儲 BDC 數據查找指導 不適用 企業搜索 BDC 協作站點 不適用 Windows SharePoint Services InfoPath® 窗體服務 應用程序生成的任務和通知 簡單任務和通知傳送 —通過電子郵件通知將任務和工作單向指派給某人。任務同步—Outlook 中任務的雙向同步。 智能任務和通知—描述如何根據分配的任務執行操作。基於窗體的任務和通知—描述如何集成 InfoPath 窗體以提供更豐富的業務規則驗證及自動化。 Outlook 2007 和 MOSS 集成 VSTO（自 定義任務窗格、Outlook 窗體區域等）InfoPath 窗體服務您可以使用這些模式作 為其他 OBA 內容的占用部分，以了解 OBA 的構成對象以及用於構建它的技術，或者在您自己的 OBA 設 計中使用這些模式。還有許多“參考體系結構包”可用。這些是用於特定行業（例如，制造業 或銀行業）的 OBA 體系結構（和應用程序）指南包。有關更多信息，請參閱“OBA 信息資源 ”側欄。
至此，我們已涵蓋了 OBA 模式的一些實質內容，讓我們將 OBA 解決方案模式應用 於真正的軟件設計中。
使用 OBA 解決方案模式
首先，讓我們看看在軟件開發生命周期 (SDLC) 過程中，您實際會在哪個步驟使用 OBA 解決方案模式。首先從確定問題開始。如果沒有問題（或 需求），那我就不明白您為什麼要開發軟件了。一旦確定問題，接下來便需要確定與此問題相匹配的需求 。這兩個步驟是整個過程中最要的部分。如果您不能正確地完成這兩個步驟，則問題將在整個 SDLC 中越 積越多。一旦明確了需求，即可以開始設計。
在設計階段，您需要問自己許多問題。例如：需求 是否指定特殊的環境（因而對設計有所限制）？完成此工作是否需要特定軟件（現成的或自定義的）？需 要什麼硬件？圖 5 闡明了如何在設計階段繼續利用 OBA 模式。
Figure 5 設計階段的 OBA 模式
掌握一組需求並了解 OBA 之後，接下來需要查看 OBA 模式，以確定是否有一種模式適合您的需求； 如果有，確定是哪一種。此外，您可能希望深入了解特定模式，以查看是否有子模式適應您的需求。假設 您確實找出模式之一與需求之間存在映射，則可以使用該模式作為設計模板。
問題
如我所 討論，軟件開發通常以一些問題作為出發點。在我們的示例中，問題是銷售管理團隊需要查看最新的銷售 數據。要解決此問題，我們將需要了解更多有關團隊、環境和一些基礎需求的信息。
以下是我們 對這個特殊環境的了解：銷售管理團隊有 100 名成員，他們都在運行 Windows Vista®、2007 Office system、SharePoint 和最新版本的 Internet Explorer®。大多數成員都處於遠程位置，但 均可以通過公司網絡訪問中央 SharePoint 站點或服務器。
為演示目的而加以簡化的需求如下： 因為他們不是始終連接到公司網絡，所以銷售團隊每天都會將其銷售數據記錄在 Excel 電子表格中，然 後在連接到公司網絡時手動將數據重新輸入到 LOB 系統中。此外，在該過程中某些特定步驟（如數據驗 證）也需要手動執行。該團隊希望有一個能夠支持銷售團隊之間互聯並能夠自動化許多手動過程（如驗證 ）的系統。（銷售數據輸入和驗證過程平均每天要花費 30 分鐘。團隊希望將其縮短到 5 分鐘。）因為 銷售團隊已經適應了使用如 Excel 和 Internet Explorer 之類的工具，所以管理團隊希望使用基於 Excel 的解決方案和 SharePoint 視圖，以便成員可以在團隊管理站點上構建報告。
通過查看問 題定義，您可以快速了解到銷售管理團隊需要的是擴展其 LOB 應用程序，以便管理直接提供給遠程銷售 人員的銷售數據。通過比較該定義和 OBA 解決方案模式列表，我們發現它與“作為溝通渠道的 OBA 應用程序”能夠很好地匹配。
作為溝通渠道的 OBA 應用程序
該模式的目標是顯示如 何將 LOB 系統功能擴展到使用 Office 應用程序作為載體的更廣泛的用戶群。該模式實現將為更多人提 供對 LOB 系統業務數據的訪問。遵循該模式，您可以使用 Outlook 或 Excel 作為豐富的客戶端與 LOB 系統集成，或者使用 SharePoint Web 部件作為服務器端瘦客戶端。在本案例中，該模式非常適合，因為 您將為小型組織推出 OBA，以便 Excel 和 SharePoint 可提供兩種與銷售數據相連接的不錯的方法。事 實上，您最想要的是使客戶端和瘦客戶端均可以訪問 LOB 系統的解決方案。因此，我們的銷售數據 OBA 如圖 6 所示。
Figure 6 訪問 LOB 系統的客戶端和瘦客戶端
Figure 6a 訪問 LOB 系統的客戶端和瘦客戶端
Figure 6b 訪問 LOB 系統的客戶端和瘦客戶端
通過進一步研究，您會注意到“作為溝通渠道的 OBA 應用程序”有兩種子模式：直接集成 和間接集成。下面讓我們進一步看看這兩種子模式。
使用“直接集成”，對基礎 LOB 系統的訪問會直接集成到 Office 客戶端或 SharePoint Web 部件中。使用此模式，您通常可構建直接到 後端進程或數據源的連接，而且附加業務邏輯應最少。
雖然“直接集成”很常見，但 難以跨多個系統重復使用。“間接集成”要求在 LOB 系統和自定義客戶端組件（例如，自定 義的任務窗格）之間創建作為集成中介的服務層，從而簡化跨多個系統的重復使用以及客戶端與服務器之 間的松散耦合。對於銷售數據 OBA 來說，這是一個好消息。現在，我們可以創建包裹銷售數據模塊（輸 入所有銷售數據之處）的 Web 服務，並將此 Web 服務與所有客戶端接口集成。因此，如果您希望將 LOB 系統與 Excel 集成，完全可以做到。您可以通過在 Visual Studio 2008 內創建引用或通過 SharePoint 內的 BDC 使用該服務。
現在您已取得一些進展：您已明確了問題聲明和需求，並已准備好應用 OBA 模式。生成的體系結構利用“間接集成”模式，即，利用 Web 服務在 Excel 和 SharePoint 中提供銷售功能的 OBA。請注意，在圖 7 中稍有不同（與圖 6 相比）。這是因為 BDC 僅作 為數據可視化的只讀載體進行工作，您可以從客戶端自定義發出讀/寫調用。這必須反映在體系結構圖表 中。
Figure 7 銷售數據 OBA 體系結構
現在，體系結構包括 Excel 2007 加載項、MOSS 2007 站點，以及充當到 LOB 系統中介連接的 Web 服務。此外，您現在已了解了所涉及的技術，因此可以編寫更加詳細的規范並構建開發環境（使用 OBA 解決方案模式中包含的技術）。
您可能會認為現在應該可以將 OBA 解決方案模式丟到一邊去。然而，您可能還需要將所選擇的模式與 七種核心解決方案模式中的其他可能模式作比較。這將驗證您的體系結構，並可能為您的新解決方案提供 一些靈感，使其包括更多服務器、工具和 Office 開發平台的服務。
最後一步是考慮應該如何構建體系結構中的每個組件。我將提供一個高層次概述以及一些附加鏈接， 通過這些鏈接，您可以進一步研究所討論過的每種技術。
掌握體系結構後，您可能希望了解如何構建此 OBA。您將需要安裝 MOSS 站點（或擁有現有站點的管 理員權限以便能夠根據它進行開發）。如果您選擇安裝一個新站點，則需要在 Windows Server 2003（或 Windows Server 2008）上安裝 MOSS（以及所有先決條件）。還要確保已安裝 Visual Studio 2008 Professional Edition，以及 2007 Office system Professional Edition 和作為 Visual Studio 2008 安裝選項的 Office Primary Interop Assemblies (PIA)。此外，您還需要訪問 LOB 系統，因為您需要 根據它的實例來開發和測試 Web 服務。
至少需要花費一天時間才能建立起該環境。我將繼續進行介紹，假設安裝服務器操作系統、在服務器 上安裝 MOSS、在服務器上安裝 Office，以及在本地計算機上安裝 Visual Studio 2008（和 PIA） 這些 操作均已完成。此時，您將可以對任何已創建（或已存在）的服務進行測試訪問。
建立起環境之後，您將需要創建 Web 服務。對於銷售數據 OBA 來說，您可能需要創建至少兩個 Web 服務：一個用於獲得銷售數據（這些數據顯示在 Excel 客戶端加載項和 MOSS 站點中），另一個用於更 新來自 Excel 客戶加載項的數據。雖然 LOB 系統很通用，但您還是需要使用 Web 服務工具來創建包裹 更多域特定功能的服務，例如現有的業務模塊—以 SAP 為例。
不同的 LOB 系統將明顯以不同方式進行工作，但目標應該是最終能夠提供可以在 BDC 和 VSTO 加載 項中使用的服務。要從相關領域（SAP 和 Office 集成）獲得此處的幫助，您可以查看 OBA Starter Kit for SAP，它提供了有關如何為 SAP 創建 Web 服務的幫助 (msdn2.microsoft.com/bb498189)。
現在，您已經創建了 Web 服務，因此可以創建 VSTO 加載項。為此，請使用 Visual Studio 2008 創 建 VSTO 應用程序級加載項或文檔級解決方案。兩種方案將以相同的方式使用 Web 服務。您很可能希望 在加載項中創建用於管理銷售數據的自定義任務窗格（控制顯示哪些數據的過濾器），以及用於管理數據 視圖的自定義功能區（創建圖表、使用數據測試功能等）。可在 msdn2.microsoft.com/aa905533 的 “VSTO 開發人員中心”中找到有關如何完成此項工作的大量信息。
下一步是將 Web 服務添加到 MOSS 站點。這意味著要為該 Web 服務創建應用程序定義文件 (ADF)（ 即手動編寫 XML 文件，或使用類似 BDC Definition Editor 或 BDC MetaMan 之類的工具創建該文件） 、將 ADF 導入 SharePoint、創建 BDC Web 部件，然後將 Web 部件綁定到 ADF 以完成 BDC Web 部件和 LOB 系統之間的集成。有關如何完成這些操作的詳細信息，請參閱 msdn2.microsoft.com/bb737887。
部署此解決方案意味著需要部署客戶端開發機制和 MOSS 站點，銷售團隊將通過該站點訪問 BDC Web 部件和 Web 服務。您可以將 VSTO 客戶端程序集發布到 SharePoint 站點，銷售管理團隊隨後可以將這 些程序集下載到本地客戶端，客戶端將在每次調用加載項時通過部署指令清單檢查服務器上的更新。
部署 BDC Web 部件要求您已建立一個 MOSS 站點並將其配置為供團隊使用，因為 Web 部件的部署過 程包括在現有站點上創建 Web 部件。有關部署的詳細信息，請參閱“VSTO 開發人員中心” (msdn2.microsoft.com/aa905533) 和“SharePoint 開發人員中心”(msdn2.microsoft.com/sharepoint) 。
其他用途
雖然我已為您介紹了如何應用 OBA 模式，但您可能希望使用其他方法來應用它們，以實現您自己的目 的。例如，您可能只是使用它們來了解現有模式和建議模式，把它們作為體系結構設計的參考，或者您可 能將其用作 OBA 解決方案的體系結構模板，或重復使用它們作為向 OBA 解決方案提供結構的方法—並逐 漸使其成為規范流程的先決條件。今後，您將看到有關 OBA 開發的更多指南，其中很可能包括現有模式 的增強功能以及其他內容。讓我們拭目以待！
