丰富互联网应用程序
发展历史
“丰富互联网应用程序系统”一词源于Macromedia公司在2002年3月发表的一份白皮书,尽管如此,该词在更早的年代中就已包含以下含义:
远程脚本(由微软于1998年左右提出)
X Internet(由Forrester Research于2000年10月提出)
丰富(网页)客户端
丰富网络应用
传统的网络应用程序将所有交互应用都集中在基于“瘦”客户端的B/S架构上。在这样的系统中,所有处理操作均在服务器端执行,客户端仅仅是用于显示静态的信息内容(如HTML)。这种系统最大的缺陷是所有的交互操作都必须经由服务器端进行,首先客户端要将请求数据上传至服务器端,然后服务器端作出响应并传回结果,最后客户端再重载响应信息。而通过使用在客户端执行指令的客户端技术,RIA可以有效的避免延时,实现程序与用户操作的同步。这种差异有点类似于“终端与主机”或C/S结构与“胖”应用系统的差异。
随着时间的迁移,互联网标准正在逐渐地改变着,从而以适应这种新技术,所以也就很难为丰富互联网应用程序划定出一个明确的概念范围。但是,所有的丰富互联网应用程序都有一个相同的特征:它们在客户端与服务器端之间引入了通常被叫做“客户端引擎”的中间代码层。这种客户端引擎通常作为应用初始化的一部分被下载,也可能随着应用的运行在后续代码中作为补丁被下载并补充进来。客户端引擎充当浏览器的一个扩展,而且通常还会接管呈现用户界面和与服务器端进行通信的职责。
丰富互联网应用程序的功能可能会受客户端操作系统性能的限制。但是,在大多数情况下,客户端引擎会按设计者的意愿执行某些编辑好的功能,从而提升用户界面某些方面或在一定程度上改进用户界面的运算速率。而且增加一个客户端引擎也不会导致任何应用脱离原有浏览器与服务器端之间的同步交互模式,其实大多数丰富互联网应用程序中,客户端引擎在原基础上与服务器端进行的是异步通信。
优点
尽管与开发运行在桌面的程序相比,开发运行在浏览器中的应用程序要更受限、更复杂、更困难,但是这种努力还是值得的,因为它具有以下优点:
安装简便——更新与使用费用与桌面程序和操作系统相比要经济的多。
终端用户可以自动或简单手动的更新到最新版本
用户可以在任何连接到互联网上的电脑中使用程序
有很多任务具支持离线使用,例如Adobe AIR,Google Gears等等。
多数丰富互联网应用程序可以跨平台使用
与可执行文件相比,基于网络的应用程序可以有效的避免病毒的侵袭
由于丰富互联网应用程序采用客户端引擎,所以它具有以下特点:
表现力丰富。丰富互联网应用程序能在基于标准浏览器的网页应用实现HTML标签根本无法实现的用户界面效果。这种内涵更丰富的交互涵盖所有在客户端所能实现的功能,例如拖拽功能、滑块功能,而且这些功能无需与服务器端交互数据,完全是在客户端进行运算,如抵押计算。
反应更加迅速。与那些总须与远程服务器进行交互的标准网页浏览器相比,丰富互联网应用程序界面功能的反应要迅速的多,这也是丰富互联网应用程序特点之一。最成熟的丰富互联网应用程序会给人近似于桌面程序的外观感觉。而且,使用客户端引擎还有以下好处:
C/S结构的负担平衡。丰富互联网应用程序可以使客户端和服务器端对资源的需求更加平衡,从而使服务器不必再像传统网页应用中那样一直高负荷的运转。由此服务器端的资源得到了解放,从而提升了同一服务器端硬件设施所能并行服务的客户端会话数量。
异步通信。无须等待用户执行诸如在按钮或链接上点击的交互操作,客户端引擎便可与服务器端进行交互。如此,用户便可在客户端引擎跟服务器端通信的同时,异步地进行页面浏览或交互。从而,丰富互联网应用程序的设计者便可在免予让用户等待的情况下,在客户端与服务器端之间传输数据。程序会预先从服务器端预取数据,即程序预见到未来可能需要某些数据的时候,会预先于用户请求将其下载,借此来提升响应后续请求的速度。Google Maps便是利用了这种技术,先于用户将屏幕滚动到临近的地区,预取到上边的地图片断。
网络效率高。丰富互联网应用程序的网络通信量也会明显减少,这是由于在决定需要与服务器端交换什么数据时,为应用程序专门设计的客户端引擎会比标准的网页浏览器更智能。由于每次交互所需传输的数据量变少了,从而总负载也减轻了,所以每个请求和响应的速度也就提升。但是,滥用异步请求和预取技术有可能会抵消这种优势带来的好处,有时甚至还会起到反作用。因为程序无法准确地预期每个用户下一步操作所需的数据,所以采用这种技术时,时常会下载多余的数据,而对大多数客户端而言,这些数据其实并不是用户真实需要的。
缺点
丰富互联网应用程序存在以下缺陷:
受限于安全沙箱。由于丰富互联网应用程序程序运行在安全沙箱中,所以其对系统资源的访问会受到限制。一旦对系统资源的访问出现错误,那么丰富互联网应用程序程序就将无法正常运行。
依赖于脚本支持。丰富互联网应用程序程序常常需要JavaScript或其它脚本语言的支持。一旦用户浏览器对这些脚本进行屏蔽,丰富互联网应用程序将无法正常运作。
客户端运行速度受限。为实现平台无关性,一些丰富互联网应用程序选用诸如JavaScript这类脚本语言来编写其客户端脚本,从而导致了性能上的损失(在移动设备中,此类问题尤为显著)。而对于如Java这类的客户端语言是不存在这类问题的,因为它的性能已可比拟传统的编译型语言了,而对于Flash,Curl或Silverlight,因为在其插件中所运行的代码也是经过编译的,所以同样也不存在这类问题。
下载脚本的延时。虽然无需安装软件,但是丰富互联网应用程序的客户端引擎还是要从服务器端传送信息到客户端。虽然绝大多数传输信息会被缓存,但这种传输也至少要执行一次。根据下载的类型和大小,脚本的下载可能会是一件令人苦恼的事情。对此,丰富互联网应用程序的开发者可采取压缩、分段等技术在一定程度上减少这种延迟带来的影响。
集成困难。如果基于X/HTML开发应用,那么应用程序的目的(向往控制一切表现效果和行为)和X/HTML的目的(向往解除一切控制)之间的冲突会进一步加剧。X/HTML的DOM接口为创建丰富互联网应用程序提供了一个可能,但是该方案又会导致丰富互联网应用程序中的一些功能瘫痪。因为在该方案中,丰富互联网应用程序的客户端可以修改应用程序的基本结构并覆盖其的表现效果和行为,这可能将导致应用程序在客户端的执行错误。最终,该问题通过采用新式的客户端机制来解决,在该机制中,丰富互联网应用程序将受限于只能对其自身范围的资源进行修改。(标准的运行在本地软件之所以不存在该类问题是因为其遵循一个自动程序的定义,只能处理它自行分配的资源)。
搜索引擎优化困难。搜索引擎可能无法搜索应用程序文本内容中的索引。
依赖于互联网连接。最理想的替代桌面程序的互联网应用程序要允许用户间断性的上网,这样用户就可以游走在各个热点与办公地之间。鉴于此,一些特殊的平台(如Adobe AIR,Google Gears)就需要允许离线操作的丰富互联网应用程序程序。
可访问性存在困难。在丰富互联网应用程序中存在很多访问性的困难,其中多数明显地表现为屏幕阅读器在探测由JavaScript引起的HTML内容更变上遇到了极大的困难。
无法部署。除了Adobe的AIR技术以外,其它的丰富互联网应用程序不能像传统的桌面应用那样进行部署。
软件开发复杂性
丰富互联网应用程序技术的出现给网页应用的开发引入了可观的复杂度。仅使用标准HTML构建的传统的网页应用,其软件架构相对来说要简单,同时也只有有限的开发方案选择,所以相对来说要易于设计和管理。对使用丰富互联网应用程序技术的个人或组织而言,他们所面临的额外的复杂度是他们更难于进行设计、测试、评估和支持。
丰富互联网应用程序技术的使用引起了若干个在服务级管理(service level management,简称SLM)上的新挑战。而这些挑战至今也仍未得到彻底解决。服务级管理所关心的并不总是应用开发者的焦点所在,也甚少为应用用户所察觉,但它们对一个在线应用的成功交付却起着至关重要的作用。丰富互联网应用程序架构中使管理过程变得复杂的方面包括:
更大的复杂度让开发变得更加困难 。将代码移至客户端的能力,给了应用设计者和开发者更多的创造空间。但是这反过来也让开发变得更加困难,增加了发生过失(bugs)的可能性,也加大了软件测试的复杂度。无伦引入何种方法学或过程,这些复杂化都将延长软件开发过程。这些问题中有些可通过使用网页应用框架对丰富互联网应用程序的设计和开发进行标准化来减轻。但是,无论如何,在软件的解决方案中增加复杂度,如果增加了用例的数量,将导致测试过程复杂化和延长。而不完整的测试又会降低应用的质量和使用时的可靠性。有人可能要说,上边讨论的问题并非只是丰富互联网应用程序技术特有的,而是关于复杂性的广泛问题。例如,同样的争论就发生于苹果跟微软分别在1980年代发布其GUI时,甚至可能还发生于Ford发布其Model T时。无伦如何,人类已经展示出了在数十年间吸收新技术的优势的能力。
丰富互联网应用程序架构违反了网页范式 。传统的网页应用可以看成一系列网页,这些网页每页都需单独经历由HTTP GET请求发起下载过程。这种模型被称为 网页范式 。丰富互联网应用程序废掉了这种模型,同时额外引入了异步的服务器端通信方式来支持反应更迅速的用户界面。在丰富互联网应用程序中,完整加载一个页面所需的时间可能不再是用户所能察觉到的重要指标,因为(打个比方说)客户端引擎可能为未来预取了一些内容。为对丰富互联网应用程序作有效的评估,来反映用户体验的指标,肯定会有新的技术被设计出来。在这种评估技术出现之前,丰富互联网应用程序的开发者应该指示他们的应用代码来为SLM产生测量数据。
异步通信导致难以隔离性能问题 。看似矛盾地,用以增强应用的响应能力的措施同时也使其难于衡量、理解、报告以及管理响应能力。一些丰富互联网应用程序在加载第一个页面后便不再从浏览器发送任何HTTP GET请求,而是通过其客户端引擎使用异步请求来初始化后续下载。
开发现状
List of RIA Platforms / Approaches
Adobe Flash, Adobe Flex and Adobe AIR
Adobe Flash是创建富网络应用程序另一个方法。这项技术是跨平台,用来产生用户界面。
Adobe Flex是一个框架,提供选项给开发者,经由编译MXML,(一个以XML为基础的接口描述语言),来建造使用这接口。这个Adobe Flex框架编译并转成SWF file后,其能在Adobe Flash player上运行。
Backbase
Curl
Google"s GWT framework
Google Web Toolkit(GWT)提供WYSIWYG的AJAX设计接口。可让开发人员使用Java程序设计语言,快速建置与维护复杂但高性能的JavaScript前端应用程序,借此减轻开发人员负担。
Java applets
Java applets是Java语言的一种浏览器程序。
Java applications
Java application 是由Java语言编写的应用程序
JavaFX
Microsoft ActiveX controls
Microsoft Silverlight
Silverlight原名WPF/E,使用XAML,是一种基于XML的语言,有声录影(Movie Clips)、向量图形(Vector Graphics)等功能,被称为是“Flash Killer”,亦可运行于Firefox甚至Safari等浏览器。Silverlight 3.0可支持H.264影音媒体格式与3D绘图能力。
Mozilla Prism
OpenLaszlo
REBOL 2.6 and Seaside for Smalltalk
ZK
ZK是一个广受欢迎的开放码AJAX框架,只需写少许的程序,不需要写JavaScript,就能丰富网络应用程序接口。
RIA Related Topics
RIA with real-time push
Demand for localised usage of RIA
Client-side functionalities and development tools for RIA needed
User interface languages
Other techniques
参考资料
参看
Adobe Flex
Adobe AIR
AJAX
Ajax Frameworks
Appcelerator
Backbase Enterprise Ajax
Bindows Ajax Framework
Canoo UltraLightClient
Comet or server push
Curl
Dojo Toolkit
Echo
Ext JS
Google Gears
Google Web Toolkit
HTML5
IBM Blue Spruce
ICEfaces
IT Mill Toolkit
Java
JavaFX
jZeno
Lobo RIA Platform
MicrosoftSilverlight
Morfik
Moonlight
Nexaweb
Omnis
OpenLaszlo
PIGUI
REBOL
RemoteXUL
Remote Scripting
Seaside for Smalltalk
Single Page Application
User Interface Description Language (UIDL)
Web Application Framework
Web desktop
Windows Presentation Foundation
XoetropeXUI
ZK Framework
免责声明:以上内容版权归原作者所有,如有侵犯您的原创版权请告知,我们将尽快删除相关内容。感谢每一位辛勤著写的作者,感谢每一位的分享。
- 有价值
- 一般般
- 没价值