COMET: UN SIGUIENTE PASO AL AJAX MOVIENDO DE LAS APLICACIONES WEB TRADICIONALES A

UN NUEVO ESTILO.

Luis Enrique Oviedo Chaparro Facultad de Ciencias y Tecnología, Universidad Católica de Asunción

Asunción, Paraguay le.oviedo@gmail.com

RESUMEN La Tecnología COMET consis te en la apl icación de una “vieja” técnica Web que lentamente está resuci tando desde las profundidades de la h is tor ia , e l cual nos permite crear apl icaciones colaborat ivas, in teract ivas y actual izadas , sacando un mejor provecho a las capacidades de los navegadores actuales .

INTRODUCCIÓN El paradigma tradicional de la Web es Síncrona . Esto indica que para cada pedido desde un cl iente (Navegador Web) exis te una correspondiente respuesta de un servidor (Servidor Web). Cuando una página Web es v isual izada, los datos contenidos en la misma son estát icos en el navegador del usuar io y estos datos no son actual izados hasta que la página sea refrescada nuevamente . Sin embargo existe un número creciente de apl icaciones que necesitan una visual ización de los datos más recientes , que son cont inuamente actual izados en t iempo real . Algunos ejemplos de es tas aplicaciones son:

- Precios de Stock de los s i t ios de compra on- l ine, pr incipalmente. - Resul tados de Competencias Deport ivas que necesi ten actual izar

constantemente sus resul tados. - Sit ios de Apuestas . - Mensajes intercambiados a través de las comunidades v ir tuales .

Son pocos ejemplos de los s is temas que, por la necesidad de ofrecer lo máximo en usabi l idad y cal idad para e l usuar io , requiere una cont inua actual ización de los datos visual izados en e l navegador. En s íntes is , debido a la d inámica propia del servicio, se hace cr í t ica mantener una actual ización constante de la información requerida por e l usuar io . Algunas aplicaciones uti l izan una técnica de poll ing donde sea requerida una actual ización automática . Mediante es ta técnica resolvemos parcialmente e l problema, debido a que:

- La frecuencia de actual ización no puede ser a l ta , debido a que el paradigma se mantiene síncrono ( requer imiento/respuesta) , lo que implica que también es imposible recibir datos en t iempo real .

- El ancho de banda ocupado es al to , para cada pedido por par te del navegador , es t ransfer ida la página web completa , en vez de transfer irse únicamente los datos que necesi tan ser actual izados.

- El impacto en los Servidores Web son enormes, porque necesi ta complacer una al ta cant idad de pedidos de página inclusive s i los usuarios están inact ivos.

Para solucionar es tos problemas desde la fuente, es necesario un cambio de paradigma. En otras palabras , a lgún s is tema push o de s treaming es necesar io con un mecanismo que provea un cont inuo f lujo de datos desde el servidor hasta e l c l iente , s in que el c l iente necesi te real izar un pedido de la página web entera, real izando en vez de lo anter ior e l manejo adecuado a una t ipología de datos y solamente esperar la recepción de las actual izaciones en t iempo real de los datos , a medida que vayan ocurr iendo.

