SISTEMA Y MÉTODO PARA MANTENER LA COHERENCIA DE UN CONTENIDO "CACHÉ" EN UN SISTEMA DE SOFTWARE DE NIVELES MÚLTIPLES DESTINADO A CONSTITUIR INTERFAZ ENTRE GRANDES BASES DE DATOS.

Método para mantener la coherencia de contenidos caché en una arquitectura de software de niveles múltiples,

que comprende un primer nivel (220) dotado, como mínimo, de un servidor/cliente, operando cada uno de dichos, como mínimo, un servidor/cliente, una caché local (230), incluyendo dicha arquitectura un nivel intermedio (210) que comprende, como mínimo, un servidor central (212), operando cada uno de dichos, como mínimo, un servidor central, una caché central (216), interconectándose cada uno de dichos, como mínimo, un servidor central con, como mínimo, una base de datos (204) a través de, como mínimo, un servidor de base de datos (202), conteniendo dicho, como mínimo, una base de datos, elementos de datos (360), siendo recuperados dichos datos con peticiones emitidas desde cada uno de dichos, como mínimo, un servidor central a dicho, como mínimo, un servidor de la base de datos, cuyo método comprende las siguientes etapas de: - construir (350) objetos en dicho, como mínimo, un servidor central desde, como mínimo, uno de dichos elementos de datos procedentes de, como mínimo, una base de datos, incluyendo en dicha etapa de construcción las etapas adicionales de: validar dichos objetos; atribuir un tiempo de validez TTL a dichos objetos y almacenar dichos objetos en dichas cachés centrales (340); - enviar (330, 370) dichos objetos desde dichas cachés centrales a cualquiera de dichos servidores de cliente que solicitan dichos objetos, incluyendo dicha etapa de envío la etapa adicional de: almacenar dichos objetos en dichas cachés locales; - suministrar (335, 375) dichos objetos a las aplicaciones de software utilizadas en dichos servidores de clientes y que solicitan dichos objetos; y que se caracteriza porque los objetos almacenados en dichas cachés centrales y en dichas cachés locales son invalidados tan pronto como, como mínimo, uno de dichos elementos de datos utilizados para construir dichos objetos (500) ha sido modificado en dicha base de datos, comprendiendo el método además las etapas de: - determinar los objetos afectados; - emitir solicitudes de invalidación (510) a todos los gestionadores invalidación de dichos servidores centrales; - invalidar los objetos correspondientes (515) en dichas cachés centrales; - propagar dichas instrucciones de invalidación (550) a todas las mencionadas cachés locales; - invalidar los objetos correspondientes (560) en dichas cachés locales, incluyendo dicha etapa de invalidación la etapa adicional de borrado de dichos objetos

SECTOR DE LA INVENCIÓN

La presente invención se refiere de manera general a arquitecturas de software de niveles múltiples de cliente/servidor, y más específicamente, a un método y a un sistema para mantener la coherencia entre el contenido de cachés que están implementadas en aparatos de nivel frontal o primer nivel y nivel medio para mejorar el rendimiento global.

ANTECEDENTES DE LA INVENCIÓN.

El modelo cliente/servidor que ha surgido a finales de los años 1980 es una arquitectura de software versátil y modular que ha estado destinada a mejorar la capacidad de utilización, flexibilidad, interoperabilidad y escalabilidad en comparación con la utilización de ordenadores principales centralizados con división de tiempo, que era lo habitual en aquel momento. Un cliente es un solicitante de servicios y el servidor un proveedor de dichos servicios. Dependiendo de la configuración del software, un mismo aparato puede ser tanto cliente como servidor.

La arquitectura cliente/servidor ha sustituido progresivamente la arquitectura de software anteriormente conocida con ordenadores principales (“mainframe”) en los que toda la inteligencia se encontraba en el ordenador central y en el que los usuarios interaccionaban con el ordenador central a través de un terminal no inteligente (“dumb terminal”) que solamente capta pulsaciones de teclado y envía esta información al ordenador principal. Una limitación bien conocida de las arquitecturas de software de ordenador principal es que no soportan fácilmente interfaces de usuario de gráficos (GUI) o el acceso a bases de datos múltiples desde lugares geográficos dispersos. Los ordenadores principales se utilizan, no obstante, todavía como potentes servidores en arquitecturas distribuidas de cliente/servidor.

La arquitectura cliente/servidor ha introducido un servidor de base de datos que actúa como servidor de archivo. En esta arquitectura, las solicitudes del usuario son contestadas utilizando directamente un sistema de gestión de base de datos relacional o RDBMS. El tráfico de la red se reduce al facilitar una respuesta a la petición en vez de transferir siempre los archivos completos. También mejora la actualización de usuarios múltiples a través de un elemento del proceso (“front end”) GUI a una base de datos compartida. En arquitecturas cliente/servidor se utilizan de manera típica las afirmaciones estructuradas en lenguaje de interrogación (SQL) para el intercambio de datos entre clientes y servidores.

Con la arquitectura cliente/servidor de dos niveles (100) mostrada en la figura 1, el interfaz del sistema de usuario está situado en el entorno del ordenador de sobremesa (102) del usuario y los servicios de gestión de la base de datos se encuentran en un servidor (104) capaz de dar servicio a muchos clientes. La gestión del proceso está dividida entre el entorno del interfaz del sistema de usuario y el entorno del servidor de gestión de la base de datos. Todas las combinaciones de topologías, incluyendo el interfaz de clientes único/múltiples, servidores únicos/múltiples (no mostrado), muy frecuentemente en una red de área local o LAN (108), son evidentemente posibles.

En la arquitectura tradicional de dos niveles, el primer nivel, el cliente (102), posee el interfaz de usuario, la lógica principal de negocio y de proceso de datos. Acepta y comprueba la sintaxis de la entrada de usuario, procesa la lógica de aplicación, genera peticiones de bases de datos, las transmite al servidor y pasa la respuesta en retorno a tareas del usuario. El segundo nivel, el servidor de la base de datos (104), acepta y procesa peticiones de base de datos de clientes, comprueba autorizaciones, asegura que no se violen las limitaciones de integridad, lleva a cabo proceso de peticiones/actualización y transmite repuestas al cliente. También mantiene el catálogo del sistema, proporciona acceso simultáneo a la base de datos y lleva a cabo control de recuperación.

La arquitectura cliente/servidor de dos niveles se ha demostrado como una solución satisfactoria para el trabajo con ordenadores distribuido cuando los grupos de trabajo no superan 100 personas que interaccionan en un LAN simultáneamente. No obstante, cuando el número de usuarios aumenta, el rendimiento empieza a deteriorarse como resultado de que el servidor mantiene una conexión mediante mensajes de “mantenimiento vivo” (“keepalive”) con cada cliente, aunque no se esté realizando trabajo. Una segunda limitación de la arquitectura de dos niveles es que la implementación de los servicios de gestión de proceso, utilizando procesos de bases de datos, propiedad del vendedor, restringe la flexibilidad y selección de RDBMS para las aplicaciones. Asimismo, las implementaciones de la arquitectura de dos niveles han demostrado una flexibilidad limitada en el desplazamiento (reparto) de la funcionalidad de un programa del servidor a otro.

Posteriormente, aparecieron en los años 1990 la arquitectura de tres niveles (120) y variantes de niveles múltiples para superar las limitaciones anteriores. En la arquitectura de tres niveles se añadió un nivel intermedio (126) entre el interfaz del sistema de usuario del entorno del cliente (122) y el entorno (124) del servidor de gestión de la base de datos. Si bien existen múltiples maneras de implementar esta arquitectura y el nivel intermedio, este último tiene frecuentemente la función de ordenación o formación de colas, ejecución de aplicación y disposición de la base de datos. De manera típica, un cliente facilita su petición al nivel intermedio y se desconecta porque el nivel intermedio debe tener acceso a los datos, y devuelve la respuesta al cliente. Además, la capa intermedia añade programación y priorización para el trabajo que se está realizando.

En la variante indicada anteriormente de arquitectura de tres niveles, el cliente, es decir, el primer nivel, puede tener que llevar a cabo solamente el interfaz de usuario, es decir, validar las entradas; en cuyo caso el nivel intermedio soporta toda la lógica de negocio y realiza el proceso de datos, mientras que el servidor, es decir, el tercer nivel, lleva a cabo la validación de datos y controla el acceso a la base de datos.

Los documentos US-A1-2003 0188 106 y US-B1-6934717 dan a conocer arquitecturas de niveles múltiples con cachés de replicación para los datos contenidos en una base de datos principal o maestra, situada en el programa de proceso del sistema (“backend”).

