但IT专家们有足够理由对此不放心。

　　混搭仍然是由消费者而非商业主导的创新。Google Gadgets、Yahoo Pipes和众多网站已经把互联网变成一个开放的平台。无数的非职业开发人员正把各种网络服务组合成无数新应用，速度远比在基于SOA架构的开发来得迅猛，而SOA可算是企业架构里最接近混搭的模式了。

　　但混搭与曾在企业里流行过的消费者应用热潮不同，混搭并不等同于安全漏洞、员工满意度的提升途径、廉价的技术手段。对企业创新来说，那些积极接受混搭站点和工具的员工就是个未开发的丰富宝库。

　　当然并不是每个IT部门都想让自己的员工强大至此。在我们为这篇报道所做的在线调查里，只有少于一半的受访者表示考虑让非IT员工创建自己的混搭应用。但也别因此立即否定这项技术：因为即使在桌面机的软件安装受到严格管制的工作环境里，混搭仍然能够发挥效果。它能通过单一的前端整合不同的应用和数据源，籍此提升生产效率，简化工作流程，让企业应用得以从公众互联网上的Web服务获益。

　　对于谁会去创建混搭应用，可以拿IM(即时通讯软件)做参考例子，IM软件在工作场合得到广泛应用，全赖一群极度依赖互联网，认为电子邮件太落伍，宁可选择RSS或widgets而不是网页的热情用户。目前来说，会构建复杂混搭应用的员工仍属有限。API(应用编程接口)的使用需要具备一定的JavaScript 知识，甚至由软件厂商提供的无需编程技巧的开发工具也并不适合所有人。

　　要创建真正有用的混搭，用户必须理解底层的业务流程;例如Serena Software软件的目标用户就是使用业务流程管理软件或写Excel宏的人。

　　第一批用Google Maps(谷歌地图)和Google Ajax API做出来的Web 混搭应用到现在仍然广受欢迎。如今微软和雅虎也有类似的服务，而Yahoo还有Flash的版本可供选择。

　　在企业里，网络管理软件已经能为IT部门提供地图上叠加数据的功能--例如无线网状网(wireless mesh)开发商Tropos Networks就把Google Maps的数据加入到自己基于浏览器的控制台里，为网络管理员实时显示每个无线节点的覆盖范围和活动状况。跟踪单个用户和客户端设备将是未来版本的功能。它的竞争对手SkyPilot和 Strix System则使用Google Earth在非浏览器环境里实现类似的功能。

　　而在企业内部，常规性的搜索非常实用：超过一半的调查受访者搭建的混搭都整合了Google的搜索结果。难道这就是谷歌大受欢迎的原因?它相对简单的API能让开发人员仅用几行代码就能包含搜索结果。例如浏览或点击显示销售预期目标列表的网页或应用时，可以自动根据人员或公司名称，到网络上去搜索更多的信息。当然通过手工方式实现该功能也不难，但混搭避免了剪切、粘帖和在多个浏览器窗口里切换等动作，而这些操作会大大降低效率。

　　与业务伙伴的系统整合则还没有那么成熟，但包裹货运业肯定是可混搭API的先锋行业。

　　超过四分之一的受访者使用了FedEx的服务创建混搭应用，比这数字稍少的人选择了UPS的混搭API。两家货运商都为内部账单查询和包裹跟踪提供了Web服务访问。

　　来自电子商务站点如Amazon.com和eBay的服务很受小公司的欢迎，它们尽管规模不大但也占企业应用里的一席之地。有的企业混搭与AOL整合，通过该公司的XML API，获得AOL实时通讯软件里用户的在线状态。

　　但混搭来自公众互联网的应用只是企业混搭目标的一半--在混搭的应用上，企业通常都落后于本就在根植在互联网上的公众站点。

　　SOA的"最后一英里"

　　对大公司来说最大价值往往来自内部企业应用的整合，但这是一个让人望而生畏的任务。大多数公众网站能提供通过XML或JavaScript方式访问的API接口，而在企业里却要挨个改造自己的应用，以使它们能对外提供服务。即使只在企业内部使用，要开放内部应用使数据更容易被访问到，也要面临安全和管理控制等问题。

　　这就是SOA的切入点了。越来越多的大SOA软件商摇身变为为企业定制混搭服务的软件商，他们中的大多数人都认为混搭是SOA的"最后一英里"，它架通了最终用户与SOA架构服务的访问。不同的是SOA里的Web服务往往只用于不同服务器之间的通讯，而混搭通常还涉及到客户端。

