Microsoft Corporation

构建 Office 业务应用程序
发布日期 : 2007-03-22 | 更新日期 : 2007-03-22
Atanu Banerjee
摘要：2007Microsoft Office system提供了一套服务器、客户端和工具，可使企业和软件供应商更容易地在企业内构建和部署复合应用程序。这些称为 Office 业务应用程序 (OBA)的解决方案可以快速地进行构建和部署；使最终用户能够使用大量的个性化功能；易于根据业务需求进行更改；使用熟悉的 Microsoft Office工具和应用程序而构建。本文介绍如何对复合应用程序进行架构设计，以及 2007 Microsoft Office system如何为构建此类应用程序提供最终用户所熟悉的良好平台。
本页内容
什么是复合应用程序？
2007 Microsoft Office System 作为构建复合应用程序的平台
Office 业务应用程序如何成为复合应用程序
构建 Office 业务应用程序
构建部门的 SharePoint 站点以托管本地文档和进程
结束语
全球化、专业化以及外包化要求人们在工作中比以往更为密切地进行协作。这种趋势要求在信息工作者用来进行了解、协作、做出决定以及采取行动的工具中进行相应更改。目前，多数业务应用程序在自动化事务处理方面都很有效，但却不能突破功能上的界限进行充分协作。这通常导致信息工作者使用个人生产率工具来执行从事业务所需的复杂交互。但是，这种做法也导致了生产率降低，因为这迫使用户不得不在各种工具集之间来回切换，经常通过剪切和粘贴之类的方式来手动移动数据。需要铲除在不同业务应用程序和生产率工具之间存在的这些障碍，才能使信息工作者以一种无缝、同步并且安全的方式工作。
目前确实没有一种有效的方式，能够使在某种程度上与上下文相关、相互协作、易用、基于角色并且可配置的业务应用程序组合与构建这些种类的复合应用程序所需的其他平台技术接轨。易用这一点非常重要，这是因为复合应用程序的平台、工具和体系结构不应引入需要彻底对人员进行重新培训的过高的技术复杂性。
什么是复合应用程序？
复合应用程序是经过组装能提供业务功能的软件资产的集合。这些资产是可独立部署、启用复合并且利用特定平台功能的产物。
过去，企业的软件资产通常由功能单一而且相互集成性差的独立业务应用程序组成。但是，为获得复合带来的商业效益，企业必须以更精细的方式来对待其软件资产，并且在体系结构的不同层级上将需要诸如表示、应用和数据等各种不同资产。例如，Web 服务可能是应用资产，联机分析处理 (OLAP)多维数据集可能是数据资产，而特定的数据录入屏幕可能是表示资产。
软件资产的清单本身不启用复合应用程序。这需要平台具有实现复合的功能，也就是说，平台既能够以单独方式部署资产，也能够以互相组合的方式部署资产。换言之，这些资产必须为组件，而且平台必须提供容器（图 1）。

图 1. 复合应用程序的高级表示
平台提供的容器需要分为不同类型，这些类型与体系结构中的不同层映射。企业的体系结构通常可分解为三层：表示层、应用（或业务逻辑）层和数据层。因此平台需要为这些层提供容器。但是，三层体系结构假定业务流程和数据均已结构化，其中的所有要求在设计和构建系统的过程中都是已知的。就其本质而言，复合应用程序意味着构建和部署资产之后即可组合解决方案，因此需要对信息工作者之间进行的人与人交互进行明确说明，这也是完成任何业务流程的基础。通常这些交互不会被结构化流程和传统业务应用程序所捕获；因此，添加第四层 — 生产率层来对这些人员交互进行说明就显得极为重要。如图 2 所示。

