构建 Office 业务应用程序

摘要

2007 Microsoft Office 系统提供了一套服务器、客户端和工具，使企业和软件供应商能够更轻松地构建和部署企业中的复合应用程序。这些解决方案称为 Office 业务应用程序 (OBA)，它们构建和部署速度快；通过广泛的个性化功能增强最终用户能力；在业务需求变化时易于更改；并使用熟悉的 Microsoft Office 工具和应用程序构建。本文展示了如何架构复合应用程序，以及 2007 Microsoft Office 系统如何为构建此类应用程序提供一个熟悉的平台。

目录

什么是复合应用程序？
2007 Microsoft Office 系统作为构建复合应用程序的平台
Office 业务应用程序如何成为复合应用程序
构建 Office 业务应用程序
构建部门 SharePoint 站点以托管本地文档和流程
结论
关于作者

全球化、专业化和外包要求人们比以往任何时候都更具协作性。这种趋势要求信息工作者用于获取洞察力、协作、做出决策和采取行动的工具也随之改变。如今，大多数业务应用程序在自动化事务方面是有效的，但不能实现跨职能边界的丰富协作。这通常导致信息工作者使用个人生产力工具来执行开展业务所需的复杂交互。然而，这反过来又导致生产力下降，因为用户被迫从一套工具切换到另一套工具，通常通过剪切粘贴等方式手动移动数据。不同业务应用程序和生产力工具之间的这些差距需要以无缝、同步和安全的方式弥合，以方便信息工作者。

目前还没有一种有效的方法能够以上下文相关、协作、易于使用、基于角色和可配置的方式实现业务应用程序的组合，以引入构建这类复合应用程序所需的其他平台技术。易用性很重要，因为组合的平台、工具和架构不应引入不合理的、需要对人员进行彻底再培训的技术复杂性。

什么是复合应用程序？

复合应用程序是为提供业务功能而组装的软件资产集合。这些资产是可以独立部署、实现组合并利用特定平台功能的工件。

过去，企业的软件资产通常由独立、单一且彼此集成不佳的业务应用程序组成。然而，为了获得组合的业务优势，企业必须以更精细的方式处理其软件资产，并且不同的架构层将需要演示、应用程序和数据资产等各种资产。例如，Web 服务可能是一个应用程序资产，在线分析处理 (OLAP) 立方体可能是一个数据资产，而特定的数据输入屏幕可能是一个演示资产。

软件资产清单本身并不能实现复合应用程序。这需要一个具有组合能力的平台——也就是说，一个能够单独部署资产以及组合部署资产的平台。换句话说，这些资产必须是组件，并且平台必须提供*容器*（图 1）。

图 1. 复合应用程序的高级表示

平台提供的容器需要有不同的类型，这些类型对应于架构中的不同层。企业架构通常分解为三层：表示层、应用层（或业务逻辑层）和数据层。因此，平台需要为这些层提供容器。然而，三层架构假定结构化的业务流程和数据，其中所有需求在设计和构建系统过程中都已确定。复合应用程序的本质是假设解决方案的组合可以在资产构建和部署之后发生，因此需要明确考虑信息工作者之间为完成任何业务流程而必不可少的人与人之间的交互。通常，这些交互未被结构化流程或传统业务应用程序捕获；因此，添加第四层（生产力层）来解释这些人类交互至关重要。这在图 2 中显示。

图 2. 复合应用程序的四个层

关于业务应用程序架构的传统讨论倾向于将应用层视为人与数据之间的连接。然而，通常应用层包含结构化的业务逻辑，这适用于对面向服务架构 (SOA)、企业服务总线 (ESB)、服务组件架构 (SCA) 以及当今行业中大多数其他架构观点（包括关于复合应用程序的第一代讨论）的讨论。然而，构建复合应用程序不仅要求架构师将生产力层视为堆栈的关键元素，而且还要认识到它包含最大的商业价值。

为了扩展复合应用程序与 SOA 的比较：它们都旨在实现灵活性和模块化。然而，SOA 仅在一个层提供灵活性：中间层的结构化业务逻辑。复合应用程序旨在所有四个层实现灵活性。话虽如此，复合应用程序是提取 SOA 中信息的好方法，并且将业务线 (LOB) 应用程序公开为服务使得更容易在复合应用程序中构建对跨职能流程的支持。

