h1

Echo2: AJAX Reloaded

03/29/2007

Wizdoc [Icon By Buuf]  Tips & Tricks
El futuro de las aplicaciones Web

Como parte de las nuevas tecnologías asociadas a AJAX han aparecido varios frameworks de desarrollo que facilitan la implementación de aplicaciones web que aparentan la funcionalidad de un programa desktop. Un buen ejemplo de este tipo de aplicaciones es meebo, que permite conectarse a las cuentas de mensajería instantánea como Messenger Live, Yahoo o Google Talk aparentando muy bien la funcionalidad que se obtendría al descargar un cliente en nuestra computadora. (Aquí se proporciona un resumen de Meebo en la Wikipedia).

Meebo en accion

meebo en accion (con visión simultánea de los contactos de las cuentas de yahoo, hotmail y gmail)

Esto genera dos tendencias:

  • Aplicaciones con contenido cada vez más dinámico, creando desarrollos web con back-end en java y un front-end que aparente la funcionalidad de un Visual Basic sin necesidad de desarrollar HTML, CSS o JavaScript (adiós JSPs, Servlets y frameworks tales como Struts).
  • La desaparición de arquitecturas cliente-servidor que tengan botones, barras de deslizamiento y demás componentes gráficos (adiós Swing o AWT).

Los frameworks

Los frameworks que actualmente están disponibles y cuyo uso es bastante común en la industria son JackBe (que personalmente considero bastante más complejo de lo deseado aunque su principal mérito es la introducción de este tipo de tecnología), el Google Web Toolkit y ahora ha aparecido una tercera opción: Echo2.

De acuerdo al reportaje Comparing the Google Web Toolkit to Echo2, aprovechando las características inherentes a las arquitecturas de ambos frameworks, podremos llevar a cabo exitosamente la implementación de una aplicación de este tipo de acuerdo a los objetivos del proyecto. Resumiendo:

Framework/
Funcionalidad

Google Web Toolkit

Echo2
Frontend

  • El código de la interfaz de usuario reside en la computadora del cliente.
  • Para funcionalidad que no requiere recuperación de información del servidor, no hay tiempos de respuesta dependientes de la conexión.
  • El código de la interfaz reside en el servidor de forma íntegra.
  • Todas las interacciones del usuario requieren conexión con el servidor por lo que hay dependencia de su desempeño (latencia, ancho de banda, etcétera).
Middleware

  • Cuando se requiere procesar información en el servidor (por ejemplo recuperar los registros de un query), se realizan llamadas a procesos remotos (RPC) del Web browser al servlet de negocio.
  • Se requiere una mayor atención a problemas de seguridad debido a la naturaleza distribuida de la arquitectura.
  • Más variedad de elección: arquitectura distribuida o modelo SOA (Service Oriented Architecture).
  • Es factible conectar la funcionalidad del middleware con frameworks preexistentes (siendo los más importantes Spring y Hibernate).
Desempeño

  • Modelo Thick-client donde las aplicaciones corren en el cliente.
  • El desempeño depende de las capacidades de los clientes donde corre dicha aplicación.
  • Modelo Thin-client donde las aplicaciones corren en el servidor.
  • El desempeño depende de la capcidad del Application Server donde se hospeda la aplicación así como el ancho de banda de ambas capas (clientes y servidor).
Runtime

  • Como la interfaz de usuario corre en el cliente, depende del JRE instalado en la máquina del mismo.
  • Debido al punto anterior, la funcionalidad que es posible realizar se ve limitada por las caracteristicas del JRE (que es sólo un subconjunto de clases e interfaces de Java).
  • El JRE soportado actualmente es el correspondiente a la especificación de Java 1.4.
  • La interfaz corre en el servidor; se pueden utilizar todos los componentes de la suite de Java (JSE/JEE) dependiendo de la marca y versión del servidor de aplicaciones implementado.
Debugueo

  • El framework proporciona un ambiente de debugueo llamado Modo Hosteado que utiliza la JVM seleccionada por el programador y permite validar la interfaz mediante un browser propietario.
  • Como todo es java, con un IDE convencional (Eclipse, NetBeans) y/o algún framework de pruebas (JUnit) es posible verficiar la calidad del código.
Licenciamiento

  • Engine propietario (sólo los binarios disponibles).
  • Descarga grátis.
  • Opensource (Mozilla Public License).
  • Descarga grátis.
Aplicabilidad

  • Creación de componentes AJAX e integrarlos a páginas web estándar (JSPs, servlets) e incluso HTMLs estáticos.
  • Problema al descargar toda la aplicación en el cliente cuando es muy grande.
  • Dificultad para integrar con frameworks de front preexistentes (por ejemplo: Struts o Tapestry).

Usos en la vida real

Hace poco se dió luz verde al proyecto Open Content Delivery Server por parte de Sun. Esta plataforma permite administrar los contenidos (ringtones, imágenes y juegos) que se pueden descargar en teléfonos celulares (con portales enfocados por separado para proveedores de contenido, el departamento de marketing y el usuario final) y está implementado 100% en Java/JEE. Como la estrategia de Sun no ha incluido hasta ahora frameworks de desarrollo para AJAX, y el problema de que un producto de este tipo tenga dependencias con frameworks comerciales, se optó por Echo2 para el front. La demo del CDS con Echo2 es un buen ejemplo de la funcionalidad que se puede lograr: El sitio no tiene una sola linea de HTML, JavaScript o CSS; el back end contiene componentes de Java pero ningún JSP o servlet. Resumiendo, the future is now… and i like it.

Responder

Introduce tus datos o haz clic en un icono para iniciar sesión:

Logo de WordPress.com

Estás comentando usando tu cuenta de WordPress.com. Cerrar sesión / Cambiar )

Imagen de Twitter

Estás comentando usando tu cuenta de Twitter. Cerrar sesión / Cambiar )

Foto de Facebook

Estás comentando usando tu cuenta de Facebook. Cerrar sesión / Cambiar )

Google+ photo

Estás comentando usando tu cuenta de Google+. Cerrar sesión / Cambiar )

Conectando a %s

A %d blogueros les gusta esto: