Mashup 业务场景和模式：第 1 部分

版权声明：本文转自http://www.ibm.com/developerworks/cn/lotus/mashups-patterns-pt1/?S_TACT=105AGX52&S_CMP=tec-csdn，原作者Duane Merrill ,对本文的再次转载请遵守有关法律法规和公认约定，如对本次转载有异议，请与本人联系，本人将按照版权所有人要求进行相关操作。

本文是一个分两部分的系列的第 1 篇文章，该系列讨论可用于部署 mashup 以解决业务需求的使用模式和架构模式之间的关系。第 1 部分介绍了一些企业应用 Mashup 的业务目标和场景。第 2 部分 将论述用于实现业务场景和使用模式的解决方案架构和架构模式。

 

在采用曲线上，应用 mashup 解决企业需求已经达到了指数级增长阶段。很多行业目前正在利用这项技术，通过一些常见的使用和架构模式来解决独特的业务场景。很多情况下，用于某个行业的解决方案可以横向部署到具有类似需求的其他行业。

mashup 解决方案的不同之处在于用户角色和用于创建独特价值的聚合的数据集。在很多情况下，使用模式（例如捕捉搜索标准、在用户界面中呈现数据、根据主数据选择更新辅助表、操纵数据和与其他人通信）是类似的，但是对于不同的客户，要解决的业务目标有所不同。

mashup 的设计和架构选项取决于选择的实现平台。对于利用大量常见使用模式的业务场景，可以使用少量的设计和架构模式实现（例如，使用 RSS/ATOM 提要，调用 REST 服务，通过 pub/sub 模型实现部件通信，通过中央 hub 聚集数据源，以及在数据源和服务源中过滤数据）。

图 1.Mashup 的采用趋势
 

简介

近几年来，IBM® software Emerging Technology 团队（jStart）一直与客户和业务伙伴合作，在概念证明环境中利用各种 mashup 技术（例如 QEDWiki、IBM Mashup Center）解决不同的业务需求，以验证这项技术的有用性。jStart 团队观察了这些技术的很多常见场景和解决方案实现，并归档为正式的工作成果。早期的采用者利用这些工件提出了企业 mashup 的价值主张。

被实现为情境应用程序（situation application）的企业 mashup 是一种新型的用于特定商业目的的 mashup。情境 mashup 是为独特的业务需求而创建的，通常只在存在业务情况的短期内使用。用户可以自己创建应用程序，但是在设计方面，这种应用程序并不解决那些与关键 Web 应用程序联系在一起的非功能性需求（例如可靠性、可用性和性能）。通常，当用户认为这些应用程序足够好之后，这些应用程序便逐渐被一些商务人士采用为标准，他们喜欢自己动手解决谋求市场发展时遇到的问题。

在所有解决方案开发原则中，资产重用（例如方法学、设计概念和组件的重用）是很常见的，并且资产重用受到鼓励，用以提高效率和减少开发成本和时间。当这些资产被广泛地、可重复地重用时，它们常常被称作模式（pattern）。该术语本身就是通用的，可以单独或组合使用该术语来描述业务场景、使用交互、架构设计和实现。对于本系列的文章，当描述受支持的交互以及 mashup 应用程序的设计和实现的架构方面时，将使用这个术语。

回页首

Mashup 业务场景

mashup 之所以被越来越多的企业采用，与两个业务因素有关：收益和成本。企业总是需要通过增加销售和服务来提高收益。然而，在当今市场中，企业可能更需要稳定客户忠诚度以保障已有的收益流。同样，为了降低运营成本，还有一个因素也需要考虑，那就是调整企业 mashup 中的投资。减少用于应用程序开发的 IT 资源，或者在日常任务中提高 IT 技术人员的效率，都有利于企业的盈利。

企业开始注重利用企业 mashup 解决上述业务因素，这主要是因为之前的 IT 开发已经积累了一些应用程序。在很多情况下，业务线（LOB）需要更自主地解决自身的需求，从而降低对 IT 组织的依赖。同样，IT 组织感受到需要以更少的资金、更快的速度向 LOB 交付应用程序的压力，他们正在将 mashup 用于非关键型应用程序，因为 mashup 不需要高超的技能，并且周期更短。IT 组织使用 mashup 辅助那些不能完全自主创建 mashup 应用程序的、对网络了解不足的业务用户。图 2 展示了 mashup 的一些业务场景。

图 2. 业务场景
 

通常伴随收益和成本这两个业务驱动因素的还包括利用 mashup 的企业的一些常见目标。这些目标包括：

