Rich Internet Application

The term “RIA” was first mentioned by Macromedia in an official announcement published in March 2002. The idea of ​​RIA existed several years earlier with the following names:

• “ Remote Scripting ” ( Microsoft ; circa 1998 );
• “X Internet” (Forrester Research; October 2000);
• "Rich (web) client";
• "Rich web application."

Traditional web applications work as follows.

1. The client sends a request to the server and waits for a response.
2. The server receives a request from the client, generates and sends a response to the client.
3. The client receives and displays the response.

These actions are constantly repeated (cycle). In such an architecture, the client only deals with the display of information (static content, for example, HTML ), and transfers all tasks for data processing to the server. The main drawback of this architecture is that all the work is done by the server. You can increase the speed of the application if you shift part of the work to the client.

In RIA architecture, part or all of the work can be done by the client.

The gradual development of Internet standards has led to the possibility of implementing RIA. However, it is difficult to draw a clear line between which technologies include RIA and which do not. But all RIAs have one peculiarity: the so-called “client engine” is loaded on the user's device before starting the RIA; in the future, the engine can be loaded as the application runs.

The “client engine” implements capabilities not available to traditional web applications, can be loaded in the context of a web browser (HTML, JavaScript) or in the context of a web browser plug-in (add-on), Adobe Flash, JavaFX, Microsoft Silverlight, Native Client). The “client engine” is usually responsible for rendering (drawing) the user interface (UI) (for example, the implementation of the UI for RIA can be simpler and can work faster than for a traditional web application) and interaction with the server (for example, the client part of RIA can send requests to the server side of the RIA both synchronously (both traditional web applications) and asynchronously ). The capabilities of the “client engine” may be limited by the capabilities of the device and the user's OS .

Web Application Benefits:

• the web application does not require installation (users download the application from the server as necessary; this ensures the automatic distribution of the application);
• the web application is updated automatically (the latest version of the application is hosted on the server);
• the web application can run on any device that has an Internet connection and is running any OS (a variety of OSs does not create problems due to the same API for all OSs);
• when the web application is running, the user's device is less susceptible to virus infection than when executing binary executable files (the web application is executed in the sandbox).

Advantages of RIA in comparison with traditional web applications, achieved by using the capabilities of the “client engine”:

• the ability to use standard controls for the OS in the UI (for example, using a slider to change data);
• the ability to use typical actions for interacting with other programs (for example, drag-and-drop , copying data to the clipboard );
• the ability to perform calculations on the user's device (without sending personal user data to the server (for example, a mortgage calculator));
• flexible UI construction capabilities (for example, validation of user input during input without sending requests to the server (interactivity));
• the ability to continue the application after sending a request to the server (asynchrony);
• the ability to download data from the server before the user requests data (for example, in Google Maps map fragments located next to the fragment that the user is looking at are loaded in advance);
• the ability to reduce the load on the server (in the case of performing calculations on the client), and, therefore, the ability to increase the number of sessions processed by the server at the same time (without replacing the hardware).

RIA disadvantages:

• lack of access to OS resources (since the web application runs in the sandbox ). If access rights to resources are incorrect, the RIA may not work correctly;
• To run a web application, you may need to execute code written in a scripting language (for example, JavaScript); if the user disables code execution, the RIA may not work correctly or may not work at all;
• low speed multi-platform web applications. To ensure the independence of the RIA from the platform, the client side of the RIA can use code written in a scripting language (for example, JavaScript); when executing such code, a drop in performance is observed - a serious problem for mobile devices. This problem does not occur when using an embedded language compiled on the client side (for example, Java), where the performance is comparable to using traditional embedded languages, either with Adobe Flash or Microsoft Silverlight , in which the program code is run directly in the Flash Player or Silverlight plugin, respectively ;
• the need to install a "client engine";
• extended web application load times. Each time the client downloads the client part of the RIA from the server. Since most of the downloaded data is stored in the cache, the RIA client part must be loaded at least once to speed up startup. Download time depends on the size of the downloaded data; to reduce the size of the RIA client part, developers can compress it or divide it into parts, downloaded as needed;
• loss of integrity. If the application is based on X / HTML, conflicts may arise between the goals of the application (which, naturally, wants to have control over its presentation and actions) and the goals of X / HTML (which wants to give control). The DOM interface for X / HTML makes it possible to create an RIA, but it does not give any guarantees that it will work correctly. Due to the fact that the RIA client can change the basic structure of the application and redefine its actions and presentation, this can lead to an application error on the client side. In the end, this problem can be solved through a new client-server mechanism that provides the RIA client with limited access to change those resources that are not within its scope of authority. The work of the native standard software does not cause such problems, since by definition they automatically have all the necessary rights to local resources;
• the impossibility of indexing a web application by search engines . Search engines may not be able to index RIA content. However, often, indexing is not required;
• Dependence on internet connection. RIAs created to replace desktop applications should allow users to connect to the network as needed, for example, should not lose their functionality when moving a user between wireless coverage areas . By 2007, typical RIA applications required a permanent network connection. With the advent of HTML5, this problem becomes less relevant; The HTML5 local storage API allows you to store data on the client side; HTML5 File API allows you to access the user's device’s file system.

