一．简介
一种新型的基于 Web 的数据集成应用程序正在 Internet 上逐渐兴起。通常用术语 mashup 表示，它们的流行萌芽于对交互式用户参与和集成第三方数据的类似于科学怪人方式的重视。我们使用萌芽一词是有一定原因的；mashup Web 站点的特点就表现为它正在 Web 上扎根发芽，它们利用了从组织边界之外的数据源获取的内容和功能。
mashup 这种隐晦的数据集成定义当然不是非常严格。要深入了解什么是 mashup，就应该了解一下这个单词的起源：它源于流行音乐，mashup 是从两首不同的歌曲（通常属于不同的流派）中混合演唱和乐器的音轨而构成的一首新歌。与那些 “bastard pop” 歌曲类似，mashup 也是内容的一种不常见的创新组合（通常都源自于无关的数据源），这都是人工进行合成的（而不是通过计算机来合成的）。
那么，mashup 看起来到底是什么样子呢？ChicagoCrime.org 的 Web 站点上有非常直观的例子，它解释了地图 mashup 到底是什么。最初广泛流行起来的 mashup 之一是一个 Web 站点，它将芝加哥警局在线数据库中的犯罪记录与 Google Maps 上的地图复合在一起。用户可以与 mashup 站点进行交互，例如告诉它在图形界面上显示一个包含图钉的地图，图钉展示南加州最近所有入室抢劫案件的详细信息。这种概念和呈现方式非常简单，犯罪和地图数据复合之后提供的可视化的功能非常强大。
在Mashup 流派中，我们探索了流行的 mashup，包括地图 mashup。简要介绍了与 mashup 的构建和操作有关的技术前景。技术挑战和社会挑战部分分别介绍了影响mashup 的主要技术挑战和社会挑战。
二．Mashup类型
在本节中，我们将简要介绍对出名的 mashup 类型进行的一些调查。
地图 Mashup
在这个阶段的信息技术中，人们搜集大量有关事物和行为的数据，二者都常常具有位置注释信息。所有这些包含位置数据的不同数据集均可利用地图通过令人惊奇的图形化方式呈现出来。mashup 蓬勃发展的一种主要动力就是 Google 公开了自己的 Google Maps API。这仿佛打开了一道大门，让 Web 开发人员（包括爱好者、修补程序开发人员和其他一些人）可以在地图中包含所有类型的数据（从原子弹灾难到波士顿的 CowParade 奶牛都可以）。为了不落于人后，Microsoft（Virtual Earth）、Yahoo（Yahoo Maps）和 AOL（MapQuest）也很快相继公开了自己的 API。
视频和图象 Mashup
图像主机和社交网络站点（例如 Flickr 使用自己的 API 来共享图像）的兴起导致出现了很多有趣的 mashup。由于内容提供者拥有与其保存的图像相关的元数据（例如谁拍的照片，照片的内容是什么，在何时何地拍摄的等等），mashup 的设计者可以将这些照片和其他与元数据相关的信息放到一起。例如，mashup 可以对歌曲或诗词进行分析，从而将相关照片拼接在一起，或者基于相同的照片元数据（标题、时间戳或其他元数据）显示社交网络图。另外一个例子可能以一个 Web 站点（例如 CNN 之类的新闻站点）作为输入，并在新闻中通过照片匹配而将照片中的内容以文字的形式呈现出来。
搜索和购物 Mashup
搜索和购物 mashup 在 mashup 这个术语出现之前就已经存在很长时间了。在 Web API 出现之前，有相当多的购物工具，例如 BizRate、PriceGrabber、MySimon 和 Google 的 Froogle，都使用了 B2B 技术或屏幕抓取的方式来累计相关的价格数据。为了促进 mashup 和其他有趣的 Web 应用程序的发展，诸如 eBay 和 Amazon 之类的消费网站已经为通过编程访问自己的内容而发布了自己的 API。
新闻 Mashup
新闻源（例如纽约时报、BBC 或路透社）已从 2002 年起使用 RSS 和 Atom 之类的联合技术来发布各个主题的新闻提要。以联合技术为基础的 mashup 可以聚集一名用户的提要，并将其通过 Web 呈现出来，创建个性化的报纸，从而满足读者独特的兴趣。Diggdot.us 正是这样的一个例子，它合并了 Digg.com、Slashdot.org 和 Del.icio.us 上与技术有关的内容。
三．技术挑战
与其他数据集成领域一样，mashup 开发也充斥着许多亟待解决的技术挑战，随着 mashup 应用程序特性和功能的进一步丰富，这种挑战也变得更加严峻。本节简单介绍了一些挑战，其中有些挑战目前已经能够解决或缓解，而其他问题依然没有解决。
数据集成挑战：语意和数据的品质
品质调查显示，当今的企业 IT 首要关注的问题就是是企业虚拟组织中的数据集成。（在这种情况中，我们使用了 虚拟组织（virtual organization） 这个术语表示很多联合业务单元的组合，每个业务单元都包含在自己的管理域中。）与很多发现自己忙于集成传统数据源的企业 IT 管理人员一样（例如，创建可以反映当前业务状况的企业仪表板），mashup 开发人员需要面对类似源自于在异构数据集之间共享语义的挑战。因此，要了解 mashup 开发人员是如何为此作出准备，只需了解企业 IT 所面临的集成挑战。
例如，我们必须设计数据模型之间的转换系统。在将数据转换成通用的格式时、在映射不完整时（例如，一个数据源可能有一个模型，其中一个地址类型包含了一个国家字段，而另外一个模型中没有这个字段），我们必须进行一些合理的假设。尽管已经面临这些挑战，但是 mashup 开发人员可能并不是源数据模型领域的专家，因为这些模型可能是第三方的产品，这些合理的假设可能并不直观清晰，这更加剧了挑战的严峻性。
除了缺少数据和映射不完整之外，mashup 设计者可能会发现他们希望集成的数据并不适合进行机器自动化处理；这将带来很多净化工作。例如，执法逮捕记录可能不一致：记录中可能为名字使用了常用的缩写形式（例如，一条记录中使用的是“mkt sqr”，另外一条记录中使用的是“Market Square”），这使得关于等同性的自动推理变得非常困难，即使采用很好的启发式规则也很难实现。语义建模技术，例如 RDF，可以帮助简化对不同数据集之间自动进行推理所面临的问题，这些数据集是内嵌在数据存储介质中的。对于传统的数据源来说，通常需要投入大量人力物力，进行分析和数据净化工作，然后才能将其用于语义建模技术。
mashup 开发人员可能还必须面对 IT 集成管理人员不需要面对的一些问题，其中一个问题是数据污染。作为应用程序设计的一部分，很多 mashup 都要求公共用户提供输入。wiki 应用程序领域的研究表明，这是一把双刃剑：它可能非常强大，因为可以提供开放的贡献和最佳的数据革新，但这又会导致不一致、不正确或容易产生误导的数据项。后者可能会危及数据的可信度，最终降低 mashup 带来的价值。
mashup 开发人员需要面对的另外一种集成问题是由于获取数据必须采用屏幕抓取技术而引起的。正如上一节所讨论的一样，分析和获取工具以及数据模型都需要大量与反向工程相关的工作。在最理想的情况下，可以创建这些工具和模型，但依然存在一个问题：源站点如何呈现自己的内容，这可能会破坏集成过程，并导致 mashup 应用程序出错。
组件挑战
尽管 Web 开发的 Ajax 模型可以比传统的整个页面刷新技术提供更为丰富而且更加无缝的用户体验，但是也带来了一些难题。作为基础来说，Ajax 要求将浏览器的客户端脚本功能与自己的 DOM 配合使用，实现一种内容交付方法，这完全是由浏览器设计者所设想的。（可能 Ajax 类似于黑客的特性增加了它的吸引力。）然而，这使基于 Ajax 的应用程序具有相同的浏览器兼容问题，这些问题从微软开发 Internet Explorer 以来就一直困扰着 Web 开发人员。例如，Ajax 引擎利用了一个 XMLHttpRequst 对象来与远程服务器异步交换数据。在 Internet Explorer 6 中，这个对象是使用 ActiveX 实现的，而不是使用本地 JavaScript 实现的，这要求必须启用 ActiveX。
更加基本的一个需求是 Ajax 要求必须在用户的浏览器上启用 JavaScript。这对于大部分人来说可能是一个合理的假设，但是对于某些特定的用户，他们的浏览器或自动化工具可能不支持 JavaScript，也可能没有启用对 JavaScript 的支持。这种工具有 robot、spider 和 为 Internet 和 Intranet 搜索引擎搜集信息的 Web 爬行榜。如果没有功能方面的让步，基于 Ajax 的 mashup 应用程序也可能会发现自己失去了部分用户群，搜索引擎的吸引力也会降低。
使用 JavaScript 来异步更新页面中的内容还会产生用户界面的问题。由于内容不再需要链接到浏览器地址栏中的 URL 上，用户可能无法体验到正常使用浏览器的 BACK 按钮或书签时的功能。另外，尽管 Ajax 可以通过请求增量内容更新来减少延时，但不好的设计可能会对用户体验造成负面影响，例如当更新粒度非常小时，所更新的数量和负载会占据所有的可用资源。另外，在加载界面或更新内容时，我们还需要关心如何为用户提供支持（例如，使用诸如进度条之类的可视化反馈技术）。
与任何分布式交叉领域的应用程序一样，mashup 开发人员和内容提供者同样也需要解决一些安全性问题。身份的概念可能会成为一个棘手的主题，传统 Web 主要是为匿名访问而构建的。单点登录是一种令人满意的特性，但在这方面存在多种彼此竞争的技术（从 Microsoft Passport 到 Liberty Alliance），因此可能会导致产生杂乱的身份命名空间，我们必须对之进行集成。内容供应商可能会在自己的 API 中采用身份验证和授权模式（这需要安全身份或安全确认属性的概念）来强制采用涉及付费订阅或敏感数据的业务模型。敏感数据也可能要求一定的机密性（即加密），我们必须要清楚何时将它们与其他资源集成在一起，而不会带来风险。身份对于审计和法规遵从性来说也非常重要。另外，由于数据集成是在服务器和客户端同时发生的，因此从用户到 mashup 服务进行的身份和证书委托也可能会成为一个需求。
四．社会挑战
除了上一节介绍的技术挑战之外，随着 mashup 的进一步普及，也出现了（或即将出现）一些社会问题。
mashup 开发人员需要面对的一个最严重的社会问题就是：在知识产权的保护和消费者的私密性与公用化以及信息的自由流动之间达成一种平衡。不知情的内容提供者（屏幕抓取的目标）、提供 API 来帮助数据检索的内容提供者都可能需要确定其内容是否正在被他人以未获得自己批准的方式使用。mashup Web 应用程序仍然处于萌芽阶段，只是有一些开发爱好者在业余时间编写 mashup。这些开发人员可能并没有意识到（或不关心）安全性之类的问题。另外，内容供应者也只是刚刚开始看到为基于机器的内容访问提供 API 的价值所在，而且还有很多人不认为这是一个核心业务关注点。这一切结合在一起，导致目前的软件质量低下，因为诸如测试和品质保证等工作的优先级都要低于概念验证和创新的优先级。为促进软件开发过程的成熟，社区必须作为一个整体协同工作，制定开放标准和可重用的工具包。
在 mashups 可以从一种炫酷的玩具变成程序的应用程序之前，还需要做大量的工作，形成高度健壮的标准、协议、模型和工具包。为此，主要的软件开发业界先驱、内容提供者和企业家必须认识到 mashup 的价值，它意味着可行的商业模型。API 提供者需要确定是否对自己的内容收取费用，如果需要收取费用，应该怎样收费（例如，通过订阅还是按使用次数收费）。或许他们将提供不同级别的服务品质。有些市场提供者，例如 eBay 或 Amazon，可能会发现免费 API 将提高产品周转。mashup 开发人员可能要寻求一种基于广告的创收模型，或者构建有趣的 mashup 应用程序赢得人们的认同。
结束语
mashup 的确是一种相当新颖的 Web 应用程序。源于语义 Web 领域的数据建模技术和松耦合、面向服务、与平台无关的通信协议相结合，最终将提供一种开发可充分利用并整合大量 Web 信息的应用程序所必需的基础设施。随着 mashup 应用程序越来越多地被人们所关注，了解它将对某些社会问题（例如公共使用和知识产权保护之间的问题）和其他应用程序领域（跨组织边界集成数据，例如网格计算和 B2B 的工作流管理）产生怎样影响，这一点非常有趣。
