Notas sobre la arquitectura de Facebook Chat

En la línea de las notas de arquitectura que suelo publicar voy a escribir hoy un post con un resumen de notas que he ido sacando sobre un documento acerca de la arquitectura del chat de Facebook. Si os interesa el tema entonces os pueden interesar también las notas sobre la arquitectura de Facebook del año pasado. Empiezo.

En 2007 en Facebook se dan cuenta de que necesitan un Chat, seguir los mensajes entre muros es un infierno. El código surge en el 2007 de lo que en Facebook denominan un Hackathon, es decir quedarse los ingenieros durante toda una noche programando. No es hasta el 2008 cuando se manda el primer mensaje y lo lanzan oficialmente.

Las estadísticas del chat dan miedo:

• 800+ million user messages / day


• 7+ million active channels at peak


• 1GB+ in / sec at peak


• 100+ channel machines

Repasando los cambios en Servlets 3.0

Recuerdo hace años que me solía leer muchas de las especificaciones del JCP conforme iban apareciendo. Vaya, esto me hace sentirme como un verdadero bicho raro. Pero es que me resultaba bastante interesante ver como evolucionaba la especificación de EJBs, leer sobre JDO, aprender sobre JCR e intentar hacer una implementación o pegar un giro radical y leer sobre J2ME o CLDC. Con el paso de los años me he ido desenganchando :-) No sé si es la edad, o si más bien es que hay tantas especificaciones ahora mismo que te da pereza siquiera echarles un vistazo.

Aún así, hoy he vuelto a esa vieja adicción y me he leído muy por encima el early draft de la especificación de Servlets 3.0. La lectura ha sido muy fácil porque tienen resaltados los cambios que han hecho respecto a la anterior versión 2.5, así que se deja leer. Creo que puede ser interesante que los resuma por aquí, por si alguien se la quiere ahorrar:

• Anotaciones: Probablemente el cambio más grande es que ahora ya no será necesario editar los descriptores (web.xml) para crear las aplicaciones web. La nueva spec. define en su sección 8 una serie de anotaciones que se pueden utilizar para describir elementos comunes como Servlets, filtros, mapeos de URLs, parámetros de inicialización y el context listener de cada Servlet.
  
  Las nuevas anotaciones son @Servlet, @ServletFilter, @FilterMapping, @InitParam y @ServletContextListener. A mayores, la especificación hereda anotaciones definidas en la especificación JAX-RS (The Java API for RESTful Web Services), más concretamente @HttpMethod, @GET, @PUT, @POST, @DELETE, @HEAD. El siguiente sería un ejemplo:
  
  

  
  @Servlet(urlMappings={"/foo", "/bar"})
  public class SampleUsingAnnotationAttributes {
      @GET
      public void handleGet(HttpServletRequest req, 
                            HttpServletResponse res) {
      }
  }
  

  
  
  Probablemente lo que no me acabe de convencer es que la especificación deja abierta la posibilidad de mezclar las dos aproximaciones, es decir el utilizar anotaciones y el descriptor web al mismo tiempo, lo que ofrece la posibilidad de crear una especie de configuración spaghetti.
  


• Fragmentos web: El segundo cambio importante son los fragmentos web. Todos los que hemos hecho aplicaciones web relativamente grandes sabemos la tendencia a crecer y crecer del fichero web.xml, lo que hace que a veces sea complicado el mantenerlo ya que no sabes donde está cada cosa, o es sencillo cometer el error de duplicar información, etc.
  
  Los fragmentos web permiten crear ficheros web.xml individuales que se distribuyen dentro de un fichero JAR que contendría lo que podríamos llamar una mini-aplicación web. El fichero web.xml debe colocarse dentro del META-INF y el JAR dentro del /lib. El contenedor de Servlets al arrancar la aplicación se encargará de buscar todos los fragmentos web que pueda encontrar e irá añadiendo las entradas de los diferentes web.xml individuales a la configuración de la aplicación. El siguiente es un ejemplo:
  
  

  
  <web-fragment>
      <servlet>
          <servlet-name>welcome</servlet-name>
          <servlet-class>WelcomeServlet</servlet-class>
      </servlet>
      <listener>
          <listener-class>RequestListener</listener-class>
      </listener>
  </web-fragment>
  

  
  
  Un ejemplo sería cuando quieres distribuir una consola de administración para tu aplicación web. En lugar de poner todo con la aplicación web principal, pues se podría empaquetar la consola de administración como si fuera una aplicación web independiente y distribuirla con la aplicación principal a modo de fragmento web.
  
  En mi opinión esta nueva funcionalidad es una buena idea que contribuye a mejorar la modularidad de las aplicaciones web. Queda abierto sin embargo el problema del punto uno de poder mezclar anotaciones con XML.
  


