复合应用程序：新范式

有关 Office 业务应用程序的概述，请访问 http://www.microsoft.com/office/oba。
有关架构和开发 Office 业务应用程序的深入技术信息，请访问

• Office 业务应用程序开发人员门户
• 面向架构师的 Office 系统

摘要： 复合应用程序提供了一种长期以来人们梦寐以求的商业“极乐世界”，在这种模式下，经过赋能的技术业务用户可以将组件化的业务能力组合在一起。在很多方面，复合应用程序相当于业务用户的 Web 2.0 和“聚合应用”。尽管围绕复合应用有很多炒作，但许多供应商在提供实际价值方面一直进展缓慢。然而，新技术正在涌现，这将改变这一格局，并且组合将成为构建业务逻辑越来越重要的方面。在本文中，我们将讨论使用复合应用程序应对当今业务挑战的基础知识和优势。

目录

业务动机
组合：分步详解
组合的层次
新兴的应用程序范式
结论
致谢
关于作者

业务动机

对于许多企业而言，赋能业务用户以快速响应不断变化的商业环境并获得竞争优势是一项高度优先的任务。业务用户长期以来一直依赖 IT 来创建流程和逻辑。然而，复合应用程序有可能将重用讨论从技术领域转移到业务领域，从而使企业摆脱孤立的宿主应用程序和开发人员的限制，并使他们能够通过流程和元数据定义针对其业务优化的行为。

Web 2.0 在消费品市场上的最新现象表明，一种根本性的转变正在发生，这是用户期望日益提高的领先指标。越来越多的用户在驱动自己的体验方面拥有更大的影响力，并将这些相同的期望带到工作场所。基于 Web 2.0 的工作经验，用户将越来越多地期望对自己的工作体验施加更多控制并参与其中。他们将期望业务应用程序适应他们的工作方式，而不是接受非最佳体验。这些 Web 2.0 功能将在推动企业应用的过程中走向成熟。最终，Web 2.0 并非真正关于技术。它关乎社交网络和用户对自身体验的控制；由最终用户创建的易于替换的应用程序代表了对快速变化环境的最终响应能力。在企业中，将这种权力转移给最终用户的方法是通过一种同时考虑业务用户和开发人员的复合解决方案。

组合平台提供了一种机制，使多个技术供应商能够参与解决方案，而无需硬编码且脆弱的依赖关系。通过更广泛的应用供应商，可以更轻松地实现更大的价值；组合框架提供了一种交互模型，允许组件有效地解耦并抽象化对其他组件的依赖。随着系统日益转向组合，它们也将越来越多地以元数据为驱动。元数据的迁移将为新功能集打开机会，例如应用程序的自我修复和版本弹性。因此，组合模型将服务导向的许多方面带入了整个格局。

组合：分步详解

组合对不同的人来说意味着不同的东西。如今，业务线 (LOB) 供应商的系统主要管理着在将潜在客户转化为销售的过程中代表离散时间点的已知步骤。这通常被称为结构化流程。

近年来，供应商开始使用熟悉的应用程序——例如，Microsoft Office——来提供更好的用户界面，以在现有流程的特定点进行交互。这些改进提高了流程的生产力和可用性，并将应用程序逻辑的范围扩展到了更广泛的用户群。

这些功能本身就应该促使企业采用它们。虽然这些应用程序在扩展范围方面是重大的改进，但它们通常只是以更易用的方式呈现现有功能。尽管如此，即使有了这些应用程序，传统的 LOB 应用程序也可能无法超越这一控制级别。抑制因素包括

• 遗留系统构建——分区和组件化这些复杂的应用程序，其中包含许多隐式依赖关系，是艰巨的任务，要真正解开硬编码的逻辑还需要很长时间。LOB 供应商最终打算从其紧耦合的遗留系统迁移到松散连接的、基于服务导向概念的功能，从而能够在“组合”领域实现更深层次的参与。
  
