Elle concerne également un système de réservation par ordinateur apte à mettre en oeuvre ce procédé.

Les systèmes de réservation par ordinateur sont couramment employés actuellement, notamment dans le domaine des voyages, du transport aérien, ou encore pour la réservation dans l'hôtellerie.

Dans ce cadre, il existe une ou plusieurs bases d'inventaire correspondant à l'état des réservations chez chacun des prestataires de services tels la compagnie aérienne ou la compagnie de location de voitures. Un système central permet d'accéder aux différentes bases d'inventaire pour en traiter les informations et répondre aux demandes des utilisateurs. Ces derniers peuvent en effet interroger le système central par le biais d'applications client pour obtenir des données notamment quant aux disponibilités, aux tarifs, et aux modalités des services offerts.

L'ensemble de ces accès et transferts de données s'effectue par un réseau de communication.

Selon l'état de la technique actuel, le système central reçoit de multiples requtes d'une pluralité d'utilisateurs et, pour y répondre, interroge de façon directe une ou plusieurs bases d'inventaire.

Ce principe de fonctionnement a l'inconvénient d'alourdir et d'encombrer les réseaux de communication, principalement en liaison avec les bases d'inventaire.

Ce point est d'autant plus dommageable que certaines requtes des utilisateurs ne nécessitent pas un accès direct de façon synchrone aux bases de données d'inventaire.

A titre d'exemple, des utilisateurs se connectant par le biais d'un réseau de large extension tel Internet interrogent parfois le système de réservation dans le seul but de connaître les modalités de réservations et des tarifs. II n'est donc pas forcément nécessaire de leur fournir en mme temps une information certaine quant aux disponibilités de place.

L'état de la technique actuel comprend notamment le document US-A-5 570 283. Celui-ci divulgue un système informatique doté d'un logiciel modulaire permettant, autant à des voyageurs d'accéder électroniquement à un inventaire pour obtenir des tarifs de vols d'avions de façon très rapide dans un environnement logiciel convivial, qu'à des agents ou des professionnels de faire des réservations et d'accéder à des bases de données spécifiques au regard de leurs activités professionnelles.

Ce document s'attache essentiellement au problème du prix des prestations offertes. En effet, il vise à avoir des prix parfaitement à jour pour les agents ou autres professionnels.

Cependant, selon ce document, il est encore nécessaire d'avoir un accès direct aux bases d'inventaire d'état de réservation pour tout type de requtes.

La présente invention pallie les inconvénients des techniques actuelles.

Elle permet de diminuer le volume des accès en direct aux bases d'inventaire d'état des réservations en proposant une base de données de type « CACHE » apte à répondre aux premières interrogations des utilisateurs.

Par ailleurs, l'accès à ce cache a l'avantage de pouvoir tre effectué par le biais d'un réseau de communication de type large extension tel qu'Internet pour lequel le coût de communication est très réduit.

D'autres buts et avantages apparaîtront au cours de la description qui suit qui présente un mode préféré de réalisation de l'invention mais qui n'est cependant pas limitative.

La présente invention concerne un procédé de traitement et d'accès à des données dans un système de réservation par ordinateur comportant une partie serveur dotée d'un système central et d'au moins une base d'inventaire d'état de réservations, et une partie client comprenant au moins une application client, les parties serveur et client étant reliées par un réseau de communication, caractérisé par le fait que : - on crée au moins un cache dans la partie serveur, ledit cache contenant des données de réservation ; - on ajoute des données au cache par transfert depuis au moins une base d'inventaire ; - on crée une application d'interfaçage entre le cache et la ou les applications client pour que son utilisateur puisse adresser des requtes au cache et recevoir des données en réponse.

Ce procédé peut se présenter selon les variantes énoncées ci-après : + si, lors d'une requte au cache par une application client, le cache ne contient pas les données demandées : - on traite la requte dans le système central par accès aux bases d'inventaire d'état de réservations pour trouver les données demandées ; - on ajoute lesdites données au cache ; - on retourne les données demandées, en réponse, à l'application client. on nettoie les données contenues dans le cache par mise en oeuvre de la procédure suivante : - affectation d'une durée maximale de conservation à chaque donnée contenue dans le cache ; - scrutation périodique des données contenues dans le cache pour déterminer les données dont la durée maximale de conservation est dépassée ; - suppression des données dont la durée maximale de conservation est dépassée. on nettoie les données contenues dans le cache par la procédure suivante :