图 2. 复合应用程序的四个层
传统的关于业务应用程序体系结构的讨论倾向于关注连接人与数据的应用层。但在通常情况下，应用层包含结构化的业务逻辑，这适用于现今行业内关于面向服务的体系结构 (SOA)、企业服务总线 (ESB)、服务组件体系结构 (SCA)以及多数其他体系结构角度的讨论，其中包括关于复合应用程序的第一代讨论。但是，构建复合应用程序时，要求架构师不仅要将生产率层视为堆栈的关键元素，还要认识到它包含着绝大部分的商业价值。
详述复合应用程序与 SOA 之间的比较：二者均以灵活性和模块化为目标。但是，SOA仅在一个层上提供灵活性：即中间层的结构化业务逻辑。复合应用程序则在所有四个层上均提供灵活性。尽管如此，复合应用程序是从 SOA中提取信息的一种重要方法，而以服务的方式公开行业 (LOB) 应用程序会使在复合应用程序中加入对跨功能过程的支持更加容易。
因此，要设计复合应用程序，解决方案架构师必须：
选择复合堆栈。从每一层中拾取一个或多个容器，以及一组可部署到这些容器中的组件类型。
选择组件。根据业务需求，定义必须从该组组件类型构建的资产存储库。
指定复合应用程序。定义连接这些资产的方式，以提供特定的跨功能过程。平台应启用这些将要松散耦合的连接。
部署之后，用户将有机会个性化资产和连接，而复合堆栈应通过松散耦合和可扩展性机制来启用个性化。
返回页首
2007 Microsoft Office System 作为构建复合应用程序的平台
2007 Microsoft Office system 就是这样一个用来构建称为 Office 业务应用程序 (OBA) 的复合应用程序的平台。

图 3. 2007 Microsoft Office system 提供的功能
返回页首
Office 业务应用程序如何成为复合应用程序
现在让我们看看图 2 中的各个层，并检查一下平台提供的容器类型和组件类型。
表 1. 高级 2007 Microsoft Office system 功能
功能
说明
网站和安全框架
用于创建不同种类站点（例如团队协作站点、Intranet 门户、Internet 网站）的通用框架。
Open XML 文件格式
该功能允许对文档进行丰富的服务器端处理。对于 Microsoft Office 的先前版本，使用文档对象模型分析文档（例如电子表格）时，需要在内存中运行通常用于创建文档的应用程序（例如 Excel）实例。
可扩展 UI
可由用户进行个性化处理的服务器端门户，来自于可由解决方案提供商扩展的构建基块。可使用 Visual Studio Tools for Office 扩展的客户端应用程序。
业务数据目录
一个元数据存储库，用于定义存储在后端数据存储中的业务实体、模型化实体间的关系以及定义在实体上可执行的操作。
企业搜索
通过搜索从各种企业源中提取数据。
工作流
与 Workflow Foundation 集成，托管表示人与人交互的工作流和链接 UI 元素的工作流。
企业内容管理
通过一种适用于 Web、文档和记录管理的拓扑管理各种内容。支持文档生命周期管理。
商业智能
基于服务器的 Excel 电子表格，以及内置于门户中的 BI 组件（仪表板、报告、Web 部件）和连接到 SQL Server Analysis Services 的 BI 组件。
通信和协作
支持集成到平台中的统一通信。
表示层中的复合
表示层中第一种容器类型是 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 应用程序 — 已扩展为使用 WSS 的 IIS Web 站点，可以托管站点集合。
站点集合 — 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 部件或重新整理布局来个性化页面。
生产率层中的复合
2007Microsoft Office system提供了多种在使用信息时共享信息和相互协作的不同方式。例如，服务器端存储为处理中的文档提供容器，为其他类型的异类内容提供版本控制。这支持在意料之外或计划之外的情况下进行相互协作。在业务流程管理 (BPM)系统中捕获所有复杂的人员交互是很困难的，因为工作通常不按计划进行。在传统的三层体系结构中，除了在个人硬盘驱动器或电子邮件服务器上存储正在传输的文档外，对此仅有很少支持，并且有时很难确定哪个文档是正确版本的文档。但是，2007 Microsoft Office system可建立受版本控制的文档库，以存储处于业务流程中间阶段的文档，从而改进了可管理性，也提高了从意外事件适度恢复的可能性。WSS提供以下类型的存储：
列表 — 项目的容器，这些项目可来自内置列表类型或自定义列表类型。在过去，列表一直是存储的基本单位，但现在列表可以存储数量庞大的数据，例如知识库或 Web 内容。同时也支持内置索引和查询。
文档库 — 特殊类型的列表，支持对文档进行版本更新和源控制。例如，InfoPath 表单可存储在表单库中，报告可存储在报告库中，而其他文档则可存储在文档库中。

