Aplicación de Internet enriquecida
La versión actual de la página aún no ha sido revisada por colaboradores experimentados y puede diferir significativamente de la
versión revisada el 19 de julio de 2021; las comprobaciones requieren
4 ediciones .
Una aplicación Rich Internet (web) [1] [2] ( ing. Rich Internet Application , RIA ) es una aplicación web descargada por un usuario a través de Internet , diseñada para realizar las funciones de las aplicaciones de escritorio tradicionales y que se ejecuta en el dispositivo del usuario ( no en un servidor).
Tecnologías utilizadas para implementar RIA:
Principales características:
- RIA consta de dos partes: cliente y servidor;
- la parte del servidor RIA se ejecuta en el servidor, puede almacenar la información necesaria para que la aplicación funcione y puede manejar solicitudes provenientes de la parte del cliente RIA;
- la parte del cliente RIA se ejecuta en la computadora del usuario, dibuja la interfaz de usuario , ejecuta las solicitudes del usuario y, si es necesario, puede enviar solicitudes a la parte del servidor RIA;
- La parte del cliente de RIA se ejecuta en un entorno seguro llamado " sandbox " ( sandbox en inglés ), y no requiere la instalación de software adicional .
Según [3] , en julio de 2012, las plataformas más populares utilizadas para crear RIA eran Adobe Flash , JavaFX , Microsoft Silverlight .
Historia
El término "RIA" fue mencionado por primera vez por Macromedia en un libro blanco de marzo de 2002. La idea de RIA existió unos años antes con los siguientes nombres:
- " Secuencias de comandos remotas " ( Microsoft ; alrededor de 1998 );
- "X Internet" (Forrester Research; octubre de 2000);
- "Cliente rico (web)";
- aplicación web rica.
Las aplicaciones web tradicionales funcionan así.
- El cliente envía una solicitud al servidor y espera una respuesta.
- El servidor recibe una solicitud del cliente, genera y envía una respuesta al cliente.
- El cliente recibe y muestra la respuesta.
Estas acciones se repiten constantemente (ciclo). En tal arquitectura, el cliente solo se dedica a mostrar información (contenido estático, por ejemplo, HTML ) y transfiere todas las tareas de procesamiento de datos al servidor. La principal desventaja de esta arquitectura es que todo el trabajo lo realiza el servidor. Puede aumentar la velocidad de la aplicación si parte del trabajo se traslada al cliente.
En la arquitectura RIA, el cliente puede realizar parte o la totalidad del trabajo.
El desarrollo gradual de los estándares de red de Internet ha llevado a la posibilidad de implementar RIA. Sin embargo, es difícil trazar una línea clara entre qué tecnologías incluyen RIA y cuáles no. Pero todos los RIA tienen una característica: el llamado "motor de cliente" se carga en el dispositivo del usuario antes de que comience el RIA; en el futuro, el motor se puede recargar en el curso de la aplicación.
El "motor de cliente" implementa funciones que no están disponibles para las aplicaciones web tradicionales, se puede cargar en el contexto de un navegador web (HTML, JavaScript) o en el contexto de un complemento de navegador web (complemento) (Adobe Flash , JavaFX, Microsoft Silverlight, Native Client). El "motor de cliente" generalmente es responsable de representar (dibujar) la interfaz de usuario (IU) (por ejemplo, implementar una IU para un RIA puede ser más simple y rápido que para una aplicación web tradicional) e interactuar con el servidor (por ejemplo, el lado del cliente de un RIA puede enviar solicitudes al back-end de RIA de forma síncrona (como las aplicaciones web tradicionales) o de forma asíncrona ). Las capacidades del "motor de cliente" pueden estar limitadas por las capacidades del dispositivo y el sistema operativo del usuario .
Beneficios
Beneficios de las aplicaciones web:
- la aplicación web no requiere instalación (los usuarios descargan la aplicación del servidor según sea necesario; esto asegura la distribución automática de la aplicación);
- la aplicación web se actualiza automáticamente (la última versión de la aplicación está alojada en el servidor);
- una aplicación web puede ejecutarse en cualquier dispositivo con conexión a Internet y bajo cualquier sistema operativo (la variedad de sistemas operativos no crea un problema gracias a una única API para todos los sistemas operativos );
- cuando se ejecuta una aplicación web, el dispositivo del usuario es menos susceptible a la infección por virus que cuando se ejecutan archivos binarios ejecutables (la aplicación web se ejecuta en un espacio aislado).
Ventajas de RIA en comparación con las aplicaciones web tradicionales, logradas mediante el uso de las capacidades del "motor de cliente":
- la capacidad de usar controles estándar del sistema operativo en la interfaz de usuario (por ejemplo, usar un control deslizante para cambiar datos);
- la capacidad de usar acciones estándar para interactuar con otros programas (por ejemplo, arrastrar y soltar , copiar datos al portapapeles );
- la capacidad de realizar cálculos en el dispositivo del usuario (sin enviar los datos personales del usuario al servidor (por ejemplo, una calculadora de hipotecas ));
- opciones flexibles para construir una interfaz de usuario (por ejemplo, validación de los datos ingresados por el usuario durante el proceso de entrada sin enviar solicitudes al servidor ( interactividad ));
- la capacidad de continuar la aplicación después de enviar una solicitud al servidor (asíncrono);
- la capacidad de descargar datos del servidor antes de que el usuario los solicite (por ejemplo, en Google Maps , los fragmentos de mapas ubicados junto al fragmento que el usuario está mirando se cargan con anticipación);
- la posibilidad de reducir la carga en el servidor (en el caso de realizar cálculos en el cliente), y, en consecuencia, la posibilidad de aumentar el número de sesiones procesadas por el servidor simultáneamente (sin reemplazar el hardware).
Desventajas
Desventajas de RIA:
- falta de acceso a los recursos del sistema operativo (ya que la aplicación web se ejecuta en un " sandbox "). Si los permisos de recursos son incorrectos, es posible que los RIA no funcionen correctamente;
- ejecutar una aplicación web puede requerir la ejecución de código escrito en un lenguaje de secuencias de comandos (por ejemplo, en JavaScript); si el usuario desactiva la capacidad de ejecutar código, es posible que RIA no funcione correctamente o que no funcione en absoluto;
- baja velocidad de las aplicaciones web multiplataforma. Para garantizar la independencia de la plataforma RIA, el lado del cliente RIA puede usar código escrito en un lenguaje de secuencias de comandos (como JavaScript); al ejecutar dicho código, se produce una caída del rendimiento, un problema grave para los dispositivos móviles. Este problema no ocurre cuando se utiliza un lenguaje integrado compilado en el lado del cliente (por ejemplo, Java), donde el rendimiento es comparable al uso de lenguajes integrados tradicionales, ya sea Adobe Flash o Microsoft Silverlight , en los que el código del programa se ejecuta directamente en Flash Player. o complemento de Silverlight, respectivamente. ;
- la necesidad de instalar un "motor de cliente";
- mucho tiempo de carga de la aplicación web. El cliente descarga el lado del cliente RIA desde el servidor cada vez . Debido a que la mayoría de los datos que se cargan se almacenan en caché, el cliente RIA debe cargarse al menos una vez para acelerar el inicio. El tiempo de descarga depende del tamaño de los datos descargados; para reducir el tamaño de la parte del cliente de RIA, los desarrolladores pueden comprimirla o dividirla en partes que se cargan según sea necesario;
- pérdida de integridad. Si una aplicación se basa en X/HTML, puede haber conflictos entre los objetivos de la aplicación (que, naturalmente, quiere tener control sobre su presentación y acciones) y los objetivos de X/HTML (que quiere ceder el control). La interfaz DOM para X/HTML permite crear un RIA, pero no hay garantía de que funcione correctamente. Debido a que el cliente RIA puede cambiar la estructura básica de la aplicación y anular sus acciones y presentación, esto puede provocar que la aplicación falle en el lado del cliente. Al final, este problema se puede resolver mediante un nuevo mecanismo cliente-servidor que le da al cliente RIA acceso limitado para modificar aquellos recursos que no están dentro de su alcance. El trabajo del software estándar nativo no causa tales problemas, ya que, por definición, automáticamente tienen todos los derechos necesarios sobre los recursos locales;
- la imposibilidad de indexar una aplicación web por los motores de búsqueda . Es posible que los motores de búsqueda no puedan indexar contenido RIA. Sin embargo, a menudo no se requiere la indexación;
- dependencia de la conexión a internet. Los RIA diseñados para reemplazar las aplicaciones de escritorio deben permitir que los usuarios se conecten a la red según sea necesario, por ejemplo, no deben dejar de funcionar cuando un usuario se mueve entre áreas de cobertura inalámbrica . En 2007, las aplicaciones típicas de RIA requerían una conexión permanente a la red. Con la llegada de HTML5, este problema se vuelve menos relevante; La API de almacenamiento local de HTML5 le permite almacenar datos en el lado del cliente; La API de archivos HTML5 permite el acceso al sistema de archivos del dispositivo del usuario.
Retos de desarrollo de aplicaciones
La llegada de la tecnología RIA estuvo acompañada de importantes dificultades en el desarrollo de aplicaciones web . Las aplicaciones web tradicionales, basadas en HTML estándar, con una arquitectura relativamente simple y un conjunto de funciones bastante limitado, eran relativamente fáciles de desarrollar y administrar. Las personas y las organizaciones que implementan aplicaciones web basadas en la tecnología RIA a menudo enfrentan desafíos adicionales de desarrollo, prueba, medición y soporte.
El uso de la tecnología RIA plantea nuevos retos para la gestión de servicios SLM ( service level management ), no todos resueltos hasta la fecha . Los desarrolladores de aplicaciones no siempre tienen en cuenta las preguntas relacionadas con SLM y los usuarios casi no las perciben. Sin embargo, son vitales para la implementación exitosa de una aplicación en Internet. Los principales aspectos que complican el proceso de desarrollo de RIA son los siguientes:
- complejidad tecnológica . La capacidad de compartir el código de la aplicación directamente con los clientes brinda a los desarrolladores y diseñadores más libertad creativa. Pero esto, a su vez, complica el desarrollo de la aplicación, aumenta la probabilidad de errores durante la implementación y dificulta la prueba del software . Estas complicaciones alargan el proceso de desarrollo, independientemente de las especificaciones de la metodología y el proceso de desarrollo. Algunos de estos problemas se pueden reducir mediante el uso de un marco de aplicación web para estandarizar el desarrollo de RIA . Sin embargo, la creciente complejidad de las soluciones de software puede complicar y alargar el proceso de prueba a medida que aumenta la cantidad de casos de uso que se prueban. Las pruebas incompletas reducen la calidad y la confiabilidad de la aplicación durante su uso. Se puede discutir si esto se aplica solo a la tecnología RIA oa la complejidad del desarrollo en general. Por ejemplo, se hizo exactamente el mismo argumento cuando Apple y Microsoft anunciaron de forma independiente la GUI en la década de 1980, y tal vez incluso cuando Ford presentó su Modelo T. Sin embargo, la humanidad ha demostrado una capacidad notable para absorber todas las innovaciones tecnológicas durante décadas, si no siglos;
- La arquitectura RIA rompe el paradigma de la página web . Las aplicaciones web tradicionales son una colección de páginas web ; para descargar cada página web, el cliente envía una solicitud HTTP GET ; tal modelo se llama el paradigma de la página web. RIA "rompe" este paradigma; el servidor ahora debe atender solicitudes asincrónicas para admitir una experiencia más interactiva. Para obtener información sobre la cantidad de tiempo dedicado al trabajo del RIA, se deben desarrollar nuevas tecnologías estándar. En ausencia de tales tecnologías (herramientas estándar), los desarrolladores de RIA deben agregar las herramientas de medición de datos necesarias para SLM a sus aplicaciones;
- la asincronía dificulta la identificación de problemas de rendimiento . Paradójicamente, las medidas tomadas para mejorar el tiempo de respuesta de la aplicación dificultan la determinación del tiempo de respuesta, la medición del tiempo y la gestión de la aplicación. Algunos RIA se ejecutan en un navegador web después de que el navegador haya descargado una sola página web, utilizando un "motor de cliente" para descargar de forma asíncrona los datos necesarios; el navegador ya no envía solicitudes HTTP GET . El lado del cliente del RIA se puede programar para descargar constantemente nuevos datos (contenido) y actualizar el contenido de la pantalla, o (en aplicaciones que usan el enfoque Comet ) el lado del servidor del RIA puede enviar constantemente nuevos datos (contenido) al lado del cliente a través de una conexión siempre abierta. En este caso, el concepto de “cargar una página” ya no es aplicable. Todo esto introduce ciertas dificultades en la medición del tiempo y la división del tiempo de respuesta de la aplicación, que son requisitos fundamentales para identificar problemas de rendimiento y SLM. Las herramientas diseñadas para medir el tiempo de actividad de las aplicaciones web tradicionales, según las especificaciones y el conjunto de herramientas de la aplicación, pueden considerar cada página web solicitada a través de HTTP, individualmente o como un conjunto de indicadores no relacionados. Sin embargo, ninguno de estos enfoques muestra lo que realmente sucede a nivel de aplicación;
- El "motor de cliente" dificulta la medición del tiempo de respuesta de la aplicación . Para las aplicaciones web tradicionales, el software de medición de tiempo se puede ubicar en la máquina cliente y en una máquina cercana al servidor, puede monitorear el flujo de tráfico de red en las capas TCP y HTTP . Dado que TCP y HTTP son protocolos sincronizados y predecibles, el sniffer puede leer datos de paquetes TCP y HTTP, interpretar los datos leídos e inferir tiempos de respuesta mediante el seguimiento de mensajes HTTP y el tiempo de reconocimiento de paquetes TCP de bajo nivel. Usar un sniffer para medir el tiempo de las aplicaciones que utilizan la arquitectura RIA es difícil porque el motor de usuario divide la interacción entre el cliente y el servidor en dos bucles separados que funcionan de forma asíncrona: el bucle de primer plano (motor de usuario) y el back-end ( bucle motor-servidor). Ambos ciclos son importantes porque su relación común determina el comportamiento de la aplicación. Pero esta relación depende únicamente de la arquitectura de la propia aplicación, que en la mayoría de los casos no se puede predecir con herramientas de medición, especialmente la primera (sniffer), que solo puede observar uno de los dos ciclos. Por lo tanto, la medición más completa del tiempo RIA solo se puede obtener utilizando herramientas que estén del lado del cliente y del observador en ambos ciclos.
Véase también
Notas
- ↑ Larry Seltzer. Las aplicaciones dinámicas de Internet son atractivas para los atacantes // PCWeek, 15/09/2010.
- ↑ Powers S., Powers S. Adición de Ajax. - BHV-Petersburgo, 2009. - S. 3-4. - ISBN 978-5-9775-0226-9 .
- ↑ Cuota de mercado de aplicaciones de Internet enriquecidas (enlace descendente) . Consultado el 9 de diciembre de 2010. Archivado desde el original el 6 de octubre de 2011. (indefinido)
Literatura
- Konstantin Kovalev. RIA significa libertad // World of PC. - 2008. - Nº 3. - S. 62-65. — ISSN 0235-3520