- affectation d'une taille limite et d'une taille seuil au cache, ladite taille seuil ayant une valeur inférieure d'une marge déterminée à ladite valeur limite ; - lorsque la taille limite est atteinte, suppression des données contenues dans le cache par ordre décroissant d'ancienneté d'utilisation, jusqu'à atteindre la taille seuil. on range les données dans le cache par : - affectation d'une clé à chaque donnée à stocker ; - transformation de la clé en une valeur numérique ; - création d'un vecteur de listes comprenant une suite de compartiments aptes à contenir une liste de plusieurs données ; - affectation, à chaque compartiment, d'un index numérique entier à partir de zéro ; - détermination, pour chaque donnée, de l'index du compartiment de stockage par modulation de la valeur numérique de la clef de la donnée par le nombre de compartiments ; - stockage de la donnée dans le compartiment ainsi déterminé.

+ on recherche une donnée dans le cache par transformation de la clé en une valeur numérique et détermination de l'index du compartiment de stockage par modulation de la valeur numérique de la clef par le nombre de compartiments, et par le fait que : - si une seule donnée est présente dans le compartiment, on retrouve la donnée recherchée ; - si aucune donnée n'est présente dans le compartiment on retourne une information d'absence ; - si plusieurs données sont présentes dans le compartiment on compare leurs clés pour déterminer celle qui est effectivement recherchée.

+ On ne bloque l'accès que des compartiments en cours de traitement d'une requte pour autoriser d'autres traitements de requtes simultanées dans d'autres compartiments.

L'invention concerne en outre un système de réservation par ordinateur comportant une partie serveur dotée d'un système central et d'au moins une base d'inventaire d'état de réservations, et une partie client comprenant au moins une application

client, les parties serveur et client étant reliées par un réseau de communication, apte à mettre en oeuvre le procédé selon l'invention.

Caractérisé par le fait qu'il comporte - au moins un cache dans la partie serveur, ledit cache contenant des données de réservation ; - au moins une application d'interfaçage entre le cache et la ou les applications client pour que son utilisateur puisse adresser des requtes au cache et recevoir des données en réponse.

Selon des variantes : - au moins un bloc de cache doté d'un cache et d'une application de gestion du cache ; - au moins un bloc de gestion d'entrée doté d'une pluralité de modules de gestion d'entrée recevant chacun les requtes d'une ou plusieurs applications client et gérés par un gestionnaire d'entrée.

- chaque module de gestion d'entrée est affecté à une seule application client.

- des modules de gestion d'entrée sont affectés à plusieurs applications client et que leur bloc de cache comprend : - une file apte à recevoir les requtes issues des applications client et à les redistribuer par ordre d'entrée sur demande du cache ; - le ou les caches comprennent un vecteur de listes comprenant une suite de compartiments aptes à contenir une liste de plusieurs données et auquel est affecté un index, pour la recherche d'une donnée par l'index du compartiment où elle est stockée.

- il comporte un outil de nettoyage apte à adresser des commandes de nettoyage au cache selon une procédure déterminée.

Les dessins ci-joints sont donnés à titre d'exemples. Ils représentent des modes de réalisation qui permettront de comprendre aisément l'invention.

La figure 1 montre un exemple de traitement des requtes des clients selon l'état de la technique actuel.

La figure 2 schématise les organes du système de l'invention dans un mode particulier de réalisation.

La figure 3 est un autre schéma de réalisation du système selon l'invention qui précise certains organes.

La figure 4 est un synoptique des phases d'interrogation et de mise à jour du cache dans le système et selon le procédé de l'invention.

La figure 5 montre un exemple de nettoyage des données contenues dans le cache, tandis que la figure 6 illustre une variante de rangement de données dans le cache.