图 6. SharePoint 工作流体系结构
信息工作者可以自行添加文档库，并指定这些库中所有文档使用的特定文档模板。例如，业务分析人员可使用 InfoPath WYSIWYG设计工具创建表单，然后使用该表单作为模板来创建表单库。每当用户在该库中创建新文档时，都会使用此模板创建一个空表单。2007 MicrosoftOffice system 还对 Windows Workflow Foundation (WF) 提供内置、服务器端支持。WF运行时引擎驻留在 MOSS中，并在工作流表单中充当可附加到工作项目和文档的业务逻辑的容器。这些工作流可能与列表、文档库或特定内容类型相关联。它们由用户操作来启动和完成，使用 WSS 任务列表进行管理。例如，工作流活动根据需要创建并更新任务项目，用户可通过历史记录表格跟踪工作流进度。2007 MicrosoftOffice 客户端应用程序还可以识别工作流。它们可用于工作流初始化、配置、完成以及特别的自定义（转发/委派）。
工作流可与列表、文档库或特定内容类型相关联。会在场范围的工作流关联表中跟踪这些与 WF 模板的关联。WF 模板由 XML元数据定义，并且可以同时包含工作流程序集和表单。例如，当用户创建文档库时，他们可以选择将该库与特定工作流相关联，并指定触发工作流的条件（例如，给定库中的文档可能已被修改或创建）。此工作流可支持特定的业务流程或支持文档生命周期管理。
将 2007 MicrosoftOffice system 与 WF 集成会带来很多好处（图 7）。与 SharePoint UI 无缝集成可以实现简单业务流程的自动化。减少IT 工作人员对组合简单应用程序的工作的参与，可使用户能够使用自助服务功能，例如，支持多种用户控制的文档路由和跟踪方案。WF还为垂直解决方案提供商提供了一个扩展点，以将其自己的业务规则和逻辑部署到 2007 Microsoft Office system所提供的容器中。

图 7. 托管 WSS 的工作流
最后，生产率层还必须提供一种创建并发布信息和报告的轻便方式。这由 2007 Microsoft Office system 所支持，2007Microsoft Office system 集成到 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 system中的封装活动库。我们先前讨论过工作流如何能够与列表、文档库和特定内容类型相关联。图 7 显示了 WF运行时如何为应用程序特定的活动（这些活动作为活动库进行封装和部署，工作流组装在这些活动之上）提供容器。
在应用层中，由 2007Microsoft Office system 提供的复合的第二个级别贯穿 Excel Services。它是内置于 SharePointServer 的服务器端 Excel 计算引擎。它提供服务器上部署的活动、交互式电子表格的浏览器访问权限，还提供服务器端 OfficeExcel 计算的 Web 服务访问权限。有了 Excel Services，现有 Excel高级用户现在可以采用他们所熟悉的方式提供服务器端应用程序逻辑。这就意味着 MOSS 现在是应用程序逻辑的一个容器，如图 8 所示。

图 8. 2007 Microsoft Office system 中的 Excel Services
在应用层中，OBA 用来启用复合的第三种方法是使用由其他平台技术提供的复合服务。2007 Microsoft Office system可无缝插入到面向服务的体系结构中。如果企业已经开发了服务中枢，则可通过 2007 Microsoft Office system使用这些接口。这可以通过两种方法实现。第一种方法是，调用活动（这些活动已内置到在生产率层中部署的工作流中）中的 Web服务接口。第二种方法是通过业务数据目录 (BDC)，将在下一部分对其进行介绍。
数据层中的复合
2007Microsoft Office system 还附带业务数据目录(BDC)，在服务器内作为共享服务运行。它可从多种类型的数据源（数据库、分析服务多维数据集和 Web 服务）中读取数据，然后通过SharePoint表格和列表在门户中显示此数据。它会充当元数据存储库，用于说明业务数据实体及其属性，并将这些实体映射回企业内的数据存储，如图 9 所示。