• 通过管理改善决策制定
• 优化人力资源的生产率
• 由业务分析师证明新的业务机遇
• 由雇员、业务伙伴和客户发现和定位专门技术和内容
• 通过团队协作改进非正式的业务流程

利用 mashup 解决业务需求的很多业务场景都可以跨行业采用。两个常见的场景是资源管理和个人指示板。资源管理可用于统筹管理多家商店的零售存货，优化产品的销售，以应对世界大事或自然灾难。它还可以用于管理固定资产，例如火车或船舶，以优化货物的运输。此外，还可以应用它来分配人力资源，以便在面临销售和服务机遇时获得最大收益。以上情况都是将不同来源的数据聚合到同一个屏幕上，使业务用户可以改善决策、优化生产率和改进非正式的业务流程。

个人指示板很少特定于给定的业务流程，但是它们通常针对给定的用户进行定制。在改善决策、改进非正式流程和定位专门技术和内容方面，它们可以提供巨大的价值。很多时候，个人指示板并不是用于解决特定的业务目标，而是让用户可以整合信息和管理任务，以支持他们的日常活动。在紧急响应、财务分析、企业资源计划乃至战略分析方面，指示板都可以提供帮助。

其他被实现的协作业务场景还有个人通信和现场支持服务，在这些场景中，团队可以查看和更新信息，并发起通话、电子邮件和即时消息传递。用户场景还为客户提供自助服务，使用户可以管理他们的银行账户，查找支行和 ATM 机，以及与银行雇员联系。

这些场景示例的一个基本概念是，可以轻松利用基本的用户交互模型（本文后面会谈到）和数据聚合，使用不同用户角色的数据源解决他们的其他业务需求。因此，本文的重点是模式。

回页首

早期采用者的交互模型

无论具体的业务场景或行业是什么，对于早期采用者而言，jStart mashup 项目目前趋向于以下两种风格的应用程序：搜索/查找或个人指示板。

第一种风格使用迷你表单构造对一个或多个信息源的搜索。结果以某种可视化的方式显示：在一个表中显示，显示为地图上的点，显示为图表中的条形，等等。当用户选择一个项时，关于这个项的附加细节将被显示给用户（搜索和查看行为）。通常，显示的信息有多个来源，包括内部企业系统或外部 Internet 源。至此，业务场景已经完成，或者接下来用户利用 mashup 根据呈现的信息采取操作。

个人指示板风格捕捉用户凭证（ID 和密码），并使用它们为用户显示定制的数据 “指示板”。指示板可以显示整个场景，也可以是可重复的以前的场景，用户可以继续单击某个项，获得更详细的信息，然后根据呈现的信息采取操作。最近，早期采用者正在扩展 mashup 的这两种基本风格，增加后端系统中的数据更新、创建和删除（搜索、查看、更新行为），另外还增加通信机制，以支持雇员、合作伙伴和客户之间的协作（搜索、查看、协作、更新行为）。

图 3. 早期采用者的交互模型
 

图 3 描绘了早期采用者的一个交互模型，以便于理解基本的 mashup 使用。一个交互就是一对用户操作，具有一个或多个来自 mashup 的响应（例如，单击一个选项卡，导致一部分内容被隐藏，而另一个内容被显示；将鼠标移到一个图像上，导致一个弹出操作；或者选择一个数据记录，导致附加的细节被填充到辅助表中）。本文在论述使用模式时，都标记出了交互，并包括关于用户操作的讨论和产生的 mashup 响应。

特别要注意，搜索、查看、更新和协作类型的 mashup 行为是之前描述的初始业务场景的基础。展望未来，可以看到这些技术的更为广阔的应用，包括视频、自动更新、基于 IP 的远程设备的集成和全球定位系统（GPS）。无论业务目标、用户角色、数据或者行业焦点是什么，大多数业务场景都可以用上述交互模型表示。支持早期采用者的这个交互模型的常见使用模式都源于 jStart 项目的参与者，后面的小节将对此进行讨论。

回页首

业务场景与使用和架构模式

根据以上所述，业务场景是用于解决业务目标的高级业务活动，很少涉及到技术。场景的实现意味着业务用户以常见的方式和特定的技术通过交互执行任务，这些方式在本系列中被称作使用模式。这些模式包括个人在使用 mashup 界面的特性或控件时所执行的常见的步骤（即操作，例如登录到 mashup，输入搜索标准，从表中选择数据，将鼠标移到图像上，添加或更新数据记录）。当用户与 mashup 中的控件或显示的数据交互时，执行的一些操作会导致 mashup 进行某种处理。这种处理将改变 UI 本身的呈现（例如导航、控件可见性），调用其他软件中的服务或数据源，或者在 mashup 中显示附加的信息和图像。在某些情况下，mashup 在响应用户操作时，可能同时执行以上三种处理。如图 4 所示。

