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 dedichos, como mínimo, un servidor/cliente, una caché local (230), incluyendo dicha arquitectura un nivelintermedio (210) que comprende, como mínimo, un servidor central (212), operando cada uno de dichos, comomínimo, un servidor central, una caché central (216), interconectándose cada uno de dichos, como mínimo, unservidor central con, como mínimo, una base de datos (204) a través de, como mínimo, un servidor de base dedatos (202), conteniendo dicho, como mínimo, una base de datos, elementos de datos (360), siendorecuperados dichos datos con peticiones emitidas desde cada uno de dichos, como mínimo, un servidor centrala dicho, como mínimo, un servidor de la base de datos, cuyo método comprende las etapas de:

- construir (350) objetos en dicho, como mínimo, un servidor central desde, como mínimo, uno de dichoselementos de datos procedentes de, como mínimo, una base de datos, incluyendo en dicha etapa deconstrucción las etapas adicionales de: validar dichos objetos; atribuir un tiempo de validez (TTL) a dichosobjetos 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 clienteque solicitan dichos objetos, incluyendo dicha etapa de envío la etapa adicional de: almacenar dichos objetosen dichas cachés locales;

- suministrar (335, 375) dichos objetos, como mínimo, a una aplicación de software que funciona en dicho,como mínimo, un servidor de clientes y que solicita dichos objetoscaracterizado por comprender:

- la utilización de 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;

- una etapa de invalidación de objetos que incluye la etapa de reconstruir dichos objetos (535) en dichoservidor central principal (520), comprendiendo la etapa adicional de replicar (540) dichos objetosreconstruidos en todos los mencionados servidores centrales de refuerzo;

- incluyendo cada uno de dichos servidores centrales una tabla de avance de la reconstrucción de objetos(600) y un proceso de barrido (635) para controlar dicha reconstrucción de objeto a partir de dicha tabla deavance, comprendiendo las etapas de;

- registrar el inicio 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 deobjeto, comprendiendo la etapa adicional de: borrar entradas de tabla de reconstrucciones de objeto quehan sido completadas satisfactoriamente;

- detectar reconstrucciones de objeto en avance que se encuentran en fallo;

- volver a intentar las reconstrucciones de objetos en fallo.

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.

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 como 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 el 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” (“keep-alive”) 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 90 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.

El documento US-B1-6934717 da a conocer una arquitectura 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 sistema de proceso (“back end”) . Los mismos datos se encuentran presentes en la base de datos principal y en los cachés.

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... [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 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, como mínimo, a una aplicación de software que funciona en dicho, como mínimo, un servidor de clientes y que solicita dichos objetos

caracterizado por comprender:

- la utilización de 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;

- una etapa de invalidación de objetos que incluye la etapa de reconstruir dichos objetos (535) en dicho servidor central principal (520) , comprendiendo la etapa adicional de replicar (540) dichos objetos reconstruidos en todos los mencionados servidores centrales de refuerzo;

- incluyendo cada uno de dichos servidores centrales una tabla de avance de la reconstrucción de objetos

(600) y un proceso de barrido (635) para controlar dicha reconstrucción de objeto a partir de dicha tabla de avance, comprendiendo las etapas de;

- registrar el inicio 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 objeto, comprendiendo la etapa adicional de: borrar entradas de tabla de reconstrucciones de objeto que han sido completadas satisfactoriamente;

- detectar reconstrucciones de objeto en avance que se encuentran en fallo;

- volver a intentar las reconstrucciones de objetos en fallo.

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 la reivindicación 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 la reivindicación 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 reivindicación 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, 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.

7. Método, según cualquiera de las reivindicaciones anteriores, 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.

8. 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.

9. 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.

10. Método, según la reivindicación 9, 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.

11. Método, según la reivindicación 1, 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.

12. 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.

13. Método, según la reivindicación 12, 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.

14. Método, según la reivindicación 1, que comprende la disposición de un límite en el número de nuevos intentos llevados a cabo durante la etapa de nuevo intento.

15. 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.

16. 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 sistema de 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 15.