在 Mashup 应用程序和传统 Web 应用程序之间进行选择
在 Mashup 应用程序和传统 Web 应用程序之间进行选择
利用 IBM Mashup Center 的注意事项
本文对比了传统的 Web 应用程序和 Mashup 混搭应用程序，看看哪个更适合用作可行的业务工具。
Holt Adams, 高级顾问 IT 架构师, IBM jStart
John Gerken, 高级架构师, IBM
2009 年 7 月 17 日
内容混搭应用程序和 Web 应用程序有什么共同点？
传统的 Web 应用程序：传统仅是相对的
混搭应用程序：Web 2.0 的产物
哪种方法更适合您？
结束语
参考资料
评论
混搭应用程序（mashup）是 Web 2.0 的有趣新特性。这个行业通过利用新的技术和方法，通常能够及时实现新技术的价值。大肆的宣传常常会使人们误解新技术能够创造的价值和目前存在的价值。使用混搭应用程序时，IT 人员通常不明白现有 Web 应用程序与通过新办法将数据与浏览器混搭起来有什么区别。
客户最常问的一个问题是 “混搭应用程序和我们目前在企业中使用的 Web 应用程序有什么区别？”这种区别与技术或系统集成没有多大关系。相反，它反映用户创建应用程序的难易程度、应用程序的使用方式，以及在部署混搭应用程序或 Web 应用程序之后需要解决的非功能性需求（例如，可靠性、可用性和性能）。
Lotus Mashup Center 试用下载
立即下载最新版本的 IBM Mashup Center 试用软件，轻松体验产品的最新特性！
试用版下载：IBM Mashup Center V1.1
在本文中，我们将 Web 应用程序与一种新型的混搭应用程序进行比较，后者通常称为企业情境应用程序，它们服务于商业目的。混搭应用程序通常是针对特定场景创建的，并且通常仅在该场景存在的时间段内使用。为了弄清楚混搭应用程序和传统的 Web 应用程序之间的区别，我们首先看一下它们的相同之处。
在最近发布 IBM® Mashup Center 产品（由 Lotus® Mashups 和 InfoSphere™ MashupHub 组成）之后，IT 架构师和业务分析员可以考虑如何利用该产品的组件和特性，以更好地满足情境需求，以及增强公司在市场上的竞争力。
混搭应用程序和 Web 应用程序有什么共同点？
混搭应用程序和 Web 应用程序都使用浏览器作为客户端解决方案组件，从而为特定的应用程序提供一个用户界面（UI）。混搭应用程序和 Web 应用程序都是从企业的服务器统一管理的，并且都是部署到用户的浏览器上，用户通过一个 URL 就可以访问服务器上的资源（例如，HTML、JSP、Java™ Servlet、ASP、CGI 或 PHP 资源）。混搭应用程序和 Web 应用程序的业务逻辑都可以在企业系统上执行，并且可以从企业数据库、公共资源或外部服务获取它们的数据。对于这两种情况，都通过浏览器呈现用于定义 UI 的代码和从内部或外部业务系统提取的信息，从而使用户能够查看和操作数据。此外，发送给浏览器的内容可以包含在浏览器运行时中执行的 JavaScript™ 和脚本库，从而实现在本地浏览器中运行定制逻辑。在很多情况下，JavaScript 和脚本库都用于简单的字段验证或实现复杂的 UI 控件，从而提供一个交互式富用户界面。
回页首
传统的 Web 应用程序：传统仅是相对的
现在我们看看两种类型的应用程序之间的区别。对传统 Web 应用程序的定义带有许多主观因素；在某些方面，这种定义是相对于如何开发 Web 应用程序而言的。总体来说，传统 Web 应用程序的分类主要与使用正式的开发和部署方法模型有关。传统 Web 应用程序的分类还包含根据用户交互（例如，提交表单或单击链接）动态生成内容的应用程序，但是这些应用程序的 UI 信息聚合和 UI 控件关联是在服务器上完成的。因此，基于 Java Server Pages (JSP)、Active Server Pages (ASP) 或 IBM WebSphere® Portal 技术的应用程序都属于传统的 Web 应用程序。此外，基于 Web 并且支持页面导航的应用程序也划分为传统的 Web 应用程序，因为它们限制用户高效地查看和操作数据。当您考虑构造和部署方式时，利用 Adobe® Flash 技术并拥有高度交互界面的应用程序甚至也被划分为传统的 Web 应用程序。
在企业中为业务线部署的 Web 应用程序通常需要正式的开发团队和运营支持。首先，仅当受益的用户群体很大时，或者应用程序是任务关键型的，才有理由为开发和支持投资。不管对于哪种情况，都需要一个正式的流程，以确保投资的收益最大化。
其次，为了优化资源使用，企业的不同部门通常会拥有一些独特的技能。在很多情况下，拥有开发和部署技术的人员与拥有业务知识的人员是分开的。通常，业务线有一组需要解决的需求，通过解决这些需求来支持业务流程或与客户有关的销售和服务计划。这些需求通过设计和开发 UI、管理应用程序功能的控制逻辑，以及利用和操作数据的代码来解决。
开发企业 Web 应用程序时，需求定义、设计、开发、功能和系统测试，以及部署阶段都是很正式的。将这些阶段结合起来之后，完成端对端的解决方案即使不需要一年，也需要好几个月。使用这种方式时，组织的业务线就依赖于公司内部的 IT 和编程部门。但是，如果遵循正式的开发流程，得到的很可能就是一个全面、稳定并且针对目标用户进行了优化的解决方案。同样，您还需要在开发 Web 应用程序所需的时间和交互并维护该程序所需的总体成本之间进行权衡。在某些情况下，如果创建 Web 应用程序的周期过长，应用程序的业务需求可能会发生改变或不再存在。
回页首
混搭应用程序：Web 2.0 的产物
如前所述，在企业服务器和浏览器方面，混搭应用程序和传统 Web 应用程序都利用了许多相同的技术。混搭这个概念并不新鲜，因为业务和 Web 开发人员在过去 10 年以来一直使用 Web 作为平台聚合和集成数据。为了尽量避免混淆，我们阐明混搭应用程序的一些要点。对大多数人而言，混搭是一个技术术语，因为它通过混合不同来源的数据以生成新的、有趣的东西。情境应用程序被认为是策略应用程序，即针对特定目的临时创建。从这方面看，混搭应用程序可以是情境应用程序，反之亦然。在本文中，混搭应用程序指的是通过混搭实现的情境应用程序。图 1 给出了一个概览。
图 1. 混搭应用程序和情境应用程序的特征
混搭应用程序和 Web 应用程序之间的一个主要区别是：混搭应用程序的生命周期，以及它能够以有意义的方式将不相关的公共数据无缝地整合起来，而且不需要与数据供应商签订正式的协定。
混搭应用程序可以看作是一种特殊的 Web 应用程序。这有几个原因。它们是由用户或业务分析员在相对短的时间内创建的，并且几乎不需要 IT 资源成本。类似地，在企业中使用的混搭应用程序的数据通常聚合了企业的数据和公共数据。它们通过以有意义的方式将多个来源（通常利用分散的公共资源）的数据聚合起来，在解决业务或个人需求时实现自身的价值。聚合后的数据应用在正确的上下文中就变成了相关联的信息；通过创建混搭应用程序能够提供新的、有趣的东西。
例如，考虑这样一个供应链管理例子，其中地区运营经理构造了一个 Web 页面（混搭应用程序），它包含一个天气 feed、一个 Yahoo! 地图和企业库存数据，从而在出现自然灾害时（比如飓风）方便商品的后勤管理。另一个例子为一个精通网络的雇员提供了价值，该雇员是一位销售代表，他负责购买商业不动产。该雇员使用 Google 地图创建了一个 Web 页面，并加入带有图像、公共税务记录、公共犯罪记录的不动产列表，以及一个客户列表。该雇员通过从一个数据调色板拖出所需的数据并将其放到地图上面就可以完成任务。完成之后，每个带有地址信息的条目都显示为地图上的图钉标记。最终的混搭应用程序将多个来源的分散数据聚合到一个统一视图中。这样，该雇员就可以根据合理的价格、客户距离和周围环境安全购买房子。这就是混搭应用程序为他提供的价值。
传统的 Web 应用程序（例如门户网站）也能够聚合数据。但是，考虑到数据的可用性和有效性，任务关键型应用程序一般都不依赖于公共数据源。同样，业务分析员也不具备构建这种应用程序的技能。
作为 Web 2.0 的产物，混搭应用程序的一个实现区别是：它实现一个异步加载和显示内容的 Ajax 应用程序模型，从而最小化服务器请求以及 UI 交互延迟。同样，利用 JavaScript 和脚本库的混搭应用程序小部件（widget）除了能够在服务器上聚合数据之外，还能够在浏览器中聚合数据。因此，与许多传统 Web 应用程序的完整页面刷新相比，混搭应用程序能够提供更自然、更快速的用户交互响应。
业务用户要创建混搭应用程序，通常需要使用 mashup 构建器、编辑器或组装器（例如，Lotus Mashup 编辑器和 IBM Lotus Widget Factory）。mashup 构建器本身可以是一个简化的基于浏览器的开发环境。用户仅需从 mashup 构建器的调色板中选择小部件，并在工作空间中布置它们，然后通过几个步骤定制小部件，以及将它们关联起来从而创建一个简单的 Web 应用程序：一个混搭应用程序，具体而言就是情境应用程序混搭。同样，也可以使用类似的工具（例如，InfoSphere MashupHub 客户端）创建混搭 feed，该工具能够合并、过滤和转换一组现有的 feed，然后创建一组供小部件使用的新 feed。小部件本身是独立的应用程序组件，它们拥有正式的界面和可定制属性，通常用于提供数据、UI 控件以及数据后台处理的 UI 视图（例如，调用服务器端服务、数据库 CRUD 操作、屏幕抓取或在小部件之间转换和映射数据）。混搭应用程序的创建和部署都是在 mashup 构建器中完成的，而不需要依赖于正式的 IT 运营团队。IT 部门的任务是部署工具、安装和实现混搭系统并让业务用户能够使用这些工具创建混搭式 Web 应用程序，因此业务线和 IT 部门之间还存在一些原始依赖。
IT 仍然必须在生产环境中设置和配置系统，或在防火墙之后从内部配置，传统 Web 应用程序也需要这个过程。特定的混搭系统组件需要部署到服务器上，就像基于门户的 Web 应用程序需要门户引擎一样。此外，如果不能使用标准化的联合 feed（RSS 或 ATOM）、Representational State Transfer (REST) API 或简单的 Web 服务 API 访问业务数据，那么 IT 部门就需要创建这些接口。
为企业数据源创建联合 feed 的一种简单替代方法是利用混搭 hub 组件（例如，InfoSphere MashupHub），它在后端与企业系统连接起来，同时为每个系统显示单个联合 feed，或为可以在混搭应用程序中使用的系统显示一组聚合的联合 feed。类似地，如果需要超出小部件属性范围定制数据视图，或用户交互需要定制小部件，那么 IT 部门可以选择创建新的小部件或对现有的小部件进行定制。当通过标准化 API 将业务数据和逻辑具体化之后，以及定制小部件被添加到小部件库之后，对 IT 的依赖就会大大减少。最后，可能仅需使用 IT 来确保使用适当的中间件维护系统，以及为确保系统的可用性提供监控和支持。因为小部件是可重用的应用程序组件，并且是为了提供业务功能而临时组合起来的，因此需要进行权衡。权衡的对象包括减少 UI 定制、更少的性能调优，以及组成混搭应用程序的小部件仅需少量甚至不需要正式支持。
回页首
哪种方法更适合您？
传统 Web 应用程序和混搭应用程序之间有很多相似性，也有一些明显的区别，您可能很难确定使用哪个更有优势。通过考虑以下方面，确定使用传统 Web 应用程序的开发和部署模型是不是您的最佳选择：
应用程序对业务的成功是必要的。
有大量用户需要应用程序提供高可用性和正式支持。
应用程序需要解决一组全面的需求，而这些需求要求实现高度集成和可定制的 UI。
需要管理的文档工作流或流程工作流很复杂。
如果这些方面没有把您引向采用传统的 Web 应用程序，那么考虑以下方面，确定情境应用程序是否是您的最佳选择：
业务需求是直接的、临时的。
用户或业务分析员熟悉 Web 技术。
可以以有意义的方式将业务数据与不同来源（来自于企业内部或外部）的内容关联起来。
需要通过快速原型化向 IT 组织演示业务需求。
通过使用自助服务聚合和业务数据集成，社区用户能够提高生产力。
“一般” 的解决方案能够解决业务和个人需求。
数据源支持联合 feed。
数据服务支持 REST 式接口或简单的 Web 服务接口。
许多业务用户为了不同的目的访问相同的数据。
回页首
结束语
情境应用程序混搭的价值主张是：当企业支持从标准化接口访问业务逻辑和数据之后，用户就能够自己创建应用程序。应用程序是由一组能够显示和操作企业数据的小部件构成的，从而允许用户直接利用公司在 SOA 和其他标准上的投资，以及实现能够解决自身需求并优化生产力的自助行为。个人及其团队获得的生产力提高对 IT 组织的依赖很小；因此这些收益不会受到 IT 资源成本的影响