图 9. 业务数据目录 (BDC)
虽然无法使用 BDC 创建映射多个数据存储的实体，但是可以定义链接实体的关系（如父子关系）。因此，可将 BDC用于创建整个企业中数据实体之间的轻型链接 — 类似于企业辞典。此后 BDC 定义的实体便可插回 2007 Microsoft Officesystem 中，例如使用 SharePoint列表。这就可使用户通过遵循实体之间的关系，将包含指向后端数据的链接的页面加以组合，并遍历数据表。
尽管 BDC启用数据复合，但它却提供对数据的只读访问。不过，用户可以使用 BDC 来模拟可对数据实体采取的操作，这些操作由要传递回此 URL的实体定义的名称、URL 以及属性集所定义。随后便可通过 SharePoint 列表的下拉菜单使用。URL 既可与 Web服务相对应，也可以与服务器端文档（如 InfoPath 表单）相对应，并通过代码分离预先填充从 BDC传递的上下文的表单。信息工作者便可使用门户在包含提取 BDC 数据和操作的表格和列表的 SharePoint 中创建轻型应用程序。
复合的功能概述
图 10 显示了 2007 Microsoft Office system 的一些功能如何映射到图 2 中的层。表 2 提供了可用作复合的候选类型的资产类型列表。

图 10. 映射到各个层的 2007 Microsoft Office system 应用程序平台的功能
表 2. 复合的应用程序资产的列表
Open XML 文档
仪表板
工作流
站点
业务活动
页
业务规则
数据连接
架构
授权
度量
报告
Web 部件
仪表板
返回页首
构建 Office 业务应用程序
构建 OBA 这样的标准业务流程有两个步骤。
构建流程包，其中包含流程元数据和封装的应用程序组件。
将流程包部署到生产系统中。接下来对这两个步骤进行详细说明。
构建流程包
使用 Visual Studio Tools for Office Build (VSTO)，将以文档为中心的流程的用户界面构建到 Microsoft Office 客户端应用程序中。
利用任务特定的 Web 部件、页、仪表板、列表和文档库构建 WSS 站点，每个站点都为实现特定的业务功能或流程而设计。可以使用这些站点创建站点模板，用于将标准业务流程封装到 OBA 解决方案中。
使用 Workflow Foundation 将站点中的列表和文档库捆绑在一起，并使用服务器端规则和业务逻辑对处理中的文档进行服务器端处理。将这些工作流封装到程序集中以进行部署。
定义从 OBA 中的工作流到后端 LOB 系统的接触点。流程包元数据应包含用于此集成的 Web 服务接口。需要在部署阶段进行实际连接。
为实现跨功能流程（构建到 OBA 中）所需的数据连接定义 BDC 实体。
通过定义 WSS 站点所要使用的度量、报告、仪表板以及 Excel 图表和表格来添加决策支持。
使用表 2 中的组件类型，将解决方案封装为流程包（WSS 站点模板、WF 程序集、Office 文档等）。
将流程包部署到生产系统
将 WSS 站点部署到生产系统的 SharePoint 服务器中。
使用 Web 服务（或其他自定义适配器）配置从工作流到 LOB 应用程序的连接。
通过将 BDC 数据实体定义连接到实际数据存储来配置数据连接。
置备用户。
在企业中部署复合应用程序
以下是在企业中部署 OBA 的一种方法：
在部门级部署 SharePoint 站点。
连接多个部门。
将业务流程与 LOB 应用程序连接。
添加数据连接以实现跨功能流程。
将业务流程与“边缘”系统连接。
返回页首
构建部门的 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 Officesystem 相连接。这样就能够使用 BDC、SharePoint 列表和工作流的组合将针对跨功能流程的复合应用程序构建到SharePoint 门户中。例如，BDC 可用于定义具有父子关系的实体（例如订单标题和订单明细），而 SharePoint列表可以显示这些实体。通过这种父子关系，就可以从显示标题信息的列表深化到对应的详细信息。另外，可以通过 BDC元数据模拟操作，这意味着这些操作将显示为 SharePoint列表上的菜单项，而从该菜单上选择下拉项将意味着当前所选行中的上下文将传递给为该操作定义的 URL。
连接业务流程与边缘系统
通常 OBA 的范围并不局限于组织内。例如，OBA 可能支持一种需要使用托管提供商（软件即服务 (SaaS)方案）所提供的服务的业务流程。或者，OBA可能需要支持为其他组织提供服务的业务流程。这在涉及贸易合作伙伴的供应链管理方案中尤为常见。此处需要有一种方式，将文档从一名信息工作者传输到贸易合作伙伴组织中与之对应的人员这种方式需要安全、可靠、异步且透明。
图 12显示了一种将端到端体系结构组合在一起的方式。已经在组织的边缘建立了消息代理程序，以发送和接收贸易合作伙伴的消息及文档。来自不同贸易合作伙伴的消息可以通过多种消息格式进行接收，并通过多种渠道（例如 Web 服务、EDI、电子邮件、RosettaNet等）进行传送。另外，可以采用各种不同的模式交换消息，包括：单向、异步双向或同步双向消息传送。这些消息代理程序必须处理这些消息交换模式和消息格式的各种组合。