因此，要设计一个复合应用程序，解决方案架构师必须

• 选择一个组合堆栈。从每一层选择一个或多个容器，以及一组可部署到这些容器中的组件类型。
• 选择组件。根据业务需求，定义必须从这组组件类型构建的资产存储库。
• 指定复合应用程序。定义连接这些资产以提供特定跨职能流程的方式。平台应使这些连接松耦合。

部署后，用户将有机会个性化资产和连接，并且组合堆栈应通过松耦合和可扩展性机制实现这一点。

2007 Microsoft Office 系统作为构建复合应用程序的平台

2007 Microsoft Office 系统是构建复合应用程序（称为 Office 业务应用程序 (OBA)）的这样一个平台。

图 3. 2007 Microsoft Office 系统提供的功能

Office 业务应用程序如何成为复合应用程序

现在我们来看图 2 中的每个层，并检查平台提供的容器类型和组件类型。

表 1. 2007 Microsoft Office 系统高级功能

功能	描述
网站和安全框架	一个通用框架，用于创建不同类型的站点，如团队协作站点、内部门户、互联网网站。
Open XML 文件格式	这使得文档的丰富服务器端处理成为可能。在以前的 Microsoft Office 版本中，解析文档（例如，电子表格），使用文档对象模型需要文档创建应用程序（例如，Excel）在内存中运行的实例。
可扩展 UI	服务器端门户，用户可以根据解决方案提供商可扩展的构建块进行个性化。可以通过 Visual Studio Tools for Office 扩展客户端应用程序。
业务数据目录	一个元数据存储库，用于定义存储在后端数据存储中的业务实体，建模实体之间的关系，并定义实体上允许的操作。
企业搜索	通过搜索从各种企业源提取数据。
工作流	与 Workflow Foundation 集成，以托管代表人员之间交互并链接 UI 元素的工作流。
企业内容管理	管理多样化内容，Web、文档和记录管理采用统一拓扑。支持文档生命周期管理。
商业智能	基于服务器的 Excel 电子表格，以及内置到门户并连接到 SQL Server Analysis Services 的 BI 组件（仪表板、报表、Web 部件）。
沟通与协作	支持集成到平台中的统一通信。

表示层的组合

表示层中的第一种容器类型是 Microsoft Office 客户端应用程序（Excel、Word、InfoPath）。这些应用程序是可自定义的容器，现在可以通过自定义任务窗格、自定义功能区以及在用户当前活动上下文中向用户呈现数据和操作的操作，更轻松地从 LOB 应用程序中提取信息和功能。可以在这些容器中托管的组件类型是 Open XML 文档。这是 Microsoft Office 文档的新 XML 表示形式，它支持对存储在其中的信息进行丰富的服务器端处理。如图 4 所示。

图 4. Office 客户端应用程序是 Open XML 内容的可定制容器。

第二种容器类型是 Web 门户，由 Windows SharePoint Services (WSS) 和 Microsoft Office SharePoint Server (MOSS) 启用。WSS v3.0 提供了以下容器层次结构，如图 5 所示

• 场——安装一个或多个负载平衡的 Web 服务器和后端服务器，以及一个配置数据库。
• Web 应用程序——IIS Web 站点，已扩展为使用 WSS，可以托管站点集。
• 站点集——WSS 站点的容器，存在于特定的内容数据库中。站点集包含一个顶级站点和可选的子站点，是所有权、安全性和可恢复性的单元。
• 站点——子站点、页面以及列表和文档库等内容的容器。
• 页面——Web 部件区域和 Web 部件的容器。
• Web 部件区域——Web 部件的容器。
• Web 部件——以模块化形式在页面上显示内容的组件，是用户自定义/个性化页面的主要方式。

图 5. Windows SharePoint Services 提供的容器（点击图片可查看大图）

