Seguro que todos recordamos la película de los hermanos Marx en el oeste (Go West) en la que literalmente desarmaban un tren para echar leña a la caldera de la máquina al grito de ¡más madera!. Y es que si me permitís el símil, cada vez más me acuerdo de esta película cuando nos referimos a la memoria que necesitan las aplicaciones de la empresa.

Y es que la memoria de un servidor es finita y por lo tanto un bien escaso, ¿o no?… tal vez ya no lo sea tanto en un escenario en el que cada vez los costes de hardware van en continuo descenso y hacerse con unos cuantos gigas (muchos) de memoria está al alcance de cualquiera.

En una arquitectura de aplicaciones basada en SOA tendremos típicamente 4 capas (pueden ser más)

  1. el frontend o aplicación web que hace de interfaz con el usuario
  2. la capa de integración
  3. la capa con la lógica de negocio
  4. la base de datos

Con esta arquitectura, para implementar una funcionalidad que requiere el usuario, por ejemplo un listado relativamente grande (de 2000 o 3000) registros, la cosa empieza a complicarse. Evidentemente no se pueden mostrar todos los registros en pantalla, por lo que se presentan de manera paginada, es decir, unos cuantos registros y un botón de página siguiente.  Pero ¿donde se guardan los 2000 registros?:

  • El primer sitio donde se podría guardar sería en el navegador pero en este caso obligaríamos a descargar esta cantidad de registros que probablemente el usuario no verá nunca sobrecargando la red y el servidor web.
  • ¿En la sesión del servidor de frontal? si hay muchos usuarios concurrentes, evidentemente la memoria se agotará y estaremos en un problema.
  • ¿En la capa de integración? los servicios deben ser sin estado por lo tanto en principio no podríamos guardarlo ahí.
  • Lo mismo para la capa de negocio (también sin estado).

En fin, que nos quedamos sin opciones. Una alternativa sería guardar en la sesión frontal la mínima información posible (las claves primarias de los registros) e ir pidiendo sucesivamente a la capa de integración, capa de negocio y de datos, el contenido de los registros de las claves que pasemos como parámetro. Con esto logramos que en ningún momento se guarde todo el listado en la sesión de frontal.

Sin embargo, la solución anteriormente expuesta tiene un problema. Estamos “contaminando” los contratos de nuestros servicios con unos parámetros que no responden a necesidades de negocio sino a una limitación técnica.

La solución definitiva al problema puede venir de la mano de un caché distribuida del tipo de Oracle Coherence o  Gemstone (recientemente adquirida por VMWare, la propietaria de Spring).

Por ejemplo, en el caso de Coherence, la memoria se gestiona en una serie de nodos fuera del servidor de aplicaciones. Esto es, “liberamos” al servidor de aplicaciones del peso de lidiar con la memoria de sesión de la aplicación web, con la ventaja que tanto las máquinas adicionales que se necesitan para soportar este caché son más baratas y fáciles de administrar que las de los servidores de aplicaciones. Dicho de otro modo, podemos disponer de más memoria de forma más barata. Y este es sólo uno de los posibles de usos de este tipo de caché de memoria.

En una próxima entrada veremos los posibles escenarios de aplicación de los cachés de memoria distribuidos.

Comparte esta entrada…

Share

Anuncios