图 4. 场景与模式

mashup 应用程序中对受支持的行为和交互的实现是由它的底层架构控制的。mashup 应用程序由一些被称作部件（widget）的组件构造而成，这些部件被链接在一起，以创建用于聚合要显示的数据和供用户执行操作的 UI 和模型。这些部件可以是可视的，以便用于呈现 UI，也可以是隐藏的，以便用于执行后台处理。可视化部件也可以执行或发起后台处理。部件之间的链接（通过编程耦合或通信）形成了一种机制，使 mashup 得以为用户提供一种交互式的、快速响应的体验（例如，单击部件的某个控件，会导致其他部件中的数据被刷新，或者导致在界面中呈现其他的部件）。如何定义和实现链接取决于 mashup 应用程序平台。本系列的第 2 部分将介绍一些设计，通过这些设计可以实现一些使用模式，以支持 mashup 的行为和用户交互。

回页首

使用模式，包括启用的操作和 mashup 响应

jStart 团队与超过 50 名客户进行了合作，采用 mashup 技术解决现实中的业务需求。基于 mashup 应用程序中最初的那些搜索、查看、协作和更新行为，jStart 团队为很多通用的使用模式编制了文档，并加以重用。这些模式所提供的功能很容易映射到采用 mashup 的客户的常见 IT 需求，这也可以解释为什么这些模式适用于多个行业，并且被广泛重用。后面小节中列出的使用模式（包括操作和响应的交互）是由 jStart 团队在客户采用的初始阶段实现的。应该将这些模式看作在利用 mashup 技术解决业务需求时所能取得的一些可能性。

访问控制和个性化模式

很多企业 mashup 需要利用一些重要的公司数据或机密数据，前一种数据因其隐含的市场价值而被视作重要资产，后一种数据则涉及到个人数据或提供了竞争优势的数据。无论哪种情况，都需要对用户社区进行验证和授权，并要求成员先进行登录，然后才允许他们看到 mashup 应用程序 UI。用户社区可以包括雇员、业务伙伴和客户。图 5 展示了常见的使用模式和登录时支持的操作。

图 5. 登录交互

捕捉和验证用户的凭证后，便可以向用户开放对公司数据的访问，并根据用户的角色执行个性化设置。这种授权还包括控制对 mashup 应用程序的特性的访问（例如导航控件、通信控件）。类似地，还可以根据角色控制对收费服务的访问，以确保对服务的适当使用。登录后，用户便可以通过单击 mashup UI 中的控件发起操作，以便根据手头上的业务任务确定在 UI 中显示哪些特性和数据。

呈现 mashup UI 和数据模式的检索

为了优化 mashup 中对来自多个源的数据的聚合，并将从这些源检索的数据限制为最相关的数据，可以使用由用户定义的搜索标准对一组主数据记录执行初步的查询。搜索标准常常在一个使用文本输入字段、下拉菜单、复选框或单选按钮的表单中进行捕捉。取决于集成的数据源或服务的类型，在最简单的情况下，可以直接调用数据源或服务，以便提取 RSS 或 ATOM 提要。或者，可以向一个中心发出请求，以聚合来自多个源（例如提要、SQL、文件、Web 服务、LDAP、SAP）或具有不同数据格式的源（例如 RSS、ATOM、CSV、XML、非结构化字符串）的数据，从而创建统一的数据提要。

此外，更复杂的调用还包括使用本地协议和 API 直接从后端系统提取到的数据（在第 2 部分中，当讨论架构模式时，将更详细地讨论这一点）。通常，还需要进行过滤，去掉不相关的数据或冗余的数据，以减少呈现 mashup 的浏览器与后端系统、外部公共数据源或来自其他供应商的服务之间交换的信息量。图 6 展示了登录后用于定义搜索标准的常见使用模式和支持的操作。

图 6. 搜索和检索交互

检索到一组初始的数据后，mashup 使用包括表、列表、分层树结构、地图、菜单和图像的可视化部件（即用于显示信息的一些可视化组件）来呈现主数据记录。数据可以是数据库表中的结构化数据，也可以是地图上标识独特资源的彩色图标、图像幻灯片，或者是具有在线指示功能的好友群组中列出的联系人。

