Ajax es el estándar de facto para construir RIA (del acrónimo en ingles Rich Internet Application). Es la tecnología soportada por todos los browsers modernos (W3C) y la base de la mayoría de los frameworks JavaScripts (digase prototypejs, jQuery, Dojo o extjs, por nombrar los más conocidos) y de otras tecnologías como Flex, GWT o M$ Silverlight. Ajax ha permitido dar un nuevo enfoque al WWW y está colaborando en la creación de la nueva burbuja de internet con la versión 2.0 de la web. Ha permitido también ver al browser como una plataforma donde se pueden ejecutar aplicaciones complejas que minimizan el esfuerzo del usuario y hace más agradable su uso.

No obstante Ajax no es la única opción. A continuación hablaremos de Comet y WebSocket como opciones substitutas para la contrucción de aplicaciones con interfaces y comportamiento complejos que en el caso de Comet no gozan de la popularidad de Ajax ni se ha convertido en estándar por no tener una espalda empresarial como Microsoft[1], Google o Yahoo!. El caso de Web Socket es diferente por haber nacido como parte de una especificación creada y en desarrollo por parte de W3C.

Comet:

Alex Russell (creador de Dojo[2]) descubre una nueva forma de comunicación ‘no estándar’ entre el browser y el servidor usado por aplicaciones como Google Talk, Meebo o JotLive (ahora de Google) diferente a la tradicional Ajax y decide denominarla Comet como una forma de poder referenciarla a futuro.

La diferencia de Comet con Ajax es que en Ajax, las peticiones de ejecución en el server nacen en el browser (la dirección es la tradicional, del browser al servidor). En Comet sin embargo se abre una linea de comunicación entre el browser y el server, reduciendo la latencia de enviar paquetes desde el browser cada vez que se necesite un requerimiento y permitiendo que sea el server quien envie los paquetes al browser de forma autónoma (la comunicación es bidireccional, ahora el servidor también puede enviar peticiones al browser). A continuación se ilustra la diferencia entre las formas de comunicación del enfoque Ajax vs Comet.

Una aplicación Comet puede enviar datos al browser en cualquier momento, lo que permite crear aplicaciones más “real time” (por ejemplo monitoreo o colaboración online entre usuarios) a diferencia de Ajax donde el browser encola las peticiones enviadas al servidor de forma asíncrona.

Dado que Comet no está contruida sobre la base de comunicación estándar HTTP Request/Response es necesario instalar componentes de parte del server. Apache provee un módulo ‘comet-ready’ en su versión 2.2, existen también soluciones como Twisted (para desarrollos en python), o POE (para perl), la lista aumenta a medida que Comet se convierte en una opción popular.

HTML 5 WebSocket:

Web Socket es la alternativa estándar (escrita desde cero) para la especificación de la versión 5 del lenguaje HTML ( que en su versión expresada en XML se podrá llamar XHTML ) y por tanto con implementación nativa para los browsers que cumplan dicha especificación.

La diferencia que da valor agregado a Web Socket ( a parte de ser estándar ) radica en que provee una conexión duplex entre el browser y el server con una sola conexión TCP/IP (a diferencia de Comet que abre conexiones para cada requerimiento) y por otro lado genera pocos headers HTTP en los mensajes ( a diferencia de Comet que se basa en escribir mucha información en el header haciendo más pesados los mensajes). Además el protocolo de transporte que usa Web Socket puede ser usado en una diversidad de clientes (e.g. JavaScript, Adobe Flex, JavaFX, Microsoft Silverlight, etc.) sin usar transformación de mensajes a diferencia de Comet que usa el protocolo Bayeux o JSON de la parte cliente, requeriendo transformación cuando el server trabaja con otro protocolo como JMS, XMPP o IMAP.

Conclusiones

Ajax no es la única alternativa técnica para la comunicación entre el browser y el server cuando se desarrollan RIA. Existen opciones como Comet ( usadas por aplicaciones como Google Talk, o Meebo ) y el futuro y prometedor estándar Web Socket de la especificación HTML versión 5.0.

1.- Microsoft se acredita la invención de Ajax con su implementación de XMLHTTP a finales de los 90 mientras escribían la interface web del MS Exchange Server 2000.

2.- Dojo fue diseñado con soporte para Comet a traves de su interfaz dojo.io.bind() (Ver Dojo toolkit para más información.)

El pasado viernes (21 de Noviembre) hicimos una presentación sobre Web 2.0 en uno de nuestros clientes.

La presentación fue separada en dos secciones:

• Mostrarles la tendencia 2.0 conceptualmente.
• Mostrarles ejemplos de aplicaciones web 2.0 que hemos implementado.

Pueden bajar la versión en PDF.

He visto en varios forums que algunas personas se quejan de que cuando generan objetos en notación JavaScript (JSON) y que tienen caracteres del latín como los acentados (ñ, á, ü, etc) usando HttpServletResponse desde un servlet el browser les muestra caracteres extraños y preguntan por la solución.

La respuesta es sencilla. Antes de hacer el getWriter() del HttpServletResponse se debe setear el tipo de encoding que usarán para mapear los caracteres de forma que el browser los pueda interpretar y convertir de vuelta.

Hay dos formas de hacer esto:

1. Mediante el método setContentType(), que envía el tipo de contenido al cliente (browser) y donde puede setearse el charset.

response.setContentType("application/x-json;charset=UTF-8");
...

2. Mediante el método setCharacterEncoding(), que si es usado sobre-escribe la acción de setContentType().

response.setCharacterEncoding("UTF-8");
...

A continuación un ejemplo completo del envio de modelos de objetos en notación JavaScript hacia el browser desde un clase que hereda de org.springframework.web.servlet.view.AbstractView de Spring

...
    protected void renderMergedOutputModel(Map model, HttpServletRequest req,
            HttpServletResponse resp) throws Exception {

        JSONObject json = (JSONObject) model.get("json");
        resp.setCharacterEncoding("UTF-8");
        if (null != json) {
            resp.getWriter().write(json.toString());

        } else {

            resp.getWriter().write("{}");
        }
    }

…

Para mayor referencia, Tim Bray explica porque Unicode y UTF-8 son excelentes. Es una lectura obligatoria para entender de estos temas.