虽然 WSS 支持为团队协作构建站点集合，但 MOSS 在 WSS 的基础上提供了门户功能，并具有额外的功能。例如，MOSS 具有增强的搜索、与业务数据存储的连接以及商业智能等功能。然而，MOSS 门户是一个 WSS 站点集合，因此也是 WSS 站点的层次结构。MOSS 还带有一个 Web 部件库，其中包含一组丰富的开箱即用 Web 部件，例如用于提取 Microsoft Office Excel 电子表格和图表。解决方案提供商还可以为应用程序特定或域特定功能提供自己的自定义 Web 部件，然后可以将其上传到 WSS 中。信息工作者可以通过从库中添加 Web 部件、从页面中删除 Web 部件或重新排列布局来个性化页面。

生产力层的组合

2007 Microsoft Office 系统提供了多种共享信息和协作使用信息的方式。例如，服务器端存储为进程中的文档和其他各种异构内容（带有版本控制）提供了容器。这允许在意外或计划外情况下进行协作。很难在业务流程管理 (BPM) 系统中捕获所有复杂的人员交互，因为工作通常不会按计划进行。在传统的三层架构中，除了在个人硬盘或电子邮件服务器上存储传输中的文档之外，几乎没有支持，有时很难确定哪个文档是正确的版本。然而，2007 Microsoft Office 系统可以设置版本化文档库来存储业务流程中间阶段的文档，这提高了可管理性，也提高了从计划外事件中优雅恢复的可能性。WSS 提供以下存储类型

• 列表——项目的容器，可以来自内置列表类型，也可以来自自定义列表类型。传统上，这是存储的原子单元，但现在列表可以存储大量数据，例如知识库或 Web 内容。还有内置的索引和查询支持。
• 文档库——支持文档版本控制和源代码控制的特殊类型的列表。例如，InfoPath 表单可以存储在表单库中，报告存储在报告库中，其他文档存储在文档库中。

图 6. SharePoint 工作流架构（点击图片可查看大图）

信息工作者可以自行添加文档库并指定用于这些库中所有文档的特定文档模板。例如，业务分析师可能会使用 InfoPath WYSIWYG 设计工具创建一个表单，然后使用该表单作为模板创建一个表单库。每当用户在该库中创建新文档时，此模板将用于创建一个空表单。2007 Microsoft Office 系统还内置了对 Windows Workflow Foundation (WF) 的服务器端支持。WF 运行时引擎托管在 MOSS 中，并作为业务逻辑的容器，这些业务逻辑可以以工作流的形式附加到工作项和文档。这些工作流可以与列表、文档库或特定内容类型关联。它们由用户操作启动和完成，并使用 WSS 任务列表进行管理。例如，工作流活动根据需要创建和更新任务项，用户可以通过历史记录表跟踪工作流进度。2007 Microsoft Office 客户端应用程序也支持工作流。它们可用于工作流的启动、配置、完成以及即时自定义（转发/委派）。

工作流可以与列表、文档库或特定内容类型关联。这些与 WF 模板的关联在场范围的工作流关联表中进行跟踪。WF 模板由 XML 元数据定义，可以包括工作流程序集和表单。例如，当用户创建文档库时，他们可以选择将该库与特定工作流关联，并指定工作流触发的条件（例如，给定库中的文档可能已被修改或创建）。此工作流可以支持特定业务流程或支持文档生命周期管理。

2007 Microsoft Office 系统与 WF 的集成带来了多种好处（图 7）。简单的业务流程可以以无缝集成到 SharePoint UI 的方式实现自动化。通过自助服务功能，用户被赋予能力，例如支持广泛的用户控制的文档路由和跟踪场景，从而减少 IT 员工在组装简单应用程序方面的参与。WF 还为垂直解决方案提供商提供了一个可扩展点，可以将他们自己的业务规则和逻辑部署到 2007 Microsoft Office 系统提供的容器中。

图 7. 使用 WSS 托管工作流（点击图片可查看大图）

最后，生产力层还必须提供一种轻量级的方式来创建和发布信息和报告。2007 Microsoft Office 系统支持这一点，它集成了 SQL Server Reporting Services 并提供以下组件

• 报告中心——用于创建 WSS 报告站点的模板。
• 报告库——一个专门用于存储报告的文档库。
• 仪表板——由报告 Web 部件组装而成的 WSS 页面。
• 报告查看器——用于查看 SQL Server Reporting Services 提供的报告的 Web 部件。
• Web 部件——用于查看 Excel 图表和表格。
• KPI（关键绩效指标）Web 部件和列表——信息工作者可以通过多种方式选择此指标的来源。

