企业级 Mashup
摘要：Mashup是用于构建应用程序的一种技术，它将多个源的数据组合起来，提供了一种集成体验。Internet的站点上运行着许多目前开发的Mashup，这些Mashup以可视化形式提供公开发表的数据。本文描述Mashup的历史和架构，并探讨如何创建供企业使用的Mashup。我们还将提供一些从项目中获取的经验，这些经验来自曾经为企业实现Mashup的客户和系统集成商。
目录 Mashup的历史
Mashup的历史 Mashups是最近几年才开始流行的，借助Web 2.0的动力在全球迅速传播开来。早期Mashup从Craigslist (http://www.craigslist.org)等数据源获取数据，并使用绘图服务或photo服务将其组合起来，以创建数据的可视化形式（例如，http://housingmaps.com）。这些早期Mashup中许多都是专注于客户的，最近才开始引起了企业的兴趣并获得认同。组织开始认识到，他们可以将定义明确的执行独立业务逻辑片断的服务与其他现有服务（无论是组织内部还是组织外部的服务）一起，以提供有趣的全新数据视图。 随着用于创建Mashup技术的成熟，我们看到企业开始以Mashup为基础创建业务模型。在美国的不动产市场，Redfin (http://www.redfin. com)和Zillow (http://www.zillow.com)都使用大量公共和私人不动产数据（来自州县记录办公室和MLS数据库等数据源），经过内部“增值”服务加工后，最终结果显示在一张地图上（分别使用Microsoft的Virtual Earth和Google Maps）。有许多可能的信息类型可以添加到不动产站点；有关本地学校、本地医院、近期犯罪率、工作招聘明细的其他类似列表、信息等。
原型化Mashup的架构 对于许多Mashup，尽管用户界面和数据源有很大不同，但我们仍然可以建立它们都能共享的通用架构模式。例如，所有Mashup实质都是“REST的”（它们符合代表性状态传输（Representational State Transfer）准则）。图1展示了一个典型Mashup的架构透视图。 
图1：典型Mashup应用程序的架构（单击图片查看大图）
数据 任何Mashup的核心元素都是将数据集中起来展示给用户。虽然上图中将数据源描述为数据库，但Mashup的概念并不要求数据库对于Mashup软件或客户端而言是本地的。数据可以完全来自Web服务，其中数据序列化为XML或JSON格式（这是基于Internet的Mashup中最通用的模式）。对于在本地数据存储库中存储基本数据并通过每个请求访问数据的情况，也可以视为Mashup。随着Mashup从基于Internet的应用程序向企业内部转移，它们对外部数据存储库的依赖正在降低。 RSS feeds RSS (Really Simple Syndication) feeds的用途是Mashup的基本或辅助数据的公共源。RSS feeds易于使用，因为它们是XML文档，许多库都可以操纵feeds。RSS的格式和规范描述详细易于理解，各版本之间只有细微的差异。RSS的扩展性也已众所周知，目前使用的扩展数量证明了这一点，如向feeds添加附件、创造性通用许可信息和位置信息。
Web服务 Mashup中包含对Web服务的调用也是很常见的。基于WSDL的Web服务和基于REST的Web服务都很常见，某些服务兼具这两种类型。Web服务可以用于提供额外数据或用于转化组合的数据。对于基于地图的Mashup，数据可能只包含街道地址和电话，可能需要调用基于WSDL或REST的Web服务将街道地址转换为地图的经度/纬度坐标。
平台服务 图2描述用于创建Mashup的一类特殊服务。我们调用这些平台服务，因为它们除了提供传统Web服务典型的请求/响应模型之外，还提供了其他功能。一个典型示例是Virtual Earth提供的绘图服务。Virtual Earth包含整个一系列服务端和客户端处理功能，以及“Cloud服务”。我们看到出现了开始创造价值的基于cloud的构建块服务。例如，Amazon S3服务提供cloud存储；这使它能够通过将数据上传给托管存储供应商，从而能够更容易地展示任何静态数据。Microsoft的BizTalk Services是一种平台服务，可提供另一种功能，即从Internet跨企业防火墙中继通信的能力，从而提供内部服务，供构建企业Mashup的业务合作伙伴或第三方使用。BizTalk Services提供的中继通信在具有很多业务部门或大量网段的企业内部也很有用。基于Internet的通信中继可以消除成为通信障碍的物理网络拓扑。 
图2：使用BizTalk Services作为平台服务来中继信息（单击图片查看大图）
Mashup应用程序 到目前为止，我们已识别了可用于创建Mashup的许多服务类型，但并未强调创建和交付Mashup体验的软件的重要性。可Mashup应用程序视为中间层服务和某些轻量级业务逻辑的一种组合。对于基于Internet的Mashup，其软件通常采用Web技术（如PHP或ASP.NET）编写，但我们看到，随着富互联网应用程序（Rich Internet Application，RIA）的出现，服务器进程和客户端应用程序之间的界线开始模糊了。RIA是在浏览器中运行的应用程序，具有类似于许多桌面应用程序的丰富功能。这些应用程序除了需要安装一些普通插件（如Adobe Flash或Microsoft Silverlight）之外，通常不需要进行客户端安装。
客户端应用程序 客户端应用程序用于将Mashup交付和展示给用户。对于公共Internet Mashup，最通用的客户端应用程序是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开发中的重要性正在提高。上一节我们描述了RSS feeds的通用模式是如何轻松地将它们合并到Mashup中的。其他类型的数据也适用于该原则（由于RSS的稳定性，我们不能将所有数据都建模成该格式）。我们已经看到出现了描述geospatial数据的KML (Keyhole Markup Language)等其他标准模式。更令人感兴趣的是Microformats，它能够交付软件（如Mashup）容易阅读的语义，是一种很有前途的框架。
企业中的Mashup 探讨企业Mashup的一种绝好方式是使用示例。假设您是呼叫中心系统的一位程序架构师，该系统接收担保和部件服务的呼叫请求。使用呼叫者的电话号码，我们可以显示该用户的纪录，包括购买历史。这种有趣的应用程序如今在大多数呼叫中心已经实现。但是，除了查看客户信息之外，如果我们使用公开发布的服务在地图上标注电话号码，并且还为覆盖在地图上的产品显示一份本地服务中心或部件供应商列表，那会是什么情况呢？有了这样的数据，我们就可以在很短时间内回答客户提出的问题。如果我们还可以查看该地区的当前天气状况或当地运动队和他们的最新赛事，作为长时间电话交谈的话引子或谈资，那又会是什么情况呢？ 图3使用此示例展示了业务代表在接听电话时可以使用的模拟客户服务Mashup。通过将公共服务（如天气和新闻）数据与内部数据源（客户服务提示博客和服务位置数据库）相组合，该应用程序将Mashup元素与门户网站的可访问性结合起来。 
图3：我们呼叫中心的示例Mashup（单击图片查看大图） 如图3所示，嵌入式Mashup将海量的备用信息呈现在呼叫服务代理面前，包括优质服务项目——因此他们可以快速回答问题，以及反查电话号码——以获取谈资。这种Mashup类型完全是内部的，但为客户端的首次呼叫提供了巨大价值。 要使此Mashup成功有几个关键要素。首先，它是围绕手头任务为上下文展开的，这也是最重要的。其次，它按照最可能有用的次序排列信息。您必须了解正在与谁交谈，他们注册了什么产品，哪些优质服务项目适用于这些产品，然后开始尝试回答他们可能提出的问题，如客户所在地的本地服务中心位置。第三，一旦我们获得了客户信息和所在地，则每个内容窗格都是独立的，不需要与其他部分交互。这样就可以同时收集和集合每个部分的数据。 了解投资回报(ROI)是面向服务架构（Service-Oriented Architecture，SOA）部署的共同关注点。许多组织发现，当创建应用程序变得容易时，很难判断对创建能提供不同功能的服务的预先投资是否还能获得回报。对于SOA中的投资如何提供巨大价值，企业Mashup是一个很好示例。（请参阅参考文章《Mashups deliver ROI for IDV Solutions》。）
利用自己构建的服务 当组织将这些服务混合和协调起来时，对SOA的投资就能获得直接回报。当开始采用事先没有想到的方式利用服务或应用程序时，这种感觉好极了。（请参阅参考文章《Quicken Loans leverages mashups for fast results》。）
利用他人构建的服务 认识到自己不可能拥有世界上一切知识这一点很重要；您简单地利用一下其他人的辛苦劳动，不必事必躬亲，也可以获得相当高的投资回报。
构建他人可利用的服务 随着Mashup越来越流行，企业又获得了一次发展机会，即构建Mashup应用程序容易使用的服务。回到我们引用过的示例，如果客户服务代表为客户提供邻近的商店位置，客户会为此感到高兴。但想象一下，那样商店会将其库存和产品供应能力公布给Mashup。现在，服务代表就能在电话中向客户提供更为详细和有价值的信息。这种服务对于客户、呼叫中心和商店自身都是有价值的。
平台敏捷 正如之前所讨论的，为在基于标准的Web平台（HTML和JavaScript）上进行交付而创建了许多Mashup。这对于Mashup本身没有限制，仅仅限制了Internet上交付应用程序的标准方法。正如我们看到Mashup进入了企业，我们将看到构建在RIA平台（如Adobe的Flash和Microsoft的Silverlight）之上的Mashup会越来越多，甚至会出现构建在Windows Presentation Foundation之上的完全富桌面Mashup。富客户端平台上的完全三维显示可以提高Mashup的可视化要求。企业Mashup可以利用这些功能更丰富的平台，许多平台将有更好的桌面控制能力。 
图4：Quicken Loans利用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月作过一次调查，询问了企业客户有关他们采用Web 2.0技术的情况。可以预见，他们中有许多人都已投资或计划投资一种或多种Web 2.0技术。调查中令人惊讶的是，只有21%的受访者在使用或考虑使用Mashup，大部分受访者（54%）根本没有考虑过它的使用问题。 我们认为，相对于调查中列出的其他技术（如Web服务、podcasts和RSS feeds），Mashup技术比较新颖，因此对企业Mashup的反响比较低。构建Mashup的工具才刚开始出现，这也是一个因素（在我们撰写此文时，文中提及的这些工具有许多都还处于beta和alpha阶段）。我们确信技术会越来越普及，工具也会成熟起来。Internet服务总线（第2页）这些概念会使得这些企业Mashup的构建更为容易和有用。我们认为Mashup应在企业中占有一席之地，我们鼓励您研究它们的实际应用。
参考资料 l “Consumerization Gains Momentum:The IT Civil War,” Gartner Special Report, 2007（摘要）http://www.gartner.com/it/products/research/consumerization_it/ consumerization.jsp l “How Businesses are Using Web 2.0:A McKinsey Global Survey,” McKinsey Quarterly，2007年8月http://www.mckinseyquarterly.com/article_abstract_visitor.aspx?ar=1913 l Mashup（Web应用程序混合），Wikipedia http://en.wikipedia.org/wiki/Mashup_%28web_application_hybrid%29 l Redfin http://redfin.com l “Web 2.0 in the Enterprise,” Michael Platt, The Architecture Journal, Journal 12 l Zillow http://zillow.com
关于作者 Larry Clarkin是Microsoft的一名架构导师。Larry在设计和构造应用程序方面从业时间超过15年，曾在多种技术和行业中任职。他专攻Web技术与Legacy和ERP系统的集成已经超过10年时间。当不用与客户打交道时，Larry便在当地User Groups谈论技术。您可以通过其博客网站与Larry取得联系，网址http://larryclarkin.com。 Josh Holmes是Microsoft的一位架构导师。在上个十月份加入Microsoft之前，Josh还是一名咨询人员，为包括大型的财富500强企业和各种小型企业在内的客户提供服务。Josh是国内和国际软件开发会议的领导小组成员和常邀演说家，他关注新兴技术、软件设计和开发，研究重点是移动性和RIA（富互联网应用程序，Rich Internet Applications）。Josh曾是CodeMash大会组织委员会成员，他专注于社区建设，创建和/或经营着许多技术组织，范围从Great Lakes Area .NET Users Group到Ann Arbor Computer Society。您可以通过其博客网站与Josh取得联系，网址http://www.joshholmes.com。
|
.gif)