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