• 失控——对于传统的 LOB 供应商来说，在分解和通过服务及可配置用户界面公开功能的过程中放弃对数据和流程的控制是令人恐惧的。
  
• 协作的普遍横向性——客户需要一个协作基础设施。LOB 供应商可能不适合根据需要进行扩展/缩减，或提供普遍的、通用的、易于管理的特性。

现有流程前面的新用户界面并没有真正为企业提供任何额外的洞察或控制。尽管应用程序可能看起来更容易使用，但结果并未改善员工完成任务的能力。例如，图 1 中的此简化流程描述了将潜在客户转化为定制工程产品的订单。将潜在客户转化为销售实际上涉及元素之间比初始结构化流程所代表的要多的工作。这项工作通常具有协作性质。创新经常发生在结构化流程之外的协作互动中，在这里想象力占主导地位，信息工作者的创造力真正得到发挥，并且发生了关键的业务差异化。

图 1. 客户关系管理 (CRM) 的结构化流程示例（单击图片可查看放大图）

尽管使用新界面（如 Microsoft Office）可以改善数据视图，但它本身并不能解决协作问题。将 LOB 系统集成到以文档为中心的应用程序中，为 LOB 流程提供了丰富的机会来组合面向信息工作者的工作流扩展。随着许多门户解决方案现在集成工作流技术（例如，Microsoft Office SharePoint 和 Microsoft Windows Workflow 的集成），它将日益成为 LOB 应用程序的协作工作流解决方案——模糊了管理文档和管理业务流程之间的界限。图 2 中的示例说明了客户团队如何组装 Microsoft Word 中的提案以响应 RFP。这是一个使用组合将流程扩展到多用户体验渠道（Microsoft Word、Microsoft Excel 和 Microsoft Outlook），并运行在不同系统上的两个协作流程（一个临时的，一个结构化的）来完成一个逻辑业务任务的示例。

图 2. 使用 Microsoft Office 进行组合（单击图片可查看放大图）

复合应用还可以弥合独立 LOB 系统中运行的流程。对于需要注入一些增值处理的情况，复合服务是完美的，就像今天通过集成中间件常见的案例一样。信息工作者从 Microsoft Outlook 中获取发送给客户的报价的确认响应，并调用复合服务来桥接 CRM 和 ERP 系统，在 CRM 系统中创建销售订单，并在 ERP 系统中创建内部订单进行处理，这种情况就说明了这一点。

组合的层次

现在我们对组合的含义有了很好的了解，值得了解其他类型的组合。我喜欢按组合发生的层次来对这些组合进行分类。

• 用户界面和客户端逻辑组合——视图可以通过松散耦合的用户界面部分进行组装，这些部分通过围绕框架进行协作。这些视图可以通过触发的事件和信息组成更高层次的功能，从而组成序列，这些序列具有兼容的接口。这种组合可能通过桌面或 Web 服务器上的门户进行。今天的例子包括 Microsoft Patterns and Practices Composite Application UI Block、Microsoft Office SharePoint 的复合应用程序框架、Eclipse Rich Client Platform 以及许多其他门户框架。Web 部件（用于定义构成页面的部分的术语）是构建复合框架的使能技术。Web 2.0 聚合应用通常在此层进行组合，通常直接在浏览器中使用异步 JavaScript 和 XML (AJAX) 进行组合，并代表非正式和意想不到的组合。
  
• 服务组合——多个服务可以通过流程、元数据和规则进行拼接，以提供增值服务。一个有些微不足道但很常见的例子是在采购订单服务中添加第三方信用检查。服务组合通常由集成引擎功能执行——例如，Microsoft BizTalk Server。
  
