MashUp是什么.docx
《MashUp是什么.docx》由会员分享，可在线阅读，更多相关《MashUp是什么.docx（13页珍藏版）》请在冰点文库上搜索。
MashUp是什么
一种新型的基于Web的数据集成应用程序
Mashup是将多个不同的支持webapi的应用进行堆叠而形成的新型web服务。
这种新型的基于Web的数据集成应用程序正在Internet上逐渐兴起。
它利用了从外部数据源检索到的内容来创建全新的创新服务，将来自不止一个数据源的内容进行组合，创造出更加增值的服务。
Mashup及其典型应用
从上面的案例中，可以总结出Mashup的含义就是"糅合"、"聚合"。
Mashup这个单词来源于音乐，将两首不同歌曲（通常是不同的音乐类型）的声乐或者器乐混合在一起，形成一首新的歌曲，就是Mashup。
在Web开发中，Mashup就是将两种或两种以上的数据或者服务融合在一起，形成一种新的应用。
通过对开发的API的二次开发，Mashup能够快速简易地开发出的新的应用，是源数据/服务提供者想不到的，好比本章开头的案例，天气服务的开发者没有想到天气服务开发出的API会被整合进春运地图并且发挥了巨大的作用。
对Web2.0应用的"糅合"，Mashup成为了闪亮的智慧2.0。
Mashup不需要特别高的Web开发能力，也不需要非常强的架构能力，只要熟悉Web服务的API应用以及Web应用的工作方式，即可进行Mashup的开发。
很多的网络服务提供商都提供了自己的API及相应的使用方法，相信读者阅读并理解第4章后，都有能力开发出自己的Mashup应用来。
Mashup的概念很简单，但是迸发出来的力量却不简单。
IBM的这篇文章详细地解读了Mashup（）。
Mashup的典型应用主要包括以下几种。
地图Mashup。
公交、地铁、自驾、旅游都需要地图，网络电子地图极大地方便了人们的出行。
GoogleMapsAPI的开放推动了电子地图mashup应用的发展，比如公交公司将线路、站台信息与城市交通图结合起来，人们便可以方便地查询公交线路。
视频图像Mashup。
宽带的普及使得图片共享与视频共享在互联网上迅速地推广开来，Mashup的开发者们可以将这些照片、视频与其他数据整合在一起。
比如通过图片显示用户的社交网络图，或者将旅游时拍摄的照片视频与地理信息整合起来。
搜索与购物Mashup。
搜索与购物的Mashup应用在这个词出现之前就有了，现在的B2C网站，比如eBay和亚马逊，都纷纷开放了自己的API，Mashup开发者可以利用eBay或者亚马逊的数据库信息，开发出增值应用，并最终使商业进程一体化。
例如，当前eBay的40%的商品是从以eBay的第三方应用中上传的。
新闻Mashup。
很多新闻内容提供商较早的就提供了RSS或者Atom的新闻聚合服务。
Mashup开发者可以方便地将不同的新闻RSS或Atom与其他的数据源整合。
比如本章的春运地图的例子，各地的天气新闻、交通新闻与电子地图有机的结合了起来，方便了读者按需获取想要的信息。
Mashup的历史
Mashups是最近几年才开始流行的，借助Web2.0的动力在全球迅速传播开来。
早期Mashup从Craigslist（）等数据源获取数据，并使用绘图服务或photo服务将其组合起来，以创建数据的可视化形式（例如，）。
这些早期Mashup中许多都是专注于客户的，最近才开始引起了企业的兴趣并获得认同。
组织开始认识到，他们可以将定义明确的执行独立业务逻辑片断的服务与其他现有服务（无论是组织内部还是组织外部的服务）一起，以提供有趣的全新数据视图。
随着用于创建Mashup技术的成熟，我们看到企业开始以Mashup为基础创建业务模型。
在美国的不动产市场，Redfin（.com）和Zillow（）都使用大量公共和私人不动产数据（来自州县记录办公室和MLS数据库等数据源），经过内部“增值”服务加工后，最终结果显示在一张地图上（分别使用Microsoft的VirtualEarth和GoogleMaps）。
有许多可能的信息类型可以添加到不动产站点；有关本地学校、本地医院、近期犯罪率、工作招聘明细的其他类似列表、信息等。
原型化Mashup的架构
对于许多Mashup，尽管用户界面和数据源有很大不同，但我们仍然可以建立它们都能共享的通用架构模式。
例如，所有Mashup实质都是“REST的”（它们符合代表性状态传输（RepresentationalStateTransfer）准则）。
图1展示了一个典型Mashup的架构透视图。
图1：
典型Mashup应用程序的架构（单击图片查看大图）
数据
任何Mashup的核心元素都是将数据集中起来展示给用户。
虽然上图中将数据源描述为数据库，但Mashup的概念并不要求数据库对于Mashup软件或客户端而言是本地的。
数据可以完全来自Web服务，其中数据序列化为XML或JSON格式（这是基于Internet的Mashup中最通用的模式）。
对于在本地数据存储库中存储基本数据并通过每个请求访问数据的情况，也可以视为Mashup。
随着Mashup从基于Internet的应用程序向企业内部转移，它们对外部数据存储库的依赖正在降低。
RSSfeeds
RSS（ReallySimpleSyndication）feeds的用途是Mashup的基本或辅助数据的公共源。
RSSfeeds易于使用，因为它们是XML文档，许多库都可以操纵feeds。
RSS的格式和规范描述详细易于理解，各版本之间只有细微的差异。
RSS的扩展性也已众所周知，目前使用的扩展数量证明了这一点，如向feeds添加附件、创造性通用许可信息和位置信息。
Web服务
Mashup中包含对Web服务的调用也是很常见的。
基于WSDL的Web服务和基于REST的Web服务都很常见，某些服务兼具这两种类型。
Web服务可以用于提供额外数据或用于转化组合的数据。
对于基于地图的Mashup，数据可能只包含街道地址和电话，可能需要调用基于WSDL或REST的Web服务将街道地址转换为地图的经度/纬度坐标。
平台服务
图2描述用于创建Mashup的一类特殊服务。
我们调用这些平台服务，因为它们除了提供传统Web服务典型的请求/响应模型之外，还提供了其他功能。
一个典型示例是VirtualEarth提供的绘图服务。
VirtualEarth包含整个一系列服务端和客户端处理功能，以及“Cloud服务”。
我们看到出现了开始创造价值的基于cloud的构建块服务。
例如，AmazonS3服务提供cloud存储；这使它能够通过将数据上传给托管存储供应商，从而能够更容易地展示任何静态数据。
Microsoft的BizTalkServices是一种平台服务，可提供另一种功能，即从Internet跨企业防火墙中继通信的能力，从而提供内部服务，供构建企业Mashup的业务合作伙伴或第三方使用。
BizTalkServices提供的中继通信在具有很多业务部门或大量网段的企业内部也很有用。
基于Internet的通信中继可以消除成为通信障碍的物理网络拓扑。
图2：
使用BizTalkServices作为平台服务来中继信息（单击图片查看大图）
Mashup应用程序
到目前为止，我们已识别了可用于创建Mashup的许多服务类型，但并未强调创建和交付Mashup体验的软件的重要性。
可Mashup应用程序视为中间层服务和某些轻量级业务逻辑的一种组合。
对于基于Internet的Mashup，其软件通常采用Web技术（如PHP或ASP.NET）编写，但我们看到，随着富互联网应用程序（RichInternetApplication，RIA）的出现，服务器进程和客户端应用程序之间的界线开始模糊了。
RIA是在浏览器中运行的应用程序，具有类似于许多桌面应用程序的丰富功能。
这些应用程序除了需要安装一些普通插件（如AdobeFlash或MicrosoftSilverlight）之外，通常不需要进行客户端安装。
客户端应用程序
客户端应用程序用于将Mashup交付和展示给用户。
对于公共InternetMashup，最通用的客户端应用程序是Web浏览器，它通过HTTP接收从Web服务器交付的HTML和JavaScript文件。
但是，我们看到Mashup也开始使用RIA平台交付了。
在该模型中，客户端可以提供更丰富的可视化内容，甚至可以提供客户端的某些Mashup进程。
Mashup的未来趋势
各种早期版本的Mashup许多都非常单调乏味并且耗费时间。
其中许多采用客户端进程（通常使用PHP或PERL）和乏味的客户端JavaScript脚本来创建Mashup体验。
一种常见的现象是，人们创建Mashup来建立自定义代码，以解析他们从其数据源收到的XML返回集。
随着时间的推移，开发过程日趋成熟，许多乏味的编码工作已经被框架和更好的标准规范所替代。
服务器端的自定义脚本开始被标准库替代，标准库可以自动生成所需的客户端脚本。
我们也看到了消息格式的标准化。
它的一个示例是RSS标准的GeoRSS扩展，利用该扩展，您可以指定所提供项目的经度和纬度。
三家大的绘图服务供应商（Google、Microsoft和Yahoo）都支持GeoRSS，这意味着使用该RSS扩展的Mashup几乎不需要编码。
创建Mashup以前只是开发人员干的活，现在最终客户也具备了直接创建Mashup的能力。
随着创建Mashup的框架越来越易于使用，消息格式越来越标准化，下一个合乎逻辑的步骤是构建可以创建Mashup的工具。
其中某些工具将专门针对Mashup的最终客户设计。
Yahoo的Pipes和Microsoft的Popfly是此类框架和工具的两个示例，利用它们，用户可以创建自己的Mashup。
通用模式和元数据在Mashup开发中的重要性正在提高。
上一节我们描述了RSSfeeds的通用模式是如何轻松地将它们合并到Mashup中的。
其他类型的数据也适用于该原则（由于RSS的稳定性，我们不能将所有数据都建模成该格式）。
我们已经看到出现了描述geospatial数据的KML（KeyholeMarkupLanguage）等其他标准模式。
更令人感兴趣的是Microformats，它能够交付软件（如Mashup）容易阅读的语义，是一种很有前途的框架。
企业中的Mashup
探讨企业Mashup的一种绝好方式是使用示例。
假设您是呼叫中心系统的一位程序架构师，该系统接收担保和部件服务的呼叫请求。
使用呼叫者的电话号码，我们可以显示该用户的纪录，包括购买历史。
这种有趣的应用程序如今在大多数呼叫中心已经实现。
但是，除了查看客户信息之外，如果我们使用公开发布的服务在地图上标注电话号码，并且还为覆盖在地图上的产品显示一份本地服务中心或部件供应商列表，那会是什么情况呢？
有了这样的数据，我们就可以在很短时间内回答客户提出的问题。
如果我们还可以查看该地区的当前天气状况或当地运动队和他们的最新赛事，作为长时间电话交谈的话引子或谈资，那又会是什么情况呢？
图3使用此示例展示了业务代表在接听电话时可以使用的模拟客户服务Mashup。
通过将公共服务（如天气和新闻）数据与内部数据源（客户服务提示博客和服务位置数据库）相组合，该应用程序将Mashup元素与门户网站的可访问性结合起来。
图3：
我们呼叫中心的示例Mashup（单击图片查看大图）
如图3所示，嵌入式Mashup将海量的备用信息呈现在呼叫服务代理面前，包括优质服务项目——因此他们可以快速回答问题，以及反查电话号码——以获取谈资。
这种Mashup类型完全是内部的，但为客户端的首次呼叫提供了巨大价值。
要使此Mashup成功有几个关键要素。
首先，它是围绕手头任务为上下文展开的，这也是最重要的。
其次，它按照最可能有用的次序排列信息。
您必须了解正在与谁交谈，他们注册了什么产品，哪些优质服务项目适用于这些产品，然后开始尝试回答他们可能提出的问题，如客户所在地的本地服务中心位置。
第三，一旦我们获得了客户信息和所在地，则每个内容窗格都是独立的，不需要与其他部分交互。
这样就可以同时收集和集合每个部分的数据。
了解投资回报（ROI）是面向服务架构（Service-OrientedArchitecture，SOA）部署的共同关注点。
许多组织发现，当创建应用程序变得容易时，很难判断对创建能提供不同功能的服务的预先投资是否还能获得回报。
对于SOA中的投资如何提供巨大价值，企业Mashup是一个很好示例。
（请参阅参考文章《MashupsdeliverROIforIDVSolutions》。
）
利用自己构建的服务
当组织将这些服务混合和协调起来时，对SOA的投资就能获得直接回报。
当开始采用事先没有想到的方式利用服务或应用程序时，这种感觉好极了。
（请参阅参考文章《QuickenLoansleveragesmashupsforfastresults》。
）
利用他人构建的服务
认识到自己不可能拥有世界上一切知识这一点很重要；您简单地利用一下其他人的辛苦劳动，不必事必躬亲，也可以获得相当高的投资回报。
构建他人可利用的服务
随着Mashup越来越流行，企业又获得了一次发展机会，即构建Mashup应用程序容易使用的服务。
回到我们引用过的示例，如果客户服务代表为客户提供邻近的商店位置，客户会为此感到高兴。
但想象一下，那样商店会将其库存和产品供应能力公布给Mashup。
现在，服务代表就能在电话中向客户提供更为详细和有价值的信息。
这种服务对于客户、呼叫中心和商店自身都是有价值的。
平台敏捷
正如之前所讨论的，为在基于标准的Web平台（HTML和JavaScript）上进行交付而创建了许多Mashup。
这对于Mashup本身没有限制，仅仅限制了Internet上交付应用程序的标准方法。
正如我们看到Mashup进入了企业，我们将看到构建在RIA平台（如Adobe的Flash和Microsoft的Silverlight）之上的Mashup会越来越多，甚至会出现构建在WindowsPresentationFoundation之上的完全富桌面Mashup。
富客户端平台上的完全三维显示可以提高Mashup的可视化要求。
企业Mashup可以利用这些功能更丰富的平台，许多平台将有更好的桌面控制能力。
图4：
QuickenLoans利用Mashup来加快进度（单击图片查看大图）
快速转向
如果您正在使用现有Web服务和稳定的平台服务，则可以以小时或天而不是以周或月来计算Mashup的开发时间。
Mashup的快速转向时间可以改变组织中IT部门与用户的交互方式。
短时间内交付的应用程序的联合开发和多重迭代将变得更加符合实际情况。
数据对于用户的丰富可视性
从Mashup得到的最大受益是它们可以为用户创建可视性。
可视的数据更易于理解，并且对客户来说更有意义。
这不仅仅局限于目前为止我们讨论过的绘图示例。
其他技术（如热图和树状图）也可以创建为Mashup中的数据可视化表现形式。
关键成功因素
寻找要消费的实用主义服务（从简到繁）。
某种服务越能做更多事情，其他服务越难参与进来。
好的服务就是要把事情做好，哪怕只做一件事。
例如，某种服务返回给用户的数据有他们的地址、贷款、汽车、火车和飞机，提供的数据可能太多了。
您可能希望创建一个子集服务，只返回要组合的名称和地址，这样不会浪费带宽也不用处理不用的数据。
保持Mashup为只读
Mashup是所显示的数据中的敏捷视图。
它们不是一个全能的编辑面，不能编辑抛给它们的任意数据。
如果有人想编辑数据，他们应该返回到创建该数据的应用程序来进行编辑。
这种编辑机制也应该明确起来。
这将极大地减少Mashup应用程序的复杂性（并提高敏捷性）。
数据刷新问题
企业将基于企业Mashup做出决策。
根据多个源提取的数据做出决策是危险的，因为数据可能已经过时。
与做出决策所依据的任何报告一样，数据最后一次刷新时加上时间戳非常重要。
这会极大地提高组合后数据的清晰性和有效性，并提高制订决策的信心。
不要尝试解决企业数据问题
随着Mashup进入企业，您会不可避免地遇到数据碎裂和规范化问题，这是多年的遗留应用程序部署所导致的。
例如，地理区域的Mashup销售看起来就像是为销售经理创建的逻辑Mashup。
但是，如果数据被产品线存储在三种不同的系统中，每种系统都有不同的数据结构和业务规则管理它们，那会是什么情况呢？
我们建议为Mashup技术找出更好的候选办法，让更传统的项目（如系统合并工作）解决更复杂的问题。
了解身份验证和授权问题
如果几个服务都需要使用不同的模式执行身份验证，那么身份验证和授权可能会给这些服务的Mashup操作造成很大的障碍。
例如，如果一个服务需要用户名和密码，而另一个服务需要X509证书，则可能会出现问题。
这并不是无法解决的，但可能成为必须克服的巨大障碍。
有几个策略可以解决此问题。
您可以避免使用需要进行身份验证的服务，或者需要通过不受支持的方法进行身份验证的服务。
尽管某些情况下可以这样做，但有时的事实情况是，不进行身份验证，您需要使用的服务就无法获取。
您可以尝试强制执行其他服务或者向其支付费用，以提供适用于您的身份验证类型。
但是，事实上应用程序很有可能必须使用许多不同的机制来支持服务身份验证，这些机制都应该列入考虑范围。
风险
在实现Mashup时，应考虑四个方面的风险：
对服务的依赖性
创建企业Mashup时的主要风险之一是建立对企业外部服务的依赖性（如cloud服务）。
在建立依赖性之前，应先调查清楚服务协议中的条款。
例如，某些服务要求使用服务的软件是面向公众的Internet站点，当服务具有基于广告的盈利模式时可能出现这种情况。
服务条款在某些情况下也可能常会更改，这对您使用该服务可能造成损害。
要减轻这种顾虑，请寻找能提供适于您使用的模型的服务供应商。
数据保真度缺失
显示的数据中保真度的缺失是另一个主要风险。
随着数据可视化，出现了一种使数据匹配于显示面边界的趋势。
为了在显示面上节省空间，很自然地会对少部分数据不进行可视化，或者将数据组合成更大的集合。
这可能会“歪曲”最终用户的数据视图。
图5：
Mashup交付IDV解决方案的ROI（单击图片查看大图）
策略
创建Mashup时策略也可能成为障碍。
如果您没有创建服务，那么您可能会对该服务进行完善，让该服务的创作者根据您的需要更改服务将会非常费时费力。
这种“非我发明”（Not-Invented-Here，NIH）心理对于Mashup是致命的。
这也表明Mashup本身是受到信任的。
如果您不信任服务的供应商，那么就不会在任务关键型应用程序中依赖该服务。
无节制的消费
客户技术在企业内部的使用正日益增长，但很少有人去了解或管理组织IT，据Gartner,Inc.最新报告，面向客户的工具只是关注Mashup的创建和可视化，因此创建初始Mashup非常容易，但却不注意Mashup的长期维护。
还要考虑最终用户将企业数据加载到公共Mashup工具（如Pipes或Popfly）时，会出现什么危险。
有几种方法可以降低这些风险。
首先，对于内部和外部服务，应在服务等级协议（SLA）中清楚描述双方责任、更改请求的响应时间、正常运行时间要求、带宽限制和所有其他相关细节。
其次，当调用特定服务出现问题时，应在应用程序中列出可能的返回要求。
对于某些服务，不显示数据可能也能接受；对于其他服务，您可以缓存数据，以便在出现问题时可以在任何时间返回。
您可能需要二次服务，该服务在出现严重错误时用作呼叫备份。
最后，还需要解决消费化问题和制定策略。
与提高服务可靠性和增加服务冗余不同，这需要一种管理方法。
如果您的组织具有成熟的管理服务使用的方法，那么您也应将该方法用于Mashup创建和消费。
结束语
McKinsey在2007年1月作过一次调查，询问了企业客户有关他们采用Web2.0技术的情况。
可以预见，他们中有许多人都已投资或计划投资一种或多种Web2.0技术。
调查中令人惊讶的是，只有21%的受访者在使用或考虑使用Mashup，大部分受访者（54%）根本没有考虑过它的使用问题。
我们认为，相对于调查中列出的其他技术（如Web服务、podcasts和RSSfeeds），Mashup技术比较新颖，因此对企业Mashup的反响比较低。
构建Mashup的工具才刚开始出现，这也是一个因素（在我们撰写此文时，文中提及的这些工具有许多都还处于beta和alpha阶段）。
我们确信技术会越来越普及，工具也会成熟起来。
Internet服务总线（第2页）这些概念会使得这些企业Mashup的构建更为容易和有用。
我们认为Mashup应在企业中占有一席之地，我们鼓励您研究它们的实际应用。
参考资料
l“ConsumerizationGainsMomentum:
TheITCivilWar,”GartnerSpecialReport,2007（摘要）consumerization.jsp
l“HowBusinessesareUsingWeb2.0:
AMcKinseyGlobalSurvey,”McKinseyQuarterly，2007年8月
lMashup（Web应用程序混合），Wikipediac:
\iknow\docshare\data\cur_work\（web_application_hybrid）
lRedfin
l“Web2.0intheEnterprise,”MichaelPlatt,TheArchitectureJournal,Journal12
lZillow
关于作者
LarryClarkin是Microsoft的一名架构导师。
Larry在设计和构造应用程序方面从业时间超过15年，曾在多种技术和行业中任职。
他专攻Web技术与Legacy和ERP系统的集成已经超过10年时间。
当不用与客户打交道时，Larry便在当地UserGroups谈论技术。
您可以通过其博客网站与Larry取得联系，网址。
JoshHolmes是Microsoft的一位架构导师。
在上个十月份加入Microsoft之前，Josh还是一名咨询人员，为包括大型的财富500强企业和各种小型企业在内的客户提供服务。
Josh是国内和国际软件开发会议的领导小组成员和常邀演说家，他关注新兴技术、软件设计和开发，研究重点是移动性和RIA（富互联网应用程序，RichInternetApplications）。
Josh曾是CodeMash大会组织委员会成员，他专注于社区建设，创建和/或经营着许多技术组织，范围从GreatLakesArea.NETUsersGroup到AnnArborComputerSociety。
您可以通过其博客网站与Josh取得联系，网址。
升级会员 