WAMDM Technical Report (WAMDM-TR-2006-7)
Mashups—一种新型Web 应用程序
凌妍妍 （Web组）
1.引言
一种新型的基于 Web 的数据集成应用程序正在 Internet 上逐渐兴起。通常用术语mashup表示。根据Wikipedia的解释，Mashup是将多个不同的支持web api的应用进行堆叠而形成的新型web服务。这种新型的基于 Web 的数据集成应用程序正在 Internet 上逐渐兴起。它利用了从外部数据源检索到的内容来创建全新的创新服务，将来自不止一个数据源的内容进行组合，创造出更加增值的服务。Mashup所能利用的外部数据源格式多种多样，表现出惊人的兼容性，它涵盖public APIs, XML/RSS/Atom feeds, web services, HTML等。人们普遍认为Mashup具有Web 2.0的特点。Web 2.0的主要思路是在互联网上建立起大众的贡献的共享的信息平台，协作和共享是这种思想的精髓。Mashup技术也是建立在各种Web 应用程序贡献出自己的服务和内容，同时共享其他人和其他组织提供的信息和服务的基础上的，自此基础上进行组合、增值从而构造出更多更具吸引力的新的Web应用程序。随着越来越多的Web站点公开了自己的api，许多人已经和正在用eBay, Amazon, Google and Yahoos APIs构建新的Mashups，使得这种新型的Web应用模式成为了现实。这篇文章对Mashup 的分类和架构进行了深入的研究和探索，另外您还将看到
对Mashup在企业应用中引出的研究问题的一些分析。
2.Mashup分类
本节将简要介绍[2]中对出名的Mashup类型进行调查的一些成果。现今涌现的Mashup 应用大致由以下几类构成：
视频图像 Mashup——Mashup设计者利用与图像相关的元数据（例如谁拍的照片，照片的内容是什么，何时何地拍摄的等）对视频和图像资源进行关联。CelebrityV就是这样的一个应用—它将来自Flicker的明星照片和来自youtube对应的明星视频剪辑进行了匹配和组合。搜索购物 Mashup——搜索和购物 mashup 在 mashup 这个术语出现之前就已经存在很长时间了。在 Web API 出现之前，有相当多的购物工具，例如 BizRate、PriceGrabber、MySimon 和Froogle，都使用了 B2B 技术或屏幕抓取（screen scraping）的方式来累计相关的价格数据并进行比较。之后为了促进 mashup 和其他有趣的 Web 应用程序的发展，诸如 eBay 和Amazon 之类的消费网站已经为通过编程访问自己的内容而发布了自己的 API。
新闻 Mashup——新闻源（纽约时报、BBC 或路透社）已从 2002 年起使用 RSS 和 Atom 之类的联合技术来发布各个主题的新闻提要。以联合技术为基础的 mashup 可以聚集一名用户的提要，创建个性化的报纸，从而满足读者独特的兴趣。Diggdot.us 正是这样一个应用。地图 Mashup——地图Mashup蓬勃发
展的一种主要动力就是 Google 公开了自己的Google Maps API。现阶段，几乎所有包含位置数据的数据集均可利用地图通过令人惊奇的图形化方式呈现出来。Microsoft（Virtual Earth）、Yahoo（Yahoo Maps）和 AOL（MapQuest）也不甘示弱，很快相继公开了自己的 API。
3.Mashup架构
此架构[3]非常简单。来自客户机浏览器的请求传向 Mashup站点所在的Apache Web 服
务器。请求的页面包括 HTML 和 JavaScript。JavaScript 调用一个或多个API内容提供者提供的服务后，按照该Mashup的逻辑进行内容组合。举一个Mashup的例子，用户向Mashup 站点提交房屋的所在地点和房价查询是否高于当地平均水平，一个请求就传向一个与后台房屋信息数据库连接的 Web 服务器，同时调用Google Maps API提供的服务，执行Mashup 逻辑并将组合的内容在客户机端浏览器中显示。一般来说，Mashup服务主要涉及3方面的内容：Mashup站点，API内容提供者以及客户机的Web浏览器。
图1：Mashup架构
3.1Mashup站点
一个Mashup应用可能需要将来自多个数据源的信息进行合并组合，构造新的服务，因而这里所说的Mashup站点也就是Mashup逻辑所在的地方。尽管Mashup这类新型的Web 应用程序可以采用以往的Web服务器技术（Java servlets、CGI、PHP 或 ASP）构造传统Web应用程序，我们却发现越来越多的API开始设计成通过浏览器端的 JavaScript 进行访问。于是对于Mashup的执行来说，合并内容也可以直接在客户机的浏览器中通过客户机端脚本（即 JavaScript）或 applet 生成。我们将Mashup 使用的这种
方法称为胖 Internet 应用程序（简称RIA）。
在客户机端进行Mashup应用中的内容合并，其优点可以概括如下：首先，从Mashup 服务器的角度来说，对服务器的所产生的负载较轻（数据可以直接从内容提供者那里传送过来）；其次，从用户的角度来说，具有更好无缝用户体验（页面可以请求对内容的一部分进行更新，而不用刷新整个页面），当然这样的功能得益于Ajax这样的Web应用模型的诞生。
3.2API内容提供者
他们提供的内容为Mashup应用程序所用。为了方便外界获取和使用，他们将自己的内容通过 Web 协议对外提供（例如 REST、Web 服务和 RSS/Atom）。按照其通常的功能和使用，Web协议可以分为两组。第一组处理消息传递、接口描述、寻址和交付的问题。最有名的是消息传递协议，称为简单对象访问协议（Simple Object Access Protocol，SOAP）。此协议对消息进行了编码，这样就可以通过传输协议（如 HTTP、IIOP、SMTP 或其他协议）在网络上传递它们。下一组协议和规范定义了服务如何公开它们自己以及如何在网络上相互发现。对于要相互查的服务，统一描述、发现和集成（Universal Description, Discovery and Integration，UDDI）为查和访问服务定义了注册中心和相关的协议。当然，Web上还存在着很多有趣的潜在数据源可能并没有方便地对外提供 API，Mashup应用如果想用到这些信息，可以通过前面我们提到的屏幕抓取的技术实现，通过对特定页面进行分析，提取Mashup 感兴趣的信息。
4.企业级Mashup及引出的研究问题
Mashup技术并非只会提供消费者网站使用的、加了注释的地图，这项技术具有真正的企业应用前景。Mashup这样轻量级的集成在企业中有着很多的先例：从历史悠久的股票报价系统，到将UPS或FedEx等快递公司的跟踪数据与订单记录组合起来，提供订单状态单一视图的电子商务网站等等。IBM等门户服务器厂商提供了诸如StrikeIron之类的图形化操作工具，帮助用户集成来自不同地方的数据源，实现简单、个性化的Web应用。
一方面，企业必须将许多原本并不能很好彼此共存的管理系统和应用程序拼凑到一起。DBMS、内容管理系统、数据挖掘包和工作流系统都可以购买，但该公司必须自行开发集成软件以集成它们。每当增加了新的数据源或信息必须流转到新的目标时，就必须扩展客户自制的解决方案。因此，企业需要一个提供所有这些服务的统一视图的健壮平台，这样的平台应该突破存在于 DBMS、内容管理系统、中间层高速缓存和数据仓库之间的界限。另一方面，[4]中指出即时应用的出现使得利用企业信息架构之外的信息成为新的需求(，报告和文档，网页，电子表格，决策支持数据等等)。这样的即时应用对效率和易用性都提出了新的要求，因此在企业级Mashup应用中出现了用“assembly”来代替“programming”的思想。
图2：构造Mashup的过程
首先来看一个企业即时应用的实例（例1）—一佛罗里达州的一名保险经纪看见了一则美国风暴灾害的新闻报道，公司要求他递交一份最新灾害损失分析报告，对这场风暴给公司带来的损失进行评估。如图2所示，该名保险经纪为了完成这份受灾情况分析报告，他首先需要将电子表格里客户的ZipCode通过网
站v转化为水文学上的一种编码，然后利用网站v将水文学编码转化为经纬度的表示，最终从网站v上通过经纬度定位当地的受灾情况。当然，如果Web上已经存在了这样的一个Mashup应用www.floodlevels合并了来自上述三个网站的内容和服务，即直接提供了从ZipCode查询受灾情况的功能。那么如此现存可利用的资源更应该得到有效发掘和运用。
下面我们将从构造企业级Mashup应用的四个方面分别讨论存在的研究问题。
z资源发掘
构造企业级Mashup应用并不一定是从零做起，Web上存在着许多对处理企业即时应用有效的资源和服务。比如，例1中提到的网站www.floodlevels就是一个现存的可满足从ZipCode查询受灾情况的Mashup站点，它隐藏在Web信息海洋中。可想而知，利用现存可利用的Mashup作为构建企业解决方案的基础，在效率和有效性上都会带来质的飞跃，也大大省去了Mashup应用重复开发带来的资源浪费。
于是一种新形式的搜索引擎正在酝酿。这种搜索引擎试图通过使用者键入简单的查询，来发掘Web中所有与该查询相关的Mashup资源。如使用者期望通过查询“Flood Levels”来到这样的一个Mashup资源www.floodlevels为我所有。Mashup资源发掘的问题和Deep Web研究领域中特定类别数据源的发现问题有异曲同工之处。相关资源的发掘需要解决两方面的问题，一是对资源特性的描述，而是资源与用户需求的匹配程度。Deep Web数据源的特点相对来说比较明确，我们可以从接口的复杂性，结果的
结构化等来对Deep Web 数据源进行定义并分析该数据源的类别和接口形式。但是对于Mashup数据源来说，最大的困难是如何让搜索引擎理解Mashup的逻辑，从而推断与用户需求的匹配程度。
z需求表达
构造企业级Mashup应用的第二阶段是用户的需求表达，这主要包括两方面的含义：
首先，如果在资源发掘阶段能够到现存的可直接利用的Mashup很好地解决用户的需求，那么用户可以在此基础上进行上层应用的构建。比如一旦Mashup资源www.floodlevels 得以发掘，那么剩下的只需要在客户资料（电子表格数据源）和该Mashup之上构建异质数据源集成的解决方案。另一方面，如果在资源发掘阶段无法到或者实际并不存在可直接利用的Mashup，那么用户只有考虑从现有的资源出发，着手从最底层开始构思多个异质数据源之间的Mashup逻辑，表达自己的需求。
z应用构建
合理的Mashup逻辑从构思到实现，一个最基本的问题就是如何在一个用户友好的环境下，实现各个逻辑模块的组装（代替传统的编程）。于是，良好应用平台的构建是当务之急。首先必须考虑到对于Mashup企业级应用来说，它的使用者是最普通的用户。这样的用户既不是一个Java script专家，也不懂PHP/Java/Ruby这些编程语言。其次，我们还必须考虑到即使用户在资源发掘阶段能够到了一个现存
webservice实现
可利用的Mashup应用，但是如果该站点对外不提供API，那么这种情况甚至还要求用户自己构建屏幕抓取程序来处理该站点，这是不现实的。也就是说，广大最普通的需求者亟需一个良好的平台去构建自己的应用。
[4]中对如何方便构建Mashup进行了一些基本分析。如图3所示，构建Mashup最直接的方法是用编程语言自己动手编写一些过程性的代码（Procedure Code），这种方法对使用者技术要求很高，哪怕一个细小的读取操作都要由使用者自己来指定实现细节。第二种方法是采用类似于XQuery的声明性查询语言（Declarative Queries），这种方法实现起来更为简单，至少使用者只需要遵守查询语言的格式，指明操作步骤，而不用关心每一个细节的具体实现；然而对于广大最普通的需求者来说，我们不能做出他们熟悉计算机语言的假设。实际生活中，往往图形化的开发平台才是最能虏获人心的。
由此看出，构建Mashup应用所需要的平台应该至少应具有如下两个特点：容易使用，表达力强。实际中的Mashup应用可能涉及到的数据源种类繁多，形态各异，涵盖public APIs, XML/RSS/Atom feeds, web services, HTML等等，因此如何搭建一个能很好处理多种格式异
质数据源的平台是极其具有挑战性的。
图3：构建自己的Mashup
有的读者可能会问，帮助广大最普通的用户实现这种企业的即时应用是否还有更简单的方式呢？最理想的方式是，当用户在类似搜索引擎的环境下以自然语言的方式表达自己的整个需求，整个Mashup能够自动构建，就像搜索引擎一样直接将结果返回给用户，无须用户参与中间过程的构建。比如，例1中保险经纪通过搜索“flood levels for zipcodes 33101, 34106, etc.”而直接获得答案。这种智能化的人机交互方式首先需要自动发现和用户查询内容相关的，能帮助回答查询的若干资源（如图2中的若干网站）；并且要在理解这些资源的逻辑的基础上，在资源间进行类似join的Mashup操作。[1]在处理Deep Web数据集成的过程中，自动选择合适的相关数据源进行查询，并通过数据源查询能力的组合来回答用户提出的查
询。例如，在左图所示
的5个数据源上，用户
想查1992年之后生
产的运动车型的价格
和评论。那么首先可以
排除Source 3和
Source 4，因为这两个
数据源不提供与用户
查询相关的内容；其次
我们需要组合Source
1，Source 2，Source 5的内容。Source 1或者Source 2的输出与Source 5的输入在model和year字段上
是可以做连接的，从而通过不同Deep Web数据源的横向连接，形成能帮助用户回答查询的统一视图。在这篇文章中，处理的对象相对来说比较单一，即Deep Web网站，而且假定对每个网站的查询能力都事先进行了分析，定义了明确的输入输出接口。然而，在Mashup应用程序中，我们面临的任务更加艰巨，如何理解各个类型数据源的处理能力，接口以及提供服务的范围成为了新的研究课题。
z语义和非结构化
在解决Mashup数据集成的问题里，语义（Semantic）和对非结构化数据（Unstructured data）的处理是两大难题。语义方面举一个最简单的例子，在自己储存的一份客户资料里，客户的名字可能使用自己熟知的一些昵称或简称代替的，当某个Mashup应用需要处理到这

版权声明：本站内容均来自互联网，仅供演示用，请勿用于商业和其他非法用途。如果侵犯了您的权益请与我们联系QQ:729038198，我们将在24小时内删除。