即将到来的RIA之战 群雄逐鹿谁问鼎?
【IT168 分析评论】
一批用于迅速设计基于浏览器的软件的强大有力的新方法(又名富互联网应用程序)近来已经倍受关注地进入市场,或者是朝着市场加速迈进。而至今为止的这些日子以来,其中承受最多舆论压力的技术仍然是Ajax。有许多看似有些热衷于好事的新态度,指出它尽管作为相当强大的浏览器软件模式,但要求苛刻且难以操作。那目标呢?就是让我们能更容易地开发出下一代的网络应用程序,使它们的每一部分都能够媲美甚至超越桌面应用程序。

所有这一切的举动都不难理解;大多数软件的领域正在移向浏览器和“软件即服务(SaaS)”——你能够在整个网络或本地内部网中都能了解到——尽管浏览器缺乏与生俱来的、能集合精密的应用程序的能力。这种欠缺尤其包括对富媒体,例如视频、音频和3D图像的支持。而事实上,Ajax是一个这样的方法,它在浏览器中充分利用相当严苛的限制条件,特别是没有操作系统的完全支持,没有强有力的编程语言的使用,以及相当少的好的开发和调试工具。然而它却能做得足够令人满意,因为最好的Ajax应用程序是通过网络必不可少的超链接结构,建立在Web开发模式顶层、支持粒化数据及可用、外露、“集合”的软件控件上的。
但是Ajax看起来似乎将要面临与Flex、OpenLaszlo、WPF/E、XBAP、XUL、Java浏览器版本以及其它很多新技术的激烈竞争。
【IT168 分析评论】
在今年早些时候开始,许多的公司和开源的成果都在交付的过程中,表面看来似乎无休止的一个接一个的RIA方法。它们中的大多数在完成的富互联网应用程序(RIAs)的创造、管理和维护上不仅容易,且更具成本效益、特性丰富。而这样看来,Ajax或许无法与之相较。
然而,很多人仍然没有跟风,因为这些方法依然有需要斟酌之处,它们都要求给浏览器添加一些插件,还通常是一些破坏性的插件,它们自身就经常发生意想不到的冲突,而其中最为严重的则会破坏网络模型。这又特别作为链接结构与透明内容模型的思想,能够凭借搜索引擎的能力、将链接传导给其他人等等,使得网络更为强大。概要:应用模型大规模引发对网络影响的能力还相当有限,Web 2.0的活跃时期仍没有到来。
这也并不是说网络中没有大量的空间容纳这些及其它用户接口技术,且情况是完全相反的。通常你的应用程序也会需要一些独特的特性,需要通过这些RIA方法才能实现。或者你会发现,期待普通的软件开发者使用Javascript去创造“富的”、复杂精密的应用程序,那将不是一个明智的期望。实际上,新的RIA工具的描述模型——特别是Flex、Laszlo、XUL以及基于XAML的平台——是一个惊人的发展,它改变了开发软件的模式,由一种“要怎样”的模式转向“是什么”的模式。
Ed Burnette的新文章中有写到Java社区所做的努力带给世界真正的基于浏览器的Java RIA核心技术。
而所有的这些技术给我们的平台带来了什么,哪一个又是非常好的选择呢?值得注意的是许多更为成功的网站则是积极大量地使用Flash插件来完成他们所需的富应用程序和媒体支持(Flickr、YouTube、Google等等)。这是由于在浏览器中你所想要做到的事,Ajax无法提供任何完全的方法去处理,除非对浏览器进行一系列的大修改。实际上最平常的RIA平台是Flash插件,全世界99%的计算机上都对它进行了安装,它能单独地提供浏览器安全的本地文件存储、音频/视频捕获以及音频/视频录放等功能。
因此让我们来看一下目前我们所面对的RIA的选择,并了解它们怎样进行堆叠。我必须指明,它们中的每一个都功能强大,且妥善处理问题各有所长,但目前来说,每一种都确实存在一些显著的缺点。这些平台的设计者都对这些选择的最终结果做出了预测,他们是否能预计到市场会为哪些最优者占领且会以它们的胜利为结束?我们将拭目以待。然而现在,显而易见的,一个行之有效的RIA策略无疑大都需要Ajax与其它这些方法中的一个或更多进行联合,因此我们就有必要对它们进行更好的理解。
RIA平台集合一览——到2006年9月非常先进的技术。
![]()
【IT168 分析评论】
几个月前发布了此平台的第二个版本,Adobe看起来似乎为Flex筹划了一个的具有战略性的、长期的计划。Flex通过联合使用描述性标记和程序代码来详细指明应用程序应该如何绘制界面和工作。Flex应用程序启动时看起来就非常专业,并且在提供一个平台时有一个明确的优点,使得企业通常会热衷于它。其中有许多对后期基础建设的支持,包括网络服务、消息传送、门户管理以及服务器端事件推送等等Adobe也拥有一个关于Flex的,名叫Flex Builder的世界优秀水准的GUI设计环境,它可以作为Eclipse的插件运行。
如果你的应用程序需要面向网络,Flex 2会要求最新的Flash 9播放器,由于这个播放器是全新的,在网络上的部署仍比较有限,这也许就会在使用时导致一些问题。而开发者和社区支持都在发展,经对Flex开发者数目的计算至少也有数千人,这明确地表明,这个平台是目前可用到的最为复杂且成熟的RIA产品之一。Flex语言与SDK都是完全免费的,而对于企业来说,申请服务器端运行许可的费用则是相当昂贵的。
![]()
这个平台从前被称为Laszlo Presentation Server(LPS),在3.0版本中以开源的形式独立出来。Laszlo已经面世多年,是由原来Apple Newton小组成员之一的David Temkin所创作。Laszlo有着一个与Flex非常相似的描述模型,但它还具有运行在网络上时的丰富选项设置,包括对Flash 6播放器及以上版本的支持。Laszlo最引人注目的是其即将拥有以同样的源代码生成Flash应用程序或者Ajax应用程序的特性。如今,你可以在Laszlo的Legals页面的演示应用程序中看到这个应用;Flash和Ajax应用程序的惊艳之处不相上下。同时,Laszlo也支持一系列常见的网络服务,拥有强健的社区支持,包括引人注目的RIFE整合模型。Laszlo同时也有网络化的应用,并且在大范围的因特网应用程序中使用,如Pandora和Monster.com。OpenLaszlo是开源且完全免费的,不需要任何类型的运行许可。
![]()
【IT168 分析评论】
有趣的是,微软是自己将它的竞争对手Flash带到这个市场上的,Flash将能在包括Macintosh和移动设备的其它平台上运行。虽然WPF/E自身也是一个功能强大且类似于Flash的东西,但它没有像Flex或OpenLaszlo那样具有自己的应用程序开发模式。后两者能够生成Flash SWF文件,提供给开发者的却只是非动画的、纯粹的代码视图的开发模式,这就是XBAP产品产生的来由。ZDNet的Ryan Stewart也在最近的一篇文章中阐述了XBAP,认为它实质上就如WPF/E平台的Flex。如何使WPF/E与XBAP得到普及则确实成为一个问题,有时甚至因此显然地削弱了微软开发模式的声望。 然而为了避免你将其剔除,想想Windows Vista即将为数百万的桌面带来的令人赞叹的特性吧,它们都是通过WPF/E、Avalon和XBAP的功能来实现的。你可以在Tim Sneath的WPF/E的XBAP演示程序(http://blogs.msdn.com/tims/archive/2005/11/28/497492.aspx)中体验到XBAP的完全风貌。忠告:你需要安装WinFx来对它们进行领会。WPF/W SDK将是免费的,尽管这个开发工具的专业版或许不是。

关于如何做到只在一个浏览器上添加RIA特性而让其它的浏览器均无法支持,确实是一个有意思的研究。XUL在用于创建基于网络的应用程序上,实际还是一种颇为像样的的描述语言。它主要的缺陷在于最初仅能为Mozilla浏览器所支持(虽然通过一些插件的添加能够在其它浏览器上使用)。虽然我认为也许我将因我所说的而遭受些许XUL社区的恶言相向,但XUL目前来说确实是一个好的模型——用于如何建立一个不为广泛接受的RIA平台,尽管有一些技术上的崇高性。如果出于某些原因,XUL社区能创建一个多插件模式用于其它浏览器,或者生成Ajax的代码,这种RIA技术的发展趋向则难以捉摸,尽管目前它的前途还是清晰明朗的。
综述:
虽然上述四种RIA平台中的三种都有可能成为你所考虑的选择,然而更为明确的是,完美地结合各种特性的一个RIA平台则更为人所求。尽管Ajax有着对XML的良好支持,但由于Flash播放器并没有包含对XML的支持能力,使得上述头两个基于插件的RIA技术对XML的支持性也相当有限。插件的垃圾收集机制与应用程序(Garbage collection和application)的表现目前看起来还是较为优越,在浏览器中图像的载入与流水线操作就仍然能更为快捷良好。
最后,在插件RIA技术中对HTML和CSS的支持也还是相当缺乏,我看到RIA应用程序为了能被赋予丰富的内容而在RIA控件前的HTML层徘徊不定。这是一个neat hack,但当你离开浏览器的能力之后却是必要的。这样的技术在RIA世界中将越来越普遍:与浏览器能力、Ajax和插件方式的RIA控件深层混合的,发挥所有它们各自的长处。Ajax是具有破坏性的(参见http://ajax.sys-con.com/read/173115.htm),但它很可能成为对大多数人来说最为出色RIA技术联合的一个好搭档。
因此,目前要为网络或企业做出一个最终的对RIA的选择是相当困难的,将各种特性联合的方式仍在积极探索中。是否这些平台中的其中之一能够在此胜出,或是我们目前尚未发现的全新的技术才能够做到,这一切尚悬而未决。由于一些着实的革新和创造力,为孕育一个战场环境创造了条件。由此可见,世界的RIA传奇也许将令人感到兴趣盎然,至少在接下来的几年内。
(原文作者:Dion Hinchcliffe 文章来源:www.zdnet.com 原文地址:http://blogs.zdnet.com/Hinchcliffe/?p=65)