The advent of RIA technology has been accompanied by significant difficulties in the development of web applications . Traditional web applications built on the basis of standard HTML, which has a relatively simple architecture and a rather limited set of functions, were relatively easy to develop and manage. Individuals and organizations implementing RIA-based web applications often face additional challenges in development, testing, measurement, and support.

The use of RIA technology poses new challenges for service level management (SLM), not all of which have been resolved to date. Questions regarding SLM are not always taken into account by application developers and are hardly perceived by users. However, they are vital to the successful implementation of the application on the Internet. The main aspects that complicate the RIA development process are the following:

• technological complexity . The ability to transfer application code directly to clients gives great creative freedom to developers and designers. But this, in turn, complicates the development of the application, increases the likelihood of errors during implementation and complicates software testing . These complications lengthen the development process, regardless of the specific methodology and development process. Some of these problems can be reduced by using the web application framework for standardizing RIA development. However, the growing complexity in software solutions can complicate and lengthen the testing process with an increase in the number of tested use cases. Incomplete testing reduces the quality and reliability of the application during its use. One can argue about whether this applies only to RIA technology or to the complexity of development in general. For example, the exact same argument was made when Apple and Microsoft independently announced a GUI in the 1980s, and perhaps even when Ford introduced its Model T. However, humanity has demonstrated a remarkable ability to absorb all technological innovations for decades, if not centuries;
• RIA architecture breaks the web page paradigm . Traditional web applications are a collection of web pages; to download each web page, the client sends an HTTP GET request ; such a model is called a web page paradigm. The RIA is breaking this paradigm; the server should now serve asynchronous requests to support a more interactive interface. To obtain information on the amount of time spent working with the RIA, new standard technologies must be developed. In the absence of such technologies (standard tools), RIA developers should add to their applications the means of measuring the data necessary for SLM;
• Asynchrony makes it difficult to identify performance issues . Paradoxically, measures taken to reduce application response time make it difficult to determine response time, measure time, and manage the application. Some RIAs run in the web browser after the browser downloads one web page, use the “client engine” to asynchronously download the necessary data; The browser no longer sends any HTTP GET requests. The client part of the RIA can be programmed so as to constantly download new data (content) and update the contents of the screen, or (in applications using the Comet approach) the server part of the RIA can constantly send the client part new data (content) through a constantly open connection. In this case, the term “page loading” is no longer applicable. All this introduces certain difficulties in measuring the time and sharing the application response time, which are fundamental requirements for identifying performance and SLM problems. The tools designed to measure the runtime of traditional web applications, depending on the specifics and toolkit of the application, can consider each web page requested via HTTP, individually or as a set of indicators not related to each other. However, none of these approaches shows what actually happens at the application level;
• "Client engine" complicates the measurement of application response time . For traditional web applications, time-measuring software can be located on the client machine and on a machine close to the server, it can monitor the flow of network traffic at the TCP and HTTP levels . Since TCP and HTTP are synchronized and predictable protocols, the sniffer can read data from TCP and HTTP packets, interpret the read data and draw conclusions about the response time using HTTP message tracking and TCP packet acknowledgment time at the lower level. Using a sniffer to measure the time of applications using the RIA architecture is difficult because the user engine breaks down the interaction between the client and the server into two separate cycles that work asynchronously - the foreground cycle (user-engine) and the background cycle (engine-server). Both of these cycles are important because their common relationship determines the behavior of the application. But this relationship depends only on the architecture of the application itself, which in most cases cannot be predicted by measuring instruments, especially the first (sniffer), which can observe only one of two cycles. Therefore, the most complete RIA time measurement can only be obtained using tools that are on the client and observer side in both cycles.

• Rich media
• WAI-ARIA
• Comparison of platforms for creating RIA

• Konstantin Kovalev. RIA - means freedom // World of PC. - 2008. - No. 3. - S. 62-65. - ISSN 0235-3520