RIA

百科解释

目录·发展历史
·优点
·缺点
·开发现状
·List of RIA Platforms / Approaches
·RIA Related Topics
·References

“富互联网应用系统”一词源于Macromedia公司在2002年3月发表的一份白皮书，尽管如此，该词在更早的年代中就已包含以下含义：

远程脚本（由微软于1998年左右提出）
X Internet（由Forrester Research于2000年10月提出）
富（网页）客户端
富网络应用

传统的网络应用程序将所有交互应用都集中在基于“瘦”客户端的C/S架构上。在这样的系统中，所有处理操作均在服务器端执行，客户端仅仅是用于显示静态的信息内容（如HTML）。这种系统最大的缺陷是所有的交互操作都必须经由服务器端进行，首先客户端要将请求数据上传至服务器端，然后服务器端作出响应并传回结果，最后客户端在重载响应信息。而通过使用在客户端执行指令的客户端技术，RIA可以有效的避免延时，实现程序与用户操作的同步。这种差异有点类似于“终端与主机”或C/S结构与“胖”应用系统的差异。
随着时间的迁移，互联网标准正在逐渐地改变着，从而以适应这种新技术，所以也就很难为富互联网应用划定出一个明确的概念范围。但是，所有的富互联网应用都有一个相同的特征：它们在客户端与服务器端之间引入了通常被叫做“客户端引擎”的中间代码层。这种客户端引擎通常作为应用初始化的一部分被下载，也可能随着应用的运行在后续代码中作为补丁被下载并补充进来。客户端引擎充当浏览器的一个扩展，而且通常还会接管呈现用户界面和与服务器端进行通信的职责。
富互联网应用的功能可能会受客户端操作系统性能的限制。但是，在大多数情况下，客户端引擎会按设计者的意愿执行某些编辑好的功能，从而提升用户界面某些方面或在一定程度上改进用户界面的运算速率。而且增加一个客户端引擎也不会导致任何应用脱离原有浏览器与服务器端之间的同步交互模式，其实大多数富互联网应用中，客户端引擎在原基础上与服务器端进行的是异步通信。

优点

尽管与开发运行在桌面的程序相比，开发运行在浏览器中的应用程序要更受限、更复杂、更困难，但是这种努力还是值得的，因为它具有以下优点：

安装简便——更新与使用费用与桌面程序和操作系统相比要经济的多。
终端用户可以自动或简单手动的更新到最新版本
用户可以在任何连接到互联网上的电脑中使用程序
有很多工具支持离线使用，例如Adobe AIR，Google Gears等等。
多数富互联网应用程序可以跨平台使用
与可执行文件相比，基于网络的应用程序可以有效的避免病毒的侵袭

由于富互联网应用采用客户端引擎，所以它具有以下特点：

表现力丰富。富互联网应用能在基于标准浏览器的网页应用实现HTML标签根本无法实现的用户界面效果。这种内涵更丰富的交互涵盖所有在客户端所能实现的功能，例如拖拽功能、滑块功能，而且这些功能无需与服务器端交互数据，完全是在客户端进行运算，如抵押计算。
反应更加迅速。与那些总须与远程服务器进行交互的标准网页浏览器相比，富互联网应用界面功能的反应要迅速的多，这也是富互联网应用特点之一。

最成熟的富互联网应用会给人近似于桌面程序的外观感觉。而且，使用客户端引擎还有以下好处：