但显然这些新事物会带来一些成长的烦恼。大多数SOA套件都是基于使用SOAP协议而设计的，但大多数浏览器和客户端实时程序如Java和Flash内置都不支持SOAP协议。所以在公众互联网上的混搭一般都采用RSS 做为数据格式，而对复杂的API则提供自定义的数据格式，这通常由网络服务提供商根据实际情况而定。

　　SOA主要关注在服务器端，它往往忽略存储在客户端的文件，很大原因是因为IT部门创建SOA应用时，并未着重于对财务报表里的数据或销售材料的理解或解析。而许多混搭开发商则刚好相反，把这些文件看成可混搭数据的丰富来源--最终用户会更愿意选择对重要文件能提供服务访问的方式(好像有点不通顺)，使用Ajax 或XML API，数据就可以通过网络服务进行访问。现在新式的服务访问方式使用户可以更容易地和其他人共享文件，这样企业电子邮件服务器就不会被体积庞大的附件堵塞住，又不用转而使用类似SharePoint风格的合作型软件。

　　要使文件访问能支持服务方式，还要能管理这些服务，就需要一个与SOA类似，但却不使用SOAP协议而使用RSS格式的系统。Attensa、 Serendipity Software和/n Software都提供大致相当于SOA里的企业服务总线(ESB)的产品，其目的是创建、路由和管理后台的RSS输出，而不是设计前端的混搭应用。把文件转化为RSS输出的功能也包含在某些混搭套装软件中，较为人知的是IBM和Kapow Technologies，而Denodo Technologies的数据混搭套装软件则通过为数据库和老式服务器提供支持服务的方式和ESB竞争。

　　大多数支持RSS的工具还可以通过解析屏幕输出内容的方式获取RSS输出，使原本不提供RSS输出或网络服务API的站点数据，也能被加进混搭里(这个screen scraping有的地方译成屏幕抓取，我觉得字面上也许稍微难以理解，其实就是把任何普通的网页内容，整理成RSS输出)。这对支持服务的内部网来说是很方便的做法，但请留意第三方站点的版权问题。另外这也揭示出一个常见的混搭风险：就是站点布局的格式改变会影响RSS输出并可能使基于它的应用无法正常工作。

　　即使对内部网站点或内部应用而言，内容变更也是个问题，因为混搭往往包含原本不是用于混搭的服务或应用。这点基本上可算好事--因为这正是创新的意义--但这也意味着升级可能会导致不兼容。

　　要避免这种后果的唯一途径就是传统可靠的软件质量保证体系。确保服务都由经过认真设计和严格测试的API提供;这其实也是SOAP和WS-* stack(各种Web Service 框架)的理念。不幸的是，测试会拖慢开发进度，这也是为什么SOA系统的开发往往步履为艰和充满官僚主义味道的原因，相比之下混搭方式和Web 2.0的效率则快得多。所以事情总有利弊两面。

　　自助式 IT

　　共有3种类型的混搭：表现型、数据型和逻辑型。表现型的混搭是最简单的;网络门户就是最好的例子。数据型混搭收集来自多个数据源的信息，为方便对比而把它们都聚合在一起，而逻辑性混搭通常是最复杂的，它往往包含与2个或以上应用交互的编程。

　　低门槛意味着不需要使用定制的企业混搭产品。混搭可以放在任何网页服务器上，和其他众多基于网页的应用使用相同的工具进行开发。大多数的受访者也是这么做的。最受欢迎的平台是微软的ASP.Net、Adobe的Flex，Google的免费网页开发工具套装(Web toolkit)还有开源Ajax框架Ruby on Rails 的排名也很高。其他的选择包括Curl和 Nexaweb公司组合了Java、 Flash和Ajax功能的开发框架。

　　然而，专用的混搭平台也有它的优势，特别是在普通用户即开发人员的企业里。它们的主要价值体现在易用性和安全性上：由非IT人员使用的平台与常见的网站设计和Office应用非常相似，而IT部门则可以监控这些混搭和它们的Web服务组件以避免数据泄漏。集中式的管理也有助于对组件的重用。

　　企业级混搭软件商Coghead, JackBe和 Kapow都提供了针对企业用户的拖放式开发环境。Coghead 和JackBe针对从最简单的表象层门户到全面的应用包括业务逻辑的全部3种混搭类型。Kapow是数据混搭网站Dapper的企业版，在它的OpenKapow网站上提供了大量开放源代码的内置混搭应用。

　　大公司如BEA、IBM和Oracle进入这个市场比较晚，而BEA的AquaLogic Pages和Ensemble工具是目前为止这3家唯一正式发布的产品。IBM的Mashup Hub和Oracle的 WebCenter Composer都预计在今年年底发布。它们都强调集中化管理以及与其他SOA工具的整合，此外IB