De Grueso a Inteligente, de Delgado a… AJAX!

 Ninguno  de los dos está dispuesto a ceder. Hasta mediados de los 90 nadie se cuestionaba los clientes gruesos. Todas las aplicaciones se distribuían en diskettes. Cuantos más diskettes una aplicación, más sofisticada parecía. Con el surgimiento de la web, una creencia de que el navegador iba a ser la infraestrucura universal de plataforma cliente cobró forma. A partir de allí toda una industria surgió. Los principales vendors de plataforma, que competían en rangos como Sistema Operativo, Bases de Datos, Herramientas de Colaboración (procesadores de texto, hojas de cálculo, etc) entre otras, para principios del nuevo siglo ya competían en el rango de los Servidores de Aplicación
 
Desde entonces el concepto de aplicación de escritorio pasó por un período a ser considerado una especie en extinción, que conforme pasase el tiempo iba a terminar suplantado por su versión light. Esto iba a significar no tener que distribuir más actualizaciones, ni estar pendientes respecto de si el roll out iba a ser exitoso o no en cada puesto, ni de profundizar la huella (footprint) en la registry o en el resto del equipo. El concepto de lo web emanaba romanticismo, interfases simples, ad hoc, y una aplicación que siempre estaba actualizada. Todo lo contrario del cliente de escritorio, que ahora ya se llamaba cliente grueso en contraposición del cliente web, que ahora era delgado
 
Pero con el uso se evidenció que más allá de los beneficios brindados por las aplicaciones web, cuestiones como la desconexión ocasional (offline) dejaban al cliente fuera de combate. También, el concepto de cliente server-side implicó un estudio muy cuidadoso del uso de los recursos: qué datos se iban a dejar en la sesión HTTP -capítulo aparte si se trataba de una granja de servidores sin afinidad de sesión-, qué objetos iban ser compartidos -y cómo minimizar las exclusiones mutuas-, etc. Admito que yo me había dejado arrastrar por la corriente web y sin embargo lidiar con estos problemas que mencioné (además de los que no mencioné) realmente fue desgastante. El usuario, sea que los aún defensores del cliente web lo ignoren o no, extrañó la riqueza y reacción (responsiveness) de las interfases tradicionales. Las vitaminas introducidas por DHTML (que aportaba CSS, JavaScript y DOM) se agotaron rápido: se podía intentar igualar la potencia de los clientes enriquecidos pero a cambio de una complejidad que muchos despreciamos. Y como si faltara algo, cualquier invocación al servidor de aplicación implicaba volver a cargar la página completa
 
Entonces comenzaban a soplar los vientos de la siguiente ola: los servicios Web (XML -SOAP, WSDL, etc- como protocolo de mensaje y HTML como protocolo de transporte). El cliente grueso pasó así al ataque con la intención de recuperar el terreno perdido. Lo hizo con fuerza aprovechando los transtornos introducidos pura y exclusivamente por los clientes web (offline, etc). Claro que ya nada iba a ser como fue: las aplicaciones iban a tener un lado cliente basicamente compuesto por la lógica de presentación, además de cierta cantidad de lógica de negocio que iba a precisarse disponible en los escenarios de offline. Fuera de ello, toda la lógica de negocio quedaba en el mismo servidor de aplicación que dio origen a los clientes basados en HTML. De hecho, la convivencia fue pacífica ya que el que ahora pasaba a llamarse cliente inteligente (smart client) era en definitiva un canal más de acceso a la aplicación web existente. Esto realimentaba el concepto de plataforma multicanal (basada en el patrón de arquitectura Modelo-Vista-Controlador o patrón MVC) que ya se había gestado con la aparición de los dispositivos pocket (celulares, PDAs), y que fue el antepasado inmediato de la Arquitectura Orientada a Servicios (Service-Oriented Architecture o SOA)
 
Con todo, los escenarios prácticos quedaron bien delimitados. A grandes rasgos, para aplicaciones de intranet (a ser usadas por empleados o contratistas de la compañía), cliente inteligente. Para clientes finales de la compañía y en muchos casos proveedores, cliente web. Y parecía que con este nuevo orden estaba todo dicho. Pero el cliente delgado vuelve fortalecido con esteroides: AJAX (Asynchronous JavaScript and XML) es el nuevo estándar destinado a relanzar la usabilidad y experiencia de usuario. AJAX logra evitar tener que hacer un round trip completo al servidor por cada página. En cambio, puede reaccionar ante eventos (input del usuario, etc) y en base a eso gestionar al servidor -vía JavaScript– un stream -cuyo mensaje se formatea en XML- para recibir información parcial (elementos de una lista popup, etc) para sustituir partes específicas de la página. Qué ventaja sustantiva aporta este nuevo enfoque? Hasta el momento en las aplicaciones web, como cualquier requerimiento del cliente al servidor requería generar una nueva página, era menester, como parte del desarrollo, mantener el estado del caso de uso completo en cada parte de la página. Ejemplo, si en una página de carga de un formulario se quiere habilitar la busquéda de productos por nombre, en ejecución se deberá guardar el status de los campos que hasta el momento se hayan llenado. Sea que mantuviésemos el estado en el servidor (sesión HTTP) o, mediante técnicas, en el mismo cliente (campos ocultos, cookies, etc), toda la lógica debía ser provista como parte del desarrollo. AJAX, al permitir sustituir secciones parciales de la página, nos evita generar plomería especial. En concreto, es posible que el caso de uso entero con todas las interacciones del actor al sistema se pueda implementar en una sóla página, con estos round trips individuales (mediante el motor AJAX) y finalmente un round trip tradicional donde se postea el formulario completado. Esto obviamente achica más la brecha entre cliente grueso y delgado. Viendo el vaso medio vacío podemos decir que así es más difícil decidir que antes. Viéndolo medio lleno, en caso de elegir mal nos equivocamos por menos😀
 
Ejemplos inmediatos de aplicación de AJAX, que van a sorprender porque no requieren de un upgrade en las versiones actuales de los navegadores comunes, se pueden ver en
Mejor que contar acá los detalles técnicos de cómo trabaja el motor AJAX es leer un excelente artículo de Jesse Garrett, director de Estrategia de Experiencia de Usuario de Adaptive Path (del cual es fundador). Reproduzco a continuación el gráfico que representa el cambio en el esquema comunicacional entre el cliente web tradicional y el cliente web con AJAX
 

Ajax Overview 2

 
Tendrá éxito este relanzamiento del cliente web? Aún queda pendiente manejar ciertas problemáticas como la desconexión ocasional. Es evidente que aunque la duda sobre si cliente grueso o delgado ahora se transforma en cliente inteligente o AJAX, las partes en pugna cada vez irán ganando en sofisticación. Es buena la competencia entre proveedores de un servicio cuando el beneficiado es el usuario del mismo
 
Cómo profundizar con AJAX? Está disponible para ASP.NET 2.0 un módulo llamado Atlas (parte constituyente de Windows Presentation Foundation -ex Avalon, uno de los pilares de WinFX). Frente a frente con el cliente inteligente de .NET dejan demostrado que ninguno de los dos está dispuesto a bajarse del cuadrilátero
Esta entrada fue publicada en Software Architecture. Guarda el enlace permanente.

Una respuesta a De Grueso a Inteligente, de Delgado a… AJAX!

  1. Fabian dijo:

    Lastima que no todo AJAX sea compatible con FireFox

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