• 数据/信息组合——第三层数据/信息组合通常是最难解决的问题之一，大多数供应商在明确定义的细分市场之外都无法解决这个问题。然而，有几种技术可以帮助克服这一挑战。例如，主数据管理 (MDM) 会聚合、清理并（通过联合模型）分发特定类型的企业信息。实体聚合也讨论了几年，它代表了一种更通用的基于 ETL/数据仓库的方法。还可以使用企业信息集成 (EII) 作为一种直通处理机制，以实现共享信息的集中视图，从而跨一组不同的服务实现能力执行的协调。2 这些方法是今天的现实，因为遗留系统没有沿着服务-能力界线对数据边界进行强划分的概念。如今的系统也并不容易构建管理沿这些划分界线的信息的服务。Pat Helland 在他的《Metropolis》系列中广泛撰写了关于引用数据、资源数据、活动数据和消息数据的概念。Maarten Mullender 也在他的“服务代理”系列中讨论了这一点。诸如信息桥接框架 (IBF) 之类的框架允许开发人员导航元数据中描述的实体视图和关系，从而使应用程序能够在本地进行组合，而不是通过中间件服务器进行组合。
  
• 端到端流程组合——在这种情况下，流程是一种更高级别的组合，它通过不同的机制将不同的交互连接在一起，通常在较长时间内，通常跨越多个业务系统。例如，员工配置。图 3 中的分步详解说明了使用多个客户端应用程序随时间跨越后端进程进行的交互。即使在今天 LOB 系统捕获诸如“报价到收款”之类的结构化流程的情况下，也有许多机会可以利用围绕 LOB 结构化流程发生的交互，使用流程组合。流程对于组合边界内的其他区域（如上面提到的用户界面和服务）也很重要，但在这两种情况下，流程的使用与此案例不同。在这些情况下，流程是组成界面的内部流程——例如，在组成的客户端中为任务驱动的 UI（向导式）定义的流程，或者在组成的内部服务中用于协调多个次级服务调用和业务规则评估以提供单一业务功能单元的流程。

图 3. 跨独立 LOB 系统的组合（单击图片可查看放大图）

新兴的应用程序范式

复合应用程序框架有潜力改变应用程序的构建、交付和最终用户体验方式。然而，在某些层面，这会使应用程序开发人员的生活变得复杂，因为现在需要更多地考虑哪些体验部分应该通过哪些载体来呈现。它还迫使供应商更认真地考虑开发真正的面向服务的应用程序，在复合环境中仔细考虑能力的的服务边界。随着组合框架越来越易于使用，并且运维和支持模型发展到复合应用程序易于运行的程度，那么利用众多供应商的优势将是加速变革的强大动力。

一个成功的框架需要显著减少复合边界所有层面的摩擦。协作场景并非复合应用程序的先决条件，但它们是更轻量级解决方案的自然载体，该解决方案相对简单但价值高。随着这些平台越来越多地转向模型、工作流和规则驱动的方法，并将更多可配置属性暴露给业务逻辑，应用程序元素的组合能力将向上移动到技术业务用户。

为了实现这一点，我们需要在语法和语义层面与业务线应用程序实现互操作性。为了实现一个完整的组合基础设施，需要使大量复杂问题的解决方案对普通开发人员可用。这些领域中的每一个都值得写一篇文章，其中一些领域已经被他人深入探讨过。这些包括

• 身份——特别是，需要有机制通过单个存储或联合来普遍识别通用用户身份。随着基于云的服务日趋成熟，身份将成为一个重要的 emergent 服务。为了实现软件即服务 (SaaS) 模型，基于云的身份存储需要与本地身份存储进行联合。身份和授权凭据必须在复合客户端、复合服务和后端服务逻辑之间无缝传递。即使在桌面端，跨应用程序的体验也需要无缝才能长期有用。这将需要广泛采用联合和传播身份的机制。
  
• 上下文——为了使复合应用程序的各个部分能够协同工作以提供丰富而复杂的应用程序体验，它们必须拥有对上下文的共享概念。需要解决在协作复合应用程序之间以及在复合应用程序内部传递上下文的机制。
  