可以为用户提供一个围绕特定业务功能（例如销售、营销或库存管理）构建的报告模板仪表板。

应用层的组合

通常，结构化业务逻辑存在于应用层。这可能是一个 LOB 应用程序，如企业资源规划 (ERP) 系统，或者是跨多个系统的协调，如 BPM 系统。应用层通常包括事务系统和决策支持系统。OBA 有多种方式在应用层实现组合，以及使用其他平台技术（Microsoft 和非 Microsoft）公开的复合服务。

应用层的第一层组合是通过使用 Workflow Foundation 创建的打包活动库，并部署到 2007 Microsoft Office 系统中。之前，我们讨论了工作流如何附加到列表、文档库和特定内容类型。图 7 显示了 WF 运行时如何为应用程序特定活动提供容器，这些活动被打包并部署为活动库，并且在此之上组装工作流。

2007 Microsoft Office 系统提供的应用层中的第二层组合是通过 Excel Services。这是一个内置于 SharePoint Server 中的服务器端 Excel 计算引擎。它提供了对部署在服务器上的实时交互式电子表格的浏览器访问，以及对服务器端 Office Excel 计算的 Web 服务访问。通过 Excel Services，现有的 Excel 高级用户现在可以以他们熟悉的方式提供服务器端应用程序逻辑。这意味着 MOSS 现在是应用程序逻辑的容器，如图 8 所示。

图 8. 2007 Microsoft Office 系统中的 Excel Services

OBA 在应用程序层实现组合的第三种方式是使用其他平台技术公开的复合服务。2007 Microsoft Office 系统可以无缝地插入面向服务架构。如果企业已经有正在开发的服务骨干，则可以从 2007 Microsoft Office 系统中使用这些接口。这可以通过几种方式完成。第一种是在已部署到生产力层的工作流中内置的活动中调用 Web 服务接口。第二种是通过业务数据目录 (BDC)，这将在下一节中介绍。

数据层的组合

2007 Microsoft Office 系统还带有一个业务数据目录 (BDC)，它作为共享服务在服务器中运行。它可以从多种类型的数据源（数据库、分析服务多维数据集和 Web 服务）读取数据，然后通过 SharePoint 表和列表在门户中显示这些数据。这充当了业务数据实体及其属性的描述以及将这些实体映射回企业内数据存储的元数据存储库，如图 9 所示。

图 9. 业务数据目录 (BDC)

虽然 BDC 不能用于创建跨多个数据存储映射的实体，但可以定义链接实体的关系，例如父子关系。因此，BDC 可以用于在企业中创建数据实体之间的轻量级链接，几乎像一个企业同义词库。然后，BDC 定义的实体可以插回 2007 Microsoft Office 系统，例如在 SharePoint 列表中。这允许用户使用与后端数据的链接来组合页面，并通过实体之间的关系遍历数据表。

尽管 BDC 实现了数据组合，但它提供了对数据的只读访问。然而，用户可以使用 BDC 来建模可以对数据实体执行的操作，其中操作由名称、URL 和从实体定义传递回此 URL 的一组属性定义。然后，这可以从 SharePoint 列表上的下拉菜单中使用。URL 可以对应于 Web 服务或服务器端文档（例如 InfoPath 表单），其中包含用于从 BDC 传入的上下文预填充表单的后端代码。信息工作者可以使用门户在 SharePoint 中创建带有表格和列表的轻量级应用程序，这些应用程序可以提取 BDC 数据和操作。

总结组合能力

图 10 展示了 2007 Microsoft Office 系统的一些功能如何映射到图 2 中的层。表 2 提供了可用于组合的资产类型列表。

图 10. 2007 Microsoft Office 系统应用平台的功能，映射到各层（点击图片可查看大图）

表 2. 组合的应用资产列表

Open XML 文档 工作流程 业务活动 业务规则 模式 指标 Web 部件

仪表板 站点 页数 数据连接 授权 报告 仪表板

构建 Office 业务应用程序

将标准业务流程构建为 OBA 有两个步骤。