EVOLUCIÓN DE LA RED Cuando la red in ició, nos encontrábamos en un entorno estát ico , con páginas en HTML que sufr ían pocas actual izaciones y no tenían in teracción con el usuar io. Este estado de la red es lo que se denominó como Web 1.0 . Cont inuamente, la red fue creciendo debido al éxi to de las páginas web. Este éxi to a su vez tuvo como consecuencia la necesidad de ofrecer nuevos servicios de carácter cada vez más dinámico. Por tanto la red fue apuntando hacia servicios donde es necesar ia la actual ización de los datos en un t iempo cada más cor to . Así la red dio un pasó mas, y este paso consis t ió en webs dinámicas donde las CMS ( Content Manager System, Sis tema de Gest ión de Contenido) , que son in terfaces que controlan una o var ias bases de datos donde se alojan todos los contenidos del s i t io en cuest ión, servían páginas HTML dinámicas creadas sobre e l vuelo desde una base de datos en actual ización. A este paso algunos lo consideraron como Web 1.5. Al s i tuarnos en este estado, para las páginas web, e l conseguir h i ts (v is i tas) y la estét ica v isual eran considerados como unos factores muy importantes , por lo que los pr incipales propulsores y desarrol ladores de avances en al red fueron vis lumbrando que e l uso de las redes deber ía es tar or ientado a la in teracción y redes sociales , que pueden servir contenido que explota los efectos de las redes con o s in crear webs interact ivas y visuales. Es decir , estos s i t ios con es tas caracter ís t icas cumplen más bien funciones de puntos de encuentro, o webs dependientes de usuar ios, que como webs t radicionales . A este estado es donde se pretende l legar al mencionar la Web 2.0 . Sintet izando, La Web 2.0 se ref iere a la transición percibida en In ternet desde las webs t radicionales a aplicaciones web dest inadas a usuar ios . La gente involucrada en es ta idea espera que los servicios sust i tuyan a las apl icaciones de escri tor io en muchos usos. Comparación entre la Web 1.0 y la Web 2.0 La infraes tructura de la Web 2.0 es compleja y evoluciona, incluye e l sof tware del servidor , s indicación de contenidos, protocolos de mensajes , navegadores basados en estándares , y apl icaciones para cl ientes . Una Web se puede decir que esta usando tecnología de Web 2.0 s i se caracter iza por las s iguientes técnicas:

- Técnicas de apl icación no in trusi ta (como AJAX).

- Java Web Star . - CSS , marcado XHTML vál ido semánticamente. - URLs senci l las y con s ignif icado. - Soporte para postear en un blog. - Algunos aspectos de redes sociales .

Existen otras técnicas , cuyo uso también implican usar tecnología de la Web 2 .0, pero los en general los pr incipios o bases a seguir son:

- El s i t io no debe actuar como un “jardín cerrado”, la información debe poder introducirse y extraerse fáci lmente .

- Los usuar ios deben controlar su propia información. - Basada exclusivamente en la Web. Los s i t ios Web 2.0 con más éxi to pueden

ser u t i l izados enteramente desde un navegador . En el s iguiente cuadro observamos una comparat iva de los servicios y páginas web que ut i l izan caracter ís t icas de la Web 1.0 y de Web 2.0:

WEB 1.0 WEB 2.0

DoubleClick Google Adsense

Ofoto Flickr

Akamai BitTorrent

mp3.com Napster

Britannica Online Wikipedia

webs personales blogging

evite upcoming org y EVDB especulación de nombres de dominio

optimización en máquinas de búsqueda

páginas vistas coste por click

screen scraping servicios web

publicar participación

Páginas estáticas CMS

directorios (taxonomías) etiquetas ( "folksonomy" )

stickiness sindicación El s iguiente cuadro i lustra el paso in termedio entre lo l lamado Web 1.0 y la Web 2.0 y las apl icaciones webs in tervinientes:

WEB 1.0 WEB 1.5 WEB 2.0

Páginas Personales Wikis Blogging

Email/ Grupo de Noticias Foros de Discusión RSS-Sindication

mp3 Napster iTunes

Terraserver MapQuest Google Maps

Británica Online Wikipedia

Flickr

Sintet izando la f i losof ía de la Web 2 .0, la misma no es un cambio tecnológico en su to tal idad, pero s í un cambio en la f i losofía con la que los usuar ios y las empresas se p lantean Internet . En una s ín tesis de la s ín tesis , podemos decir que: “la Web 1.0 es la Read Only Web, mientras que la Web 2.0 es la Writable Web” La revis ión exhaust iva de las técnicas y servicios u t i l izados en la evolución de la Web no es el motivo de este trabajo, aunque dentro de esta nueva manera de entender la Web, es tán enmarcadas c ier tas tecnologías que cumplen los ro les fundamentales en e l desarrol lo del mismo, AJAX y subsecuentemente COMET.

AJAX: UN NUEVO ENFOQUE PARA LAS APLICACIONES WEB