• 组合引擎之间的流程集成——投影特定服务内定义的流程接口的视图有助于连接互补的逻辑。例如，我可以设计一个文档工作流，该工作流公开用户界面并管理用于销售管道管理的 Microsoft Excel 文档，并集成到在我销售自动化 (SFA) 业务应用程序中运行的预测的多步、汇总审批流程中。通过将该汇总流程接口投影到设计环境中，我可以更轻松地构建触发后端系统中的事件或操作的协作工作流。此外，我还可以使用投影的流程接口来理解和解释另一个系统中相应流程的当前状态。
  
• 实体定义——为了使组合能够跨越应用程序边界，并且实体能够以多种格式使用，我们需要一个中心概念来区分概念实体与其物理表示。一旦定义了实体的概念，就可以通过不同的物理表示来重用它。一个中央管理的实体定义以及实体之间的关系将扩展到复合体验。仍然存在棘手的问题需要解决：实体如何跨组织边界进行管理？平台如何让实体更容易地从一种形式转换为另一种形式？显然，过去标准化方法的成功充其量是参半的。微格式是一种有趣的、由需求驱动的创建事实标准的方法。实体数据管理和 .NET Language Integrated Query (LINQ) 是 Microsoft 平台朝着这个方向迈出的第一步。
  
• 数据/信息管理——这与实体问题相关，但略有不同。如上一节所述，今天的服务和应用程序通常没有强大的数据边界概念，或者没有实现数据边界的机制，同时仍能提供高性能。资源数据、引用数据、活动数据（与上下文相关）和消息数据的概念需要被明确识别，并通过设计模式、工具和基础设施来支持。在构建应用程序时，通常不考虑诸如数据所有权、数据版本控制、引用数据联合和多个有效版本之类的复杂性，基础设施也使解决这些问题变得容易。
  
• 事件基础设施——在现实中，大多数 Web 服务本质上是请求/响应式的。对于复杂应用程序所需的更丰富的交互模式，需要对 WS-* 协议堆栈提供支持的更复杂的方法。
  
• 存储库/发现机制——UDDI 提供了一个级别的可发现性，但存在局限性。WS-Policy 和 WSMetaDataExchange 添加了额外的层来发现服务和功能的信息。这一领域需要继续成熟。
  
• 建模和元数据框架——开发人员需要越来越多地意识到通过模型和元数据暴露开发的功能，以便将更多控制权通过配置传递给技术业务用户——并最终传递给最终用户——来控制应用程序的行为和组装方式。模型组件将使用工作流和基于规则的系统进行组装。软件工厂中的许多概念都反映了这种转变，既为开发人员构建更好的领域特定解决方案，又将控制权从开发人员那里向上转移给组织（在有必要的情况下）。这将需要应用程序架构师和开发人员进行仔细分析，以确定何时放弃某些行为控制级别，以及在何处限制可配置性，以确保正确性和一致性不会受到侵犯。

图 4. 组合堆栈的层次

结论

可组合性是计算领域的一次范式转变，从解决单一特定问题的脆弱、单体、以开发人员为中心的应用程序，转向支持特定业务流程的敏捷、上下文驱动、用户驱动的应用程序。正如服务导向的转变一样，这不仅需要重构现有代码，还需要重新思考新代码。它还需要新的基础设施来托管应用程序。Microsoft 2007 Office System，尤其是通过包含 SharePoint 服务器支持和工作流支持，是迈向这些应用程序的第一步。未来，这种趋势将继续下去，使用户能够有效地配置和控制自己的工作环境，在应用程序之间无缝传递数据，甚至可能跨越企业边界来完成他们的任务。要实现这一愿景，还有很多工作要做，但受到 Web 技术进步的用户期望的推动，现在已经很难回头了。

致谢

我特别感谢 Daz Wilkin 和 Jon Tobey 帮助我清晰和完善了本文。