1. 构建流程包，其中包含流程元数据和打包的应用程序组件。
2. 将流程包部署到生产系统。这两个步骤将在以下部分中详细描述。

构建流程包

1. 使用 Visual Studio Tools for Office (VSTO) 在 Microsoft Office 客户端应用程序中为以文档为中心的流程构建用户界面。
2. 构建带有任务特定 Web 部件、页面、仪表板、列表和文档库的 WSS 站点，每个站点都针对特定的业务功能或流程进行设计。这些站点可用于创建站点模板，以便将标准业务流程打包到 OBA 解决方案中。
3. 使用 Workflow Foundation 将站点中的列表和文档库与服务器端规则和业务逻辑连接起来，以实现对流程中文档的服务器端处理。将这些工作流打包成程序集进行部署。
4. 定义 OBA 中工作流与后端 LOB 系统的接触点。流程包元数据应包括此集成的 Web 服务接口。实际连接需要在部署阶段进行。
5. 为 OBA 中内置的跨功能流程所需的数据连接定义 BDC 实体。
6. 通过定义 WSS 站点将使用的指标、报表、仪表板以及 Excel 图表和表格来添加决策支持。
7. 使用表 2 中的组件类型将解决方案打包为流程包（WSS 站点模板、WF 程序集、Office 文档等）。

将流程包部署到生产系统

1. 将 WSS 站点部署到生产系统上的 SharePoint 服务器。
2. 使用 Web 服务或其他自定义适配器配置工作流与 LOB 应用程序的连接。
3. 通过将 BDC 数据实体定义连接到实际数据存储来配置数据连接。
4. 配置用户。

在企业中部署复合应用程序

在企业中部署 OBA 的一种方式可能如下

1. 在部门级别部署 SharePoint 站点。
2. 连接多个部门。
3. 将业务流程连接到 LOB 应用程序。
4. 为跨功能流程添加数据连接。
5. 将业务流程连接到“边缘”系统。

构建部门 SharePoint 站点以托管本地文档和流程

必须在部门级别设置 SharePoint 站点以实现团队协作，如图 11 所示。这些站点将包含文档库以存储正在处理的文档。团队中的信息工作者将拥有自己的个性化页面，这些页面根据团队站点上可用的模板进行定制。

图 11. 在部门站点中配置 OBA 以实现团队协作，通过业务流程模型协调活动，并通过服务骨干连接到 LOB 系统。

请注意，图 11 是架构的逻辑视图，因为所有这些部门站点通常不会在单独的服务器上运行。相反，多个站点可以在单个服务器上运行，与图 5 一致，物理架构（即 SharePoint 服务器的部署格局）将根据负载、可用性和团队的地理分布等其他因素进行选择。

处理中的文档存储在文档库中，并与在创建或编辑文档时调用的工作流相关联。此类工作流可能会对文档运行验证规则；对数据应用批准策略和操作；清理、验证或过滤其中包含的数据；或更新后端系统。

除了业务流程工作流之外，正在处理的文档本身也经历一个生命周期，从撰写和协作到管理和发布，再到归档或销毁。每当文档达到这些阶段之一时，都可以设置触发适当的工作流，例如用于管理归档过程。

连接多个部门

如图 11 所示，业务流程模型协调团队内部和跨部门的活动。在一个部门内部，可以使用部署到支持该部门的 SharePoint 服务器中的 WF 活动来建模业务流程。跨部门活动的协调可以通过管理单个业务实体（订单）生命周期以及业务流程（采购到付款）生命周期的协作流程来实现。

部门间业务流程可以集中放置在 IT 数据中心，也可以更靠近部门服务器中的信息工作者。例如，在 Microsoft BizTalk Server 上运行的长期工作流可能是集中运行的，而部门流程将在 SharePoint 服务器内的 WF 工作流中运行。

将业务流程连接到业务线应用程序

服务导向是将当前业务应用程序公开到 OBA 的一种方式。

从这个意义上说，SOA 促进了模块化，这是组合的基本要求，SOA 是互补的解决方案。新的跨功能业务应用程序超越了当前应用程序的边界。