C/S结构的负担平衡。富互联网应用可以使客户端和服务器端对资源的需求更加平衡，从而使服务器不必再像传统网页应用中那样一直高负荷的运转。由此服务器端的资源得到了解放，从而提升了同一服务器端硬件设施所能并行服务的客户端会话数量。
异步通信。无须等待用户执行诸如在按钮或链接上点击的交互操作，客户端引擎便可与服务器端进行交互。如此，用户便可在客户端引擎跟服务器端通信的同时，异步地进行页面浏览或交互。从而，富互联网应用的设计者便可在免予让用户等待的情况下，在客户端与服务器端之间传输数据。程序会预先从服务器端预取数据，即程序预见到未来可能需要某些数据的时候，会预先于用户请求将其下载，借此来提升响应后续请求的速度。Google Maps便是利用了这种技术，先于用户将屏幕滚动到临近的地区，预取到上边的地图片断。
网络效率高。富互联网应用的网络通信量也会明显减少，这是由于在决定需要与服务器端交换什么数据时，为应用程序专门设计的客户端引擎会比标准的网页浏览器更智能。由于每次交互所需传输的数据量变少了，从而总负载也减轻了，所以每个请求和响应的速度也就提升。但是，滥用异步请求和预取技术有可能会抵消这种优势带来的好处，有时甚至还会起到反作用。因为程序无法准确地预期每个用户下一步操作所需的数据，所以采用这种技术时，时常会下载多余的数据，而对大多数客户端而言，这些数据其实并不是用户真实需要的。

缺点

富互联网应用存在以下缺陷：

受限于安全沙箱。由于富互联网应用程序运行在安全沙箱中，所以其对系统资源的访问会受到限制。一旦对系统资源的访问出现错误，那么富互联网应用程序就将无法正常运行。
依赖于脚本支持。富互联网应用程序常常需要Javas cript或其它脚本语言的支持。一旦用户浏览器对这些脚本进行屏蔽，富互联网应用将无法正常运作。
客户端运行速度受限。为实现平台无关性，一些富互联网应用选用诸如Javas cript这类脚本语言来编写其客户端脚本，从而导致了性能上的损失（在移动设备中，此类问题尤为显著）。而对于如Java这类的客户端语言是不存在这类问题的，因为它的性能已可比拟传统的编译型语言了，而对于Flash，Curl或Silverlight，因为在其插件中所运行的代码也是经过编译的，所以同样也不存在这类问题。
下载脚本的延时。虽然无需安装软件，但是富互联网应用的客户端引擎还是要从服务器端传送信息到客户端。虽然绝大多数传输信息会被缓存，但这种传输也至少要执行一次。根据下载的类型和大小，脚本的下载可能会是一件令人苦恼的事情。对此，富互联网应用的开发者可采取压缩、分段等技术在一定程度上减少这种延迟带来的影响。
集成困难。如果基于X/HTML开发应用，那么应用程序的目的（向往控制一切表现效果和行为）和X/HTML的目的（向往解除一切控制）之间的冲突会进一步加剧。X/HTML的DOM接口为创建富互联网应用提供了一个可能，但是该方案又会导致富互联网应用中的一些功能瘫痪。因为在该方案中，富互联网应用的客户端可以修改应用程序的基本结构并覆盖其的表现效果和行为，这可能将导致应用程序在客户端的执行错误。最终，该问题通过采用新式的客户端机制来解决，在该机制中，富互联网应用将受限于只能对其自身范围的资源进行修改。（标准的运行在本地软件之所以不存在该类问题是因为其遵循一个自动程序的定义，只能处理它自行分配的资源）。
搜索引擎优化困难。搜索引擎可能无法搜索应用程序文本内容中的索引。
依赖于互联网连接。最理想的替代桌面程序的互联网应用程序要允许用户间断性的上网，这样用户就可以游走在各个热点与办公地之间。鉴于此，一些特殊的平台（如Adobe AIR，Google Gears）就需要允许离线操作的富互联网应用程序。
可访问性存在困难。在富互联网应用中存在很多访问性的困难，其中多数明显地表现为屏幕阅读器在探测由Javas cript引起的HTML内容更变上遇到了极大的困难。
无法部署。除了Adobe的AIR技术以外，其它的富互联网应用不能像传统的桌面应用那样进行部署。