数据模式的查看和操纵

将主数据集呈现给用户后，用户可以开始执行一些任务，完成 mashup 支持的业务活动。通过查看和操纵得到的高度相关的数据，可以改善决策、优化生产率、加快专门技术和内容的定位以及改进非正式的业务流程。

在同一个视图中聚合和关联不同的数据，从而产生独特的价值，这是 mashup 的基础。通过允许业务用户在数据之间轻松导航，逐项查看数据，或者将来自不同数据源的数据相关联，可以为业务用户带来直接的价值。通过选择单个数据记录以下钻更多细节，以及在表、条形图或地图中显示辅助数据，业务用户可以在不同层次上可视化地处理数据。图 7 展示了检索到一组数据或者经后续查询进行了刷新之后，通常的使用模式和支持的操作。

图 7. 数据查看交互

通过使用户可以在同一个视图中访问来自多个系统的数据，并允许他们实时地操纵数据（更新记录、创建新记录或者删除记录），用户可以在执行业务活动的过程中优化他们的任务。更新数据可以包括添加非结构化注释、将服务请求指派给团队成员或者将银行交易归为某种预算类别。创建新的数据记录可以包括将一个联系人添加到好友列表。执行交易（例如在银行帐户之间转帐）也可能在数据集中生成新的记录。还可以从数据集中删除和移除数据。如图 8 所示。

图 8. 数据操纵交互

无论如何，任何对数据的操纵都必须立即复制到后端系统，以便将更改持久化，使其他团队成员将来可以使用。取决于受支持的系统和协议，当涉及多个系统时，通常建议由一个服务器端组件对更新进行协调（例如，两阶段提交）。

与其他模式的通信

当成员之间可以轻松地相互通信时，团队就可以最高效地工作。对于如今的远程办公、分布式团队和外出成员而言，仅仅使用电话或电子邮件的标准通信方式是不够的。mashup 让用户可以用更多的方式进行联系，它可以为不同用户提供最适合的通信方式，从而创造可观的价值。对于很多专业人士和消费者而言，当需要进行简短的、非紧急的通信时，异步消息传递，例如使用即时通讯软件（IM）进行聊天或者使用短消息服务（SMS）进行文本消息传递（texting），已成为首选的通信机制。图 9 展示了用于协作型团队的通信的常见使用模式和支持的操作。

图 9. 通信交互

作为标准的操作模式，提供通信机制的 mashup 将使用联系人列表，在联系人列表中，可以对团队成员分组（例如好友列表），并且可以指定昵称，以便于使用。通过让团队可以根据个人爱好或具体情况选择多种通信渠道进行协作，mashup 确保在执行业务活动期间取得高效率。其目标是使团队可以利用团队成员的专门技术和工作流策略共同执行非正式的业务流程。如图 图 10 所示。

图 10. 通信交互细节

选定通信方式后，mashup 应用程序可以从主数据集获取数据，填充发起通信所需的必要信息（电话号码、电子邮件地址、IM 名称和 IM 提供商的服务器）。mashup 还可以对用户输入消息进行处理，以确保格式正确、拼写无误并且符合消息长度限制。

这里描述的使用模式特定于为跨多个行业的多个业务场景实现的 jStart 项目，但是它们只展示了支持以上客户业务活动所必需的东西。由于 mashup 利用浏览器中运行的 Java™Script，并且可以访问服务器端组件，因此 mashup 应用程序实际上支持无限多种交互。如果掌握了开发和定制 mashup 中使用的部件的 IT 技能，那么您就可以自由发挥想象力。

回页首

结束语

如今的 mashup 应用程序可以用一个简单的交互模型来描述，该模型支持搜索、查看、协作和更新行为。mashup 可用于业务场景，为常见的交互提供支持，在这些交互中，用户采取操作，mashup 应用程序则返回一个或多个响应。使用 mashup 的每个行业的用户角色和数据不尽相同，它们为解决行业的业务需求提供独特的价值。但是，使用模式是相似的，因为底层的 IT 需求基本相同。本文根据早期采用者的使用经验，简单介绍了 mashup 技术所能创造的一些可能性。让业务用户自主创建情境应用程序，解决自身的需求或问题，这是可以用 mashup 技术和 IBM Mashup Center 实现的价值主张。本系列的 第 2 部分 将论述用于实现本文列出的业务场景和使用模式的解决方案架构和架构模式。