Category: Arquitectura

Hola,
Seguimos adelante con el conjunto de artí­culos destinados al Especial Capa de Caché, para abordar una sencilla forma de cachear datos en memoria, una fórmula de andar por casa, mediante el uso variables de tipo static.
Una variable de tipo static cumple dos de las principales premisas necesarias para crear una capa de caché, en primer lugar es visible para toda la aplicación, en segundo lugar su contenido se almacena en memoria. Adicionalmente, cuenta con otras ventajas a nivel de programación, como es permitir almacenar objetos de cualquier tipo, incluso los no serializables.
Por tanto, ante la pregunta, ¿podrí­a utilizar como sistema de caché de andar por casa un conjunto de variables static que me permitieran resolver mi problema? La respuesta podrí­a ser, sí­, por qué no, si el problema a abordar no requiera por ejemplo:
* Polí­ticas avanzadas de refresco de caché
* El conjunto de datos a almacenar no va a ser muy grande por lo que no hay peligro de colapsar la memoria del servidor
* Compartir la información de caché entre diferentes aplicaciones
Eso sí­, como consejo, y con tal de mejorar la escalabilidad del sistema, encapsularí­a el acceso a nuestra caché basada en statics con tal de que el sistema no conozca la implementación interna de la misma. Con este tipo de implementación y en caso de necesitar a futuro contar con un sistema más potente, simplemente necesitarí­amos reimplementar el sistema de caché sin afectar al resto del sistema.
Un saludo.
Miguel.

Hola,
Y tras la introducción realizada en el capí­tulo anterior, vamos a estudiar en primera instancia dónde podemos ubicar la capa de caché y con qué relaciones puede contar.
Como siempre, los ejemplos están basados en la experiencia, no queriendo esto decir que sean las íºnicas soluciones, si no que son varios ejemplos válidos, de comíºn uso, y que podrí­an serviros en un momento dado. Los muestro como ejemplo didáctico, pero esto no quiere decir que sean la íºnica solución.
Ejemplo. Capa de caché distribuida y en cliente, siendo responsabilidad en el primer caso de la capa de negocio alimentarla de datos
A continuación un diagrama UML de componentes que da a entender el escenario y remarcando por mi parte que esta es la solución que suelo usar y con la que más veces me he encontrado.

Podremos observar 4 nodos diferentes, que representan 4 sistemas fí­sicos: un servidor de presentación, uno de negocio, uno de persistencia y una aplicación de escritorio. He resaltado en dos de los sistemas fí­sicos la utilización de 2 cachés diferentes.
En el sistema fí­sico de negocio vemos que la capa de caché es accedida por la capa de negocio (en los casos que esta lo considere, es decir, en los casos en los que el negocio sabe que dicho dato está cacheado). La capa de caché puede retornar la información ya cacheada a la capa de negocio, evitando que esta pida la información al acceso a datos, lo que forzarí­a a consultar la base de datos. En el caso de que la capa de caché no disponga de la información cacheada, será ella la que conectará con la capa de acceso a datos para obtener la información y cachearla, consiguiendo así­ que en la siguiente consulta de la capa de negocio ya no sea necesario pasar por la base de datos (a no ser que se haya reciclado la caché, claro).
Por otro lado podemos ver que en el modo que representa la aplicación de escritorio tenemos una caché local, la cual almacena ciertos datos, para evitar así­ llamadas al servidor de negocio.
A resaltar además el hecho de que la capa de caché de negocio está situado en el mismo nodo fí­sico que el resto de capas del nodo; esto es algo que veremos más adelante que puede cambiar en el momento en el que distribuyamos la caché (donde aparecerá un nuevo nodo fí­sico participante).
Un saludo.
Miguel.

Hola,
Hablamos muchas veces de arquitecturas n-capas, aunque muchas menos veces se trata el tema de los n-niveles.
Los n-niveles es un concepto que seguro que habéis usado, aunque no le hayáis etiquetado con este nombre.
Los niveles (tiers en inglés), identifican capas fí­sicas diferenciadas; como ejemplo, diferentes servidores.
En una arquitectura tí­pica en n-capas podemos mantener todas las capas en la misma aplicación o en diferentes aplicaciones pero corriendo en el mismo servidor; acabamos de ver un ejemplo de n-capas y 1-nivel.
Por otro lado, podrí­amos tener una aplicación asp.net corriendo en una máquina concreta, estando al mismo tiempo una aplicación Windows Communication Foundation corriendo en otro servidor y conteniendo ésta toda la lógica de negocio, caché y acceso a datos. Por íºltimo, la base de datos y los procedimientos almacenados en una tercera máquina. Este serí­a un ejemplo de arquitectura en n-capas y 3-niveles.
A continuación os dejo un UML de componentes que describe este íºltimo ejemplo.

Y ya una vez situados todos, las ventajas de usar una arquitectura en n-niveles:
* Separación de responsabilidades fí­sicas: puede dimensionarse cada servidor adaptándolo a las exigencias de las capas que en él se despliegan.
* Separación de la carga de trabajo: seguramente la BBDD tirará más de disco duro que el servidor de negocio que tirará más memoria; al estar en máquinas separadas los procesos que ocurran en una o en otra no afectarán al rendimiento global.
* Tolerancia a fallos: al tratarse de diferentes máquinas, si se cae una no se cae todo el sistema (aunque si sólo tienes una aplicación corriendo y necesita de todas las partes, de poco te va a servir)
* Escalabilidad: es posible añadir más de una máquina por nivel y poder permitir así­ un mayor rendimiento global. Por otro lado este punto mejorarí­a también la tolerancia a fallos.
Un saludo.
Miguel.