Enfin, la figure 7 est une variante de l'invention dans lequel plusieurs clients accèdent au système par le biais d'un mme module de gestion d'entrée.

Comme illustré très schématiquement à la figure 1, selon l'état de la technique actuel, le client peut adresser à un système central (CS) des requtes pour obtenir des données concernant des réservations par exemple de vol d'avions, ou encore de disponibilité de place dans tout domaine de service.

Cette requte peut tre résumée par une opération « GET » envoyée au système central (CS). Ce dernier est en liaison avec une ou plusieurs bases d'inventaire (I) d'état de réservations dans laquelle se trouve la donnée recherchée.

Par interrogation de ces bases d'inventaire (I), le système central (CS) peut retourner une réponse au client.

Plus précisément, selon l'état de la technique actuelle les différents clients envoient un message d'interrogation à un organe couramment dénommé « FRONT END » et ledit organe de « FRONT END » répercute la demande du client au coeur du système central dénommé « BACK END ». L'organe de FRONT END constitue en fait un intermédiaire entre les clients et le coeur du système central. C'est à ce niveau que sont envoyés les différents messages des clients avant leur transmission. Ce type d'organisation génère une multiplicité de communication entre les différents organes du système et un encombrement important de l'ensemble du système central.

Le système de réservation selon l'invention évite de tels inconvénients.

De façon connue en soit, il s'intègre dans une structure comprenant une partie client avec plusieurs applications client (19) et une partie serveur dotée d'un système central (CS) et d'une ou plusieurs bases d'inventaire (I).

Le traitement des requtes selon l'invention peut s'inscrire en complément ou en remplacement du processus actuel, tel que décrit précédemment.

Les bases d'inventaire sont généralement des bases de données mises à disposition par le prestataire de service tel la compagnie aérienne et elle présente un rafraîchissement immédiat de l'état des réservations.

Toujours selon l'état de la technique actuel et possiblement dans la structure de l'invention, la partie serveur et la partie client communiquent par le biais d'un réseau de communication 5.

Dans le cadre de l'invention, le réseau de communication 5 peut inclure un réseau de large extension tel l'lnternet.

De façon caractéristique et comme représenté en figure 2, le système selon l'invention comprend au moins un cache (9 a, 9 b).

Le cache se situe dans la partie serveur et contient des données de réservation. Les caches (9 a, 9 b) sont intégrés dans des blocs de cache (3 a, 3 b, 3 c) représentés en figure 2. De façon connue en soit, les caches (9 a, 9 b) pourront tre constitués par une mémoire volatile de type RAM (Random Access Memory). Bien entendu, une sauvegarde périodique des données contenues dans les caches (9 a, 9 b) peut tre effectuée sur une mémoire non volatile, sur un disque.

De façon intermédiaire entre les différentes applications client (19) et le ou les caches (9 a, 9 b), le système ici présenté comporte des applications d'interfaçage (18). Elles permettent à l'utilisateur d'adresser des requtes au cache et de recevoir des données en réponse.

Toujours en référence à la figure 2, le système comporte préférentiellement un ou plusieurs blocs de gestion d'entrée (2 a, 2 b).

Le ou les blocs de gestion d'entrée (2 a, 2 b) communiquent avec les applications d'interfaçage (18) par le biais de moyen de routage (4). Tout type de routage peut tre mis en oeuvre selon l'invention qui n'est pas limité à une variante particulière.

La structure composée des blocs de gestion d'entrée (2 a, 2 b), des moyens de routage (4), des applications d'interfaçage (18) et des différents blocs de cache (3 a, 3 b, 3 c) permet la formation d'une unité fonctionnelle dénommée serveur cache (1).

Plus précisément, au sein du serveur cache (1), les blocs s'articulent avantageusement de la façon suivante.

En ce qui concerne les blocs de gestion d'entrée (2 a, 2 b), ils comprennent une pluralité de modules de gestion d'entrée (8 a, 8 b) en liaison avec les applications client (19) par le biais du réseau de communication (5).