Una de las nuevas técnicas de programación uti l izadas para el desarrol lo del nuevo es t i lo de las páginas web es AJAX: AJAX, Es la técnica de ut i l izar una ser ie de tecnologías de forma conjunta como XML, JavaScr ipt y obje tos de c l iente (MICROSOFT.XMLHTTP o XMLHttpRequest) que permite a las apl icaciones web comportarse de una manera, podr ía decirse s imilar a la de las apl icaciones de escr i tor io , consiguiendo para esto una navegación más ági l y rápida. Más dinámica. AJAX es el acrónimo de Asynchronous Javascript And XML :

• Asynchronous Las pet iciones pueden ser s íncronas o asíncronas, las asíncronas engañan más porque el c l iente s igue trabajando con la apl icación mientras se resuelve la pet ic ión.

• JavaScript Lenguaje que controla las acciones del c l iente

• XML Suele o puede ser e l contenido de los mensajes de sol ic i tud

XMLHTTPREQUEST Es una API que se encuentra implementado en el navegador que proporciona los métodos y propiedades necesar ios para la comunicación con el servidor . Originalmente fue desarrol lada por Microsof t como objeto ActiveX, d iscponible desde Internet Explorer . Esta API es u t i l izada por varios lenguajes de scr ip t ing, ta les como JavaScr ipt , Jscr ip t VBScript y o tros lenguajes de scr ip t ing de navegadores web. Lo fundamental de esta API es que emplea un canal de conexión independiente . ¿Cómo funciona AJAX? Brevemente explicados es tos son los pasos que se s iguen en el funcionamiento de AJAX: Inicia lmente un usuar io provoca un evento, luego se crea y conf igura un objeto XMLHttpRequest . El objeto XMLHttpRequest real iza una l lamada al servidor , la pet ic ión se procesa en el servidor , e l servidor retorna un documento XML que cont ienen e l resul tado, e l obje to XMLHttpRequest l lama a la función cal lback() y procesa e l resul tado y f inalmente se actual iza e l DOM de la página asociado con la pet ic ión con el resul tado devuel to.

El s iguiente cuadro realiza una comparación entre e l modelo de apl icaciones c lás ico y el modelos de apl icaciones Web AJAX:

Cuadro comparat ivo entre e l funcionamiento de las apl icaciones Web tradicionales, de manera síncrona y e l funcionamiento de la tecnología AJAX, de manera s íncrona:

COMPARACIÓN CON EL PARADIGMA TRADICIONAL Ventajas de AJAX

• Mayor In teract iv idad Recuperación asíncrona de datos, reduciendo el t iempo de espera del usuar io

• Faci l idad de manejo del usuar io El usuar io t iene un mayor conocimiento de las apl icaciones de escr i tor io

• Se reduce el tamaño de la información in tercambiada • Portabil idad entre p la taformas

No requieren instalación de p lugins, applets de Java, n i n ingún otro e lemento

• Código Público Inconvenientes y Cr í t icas de AJAX

• Usabil idad: Comportamiento del usuar io ante la navegación. o Botón de volver atrás el navegador o Problema al agregar marcadores/favor i tos en un momento determinado

de la aplicación o Problemas al imprimir las páginas render izadas dinámicamente

• Tiempos de Respuesta entre la pet ición del usuar io y la respuesta del servidor

o Empleo de feedback visual para indicar e l es tado de la pet ic ión a l usuar io .

• JavaScr ipt o Requiere que los usuar ios tengan el Javascr ipt act ivado en el

navegador o En el caso de Internet Explorer 6 y anter iores , que necesi ta tener

act ivado el Act iveX (En Internet Explorer 7 , se implementa como JavaScr ipt nat ivo) .

o Como en DHTML, debe comprobarse la compatib i l idad entre navegadores y p lataformas.

COMET FUNDAMENTOS DE COMET Actualmente, se ha acuñado un nuevo término para un aspecto var iante de AJAX que esta l lamando la a tención más que la anter ior tecnología . El termino COMET descr ibe a las apl icaciones donde el servidor se mantiene “empujando” datos, o manteniendo un torrente cont inuo de datos a la apl icación cl iente , en vez de tener al navegador real izando var ias pet ic iones al sevidor para actual izar e l contenido. Esta técnica d if iere fundamentalmente de AJAX, ya que:

