Como veíamos en un post anterior es posible trabajar de forma sencilla con Windows Azure y Java empleando el plugin de Eclipse. Vimos cómo crear una aplicación Java y cómo desplegarla junto con las versiones del JDK y Tomcat que necesita la aplicación web.
Una caso con el que habitualmente te suelen encontrar desplegando aplicaciones Java, al menos con las que yo me he encontrado, es que se necesita afinidad de sesión…que si despliego la aplicación en múltiples servidores quiero que las diferentes peticiones que se hagan desde la misma máquina se hagan siempre usando el mismo servidor.
Abro el navegador, empiezo a navegar por la aplicación y todas las peticiones de la sesión se tienen que hacer siempre usando el mismo servidor….y ¿esto lo permite por defecto Windows Azure? NO, pero hay soluciones.
Cuando hay más de una instancia de un rol desplegado en Cloud Services Windows Azure se encarga de realizar de forma automática el balanceo de carga, pero no hace un balanceo por afinidad de sesión ni nos permite establecer la configuración de cómo queremos que se comporte, es una cosa transparente para nosotros.
Para este tipo de escenarios el plugin de Eclipse dispone de una opción que nos permite indicar si queremos disponer de afinidad de sesión (sticky sessions) en la aplicación que vamos a desplegar, “tan sencillo como marcar un check”.
¿Qué hace?
Pues disponer de afinidad de sesión usando el módulo ARR (Application Request Routing) de Internet Information Server, el cuál permite disponer de afinidad por sesión.
Cuando marcamos esta opción, el plugin modificar los ficheros de arranque del proyecto de Windows Azure para que se instale el módulo de ARR en las instancias que desplegamos. El módulo de ARR se puede instalar por línea de comandos de forma sencilla, utilizando el Microsoft Web Platform Installer.
Cuando no tenemos esta opción activada, cuando realizamos una petición a la aplicación el balanceador de Windows Azure decide el servidor que tiene que atender la petición y se la envía directamente al Tomcat que tenemos desplegado en la máquina, en el puerto que tengamos configurado.
Cuando activamos la opción, el módulo de ARR de IIS se pone por medio. El balanceador manda las peticiones al servidor que él considera, pero estas peticiones le llega al ARR y éste la redirecciona de nuevo al servidor Tomcat que toque teniendo en cuenta la afinidad de sesión.
Esto se consigue poniendo el IIS y el Tomcan el puerto diferentes, por ejemplo el IIS en el puerto 80 y el Tomcat en el 8080. Windows Azure manda todas las peticiones al puerto 80, el módulo de ARR decide qué servidor tiene que tratar la petición y lo redirecciona por el puerto 8080 para que le llegue al Tomcat…eso sí, el ARR en su lógica de decisión mantiene la afinidad de sesión.
Claro está, esto no es una cosa propia de aplicaciones Java, pero en este plugin de Eclipse está bastante bien solucionado, mejor incluso que Visual Studio dónde no tenemos esta opción.
Eso sí, si queremos hacer aplicaciones escalables, es mejor evitar siempre la afinidad de sesión, no es una buena práctica.
PD: y si te interesa saber más sobre interoperabilidad, te animo a que vengas al Cloud Tour http://www.plainconcepts.com/cloudtour/