Selon une première variante, chaque module de gestion d'entrée est relié à une seule application client (19). On a donc autant de modules (8 a, 8 b, 8 c) que d'applications client (19) reliées au bloc de gestion d'entrée (2 a, 2 b). Pour administrer chaque module de gestion d'entrée (8 a, 8 b), chaque bloc de gestion d'entrée (2 a, 2 b) comprend un gestionnaire d'entrée (7 a, 7 b). II permet d'appliquer des paramètres de fonctionnement à chaque module de gestion d'entrée (8 a, 8 b).

Un bloc de gestion d'entrée (2 a, 2 b) peut tre relié à un bloc de cache (3 a, 3 b) ou à plusieurs selon des conditions de routage adaptées.

Selon l'exemple de la figure 3, le bloc de gestion d'entrée (2 a) communique avec le bloc de cache (3 a).

Ce dernier comprend un cache (9 a) tel que décrit précédemment qui fonctionne par l'intermédiaire d'une application de gestion de cache (10 a).

Cette application de cache (10 a) réalise l'interfaçage entre le bloc de gestion d'entrée et le bloc de cache.

Dans l'exemple de cette figure, chaque application client (19) correspond à un module de gestion d'entrée (8 a, 8 b). Selon une variante, plusieurs clients (19) peuvent adresser leurs requtes à un seul module de gestion d'entrée.

Ainsi, dans le cas de la figure 7, les modules (8 a, 8 b) sont reliés à une file (16) fonctionnant selon la logique « premier entré, premier sorti » apte à recevoir les requtes et à les redistribuer par ordre d'entrée.

Dans ce cadre, en sortie de la file (16) se situe un groupe de ligne (17) transmettant les requtes au cache (9 a, 9 b). On peut ainsi limiter le nombre de modules de gestion d'entrée (8 a, 8 b) du système.

La figure 5 montre un mode de réalisation préféré du nettoyage des données contenues dans le cache (9 a, 9 b). A cet effet, le système comporte un outil de nettoyage (11) adressant des commandes de nettoyage (12) aux différents caches (9 a, 9 b). Les procédures utilisées pour ce nettoyage seront exposées plus loin.

On présente ci-après le fonctionnement du système selon l'invention et le procédé de traitement et d'accès qui en fait partie intégrante.

Dans ce cadre, un ou plusieurs caches (9 a, 9 b) sont créés dans la partie serveur pour contenir des données de réservation. Les clients pourront y accéder pour répondre rapidement à des requtes sans encombrer le reste du système central tel que cela est exposé plus haut.

Pour mettre à jour les données contenues dans le ou les caches (9 a, 9 b), on ajoute des données au cache (9 a, 9 b) par transfert depuis au moins une base d'inventaire (I).

Un exemple des opérations successives permettant l'ajout des données dans le cache (9 a, 9 b) est présenté en figure 4.

Selon cet arbre, le client adresse une requte générant une opération « GET » d'interrogation du cache (9 a, 9 b). Si une réponse positive peut tre apportée par le cache (9 a, 9 b) à l'interrogation « GET », la donnée contenue dans le cache est retournée au client en réponse.

Si le cache ne contient pas la réponse à la requte du client, celle-ci est adressée au système central (CS) qui est apte à générer la réponse, par liaison avec les bases d'inventaire (I). Les données en réponse sont retournées par le système central (CS) et sont ajoutées au cache (9 a, 9 b) par une opération « PUT ».

De cette façon, une donnée jusqu'alors non contenue dans le cache s'y trouve mémorisée.

Cette suite d'opérations peut tre effectuée au démarrage du système selon l'invention à partir d'un cache ne contenant aucune donnée mais dans lequel seront successivement mémorisées les données suivant les interrogations des clients.

Pour éviter que le cache ne prenne une ampleur dimensionnelle trop importante et afin d'en optimiser le fonctionnement, il est important de procéder à un rafraîchissement des données qu'il contient.

Dans ce cadre, le procédé selon l'invention propose deux procédures distinctes mais qui peuvent tre employées simultanément pour procéder au nettoyage des données.

Selon une première procédure, on affecte à chaque donnée une durée maximale de conservation. De façon périodique, on scrute les données contenues dans le cache (9 a, 9b) pour distinguer celles dont la durée limite de conservation est dépassée.

