Comet, reinventando términos

Uno de los términos técnicos del que más se ha leído durante este año es el de Comet. Este término se ha asociado con el mundo de AJAX aunque la realidad es que es un concepto que viene desde mucho más atrás.

El streaming HTTP es la técnica más básica de cualquier compañía que se dedique al mundo de la bolsa, comercio de divisas, o en resúmen cualquier mundo en el que se necesita empujar datos al cliente a velocidades de vértigo. Por ejemplo en el mundo del intercambio de divisas todos los interfaces se basan en este concepto ya que la volatilidad del mercado es brutal y cuando estas operando con monedas con mucha volatilidad, unos pocos segundos pueden significar cientos de miles de dólares.

El streaming HTTP se puede realizar tanto desde un cliente web como desde una aplicación de escritorio tradicional. No es algo que esté ligado para nada con AJAX. Por ejemplo, puedes tener tu aplicación de escritorio interactuando con un banco a través de HTTP y mantener dicha conexión abierta para que el servidor te esté continuamente haciendo streaming de datos. Como he dicho, esto es algo que se ha estado haciendo durante años. En estos casos, el usar una técnica como esta y mantener la conexión habierta es algo básico ya que es físicamente imposible el soportar una comunicación mediante polling. Si alguno se está preguntando porque utilizar HTTP, simplemente debe pensar que estamos hablando de bancos, y los firewalls son muy importantes en los bancos :-), especialmente cuando tu objetivo es el retail, es decir, el público de a pie.

Existen muchos recursos actualmente sobre Comet, AJAX, NIO, etc. y este año ha sido uno de los mejores para este terreno. Servidores web como Jetty o Apache Tomcat 6 soportan ya el mantener conexiones persistentes con el cliente a través de Java NIO, pero el caso es que la historia no se ha acado todavía ahí. El problema más importante ahora mismo es que aunque escales en la capa Servlet, todavía tienes que escalar en el Apache que los bancos te suelen ofrecer como entrada, ya que no sirve de nada liberar threads en tu contenedor web si están bloquedas en el servidor HTTP. Existen opciones como Grizzly, que es un servidor HTTP que utiliza NIO por debajo, pero la realidad es que es poco probable que estas organizaciones te permitan instalar este tipo de software en su puerta de entrada al mundo exterior.

Ante esta situación sólo queda esperar. Probablemente el próximo año se harán muchos avances en este sentido, así que promete ser un año emocionante.