La arquitectura de tres niveles cliente/servidor se ha demostrado que mejora el rendimiento para grupos con un gran número de usuarios (de manera típica, hasta mil, es decir, diez veces el caso de dos niveles) y mejora la flexibilidad en comparación con el sistema de dos niveles, especialmente, a causa de que el código de aplicación no tiene que ser compartido entre capas. La arquitectura cliente/servidor de tres niveles tiene como resultado un entorno que es considerablemente más escalable que la arquitectura de dos niveles con conexión directa del cliente al servidor. Proporciona la capacidad de actualizar múltiples RDBMS distintos en una sola transacción y puede conectarse a una serie de fuentes de datos, incluyendo archivos planos (“flat files”), sistemas de gestión de base de datos no relacionales, y asimismo a ordenadores principales que en la actualidad sirven frecuentemente como poderosos servidores de la base de datos. Las arquitecturas de tres niveles y de niveles múltiples se adaptan, por lo tanto, de manera óptima a entornos grandes de cliente/servidor distribuidos. Por ejemplo, los que tienen que desplegar las compañías de reservas aéreas para servir a sus clientes, es decir, las agencias de viajes en todo el mundo y en los que se requieren recursos compartidos, tal vez como base de datos heterogéneas (es decir, las bases de datos de tarifas y de disponibilidad de las compañías aéreas) y normas de proceso.

El hecho de que los centros de datos de niveles múltiples han pasado a ser una exigencia básica para proporcionar los mencionados servicios, reduciendo la carga de cálculo de los ordenadores y las comunicaciones, es crucial para mejorar adicionalmente el rendimiento y la escalabilidad. El disponer en memoria caché contenidos dinámicos en varios niveles de un centro de datos de niveles múltiples es un método bien conocido para reducir las cargas de cálculo de ordenador y de comunicación, de manera que se pueda servir a un mayor número de clientes simultáneamente, puesto que en caso de acceso (“hit”), los datos... [Seguir leyendo]

1. Método para mantener la coherencia de contenidos caché en una arquitectura de software de niveles múltiples, que comprende un primer nivel (220) dotado, como mínimo, de un servidor/cliente, operando cada uno de dichos, como mínimo, un servidor/cliente, una caché local (230), incluyendo dicha arquitectura un nivel intermedio (210) que comprende, como mínimo, un servidor central (212), operando cada uno de dichos, como mínimo, un servidor central, una caché central (216), interconectándose cada uno de dichos, como mínimo, un servidor central con, como mínimo, una base de datos (204) a través de, como mínimo, un servidor de base de datos (202), conteniendo dicho, como mínimo, una base de datos, elementos de datos (360), siendo recuperados dichos datos con peticiones emitidas desde cada uno de dichos, como mínimo, un servidor central a dicho, como mínimo, un servidor de la base de datos, cuyo método comprende las siguientes etapas de:

- construir (350) objetos en dicho, como mínimo, un servidor central desde, como mínimo, uno de dichos elementos de datos procedentes de, como mínimo, una base de datos, incluyendo en dicha etapa de construcción las etapas adicionales de: validar dichos objetos; atribuir un tiempo de validez TTL a dichos objetos y almacenar dichos objetos en dichas cachés centrales (340);

- enviar (330, 370) dichos objetos desde dichas cachés centrales a cualquiera de dichos servidores de cliente que solicitan dichos objetos, incluyendo dicha etapa de envío la etapa adicional de: almacenar dichos objetos en dichas cachés locales;

- suministrar (335, 375) dichos objetos a las aplicaciones de software utilizadas en dichos servidores de clientes y que solicitan dichos objetos;

y que se caracteriza porque los objetos almacenados en dichas cachés centrales y en dichas cachés locales son invalidados tan pronto como, como mínimo, uno de dichos elementos de datos utilizados para construir dichos objetos (500) ha sido modificado en dicha base de datos, comprendiendo el método además las etapas de:

- determinar los objetos afectados;

- emitir solicitudes de invalidación (510) a todos los gestionadores invalidación de dichos servidores centrales;

- invalidar los objetos correspondientes (515) en dichas cachés centrales;

- propagar dichas instrucciones de invalidación (550) a todas las mencionadas cachés locales;

- invalidar los objetos correspondientes (560) en dichas cachés locales, incluyendo dicha etapa de invalidación la etapa adicional de borrado de dichos objetos.

2. Método, según la reivindicación 1, en el que las peticiones de dichos servidores de clientes son equilibradas en cuanto a carga (385) con respecto a la totalidad de dichos servidores centrales y en el que uno de dichos servidores centrales es seleccionado por cada petición.

3. Método, según las reivindicaciones 1 ó 2, en el que dicha etapa de construcción comprende la etapa adicional de: replicar (380) un objeto (355) de nueva construcción en todos los demás servidores centrales a partir de dicho servidor central seleccionado.