“AJAX realiza grandes cambios principalmente en el navegador, mientras que COMET fundamentalmente cambia la naturaleza de la comunicación realizada

en la arquitectura cl iente – servidor.” Es en esta arqui tectura en la que se d if iere de la tecnología AJAX, aunque en var ios s i t ios de d iscusión en Internet ven a COMET como una par te de todo lo ofrecido por AJAX, complementar io a los aspectos de In terfase de Usuar io de AJAX. Pero es necesar io dejar en claro que COMET es el nombre de un patrón de arqui tectura en la re lación con AJAX COMET se basa en que el servidor te envía datos aunque el c l iente no los p ida (HTTP Push) , s i e l mismo haces una l lamada, e l canal se queda abier to y el servidor te va mandando información, o lo que es lo mismo, que el servidor nos va a estar devolviendo el resul tado en par tes . En otras palabras todas las apl icaciones de COMET ut i l izan conexiones HTTP de larga duración para reducir a la tencia con la cual los mensajes son pasados al servidor . En esencia no real izan pedidos ocasionalmente al servidor . En vez de eso e l servidor mantiene una l ínea abier ta de comunicación mediante la cual puede “empujar” datos hacia e l c l iente. CUESTIONES FILOSÓFICAS Para cualquier usuar io , e l servidor representa a o tro usuar io, por causa de que la red es de carácter mult iusuar io , s imples actual ización de in teracción no son suf ic ientes, usuarios que ut i l izan el mismo “espacio” necesitan vivir actual izados de sus propios cambios y los cambios de otros usuar ios . Esta necesidad de actual ización constante afecta a la disponibi l idad de acciones, cuando creamos una página, o levantamos una imagen, o algo más, es tamos cambiando el contexto. Los medios de conversación son def in idos por la la tencia , in terrupciones y ancho de banda. Los usuar ios desean ut i l izar los medios de comunicación de al ta in terrupción en el menor grado posible . Las conversaciones son eventos ordenados, las in terfases granulares requieren eventos granulares, las conversaciones granulares son mas inmediatos. Las apl icaciones socia les son vis tas como buses de datos, Las apl icaciones web sociales s implemente amontonan los cambios necesar ios hoy en día. No existen formas efect ivas de suscr ibir los eventos a l servidor . Para mejorar e l contexto , necesi tamos agrupar los eventos. COMET es una técnica para empujar los datos desde e l lado del servidor. En real idad es un nuevo término para una vieja tecnología. Esto se realiza mediante el es tablecimiento de de una conexión de larga duración en vez de ut i l izar var ios pedidos de los datos al servidor . COMET ut i l iza XMLHttpRequest para la entrega de datos entre e l c l iente y e l servidor a t ravés del protocolo HTTP. También es conocido como Server Push o HTTP Push. SIMILITUDES ENTRE AJAX Y COMET Existen varias s imil i tudes con AJAX, no exis te necesidad de nuevos plugins, se u t i l iza h t tp p lano, asincronía, amplio soporte de navegadores. Ejemplo de algunos s is temas que uti l izan COMET:

- GMail - GTalk - JotLive

- Renkoo - Meebo - cgi : irc - KnowNow

