RIA, las Aplicaciones de Internet Enriquecidas

Introducción

Las aplicaciones de Internet enriquecidas, o RIA (rich Internet applications"), son aplicaciones web que tienen la mayoría de las características de las aplicaciones de escritorio tradicionales. Estas aplicaciones utilizan un navegador web estandarizado para ejecutarse y por medio de complementos o mediante una máquina virtual se agregan las características adicionales.

Las RIA surgen como una combinación de las ventajas que ofrecen las aplicaciones web y las aplicaciones tradicionales. Buscan mejorar la experiencia del usuario.

Normalmente en las aplicaciones web, hay una recarga continua de páginas cada vez que el usuario pulsa sobre un enlace. De esta forma se produce un tráfico muy alto entre el cliente y el servidor, llegando muchas veces a recargar la misma página con un cambio mínimo.

En los entornos RIA, en cambio, no se producen recargas de página, ya que desde el principio se carga toda la aplicación, y sólo se produce comunicación con el servidor cuando se necesitan datos externos como datos de una base de datos o de otros ficheros externos.

Qué son las Aplicaciones RIA?

¿Cuántas veces nos hemos quejado de lo poco interactivas que son las aplicaciones web que utilizamos habitualmente? Necesitan recargar la página cuando queremos realizar tareas que son simples o que requieren un cambio mínimo. Esta lentitud suele atormentarnos y hace que echemos de menos la agilidad que nos ofrecen otro tipo de aplicaciones que ya conocemos, como las instaladas en el propio PC o las aplicaciones cliente-servidor.

A diferencia de las aplicaciones web habituales, las RIA (Rich Internet Applications) enriquecen la experiencia del usuario a través de interfaces propias de aplicaciones de escritorio, que suelen ser más interactivas y con mayores capacidades gráficas y multimedia. Éste es el caso de Gmail, la aplicación de Google para la gestión del correo electrónico, que tiene un interfaz web que permite al usuario efectuar acciones sobre su correo igual que si estuviera utilizando un programa cliente instalado en su propio equipo.

En los años 90 y con el desarrollo de Internet, las aplicaciones web fueron tomando el espacio que antes ocupaban los mainframe y las aplicaciones cliente-servidor. La razón de este cambio estuvo en la facilidad que ofrecían estas nuevas aplicaciones para su distribución y mantenimiento, en que conseguían llegar a más público utilizando un único cliente (navegador web) y en que hacían uso de los protocolos de comunicación de Internet. Pero como contraprestación, la experiencia de uso de estas aplicaciones no era tan satisfactoria. El navegador web obligaba a las aplicaciones a tener un interfaz estático tipo request-response, lo que redundaba en una recarga de página para obtener datos del servidor.

RIA introduce un nuevo modelo de programación de aplicaciones que combina las ventajas de los dos modelos predominantes hasta el momento: el de las aplicaciones cliente-servidor y el del modelo multi-capa utilizado por las aplicaciones web, con un claro objetivo: mejorar la experiencia del usuario.

Con las RIA, los usuarios reciben respuestas instantáneas sin esperar a las conexiones de ida y vuelta contra el servidor que requerían las aplicaciones web tradicionales. Pero además, en muchos de los casos, las RIA pueden funcionar en cualquiera de los sistemas operativos que tenga instalado el usuario en su equipo (son multiplataforma) y utilizan el protocolo de comunicación de Internet, TCP/IP.

Se espera un gran desarrollo de este tipo de aplicaciones en un futuro próximo de cara al gran público y al ámbito interno de las organizaciones. Las principales ventajas que introducen estas aplicaciones son las siguientes:

• Agilidad en la respuesta.

• Cálculos rápidos, controles prediseñados y funciones gráficas, interactivas y multimedia avanzadas.

• En muchos casos no requieren de instalación en el equipo del usuario (es suficiente con disponer de un navegador web), por lo que no es necesario pensar en distribuciones de software.

• Uso desde cualquier ordenador con acceso a Internet.

Pero también existen ciertos retos con los que las tecnologías RIA deberán lidiar en el futuro:

• Las RIA introducen cambios en los hábitos de navegación y en el uso de las aplicaciones web, y el usuario tardará un tiempo en digerirlos. Además, se dan ciertas complicaciones para el cumplimiento de los niveles de accesibilidad.

• Algunas de las tecnologías RIA que hacen uso del navegador web deberán superar algunos aspectos no resueltos aún, como la posibilidad de introducir "Favoritos" o la de utilizar el botón "Atrás" del navegador web.

• Las RIA deberán considerar la optimización de los motores de búsqueda o la capacidad de los sistemas de análisis para monitorizar sitios web construidos con esta tecnología.

• La incidencia de estas aplicaciones sobre aspectos relacionados con la seguridad deberá estudiarse en su globalidad a la hora de definir la arquitectura de sistemas y aplicaciones de la organización. 

Relación con SOA

La adopción de nuevos enfoques relacionados con SOA (Arquitectura Orientada a Servicios) por parte de las organizaciones y por las suites de productos de software más extendidas en el mercado de las TI, constituye un caldo de cultivo interesante para la introducción de las tecnologías RIA.

SOA ofrece una capa de abstracción que facilita la interrelación entre los servicios ofrecidos por las diferentes aplicaciones de una organización. Pero las ventajas de este nuevo enfoque habitualmente se encuentran ocultas para el usuario de negocio. Una manera de aflorar el valor que SOA reportará al usuario final será mostrando la facilidad de las aplicaciones RIA para integrar los mash-ups y web-services desarrollados siguiendo este enfoque. 

¿Qué tecnología elegir?

Existen diferentes tecnologías de programación de aplicaciones RIA. La selección de la más adecuada dependerá del resultado que se quiera obtener en cada caso y de las particularidades técnicas del entorno en el que se implementará la aplicación. Se consideran principalmente dos categorías de aplicaciones:

• Desktop

Aplicaciones que no utilizan navegador web y que se instalan en cada equipo personal. Suelen ser adecuadas para aplicaciones que requerirán un gran nivel de interacción con el usuario, intensivas en el uso de gráficos y con necesidad de utilizar funciones de otras aplicaciones. Ejemplo: aplicación desktop de eBay.

• RWA (Rich Web Applications)

Aplicaciones que se ejecutan utilizando el navegador web. Suelen ser adecuadas cuando se requiere un uso ocasional, una interacción con otras aplicaciones o servicios web y cuando el procesamiento de información y su almacenamiento se realizan en el servidor. Ejemplo: Google Docs and Spreadsheets.

Pero existen más variables a tener en cuenta a la hora de seleccionar la tecnología más adecuada. Dentro del abanico de tecnologías disponibles se encuentran las que hacen uso de estándares abiertos y las que no, así como las que resultan ser multiplataforma y las que, por ahora, solamente funcionan en unos determinados entornos.

 Principales tecnologías disponibles en el mercado:

• Ajax (por ejemplo el que genera el Google Web Toolkit)

• Flex (Adobe). Requiere tener instalado el Adobe Flash Player en el equipo del usuario

• Silverlight (Microsoft)

• JavaFX (Sun Microsystems)

• OpenLaszlo (código abierto)

Qué son los RIA Services?

Las aplicaciones RIA  (Rich Internet Application) están cada vez más de moda, ya que entre otras nos permiten ofrecer una mejor experiencia de usuario.

A lo largo de este post voy a intentar explicar, de una manera resumida y simplificada, los principales conceptos de RIA Services y para qué nos puede servir. Vamos a ver si lo consigo…

La arquitectura de una aplicación Web tradicional sería la siguiente:

Exceptuando ciertas funcionales Ajax que pueden suponer una parte "menor" del total, en las aplicaciones web tradicionales las diferentes capas lógicas (lógica de presentación, lógica de negocio, acceso a datos..) de las que está compuesta se distribuyen generalmente en dos capas físicas que se encuentran en el servidor.

En la parte cliente lo que tenemos es el código HTML que el servidor nos devuelve.

Una aplicación RIA sería algo así:

El desarrollo de una aplicación RIA supone desplazar una de las capas lógicas de la aplicación, la capa de presentación, a la parte cliente, convirtiéndole a éste en un "cliente pesado"…En el cliente tenemos parte de la aplicación, no sólo HTML.

Por ejemplo, en el caso de crear una aplicación Silverligth éste sería el caso dónde nos encontraríamos. La aplicación corre en el cliente y en éste dónde se ejecuta.

Pero claro, llevar esta parte al cliente no es gratis, ya que se complican las comunicaciones entre la lógica de presentación y la lógica de negocio.

En el caso de aplicaciones web tradicionales la lógica de presentación y de negocio suelen estar dentro de la misma capa física, por lo que la comunicación entre ambas no supone ninguna complejidad.

Si entre ambas capas metemos "internet", la comunicación ya no se puede hacer de manera directa y tendremos que pensar en desarrollar una capa de servicios en el servidor que el cliente pueda consumir, lo que complica el desarrollo, aumentando los tiempos y problemas con los que nos podemos encontrar: Crear la capa de servicios, exponer los métodos que necesita, crear proxys, validación, autenticación…

¿Cuál es el objetivo de RIA Services? 

Pues el objetivo de RIA Services es simplificar el desarrollo de aplicaciones RIA, para que podemos desarrollar aplicaciones de este tipo como si fuesen aplicaciones web tradicionales, sin tener que preocuparnos de los aspectos que mencionaba en el párrafo anterior.

Beneficiarnos de todas las bondades de tener aplicaciones RIA pero sin pagar un coste por ello (al menos no uno excesivo), pudiendo hacerlo de una manera similar al que si hiciésemos aplicaciones web tradicionales.

En algunos sitios he visto que definían RIA Services como las herramientas RAD de Microsoft para la construcción de aplicaciones RIA…no sé si será para tanto 🙂

RIA Services nos va a servir de pegamento entre la lógica de presentación y la lógica de negocio para simplificar la comunicación entre ambas, permitiéndonos centrarnos en el desarrollo de la aplicación propiamente dicha.

En la arquitectura que se presenta a continuación podéis ver dos nuevos componentes que aporta RIA Services, uno en la parte cliente ( DomainContext ) y otro en la parte servidora ( DomainService ).

Seguro que ya todos conocéis los DataSources que tenemos actualmente disponibles en ASP.NET (XmlDataSource, SqlDataSource, ObjectDataSource, EntityDataSource etc…) y lo mucho que nos facilitan el desarrollo.

Pues bien, con RIA Services tendremos uno nuevo; DomainDataSource. Este componente es muy similar al resto de DataSources (la idea es la misma) y nos va permitir trabajar de una manera bastante cómoda y sencilla contra servicios de dominio que se exponen con RIA Services.

Por ejemplo, en una aplicación RIA hecha con Silverlight podemos tener los típicos formularios de lista/detalles, con las operaciones de selección, inserción, actualización, borrado, filtrado y ordenación como si de una aplicación web tradicional se tratase.

Por cierto, aunque menciono Silverlight, el componente DomainDataSource también se puede usar en aplicaciones ASP.NET tradicionales o para montar aplicaciones con Dynamic Data, no es algo sólo para Silverlight.

Ventajas y Desventajas de las RIA"s

Actualmente, con la masificación de Ajax y el desarrollo de plataformas como Flex u Open Lazlo las RIA"s ("Rich Internet Apliccations", o aplicaciones web de comportamiento similar a las de escritorio) se están tomando la web agresivamente.El objetivo de estas tecnologías es torcerle la mano a las limitaciones de HTTP y construir interfaces "fluidas" y más usables que imiten la inmediatez del escritorio.HTTP, a diferencia del escritorio, no mantiene estado. Esto quiere decir que, entre una página y otra, no hay "memoria" de las aciones efectuadas anteriormente por el usuario. Cada vez que presionamos un link, nuestro navegador envía una petición ("request") al servidor, quien a su vez procesa los datos enviados y responde adecuadamente. El navegador recibe y despliega esta respuesta y la comunicación termina hasta la siguiente interacción del usuario. Esta es la arquitectura que nos ha acostumbrado a entender la internet como una serie de "páginas" o documentos individuales, relacionados entre si por hipervínculos.

Las aplicaciones de escritorio, por el contrario, mantienen un contacto permanente entre los procesos internos del programa y lo que sucede en la interfaz de usuario. Es por esto que no requieren del paradigma de páginas de la web y tienden a ofrecer una experiencia de usuario más fluída entre una acción y otra.

Flash, Javascript y las tecnologías citadas al comienzo tienen la virtud de mantener estado, al menos en la interfaz. Si bien la comunicación con el servidor se sigue haciendo a intervalos discretos mediante HTTP, estas aplicaciones evitan la parcelación de la interacción en "páginas" y logran una experiencia mucho más cercana al escritorio.Pero hay ocasiones donde las virtudes de HTTP y HTML, el modelo tradicional, son esenciales. En el modelo de petición y respuesta de HTTP, cada documento HTML – de hecho cada imagen y cada elemento que incluyamos en la página – es un recurso. Cada recurso tiene su propia URI en la Red y en virtud de eso puede ser visitado individualmente y utilizado en múltiples contextos.

Los recursos son reutilizables y se pueden agregar a los favoritos del navegador. Pero lo más importante es que los recursos son indexables. Eso significa que los motores de búsqueda, vitales para organizar los millones de datos que circulan en la Red, pueden llegar a ellos, analizarlos y categorizarlos, facilitando la búsqueda para nosotros los usuarios y abriendo la posibilidad de generar nueva información a partir de la recombinación de recursos.

Incluso las RIA"s que respetan los estándares tecnológicos y aquellas accesibles suelen generar el contenido dinámicamente, en base a las opciones tomadas por el usuario o cargada internamente desde ubicaciones desconocidas. En las aplicaciones Flash o cargadas al javascript -y especialmente Ajax-, los datos que ves en pantalla son totalmente invisibles para los motores de búsqueda, que sólo entienden información estructurada en formatos conocidos.

En muchos casos las RIA"s se han hecho imprescindibles. Aplicaciones innovadoras como gMail facilitan el manejo de grandes volúmenes de información junto con la ubicuidad de la Web. En otros, los comportamientos "de escritorio" en la web perjudican la usabilidad y reducen el valor de los datos al suprimir su calidad de recursos. Para entender esto hay que diferenciar entre sitios web de difusión de datos – aquellos en que navegamos los datos de forma pasiva, en calidad de lector – como blogs o sitios informativos, y aplicaciones utilitarias donde el usuario, en calidad de autor, modifica los datos e interactúa con la interfaz de forma activa. Estas últimas comunmente pueden prescindir del paradigma de páginas porque estan orientada al uso privado de usuarios.

Sin embargo hay muchos "sitios" informativos que echan mano a efectos de movimiento o configuración à la Escritorio. Es importante que en estos casos los desarrolladores mantengan un ojo en la accesibilidad -para usuarios y buscadores– y que utilicen metodologías existentes para lograr un balance entre los dos aspectos. Como mostraré en el siguiente artículo, una de las claves es separar los recursos de su comportamiento en la interfaz.

Fuentes

http://es.wikipedia.org/wiki/Rich_Internet_Applications http://www.webtaller.com

Autor:

Ing. Tito Fernando Ale Nieto

Fecha: Octubre 2010