SOA 不是将 LOB 连接到 OBA 的唯一方式。服务骨干也可以使用其他集成技术（例如自定义适配器）公开。

为跨功能流程添加数据连接

BDC（图 9）可用于通过在 SharePoint 列表和 Web 部件中显示数据，将后端数据存储连接到 2007 Microsoft Office 系统。这使得在 SharePoint 门户中构建用于跨功能流程的复合应用程序成为可能，结合使用 BDC、SharePoint 列表和工作流。例如，BDC 可用于定义具有父子关系（例如订单头和订单详细信息）的实体，并且 SharePoint 列表可以显示它们。通过遵循父子关系，可以从显示头信息的列表深入到相应的详细信息。此外，操作可以在 BDC 元数据中建模，这意味着这些操作将显示为 SharePoint 列表上的菜单项，从该菜单中选择下拉菜单意味着当前选定行中的上下文将传递到为操作定义的 URL 中。

将业务流程连接到边缘系统

OBA 的范围通常不限于组织内部。例如，OBA 可能支持需要使用托管服务提供商提供的服务（软件即服务——SaaS——场景）的业务流程。或者，OBA 可能需要支持向另一个组织提供服务的业务流程。这在涉及贸易伙伴的供应链管理场景中尤为常见。在这种情况下，需要有一种方法将文档从一个信息工作者传输给贸易伙伴组织中的对应人员。这需要安全、可靠、异步和透明。

构建端到端架构的一种方法如图 12 所示。消息代理已设置在组织边缘，用于发送和接收来自贸易伙伴的消息和文档。来自不同贸易伙伴的消息可能以多种消息格式接收，并通过多种渠道交付，例如 Web 服务、EDI、电子邮件、RosettaNet 等。此外，消息可以以多种不同模式交换：单向、异步双向或同步双向消息传递。这些消息代理必须处理这些消息交换模式和消息格式的每种组合。

图 12. 将 OBA 连接到“边缘”系统

消息由消息代理接收后，会处理成下游服务所需的单一规范格式，然后将转换后的消息持久化到消息队列，以将公共流程与私有流程解耦。接下来，消息由路由服务从队列中检索，该服务检查消息并将其路由到预期接收者。但在文档到达预期接收者之前，可能需要由企业应用程序服务（如 LOB 应用程序或 BPM 编排）进行预处理。业务规则可能会应用于消息，以确保有效性并强制执行公司策略。所有这些处理的结果是包含足够信息以便人类能够快速做出决策的文档。例如，来自客户的采购订单请求可能会输入到订单承诺服务，该服务的响应可能会用于生成一个 XML 文档，该文档对应于一个包含候选采购订单确认的 InfoPath 表单。接下来，生成的表单可能会放置到 SharePoint 表单库中，供销售部门的信息工作者批准。

信息工作者审查拟议确认并根据需要进行更改后，提交表单。这将启动返回行程的工作流，该工作流更新 LOB 系统，然后将表单中的信息作为 XML 文档发布到出站消息队列中，作为对原始请求的响应。然后，消息代理将转换回贸易伙伴使用的格式。

在边缘实现消息代理有多种方式，例如 BizTalk Server。这将提供可扩展且可管理的解决方案，其中还将包含基于标准的加速器和适配器，例如用于贸易伙伴协作的 RosettaNet 加速器。用于解耦内部和外部流程的队列可以使用 Microsoft SQL Service Broker 2005 实现。

Office 业务应用程序示例

为了提供构建具有有意义业务价值的 OBA 的技术资源和指导，在线提供了一个 OBA 的参考实现，请点击此处。此供应链管理参考应用程序包涵盖了多层供应链不同级别之间的协作场景。

结论

2007 Microsoft Office 系统提供了一套强大的功能来构建复合应用程序，这些应用程序被称为 Office 业务应用程序 (OBA)。这使得跨职能解决方案能够提供复合用户界面，从而跨异构的后端 IT 资产公开业务功能和能力。这些解决方案还提供了协作业务能力，弥合了传统业务应用程序和个人生产力工具之间的鸿沟。

更多信息

有关架构和开发 Microsoft Office 业务应用程序的更多信息，请访问

http://msdn.microsoft.com/oba 和

http://msdn.microsoft.com/architecture/office