Debe quedar en claro que COMET no es un framework o un toolset . Sino mas bien es un concepto como lo es AJAX DIFERENCIAS ENTRE AJAX Y COMET A NIVEL CONCEPTUAL En una apl icación en AJAX, el c l iente maneja la in teracción. El problema es que el contexto y el contenido manipulado caduca rápidamente en t iempos diferentes. Las apl icaciones COMET evitan e l re tardo manteniendo una conexión HTTP y TCP/IP y una s imple conexión es reut i l izada, pero la mayor d iferencia con AJAX es que la la tencia por los pedidos realizados por el mismo, que COMET evi ta . La gran estrategia: t ransfer ir únicamente los datos necesar ios , exactamente cuando la necesidad del mismo sea de mayor re levancia . A NIVEL IMPLEMENTATIVO Existen dos técnicas implementat ivas , la pr imera consis te en un pedido de larga duración donde se real iza una reconexión después de cada datagrama, esto se implementa s implemente con XMLHttpRequest . El o tro método es u t i l izar una técnica l lamada Forever-Frame. Un forever-frame es un Iframe o navegador que recibe bloques de scr ip t y u t i l iza una tecnica de render izado progresivo. Esta técnica es al tamente por table y permite conexiones y subdominios. La conexión se cierra únicamente cuando exis te un error en los ciclos de la conexión. En Firefox se implementa usando Content- type mult ipart /x-mixed-replace e indicando que el canal que se abre es mult ipart , o lo que es lo mismo, que el servidor nos va a estar devolviendo el resul tado en par tes . Con otros navegadores esta posibi l idad no exis te , y lo que se hace es abr ir un canal XMLHttpRequest , durante cier to t iempo e ir comprobando a cada ra to lo que nos l lega del servidor . Para hacer esto, no es necesar io AJAX, ni XMLHttpRequest , n i nada nuevo, s implemente un i frame y una función javascr ipt que te realice l lamadas cada cier to t iempo. Y ¿qué pasa s i e l servidor tarda más t iempo en devolvernos la sal ida de que tenemos la conexión abier ta? , esto puede ser solucionable , pero también puede ser un problema. ¿Qué se d is t ingue una l lamada COMET a una l lamada AJAX en Javascr ip t? , tan solo en que hay que indicar que va a recibir var ios objetos del servidor , para eso se usará e l a tr ibuto mult ipart . Hay que indicar que es mult ipart antes de que se abra la conexión (open) para indicar que es mult ipar t En el s iguiente ejemplo de código Javascr ipt se i lus t ra :

1. function holaMundo () { 2. var obj = document.getElementById("texto"); 3. 4. obj.innerHTML = ""; 5. comet = cometobj(); 6. comet.multipart = true; 7. comet.open("GET", "holamundo.php", true); 8. comet.onreadystatechange=function() { 9. if (comet.readyState==4) { 10. obj.innerHTML += comet.responseText; 11. } 12. } 13. comet.send(null); 14. }

SINTETIZANDO LAS DIFERENCIAS COMET emplea una conexión persis tente entre el c l iente y el servidor web, por tanto la entrega de los datos actual izados se real iza desde el servidor y s in que el usuario lo haya sol ici tado. El c l iente no sol ic i ta los datos , pero s í envía información al servidor . El servidor no rsponde al c l iente con un bloque de datos, se espera a que haya algún evento de lado del servidor para enviar la información. El s iguiente cuadro demuestra las d iferencias entre AJAX y COMET: Como se i lustra arr iba, las apl icaciones COMET pueden entregar los datos al c l iente en cualquier t imepo, no solamente en respuesta de algún input del usuar io. Los datos son entregados sobre una s imple conexión, previamente abier ta . Este enfoque reduce la la tencia de la entrega de datos s ignif icat ivamente . La arquitectura se basa desde el punto de vis ta de los datos , e l cual es or ientada a eventos en ambos lados de la conexión HTTP. Aquel los que están famil iar izados con los middleware que es tan or ientados a los mensajes pueden encontrar este d iagram especialmente famil iar . El unúnicao cambio sustant ivo es que el punto de entrega es un navegador . En tanto COMET es s imilar a AJAX en que es as íncrono , las apl icaciones que implementan el es t i lo COMET pueden comunicar cambios de estados pagando una pequeña la tencia. Esto hace a es ta tecnología adecuada para muchas c lases de apl icaciones colaborat ivas mult i – usuar ios y de monitoreo que de o tra forma ser ía muy dif íc i l o imposible de manejar en un navegador s in la u t i l ización de plugins . DESVENTAJAS DE COMET Este método podr ía s ignif icar un desperdicio en términos de sockets y threads, y también representar ía una sobrecarga para los f irewalls , los balanceadores de carga, e tc… En algunos foros de discusión se cr í t ica esta técnica ya que al mantener abier ta la conexión por un largo periodo, surgen problemas de escalabi l idad como consecuencia de lo expuesto anter iormente. Una de las cosas que hacen que las apl icaciones basadas en HTTP son que real izan pequeñas pet ic iones de páginas. Esto s ignifica que se pueden manejar pedidos de un orden de magnitud o una mayor cant idad de usuar ios en comparación con las técnicas de conexión de larga duración. FRAMEWORKS ACTUALES Existen diferentes f rameworks para COMET, entre los que ci tamos DojoToolkit , Teleport y Pushlets , que implementan APIs para COMET.

