企业混搭应用(Enterprise Mashup)有待成熟

作者：Andy Dornan 朱筱丹 译    来源：《信息周刊》杂志

欢迎访问e展厅 展厅 3 CIO信息化管理展厅 电子商务/企业门户, IT运维管理, 制造执行系统MES, 流程管理BPR/BPM, SOA/SaaS/云计算, ... 企业混搭应用既可能成为SOA创新中的下一次重大运动，也可能是解救灾难的良药。 人人都在谈论要根据业务目标调整IT策略，但这目标通常都很遥远。因为即使目标一致，IT和业务部门仍然各自为政。企业混搭应用(Enterprise Mashup)的倡导者希望使非技术人员也有能力开发自己的应用，从而拉近这两大阵营的距离，消除分歧。 但IT专家们有足够理由对此表示怀疑。 混搭应用仍然是由消费者而非商业主导的创新。谷歌(Google) Gadgets、雅虎(Yahoo) Pipes和众多网站已经把互联网变成一个开放的平台。上百万业余开发人员正把各种网络服务组合成无数新应用，速度远比基于服务导向架构(SOA)的开发来得迅猛，而SOA可算是企业架构里最接近混搭应用的模式了。 但混搭应用与企业里曾流行过的消费者应用热潮不同，它并不等同于安全威胁、员工满意度的提升途径、或者是廉价获取技术的手段。就商业创新而言，那些积极接受混搭站点和工具的员工本身就是个未开发的丰富宝库。 当然并不是每个IT部门都想让自己的员工强大至此。在我们为本文所做的在线读者调查中，只有不足一半的受访者表示，会考虑让非IT员工创建自己的混搭应用。但是，也别因此立即否定这项技术：因为即使在桌面应用软件安装受到严格管制的工作环境里，混搭仍然能够发挥效力。它能通过单一的前端整合不同的应用和数据源，籍此提升生产效率，简化工作流程，让企业应用得以从公共互联网上的Web服务中获益。 说到谁会去创建混搭应用，可以即时通讯(IM)为例加以说明。即时通讯软件在工作场合得到广泛应用，完全有赖于一群极度依赖互联网的用户，这些人认为电子邮件太落伍，而宁可选择网站上的RSS或Widget。目前，有能力建立复杂混搭应用的员工仍然数量有限。使用应用编程接口(API)需要具备一定的JavaScript 知识，甚至由软件厂商提供的无需编程技巧的开发工具也并不适合所有人。 要创建真正有用的混搭，用户必须理解底层的业务流程；例如，Serena软件公司(Serena Software)的目标用户就是使用业务流程管理软件或写Excel宏的人。 第一批用谷歌地图(Google Maps)和谷歌Ajax API开发出来的Web 混搭应用，直到现在仍然广受欢迎。如今，微软公司(Microsoft)和雅虎也提供类似的服务，而雅虎还提供Flash版以供选择。 在企业里，网络管理软件已经能为IT部门提供在地图上叠加数据的功能。例如，无线网状网(Wireless Mesh)开发商Tropos网络公司(Tropos Networks)就把谷歌地图的数据引入其基于浏览器的控制台中，为网络管理员实时显示每个无线节点的覆盖范围和活动状况，其未来版本将具备跟踪单个用户和客户端设备的功能。他的竞争对手SkyPilot公司和 Strix系统公司(Strix Systems)则使用谷歌地球(Google Earth)在非浏览器环境里实现类似的功能。 而在企业内部，常规搜索非常实用：超过半数的调查受访者表示，在他们开发的混搭应用中，都可直接使用谷歌搜索。难道这是谷歌大受欢迎的原因？他相对简单的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，这样用户就可以通过Web服务访问客户端的数据了。采用这种方式，用户可以更容易地和其他人共享文件，企业电子邮件服务器也不致被体积庞大的邮件附件堵塞住，更无需转而使用类似SharePoint风格的协同软件。 要使文件访问能支持服务方式，并且能管理这些服务，就需要一个与SOA类似的系统，此系统采用的是RSS格式，而不是SOAP协议。Attensa公司、 Serendipity软件公司(Serendipity Software)和/n 软件公司(/n Software)都提供类似于SOA中的企业服务总线(ESB)的产品，其目的是创建、路由和管理后台的RSS输出，而不是设计前端的混搭应用。某些混搭套装软件也具备把文件转化为RSS输出的功能，其中较为人知的是国际商业机器公司(IBM)和Kapow科技公司 (Kapow Technologies)的产品，而Denodo科技公司(Denodo Technologies)的数据混搭套件则通过为数据库和老式服务器提供支持服务的方式和ESB竞争。 大多数支持RSS的工具还可以通过解析屏幕输出内容获取RSS输出，使原本不提供RSS输出或网络服务API的站点数据，也能被用于混搭中。这对支持服务的内部网来说是很方便的做法，但需要注意第三方网站的版权问题。另外这里也存在一个常见的混搭风险：就是站点布局格式的改变会影响RSS输出，并可能使基于它的应用无法正常工作。 即使对内部网站或内部应用而言，内容变更也是个问题，因为混搭往往会包含并非为混搭而设计的服务或应用。这总的来说是件好事，因为这正是创新的意义所在，但这同时也意味着升级可能会导致不兼容。 避免出现这种后果的唯一办法是采用久经考验的软件质量保证体系。确保服务都由经过认真设计和严格测试的API提供；这其实也是SOAP协议和WS-*系列标准的理念。不幸的是，测试会延缓开发进度，这也是为什么SOA系统的开发往往步履维艰且充满官僚主义味道的原因，相比之下混搭方式和Web 2.0的效率则快得多。所以凡事总有利弊两面。 自助式 IT 共有3种类型的混搭应用：表现型、数据型和逻辑型。表现型混搭最简单，网络门户就是最好的例子；数据型混搭收集来自多个数据源的信息，为方便比较而把他们都聚合在一起；而逻辑性混搭通常最复杂，这往往需要进行与2个或更多应用交互的编程工作。 低门槛意味着不需要使用定制的企业混搭产品。混搭可以放在任何网页服务器上，使用的开发工具也与其他众多基于网页的应用相同。多数受访者实际也是这么做的。最受欢迎的平台是微软的ASP.Net、奥多比系统公司(Adobe)的Flex、以及谷歌的免费网页开发工具包(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和甲骨文的 WebCenter Composer都会在今年年底发布。这几款产品都强调集中化管理以及与其他SOA工具的整合，而且，IBM还特别注重与Lotus Domino等自身其他产品线的整合。 BEA专注于通过内建Widget和网页地址设置的方式实现表现型的混搭功能，所有操作都符合安全合规要求并可以进行集中式监控跟踪。甲骨文的WebCenter在三者中野心最大，该软件允许用户直接编辑JSF(Java Server Faces)文件，并能分别存储每个用户所做的修改，确保底层应用不被破坏。微软也有Beta版的混搭工具Popfly，适用于互联网和企业内部应用。 对于那些不愿意自行维护混搭服务器的机构，一些厂商也提供混搭托管服务。在这方面，Salesforce公司(Salesforce.com)走在了前面，这一方面归功于他身为软件作为服务(SaaS)厂商的历史；另一方面也得益于其建立AppExchange平台的经验，AppExchange是为其他SaaS厂商提供在线交易的平台，这些厂商的应用也可以和Salesforce的产品整合到一起。自2006年1月上线以来，从小型独立软件开发商到大型IT公司，AppExchange现在拥有来自200余家公司的300多个应用。可以肯定，由于Salesforce公司原有的客户关系管理(CRM)应用背景，AppExchange上的许多服务也都和销售与管理有关，但该网站也提供其他各种商业应用，从会计到项目管理到办公套件，无所不包。 AppExchange非常看重托管混搭应用固有的安全和隐私问题，因为这些应用需要在多个服务之间共享内部数据。尽管许多客户信任Salesforce，愿意把敏感数据提供给他，但AppExchange平台上的其他厂商就未必如此为人所知了。托管的应用数据被暴露得越多，发生数据泄露的风险就越大。 置于企业内部的混搭应用受到的威胁相对较小，但是在经历搜索引擎的查询时，他们还是可能对后者暴露隐私信息。例如，调用地图API时，就有可能向地图服务提供商暴露客户的地址。甚至更糟的是，如果链接明文不加密，数据在互联网上传输时就可能被随意截获。并不是所有的平台都支持加密传输：尽管大多数使用账号的网络服务都支持加密，但仍有许多免费的网页服务API不支持，因为他们并不需要进行用户授权。 还政于民 尽管AppExchange上的多数应用都由SaaS 厂商和软件厂商创建，有的站点却将目标客户群明确地锁定在开发人员。例如，Salesforce的竞争对手LongJump公司就在研发一套产品，该产品目前尚处于内部测试阶段，可为非程序员提供应用开发的平台。和微软的Popfly有些类似，LongJump并不仅用于内部网：在该平台上运行的应用可供公开访问或销售。 Serena公司比大多数SaaS厂商的步子迈得更大，他的目标是和Coghead、IBM以及Kapow竞争。他的Vail服务可以通过安全加密连接，与企业SOA应用或其他Web服务全面整合。Serena还为最终用户提供免费下载的混搭开发环境。 要使用外来软件整合位于企业内部的服务器，这听起来似乎有点多此一举，但Serena认为，大部分现有运行在企业内部的服务器迟早都会被托管服务所取代。无论你是否同意此观点，但SOA和混搭的确能简化托管服务和内部应用之间的交互，因此对某些机构而言，混搭服务器采用外来产品完全合情合理。 即使没有服务器或服务，也能创建混搭应用；但由于混搭应用的本质特点——基于互联网，因此大部分混搭是与网页相关的。例如，OpenSpan提供的一个混搭工具就可以在运行视窗(Windows)操作系统的PC上运行，也就是说，他可以直接和微软自己的Windows应用程序进行交互。该工具不把文件转换成RSS输出，而是监控应用程序与Windows API的交互，拦截过滤这种交互，并实现对程序的用户界面、输入/输出和共享系统资源使用的完全控制。 准备在前 在接纳混搭技术之前，关于谁来开发这类应用的问题，你需要对以下问题做出重要决策。 • IT部门需要确定哪些数据源属于开放授权，是可以被混搭的。很明显，可以选择谷歌地图等公共网站和API，在企业里只有把这些数据源与内部和外部网络服务整合在一起，才能获取真正的价值。 • 下一步，有关混搭应用的使用环境。尽管混搭应用往往和基于浏览器的应用有关，但部署了SOA的企业，也可以考虑采用各种基于服务器的工具或以桌面为中心的集成软件。 • 如果采用基于浏览器的混搭应用，需要确定：是在现有网站服务器上提供新应用，再购买一个新的专用混搭平台，还是把整个任务外包出去。 • 最后，现在已有大量开发平台和工具，其中很多是免费的。Ajax与浏览器的广泛兼容，使之成为大多数互联网应用的必然选择；但对内部网开发人员来说，客户平台并不局限于浏览器，这也就不成其为问题了。 (end)

文章内容仅供参考 (投稿) (10/17/2007)