• Procesado asíncrono. El tercer cambio importante en Servlets 3.0 es la introducción de métodos para realizar procesado asíncrono. Esto es de vital importancia para el soporte de comet de manera nativa en los contenedores web. Hasta ahora el procesado de una request es completamente síncrono. Si la request necesita bloquearse por algún recurso, el thread que está manejando esa request se bloqueará. Asimismo, si queremos mantener la request viva durante un largo espacio de tiempo haciendo streaming al cliente, la request permanecerá bloqueada. Esto hace que los contenedores web no puedan escalar apropiadamente ya que el uso de recursos no es óptimo.
  
  La solución propuesta en Servlets 3.0 es añadir tres nuevos métodos, suspend, resume y complete, muy al estilo de las Continuations en Jetty, y que permitirán suspender una request, reanudarla posteriormente por ejemplo desde otro thread diferente, y completarla. Es importante la nota que hacen en la especificación de que tanto el objeto request como el objeto response no son thread-safe por lo que habrá que tener mucho cuidado al controlarlos.



• Otros. El resto de cambios, ya no tan grandes, son el añadido de nuevos métodos a la interfaz ServletContext de modo que se puedan añadir servlets y filtros programáticamente en tiempo de inicialización; el soporte de cookies HttpOnly que no están expuestas a scripting en lado del cliente, y el añadido de métodos en la request para obtener el ServletContext y la el objeto response.

En mi opinión se trata de buenos añadidos a la especificación que la mejoran bastante. Habrá que ver el tema de las anotaciones es un poco problemático como he comentado desde el punto de vista que puedes tener gente en tu equipo haciendo anotaciones y otra gente haciendo descriptores, pero bueno, al final es algo que una empresa debe controlar de todos modos con mejores prácticas, procesos, y todo esto.

Edit: Me acabo de pasar por javaHispano y mira que casualidad que hablan de lo mismo.

Introducción a Tomcat 6

Covalent ha publicado una Introducción a Tomcat 6 como parte de su serie de webinars. La próxima semana probablemente estará el audio, pero por ahora ya se pueden descargar las transparencias. No es demasiado técnico pero está bien para tener sumarizadas todas las novedades.

Lo malo: requiere registro en su web.

Liberado Tomcat 6 stable

Comet aquí vamos. Lo que estabamos esperando muchos ha llegado. No es que jetty sea malo, pero es que Tomcat es como quien dice el estándar de facto y ya se echaba en falta soporte de comet por alguna parte. El soporte ya estaba ahí desde hace rato, pero hasta que el producto no fuese oficialmente estable no lo ibamos a utilizar. Ahora por fin ha llegado el momento. A ver si lo puedo/podemos probar y saco/sacamos algunas conclusiones.

El anuncio de la versión estable.

Comet y terracotta de la mano

Parece que los chicos de jetty han encontrado por fin el filón para hacerle pupa a Tomcat, y están aprovechando al máximo su soporte de Continuations para atraer al mundo de AJAX en torno a su servidor. Tomcat también soporta el mismo concepto, pero por ahora sólo en Tomcat 6 que sigue por ahora en versiones inestables.

El caso es que en los blogs de los chicos de jetty se pueden encontrar artículos muy interesantes sobre todos estos conceptos (continuations, ajax, comet, ...). El último artículo explica las experiencias aplicando clustering con Terracotta a su soporte de comet. Me ha parecido interesante porque mezcla dos conceptos novedosos y expone algunas de las limitaciones de Terracotta. Aquí queda el enlace.

Demostración de AJAX para mercados financieros

Se puede leer en el blog de DOJO que sitepen en colaboración con Lightstreamer anunciaron una demo que muestra el uso del framework Ajax DOJO para mercados financieros. Por cierto, lo más interesante es la documentación.

Para los que no lo conozcan, Lightstreamer es uno de los líderes en cuanto a streaming de datos de mercados financieros en tiempo real. El streaming es el corazón de todas las aplicaciones de FX, ya que todo se basa en ofrecer información del mercado en tiempo real. En mercados con tanta volatibilidad, un segundo puede significar miles de euros, por eso uno tiene que olvidarse del modelo tradicional de petición y respuesta, y pasar a un modelo push como el de este producto, o del nuestro ;-)

Ya hablé de Comet/Push/loquesea hace tiempo. Y ya en aquel momento insinué que no era tan bonito, ni nuevo como parece. Nosotros hacemos esto desde hace años, pero en lugar de recibir los datos en un navegador, los recibimos en un Applet. No hay demasiada diferencia en eso. Resumiendo mi post anterior, el problema del streaming es que asocia un socket con un usuario, y si tienes que acomodar a 35.000 usuarios, entonces tienes un problema. La ventaja como productos como Lightstream es que utilizan NIO por debajo, lo que permite multiplexar varios clientes bajo un único socket. Hasta ahí va todo bien, pero después resulta que vas al banco más importante de Europa, y te dirá que naranjas de la china, que a su web se entra primero por la aduana de Apache, que vas a tener dos sesiones de seguridad una en Apache y otra en Tomcat, y otra serie de cosillas que te devuelven al mundo real.

En fin, más sobre este tema cuando las cosas estén más clarillas.

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.