软件开发复杂性
富互联网应用技术的出现给网页应用的开发引入了可观的复杂度。仅使用标准HTML构建的传统的网页应用，其软件架构相对来说要简单，同时也只有有限的开发方案选择，所以相对来说要易于设计和管理。对使用富互联网应用技术的个人或组织而言，他们所面临的额外的复杂度是他们更难于进行设计、测试、评估和支持。
富互联网应用技术的使用引起了若干个在服务级管理（service level management，简称 SLM）上的新挑战。而这些挑战至今也仍未得到彻底解决。服务级管理所关心的并不总是应用开发者的焦点所在，也甚少为应用使用者所察觉，但它们对一个在线应用的成功交付却起着至关重要的作用。富互联网应用架构中使管理过程变得复杂的方面包括：

更大的复杂度然开发变得更加困难。将代码移至客户端的能力，给了应用设计者和开发者更多的创造空间。但是这反过来也让开发变得更加困难，增加了发生过失（bugs）的可能性，也加大了软件测试的复杂度。无伦引入何种方法学或过程，这些复杂化都将延长软件开发过程。这些问题中有些可通过使用网页应用框架对富互联网应用的设计和开发进行标准化来减轻。但是，无论如何，在软件的解决方案中增加复杂度，如果增加了用例的数量，将导致测试过程复杂化和延长。而不完整的测试有会降低应用的质量和使用时的可靠性。有人可能要说，上边讨论的问题并非只是富互联网应用技术特有的，而是关于复杂性的广泛问题。例如，同样的争论就发生于苹果跟微软分别在1980年代发布其GUI时，甚至可能还发生于Ford发布其Model T时。无伦如何，人类已经展示出了在数十年间吸收新技术的优势的能力。

富互联网应用架构违反了网页范式。传统的网页应用可以看成一系列网页，这些网页每页都需单独经历由HTTP GET请求发起下载过程。这种模型被称为网页范式。富互联网应用废掉了这种模型，同时额外引入了异步的服务器端通信方式来支持反应更迅速的用户界面。在富互联网应用总，完整加载一个页面所需的时间可能不再是用户所能察觉到的重要指标，因为（打个比方说）客户端引擎可能为未来预取了一些内容。为对富互联网应用作有效的评估，来反映用户体验的指标，肯定会有新的技术被设计出来。在这种评估技术出现之前，富互联网应用的开发者应该指示他们的应用代码来为SLM产生测量数据。

异步通信导致难以隔离性能问题。看似矛盾地，用以增强应用的响应能力的措施同时也使其难于衡量、理解、报告以及管理响应能力。一些富互联网应用在加载第一个页面后便不再从浏览器发送任何HTTP GET请求，而是通过其客户端引擎使用异步请求来初始化后续下载。

The RIA client engine may be programmed to continually download new content and refresh the display, or (in applications using the Comet approach) a server-side engine can keep pushing new content to the browser over a connection that never closes. In these cases, the concept of a "page download" is no longer applicable. These applications are commonly known as refreshless. These complications make it harder to measure and subdivide application response times, a fundamental requirement for problem isolation and service level management. Tools designed to measure traditional Web applications may -- depending on the details of the application and the tool -- report such applications either as a single Web page per HTTP request, or as an unrelated collection of server activities. Neither des cription reflects what is really happening at the application level.

The client engine makes it harder to measure response time. For traditional Web applications, measurement software can reside either on the client machine or on a machine that is close to the server, provided that it can observe the flow of network traffic at the TCP and HTTP levels. Because these protocols are synchronous and predictable, a packet sniffer can read and interpret packet-level data, and infer the user’s experience of response time by tracking HTTP messages and the times of underlying TCP packets and acknowledgments. But the RIA architecture reduces the power of the packet sniffing approach, because the client engine breaks the communication between user and server into two separate cycles operating asynchronously -- a foreground (user-to-engine) cycle, and a background (engine-to-server) cycle. Both cycles are important, because neither stands alone; it is their relationship that defines application behavior. But that relationship depends only on the application design, which cannot (in general) be inferred by a measurement tool, especially one that can observe only one of the two cycles. Therefore the most complete RIA measurements can only be obtained using tools that reside on the client and observe both cycles.