CONCLUSIÓN Es bueno COMET para los usuar ios? Si todos los usuar ios están tratando de hacer la misma cosa en el mismo lugar a a lgún pedazo de datos , entonces es lo indicado. LA actual ización de los datos que se real iza mediante es ta técnica es ideal , especialmente para apl icaciones de conversación. Si en el marco de la apl icación los datos pueden quedar la tentes y a nadie pudiese no importar le , entonces no es necesar io uti l izar lo . Por e l es tado actual de las redes , la tecnología COMET es apropiada y surge de vuel ta como respuesta a los requer imientos actuales de las apl icaciones web. BIBLIOGRAFIA ht tp : / /www.ajaxian.com/archives/comet-a-new-approach- to-ajax-applicat ionsht tp : / /www.dojotoolki t .comhttp: / /a lex.dojotoolki t .comhttp: / /phi l . technometr ia .comhttp: / /csshyamsundar .wordpress .com

ANEXO 1 Otras Tecnologías asíncronas para la Web Nicolás González ARSCIF El ARSCIF (Asynchronous Remote-Scr ipt Cal lback Invocat ion Framework) . Hace fáci l in tercambiar datos con un servidor en ECMAScript (versión estandar izada del lenguaje JavaScrip t , or ig inalmente desarol lada por Netscape) u t i l izando frames ocul tos y cal lbacks. Uti l izar f rames ocul tos para comunicarse con un servidor s in recargar una pagina es conocido como remote scr ip t ing. Lo que realmente ocurre es que in ic iamos asíncronamente con scr ip t remoto, luegop el scr ip t invoca un cal lback (posiblemente pasando datos que no estén disponibles del lado del c l iente) . Se ut i l iza remote cal lback invocation (RCI) (que no debe confundirse con remote procedure cal l ya que es te denota l lamadas a funciones ejecutadas remotamente de forma transparente) . Porque ARSCIF es mejor que otras l ibrer ías escr i tas para las mismas funciones - ARSCIF puede enviar y redcibir datos arbi trar iamente complejos en forma de l i terales ECMAScript canónicos. Uno no está l imitado a t ipos pr imit ivos o arreglos . - Sopor te p leno de caracteres UTF-8 lo que permite in tercambio de datos en cualquier lenguaje u ti l izando UNICODE, la implementación hace de este soporte dependiente únicamente del lenguaje scr ip t del servidor y así no del navegador n i en e l HTTP Server . - ARSCIF considera ser iamente la concurrencia y ofrece muchas opciones para l idiar con las mismas. - ARSCIF es sobre l ibre dis t r ibuido bajo la l icencia de X11. Fuente: h t tp : / /arscif .ds i .unimi. i t

Java2EE Service Activator Provee Procesamiento asíncrono para cualquier Enterpr ise Beans. En la especif icación 2 .0 de EJB (EJB es una de las API que forman par te del es tandar de construcción de apl icaciones empresar ia les J2EE de Sun Microsystems) , e l bean manejado por mensajes es de una sesión s in estado. Uti l izando el patrón Service Activator , es posible proveer apl icaciones asíncronas en todos los t ipos de beans empresar iales incluyendo los de sesión s in estado, sesiones de estado y los de ent idad, en pocas palabras sobre cualquier servicio de negocio. Por lo tanto provee una manera de habi l i tar procesamiento asíncrono para cl ientes que o no t ienen necesidad de esperar para resul tados, o no quieren esperar la f inal ización del procesamiento. El procesamiento puede ser d ifer ido y real izado más tarde permit iendo al c l iente completar e l servicio en menor t imepo. Fuente: h t tp : / / java.sun.com/bluepr ints /corej2eepat terns/Pat terns/ServiceActivator .h tml