图 12. 将 OBA 连接到“边缘”系统
消息代理程序接收消息之后，会将消息处理为下游服务所需的单一规范格式，并且转换后的消息仍保留在消息队列中，以将私有进程与公共进程分离。接下来，由检查消息并将消息路由到目标接收方的路由服务从队列中检索消息。但在文档到达其目标接收方之前，可能要由企业应用程序服务（例如 LOB 应用程序或BPM业务流程）对其进行预处理。此时可能会对消息应用业务规则，以确保有效性以及强制执行公司策略。经过所有这些处理过程后，将获得一个文档，该文档可由掌握充足信息的工作人员进行处理，以快速做出决定。例如，可能会将来自客户的采购单请求转给订货承诺服务，而来自该服务的响应可用于生成一个 XML文档，该文档对应于具有候选 PO 确认的 InfoPath 表单。接下来，这一生成的表单可能会放入 SharePoint表单库中，等待销售部门的信息工作者批准。
信息工作者查看所建议的确认并依需要进行更改后，会提交表单。这将启动完整的工作流，整个过程会更新 LOB 系统，然后将来自表单的信息以 XML 文档的形式发布到出站消息队列中，以作为对原始请求的响应。随后消息代理程序会将该消息转换回贸易合作伙伴所使用的格式。
有多种方式实现边缘消息代理程序，例如 BizTalkServer。这将提供可伸缩的、易于管理的解决方案，该解决方案也将附带基于标准的加速器和适配器，例如用于贸易合作伙伴协作的RosettaNet 加速器。使用 Microsoft SQL Service Broker 2005，可以实现将内部进程与外部进程分离的队列。
Office 业务应用程序示例
为提供有关构建 OBA 的商业价值深远的技术资源和指导，此处以在线方式提供了 OBA 的引用实现。这一用于供应链管理的引用应用程序包涵盖了用于在多层供应链的不同级别之间相互协作的多种方案。
返回页首
结束语
2007Microsoft Office system 提供了一个强大的功能集合，用以构建称为 Office 业务应用程序 (OBA)的复合应用程序。通过提供一个复合用户界面，将业务功能以及不同的后端 IT资产集合之间的功能公开，从而实现了跨功能解决方案。这些解决方案也提供了协作业务功能，从而跨越了传统业务应用程序与个人生产率工具之间存在的障碍。