Ces données sont alors supprimées du cache.

De cette façon des données trop anciennes ne présentant plus un caractère d'actualité et de fiabilité sont supprimées.

Bien entendu, la période de mise à jour selon cette procédure est variable suivant la nature des données contenues. A titre d'exemple, l'intervalle de temps entre deux commandes de nettoyage pourra tre de soixante secondes.

Une deuxième procédure de nettoyage peut tre mise en oeuvre selon le procédé de l'invention en remplacement ou en complément de la première.

Dans ce cadre, on affecte une taille limite au cache correspondant à la taille maximale que l'on souhaite donner au cache. Par ailleurs, on lui affecte une taille seuil de valeur inférieure à la taille limite et correspondant à une taille admissible pour le bon fonctionnement du cache. A titre d'exemple, la taille seuil peut tre fixée à 80 % de la taille limite.

Lorsque la taille limite est atteinte, on supprime les données contenues (9 a, 9 b) par ordre décroissant d'ancienneté d'utilisation jusqu'à atteindre la taille seuil.

De cette façon les données très anciennement utilisées sont supprimées dans la limite du nécessaire pour retrouver une taille admissible pour la cache.

Toujours de façon à optimiser le fonctionnement des caches (9 a, 9 b), un mode de rangement particulier des données dans le cache (9 a, 9 b) est ci-après présenté.

D'une façon générale, on affecte à chaque donnée à mémoriser dans le cache une clé.

Cette clé peut tre transformée en valeur numérique, communément appelée « HASH CODE » selon des algorithmes de hashing utilisés de façon courante.

On crée par ailleurs un vecteur de listes 14 figuré en figure 6 et comprenant une suite de compartiments (13) généralement appelés « BUCKET ». Chaque compartiment (13) est apte à contenir une ou plusieurs données.

On affecte à chaque compartiment (13) un index numérique entier à partir de zéro.

A titre d'exemple, un nombre de 20 011 compartiments pourront tre formés pour un cache de taille limite de 51 200 Kilo Octets.

On effectue ensuite une correspondance entre la clé affectée à chaque donnée et l'index numérique de chaque compartiment (13). Cet établissement de correspondance peut tre effectué par une modulation de la clé numérique de la donnée par le nombre de compartiments (13) du vecteur de listes (14).

L'objet de cette correspondance est de mémoriser les données dans un compartiment (13) avec un index particulier et de n'effectuer une comparaison des données contenues dans le cache que pour les données d'un compartiment (13) ayant le mme index que celui de la donnée recherchée par le client.

De cette façon, le nombre d'opérations de comparaison nécessaire est fortement réduit.

Le nombre de valeurs contenues dans un compartiment (13) n'est pas limité.

II s'entend cependant que moins il y a de valeurs, plus les performances sont grandes.

Toujours de façon à optimiser le fonctionnement du cache (9 a, 9 b), on pourra lors du traitement des requtes ne bloquer l'accès que des compartiments (13) utilisés. De cette façon, le traitement d'une requte affectant un compartiment (13) ne bloque pas le fonctionnement des autres compartiments (13). On utilise pour ce faire des moyens de blocage d'accès sélectifs (15) également dénommés sémaphores ou « MUTEX ».

Une meilleure gestion de requtes concurrentielles est ainsi réalisée, peu de requtes simultanées risquant d'tre à traiter dans un mme compartiment (13).

REFERENCES 1-Serveur cache 2 a, 2 b-Bloc de gestion d'entrée 3 a, 3 b, 3 c-Bloc de cache 4-Moyens de routage 5-Réseau de communication 6 a, 6 b-Port d'entrée 7 a, 7 b-Gestionnaire d'entrée 8 a, 8 b-Modules de gestion d'entrée 9 a, 9 b, 9 c-Cache 10 a, 10 b-Application de gestion de cache 11-Outil de nettoyage 12-Commande de nettoyage 13-Compartiments 14-Vecteur de listes 15-Moyens de blocage d'accès sélectif 16-File 17-Groupe de lignes 18-Application d'interfaçage 19-Application client CS-Système central I-Base d'inventaire