开发现状

RIAs are still in the early stages of development and user adoption. There are a number of restrictions and requirements that remain:

Browser adoption: Many RIAs require modern web browsers in order to run. Advanced Javas cript engines must be present in the browser as RIAs use techniques such as XMLHTTPRequest for client-server communication, and DOM s cripting and advanced CSS techniques to enable the rich user interface.

Web standards: Differences between web browsers can make it difficult to write an RIA that will run across all major browsers. The consistency of the Java platform, particularly after Java 1.1, makes this task much simpler for RIAs written as Java applets.

Development tools: Some Ajax Frameworks and products such as Curl, Adobe Flex and Microsoft Silverlight provide an integrated environment in which to build RIAs.

Accessibility concerns: Additional interactivity may require technical approaches that limit applications&＃39;&＃39;&＃39;&＃39; accessibility.

User adoption: Users expecting standard web applications may find that some accepted browser functionality (such as the "Back" button) may have somewhat different or even undesired behaviour.

List of RIA Platforms / Approaches

RIA Related Topics

RIA with real-time push
Traditionally, web pages have been delivered to the client only when the client requested for it. For every client request, the browser initiates an HTTP connection to the web server, which then returns the data and the connection is closed. The drawback of this approach was that the page displayed was updated only when the user explicitly refreshes the page or moves to a new page. Since transferring entire pages can take a long time, refreshing pages can introduce a long latency.

Demand for localised usage of RIA
With the increasing adoption and improvement in broadband technologies, fewer users experience poor performance caused by remote latency. Furthermore one of the critical reasons for using an RIA is that many developers are looking for a language to serve up desktop applications that is not only desktop OS neutral but also installation and system issue free.
RIA running in the ubiquitous web browser is a potential candidate even when used standalone or over a LAN, with the required webserver functionalities hosted locally.

Client-side functionalities and development tools for RIA needed
With client-side functionalities like Javas cript and DHTML, RIA can operate on top of a range of OS and webserver functionalities.

User interface languages
Instead of HTML/XHTML, new user interface markup languages can be used in RIAs. For instance, the Mozilla Foundation&＃39;&＃39;&＃39;&＃39;s XML-based user interface markup language XUL - this could be used in RIAs though it would be restricted to Mozilla-based browsers, since it is not a de facto or de jure standard. The W3C&＃39;&＃39;&＃39;&＃39;s Rich Web Clients Activity[1] has initiated a Web Application Formats Working Group whose mission includes the development of such standards [2]. The original DARPA project at MIT which resulted in the W3C also resulted in the web content language Curl which is now in version 5.0.
RIA&＃39;&＃39;&＃39;&＃39;s user interfaces can also become richer through the use of s criptable scalable vector graphics (though not all browsers can render those natively yet) as well as Synchronized Multimedia Integration Language (SMIL).

Other techniques
RIAs could use XForms to enhance their functionality.
Using XML and XSLT along with some XHTML, CSS and Javas cript can also be used to generate richer client side UI components like data tables that can be resorted locally on the client without going back to the server. Mozilla and Internet Explorer browsers both support this.
The Omnis Web Client is an ActiveX control or Netscape plug-in which can be embedded into an HTML page providing a rich application interface in the end-user&＃39;&＃39;&＃39;&＃39;s web browser.
Appcelerator is an open source platform for developing rich Internet applications using a service-oriented architecture and standards such as HTML, CSS and Javas cript. Appcelerator applications can integrate automatically with several different integration points on the service tier using Java, PHP, Python, .NET, Perl and Ruby on Rails. Appcelerator applications can use pre-built widgets to assemble high quality RIAs. Appcelerator is licensed under the GNU GPL version 2 License.

References

^ W3C（2008年3月15日）．W3C Rich Web Clients．w3c.org．
^ W3C（2008年3月15日）．Web Application Formats Working Group．w3c.org．

通信词典解释