丰富互联网应用程序(英语:Rich Internet applications,简称RIA),又译为丰富性网络应用服务,是一种具有近似于传统桌面应用软件系统功能和特性的网络应用系统。RIA系统最大的特点是将大部分处理任务都从用户界面端移植到客户端,仅保留一些必要数据与服务器端进行信息交互。
RIA系统的特性:
- 运行于浏览器中,不需要额外安装支持软件
- 在本地运行时,受安全沙箱全程保护
Adobe Flash是建立富网络应用程序另一个方法。这项技术是跨平台,用来产生用户界面。Adobe Flex是一个框架,提供选项给开发者,经由编译MXML,(一个以XML
为基础的接口描述语言),来建造使用这接口。这个Adobe Flex框架编译并转成Swf后,其能在Adobe Flash player上执行。
Java applets是Java语言的一种类浏览器应用程序。
Silverlight原名WPF/E,使用XAML,是一种基于XML的语言,有声录影(Movie Clips)、矢量图形(Vector Graphics)等功能,被称为是“Flash Killer”,亦可执行于Firefox甚至Safari等浏览器。Silverlight 3.0可支持H.264影音媒体格式与3D绘图能力。
“丰富互联网应用程序系统”一词源于Macromedia公司在2002年3月发表的一份白皮书[1],尽管如此,该词在更早的年代中就已包含其他含义,包括远程脚本(由微软于1998年左右提出)、X Internet(由Forrester Research于2000年10月提出)[2]、丰富(网页)客户端和丰富网络应用[3]。
尽管与开发运行在桌面的程序相比,开发运行在浏览器中的应用程序要更受限、更复杂、更困难,但是这种努力还是值得的,因为它具有以下优点:
- 安装简便—终端用户可在任何连接到互联网上的设备中使用程序,而应用程序会自动或以简单手动方式更新到最新版本,更新与使用费用与桌面程序和操作系统相比要经济的多。
- 有很多工具支持离线使用,例如Adobe AIR,Google Gears等等。
- 多数丰富互联网应用程序借由网页浏览器,可以跨平台使用
- 与可执行文件相比,基于网络的应用程序可以有效的避免病毒侵袭(此一优点或已过时)
由于丰富互联网应用程序采用客户端引擎,所以它具有以下特点:
- 表现力丰富:丰富互联网应用程序能在基于标准浏览器的网页应用,实现 HTML标签难以实作的用户界面效果。这种内涵更丰富的交互涵盖所有在客户端所能实现的功能,例如拖拽功能、滑块功能,而且这些功能无需与服务端交互数据,完全是在客户端进行运算,如抵押计算。
- 反应更加迅速:与那些总须与远程服务器进行交互的标准网页浏览应用相比,丰富互联网应用界面的反应要迅速的多,这也是丰富互联网应用程序特点之一。成熟的丰富互联网应用,会给人近似于本地端操作系统桌面程序的经验。
而且,使用客户端引擎还有以下好处:
- C/S结构的负担平衡(此点或为误解,实现刚好相反):丰富互联网应用程序可以使客户端和服务端对资源的需求更加平衡,从而使服务器不必再像传统网页应用中那样一直高负荷的运转。由此服务端的资源得到了解放,从而提升了同一服务端硬件能并行服务的客户端会话数量。
- 异步通信:无须等待用户执行诸如在按钮或链接上点击的交互操作,客户端引擎便可与服务器端进行交互。如此,用户便可在客户端引擎跟服务端通信的同时,异步地进行页面浏览或交互。丰富互联网应用程序的设计方式,便可在免予让用户等待的情境下,在客户端与服务器端之间传输数据(因此服务端可能收到更多 http请求,负荷会比传统网页更重)。程序会预先从服务器端读取数据,即程序预见到未来可能需要某些数据的时候,会先于用户端发出请求之前将其下载,可提升回应后续请求的速度。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请求,而是通过其客户端引擎使用异步请求来初始化后续下载。