4. Método, según las reivindicaciones 1 ó 2, en el que un objeto es solicitado (390) de dicha caché central seleccionada (340) siempre que falte (320, 350) o esté fuera del plazo de validez (405) en dicha caché local.

5. Método, según la reivindicaciones 1 ó 2, en el que dicha etapa de construcción (350) es puesta en marcha en dicho servidor central seleccionado siempre que el objeto solicitado falte (355) en dicha caché central seleccionada.

6. Método, según cualquiera de las reivindicaciones 1 a 5, que comprende una serie de servidores centrales y en el que uno de dichos servidores centrales está diseñado como servidor central principal (340) y todos los demás son servidores centrales de refuerzo.

7. Método, según la reivindicación 6, en el que dicha etapa de construcción es puesta en marcha en dicho servidor central principal (480) desde un gestionador de invalidación (460) siempre que dicho objeto solicitado se encuentre fuera de plazo de validez (455) en dicho servidor central seleccionado.

8. Método, según la reivindicación 7, en el que el TTL de dicho objeto fuera de validez (455) recibe un valor bajo antes de ser enviado (485) al servidor del cliente peticionario.

9. Método, según cualquiera de las reivindicaciones anteriores, en el que la etapa de invalidar objetos en dichas cachés centrales comprende la etapa adicional de borrar dichos objetos.

10. Método, según la reivindicación 6, en el que la etapa de invalidar objetos comprende la etapa de reconstruir dichos objetos (535) en dicho servidor central principal (520), comprendiendo la etapa adicional de replicar (540) dichos objetos reconstruidos en la totalidad de dichos servidores centrales de refuerzo.

11. Método, según la reivindicación anterior, en el que cada uno de dichos servidores centrales comprende una tabla de avance (600) de la reconstrucción de objetos y un proceso de barrido (635) para controlar dicha reconstrucción de objetos a partir de la tabla de avance, comprendiendo las etapas de:

- registrar el principio y final de las reconstrucciones de objetos en dicha tabla de avance (610);

- inspeccionar dichas tablas de avance (635) para detectar la terminación de dichas reconstrucciones de objetos, comprendiendo la etapa adicional de: borrar las entradas de la tabla de las reconstrucciones de objetos que han sido terminadas satisfactoriamente;

- detectar fallos en la reconstrucción de objetos en avance;

- intentar reconstrucciones de objetos en fallo.

12. Método, según la reivindicación anterior, en el que dichas reconstrucciones de objetos son llevadas a cabo en dicho servidor central principal y en el que dicha etapa de registro incluye la etapa adicional de: enviar inicios de reconstrucción de objetos (625) a la totalidad de dichas tablas de avance de los servidores centrales de refuerzo.

13. Método, según la reivindicación 12, en el que la terminación de la reconstrucción de objetos es registrada en dichas tablas de avance de los servidores centrales de refuerzo al recibir (615) los objetos enviados desde el servidor central principal.

14. Método, según la reivindicación 11, en el que dicha etapa de detección y dicha etapa de nuevo intento son llevadas a cabo en uno de dichos servidores centrales de refuerzo.

15. Método, según la reivindicación 1, en el que dicha etapa de reconstrucción incluye las etapas preliminares de: comprobar si dicha caché central está completa o no; en caso negativo proceder inmediatamente a dicha etapa de construcción; si está completa (760), seleccionar el objeto Utilizado Menos Recientemente (770) en dicha caché central; y

comprobar si dicho objeto Utilizado Menos Recientemente está fuera de validez o no; en caso negativo (792), almacenar dicho objeto Utilizado Menos Recientemente en una segunda memoria (775); y si está fuera de validez (794), descartar (780) dicho objeto Utilizado Menos Recientemente, procediendo en ambos casos a dicha etapa de construcción.

16. Método, según la reivindicación 10, en el que se efectúa la búsqueda en una memoria secundaria (720) de un objeto faltante, antes de proceder a dicha etapa de reconstrucción.

17. Sistema para mantener la coherencia de contenidos caché en una arquitectura de servidores de niveles múltiples, comprendiendo, dicho sistema, medios adaptados para llevar a cabo cada etapa del método según cualquiera de las reivindicaciones 1 a 16.

18. Producto de programa de ordenador almacenado en un medio de almacenamiento legible por ordenador, que comprende medios de código legibles por ordenador para provocar, como mínimo, que un ordenador lleve a cabo el método de mantener la coherencia del contenido caché en un sistema de software de niveles múltiples, de acuerdo con cualquiera de las reivindicaciones 1 a 16.