Elle a également trait à un système de communication intégrant une ou plusieurs de telles unités, ainsi qu'à un procédé qu'il pourra mettre en oeuvre.

L'invention trouvera notamment son application dans le domaine de la réservation de voyages ou de transports par des systèmes informatiques.

De tels systèmes, communément dénommés CRS (computerized reservation systems) utilisent des communications par des réseaux informatiques pour mettre en relation des clients (tels des agents dans le secteur du voyage ou des particuliers) et les services centraux des entreprises concernées par les réservations.

Ces systèmes sont amenés à mettre en jeu des composants très divers tels que des serveurs, des terminaux d'ordinateurs, des postes informatiques individuels, et ce

par des liaisons variées et souvent composites constituées de réseaux locaux ou mondiaux.

Cette hétérogénéité se retrouve en outre au niveau des formats des données et des protocoles de communication. Si certains protocoles comme la combinaison HTTP/HTML sont suffisamment standardisés pour limiter les problèmes d'interopérabilité, d'autres comme IIOP ou JRMP nécessitent que les parties s'accordent sur des interfaces communes mme si la manière de le représenter sur un réseau est standardisée.

II existe donc un besoin important de rationaliser le mode de fonctionnement et de communication dans les systèmes informatiques tels que décrits précédemment.

A ce sujet, des dispositifs de multiplexage sont actuellement proposés selon plusieurs variantes. Ils assurent globalement une centralisation des connections et une réduction du nombre de connections nécessaires à l'acheminement des données.

Ils ne donnent cependant pas entière satisfaction. Ainsi, ils présentent des problèmes de temps de réponse ou, lorsqu'ils sont implantés à proximité d'un groupe de machines, ils sont lourds à gérer.

Par ailleurs, il est difficile d'administrer un grand nombre de clients : il faut que les serveurs supportent plusieurs versions des applications pour répondre aux requtes de clients dont les logiciels sont à des niveaux de mise à jour différents.

Un autre inconvénient des systèmes actuels est que leur emploi n'est pas souple, notamment en terme de répartition de charge entre les serveurs, de gestion des pannes et d'éventuelles congestions.

Des solutions aux problèmes évoqués ont été proposées tel l'emploi d'intergiciels.

II s'agit de logiciels assurant une fonction d'intermédiaire entre une partie client et une partie serveur du système.

Leur emploi implique cependant de lourdes adaptations des applications. Ils pèsent donc sur les coûts et les délais de développement. Cet inconvénient est d'autant plus important que l'intergiciel doit tre également déployé, ce qui accroît les risques de non interopérabilité et complique les tâches d'administration.

Sur le plan de la compatibilité des applications mises en jeu dans les systèmes informatiques, les moyens de multiplexage et les intergiciels actuellement connus n'offrent aucune solution spécifique.

On connaît pourtant du document WO-A-99. 44155 un dispositif pour la conversion de données et la répartition de charge dans un réseau informatique. Selon ce

document, on procède systématiquement à une conversion des données en un format fixe afin de faciliter leur traitement. Un système d'affectation de serveur à certains clients et une gestion de leur étranglement est aussi présenté.

Ce système est statique et ne permet pas de choisir le serveur en fonction du contenu des messages clients.

Ce dispositif est nettement orienté vers l'usage d'un protocole unique qui est I'EDIFACT. II ne cherche pas à assurer une complète compatibilité, quelque soit les formats et protocoles employés par un serveur donné.

Par ailleurs, la répartition de charge proposée se limite à des circonstances ponctuelles et ne cherche pas à administrer globalement l'activité des serveurs. En outre ce système n'est pas modulaire ce qui gne son évolutivité et le chemin suivi par les messages comporte de nombreuses étapes qui influent défavorablement sur le temps de réponse du réseau.

Le mécanisme est réalisé dans le code des clients et des serveurs qui doivent donc tre modifiés pour le mettre en oeuvre.

L'invention ici proposée a pour but de pallier les inconvénients des techniques jusqu'alors connues.

L'un de ses premiers objectifs est d'assurer une conversion efficace des messages pour les rendre compatibles avec n'importe quelle application cible.

L'invention permet donc une communication entre toutes les composantes du réseau.

Elle permet dans le mme temps d'organiser le multiplexage des données en mettant en oeuvre des modules de gestion d'entrée et de sortie qui sont facilement contrôlés par un organe d'administration : par exemple, l'intégration d'un nouveau type de client dans le système s'effectuera rapidement par la création d'un nouveau module de gestion d'entrée. Quant aux clients utilisant le mme protocole et utilisé dans les mmes conditions, ils pourront partager un mme module de gestion d'entrée. On voit bien que l'invention ici exposée offre modularité et capacité d'adaptation à l'évolution structurelle ou fonctionnelle du réseau.

Elle assure aussi une gestion optimisée de l'étranglement des serveurs par une répartition de charge selon des critères déterminés tels la nature de la requte, I'encombrement, les pannes éventuelles.

Cet ensemble est en outre administrable de façon centralisée.

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

La présente invention concerne une unité de multiplexage pour la communication dans un réseau informatique entre une pluralité de machines clients supportant des programmes clients et un ou plusieurs serveurs supportant des programmes d'application, les programmes clients et d'application pouvant tre incompatibles, caractérisée par le fait qu'elle comprend : -pour chaque type de machine client, un module de gestion d'entrée recevant les requtes des programmes client et leur transmettant les réponses ; -pour un serveur ou un groupe de serveurs, un module de gestion de sortie transmettant au serveur les messages clients qui lui sont adressés et transmettant les réponses aux modules de gestion d'entrée des machines clients ; -des moyens de routage connectés aux modules de gestion d'entrée et de sortie et aptes à définir l'identité d'au moins un module de gestion de sortie pour le traitement d'une requte et à déterminer l'identité de la machine client à laquelle le message issu du serveur cible doit tre adressé ; -et des moyens de conversion aptes à convertir, si nécessaire, le contenu de la requte en un message client compatible avec le programme d'application du serveur cible et le contenu du message issu du serveur cible en une réponse compatible avec le programme client.

Cette unité pourra se présenter sous les variantes suivantes : -les moyens de routage comportent des moyens de répartition de charge aptes à définir l'identité d'un serveur cible pour le traitement d'une requte, selon des conditions de charge.

-les moyens de routage comportent au moins un module d'application de routage connectable au reste des moyens de routage et apte à effectuer des fonctions de routage selon des règles prédéterminées.

-les moyens de conversion comportent au moins un module d'application de conversion connectable au reste des moyens de conversion et apte à effectuer des fonctions de conversion prédéterminées.

-les modules de gestion de sortie comportent un dispositif de file d'attente apte à concentrer les entrées vers les serveurs.

-elle comporte un module d'administration apte à gérer la création, la suppression, la modification et l'état de fonctionnement des modules de gestion d'entrée et de sortie.

L'invention concerne aussi un système de communication dans un réseau informatique entre une pluralité de machines clients supportant des programmes clients

et un ou plusieurs serveurs supportant des programmes d'application, les programmes clients et d'application pouvant tre incompatibles, caractérisé par le fait qu'il intègre au moins une unité de multiplexage selon l'invention.

Selon un mode de réalisation, le système comporte un agent de supervision apte à commander le module d'administration de la ou des unités de multiplexage.

Selon une autre possibilité, il comporte des extensions sous forme de bibliothèques à liaison dynamique aptes à tre chargées par une unité de multiplexage pour contenir les modules d'application.

L'invention a trait enfin à un procédé de communication dans un réseau informatique entre une pluralité de machines clients supportant des programmes clients et un ou plusieurs serveurs supportant des programmes d'application, les programmes clients et d'application pouvant tre incompatibles, apte à tre mis en oeuvre par le système selon l'invention caractérisé par le fait que -on connecte chaque machine client d'un type considéré à un module de gestion d'entrée recevant les requtes du programme client et lui transmettant les réponses ; -on connecte à un serveur un module de gestion de sortie transmettant au serveur les messages clients qui lui sont adressés et transmettant les réponses aux modules de gestion d'entrée des machines clients ; -on route la requte par reconnaissance des données de la requte dont I'adresse du module de gestion d'entrée et I'adresse réseau de la machine client d'où elle provient, puis on détermine au moins un serveur cible selon ces données ; -on convertit la requte en un message client de format compatible avec le ou les serveurs cibles ; -on achemine le message client au module de gestion de sortie du serveur cible pour transmission ; -on route le message issu du serveur cible et transmis par le module de gestion de sortie par reconnaissance du message issu du serveur cible, puis on détermine la machine client correspondante selon le résultat de cette reconnaissance ; -on convertit, si nécessaire, avant ou après son routage, le message issu du serveur cible en une réponse de format compatible avec la ou les machines clients ; -on achemine la réponse au module de gestion d'entrée de la machine client pour transmission.

Ce procédé pourra comporter les étapes suivantes : -les données de la requte reconnues pour son routage comprennent la nature de son contenu.

-pour le routage de la requte et du message issu du serveur cible, on invoque au moins un module d'application de routage connectable pour effectuer des fonctions de routage prédéterminées.

-pour la conversion de la requte et du message issu du serveur cible, on invoque au moins un module d'application de conversion connectable pour effectuer des fonctions de conversion prédéterminées.

On gère l'étranglement différemment selon le nombre et la nature des modules de gestion de sortie sélectionnés par le mécanisme de routage.

-si un seul module de gestion de sortie a été trouvé lors du routage et reçoit des messages d'étranglement, alors on gère l'étranglement par : définition, au niveau du module de gestion de sortie, d'un nombre maximal de messages pouvant tre traités par le serveur jusqu'à une nouvelle définition ; comptage du nombre de messages clients reçus par le module de gestion de sortie ; 'soustraction du nombre de messages clients reçus du nombre maximal pour obtenir un nombre de messages admissibles, afin de déterminer un niveau d'étranglement.

-Si tous les modules de gestion de sortie trouvés lors du routage reçoivent des messages d'étranglement, on effectue pour chacun les opérations suivantes : définition, au niveau du module de gestion de sortie, d'un nombre maximal de messages pouvant tre traités par le serveur jusqu'à une nouvelle définition ; comptage du nombre de messages clients reçus par le module de gestion de sortie ; 'soustraction du nombre de messages clients reçus du nombre maximal pour obtenir un nombre de messages admissibles, afin de déterminer un niveau d'étranglement. et on choisit le module de gestion de sortie qui a le meilleur niveau d'étranglement.

-Si une partie seulement des modules de gestion de sortie trouvés lors du routage reçoivent des messages d'étranglement et que l'autre partie n'est pas sujette à l'étranglement : 1. On effectue, pour chaque module de gestion de sortie recevant des messages d'étranglement, les opérations suivantes : 'définition, au niveau du module de gestion de sortie, d'un nombre maximal de messages pouvant tre traités par le serveur jusqu'à une nouvelle définition ;

comptage du nombre de messages clients reçus par le module de gestion de sortie ; 'soustraction du nombre de messages clients reçus du nombre maximal pour obtenir un nombre de messages admissibles, afin de déterminer un niveau d'étranglement ; 'on divise le nombre de messages admissibles par le temps restant jusqu'à une nouvelle définition du nombre maximal de messages admissibles pour obtenir une fréquence de soumission de requtes 'on ajoute au temps courant la fréquence de soumission de requtes pour déterminer à partir de quand le module de gestion de sortie pourra accepter un nouveau message client.

2. on oriente le message client vers le premier module de gestion de sortie recevant des messages d'étranglement pouvant I'accepter 3. on oriente le message client vers un autre module de gestion de sortie, si aucun module de gestion de sortie recevant des messages d'étranglement ne peut t'accepter.

-on répartit la charge entre les modules de gestion de sortie ne recevant pas des messages d'étranglement, par les opérations suivantes : 1. construction d'un tableau des modules de gestion de sortie ne recevant pas de messages d'étranglement 2. incrémentation d'un compteur à chaque message client reçu 3. division entière du nombre du compteur par le nombre de modules de gestion de sortie ne recevant pas de messages d'étranglement 4. utilisation du reste de la division comme index dans le tableau pour trouver le module de gestion de sortie ne recevant pas de messages d'étranglement à utiliser.

Les dessins ci-joints sont donnés à titre d'exemples indicatifs et non limitatifs. Ils représentent un mode de réalisation. Ils permettront de comprendre aisément l'invention.

Les figures 1 et 2 montrent deux exemples de réalisation de multiplexage selon l'état de la technique.

La figure 3 schématise l'implantation d'un intergiciel entre une partie client et une partie serveur.

La figure 4 est une vue globale de l'invention.

La figure 5 illustre diverses étapes de fonctionnement de l'invention.

On a représenté en figure 2 une organisation classique de réseau informatique.

Dans ce réseau, une pluralité de machines clients 1 est en relation avec un ou plusieurs serveurs 3 qui sont souvent à un emplacement éloigné des machines clients. A titre d'exemple, les clients pourront tre des particuliers connectés au réseau par exemple par le biais d'un réseau 2 d'extension mondiale, tel qu'internet, ou des opérateurs spécialisés dans le domaine du voyage. II pourra également s'agir de serveurs informatiques.

Les réseaux mettent couramment en jeu de très nombreuses machines clients.

II faut donc préférentiellement chercher à minimiser le nombre de connexions entre les machines clients 1 et les serveurs 3, opérations de concentration et d'aiguillage effectuées par le biais d'un multiplexage.

Dans le cas de la figure 2, certaines machines clients 1 sont, par le biais du réseau 2, mises en relation avec un seul serveur 3. Les clients doivent avoir connaissance du ou des serveurs auxquels ils peuvent se connecter. Le temps d'établissement des connections est très important et en cas de défaillance de la connexion le client ne peut généralement pas savoir si la défaillance est due au réseau ou au serveur. Le seul mécanisme de tolérance aux pannes qu'il peut mettre en oeuvre est d'essayer d'établir une connexion avec un autre serveur offrant le mme service, ce qui est long, hasardeux et complique l'utilisation et le développement du programme client.

On a proposé des multiplexages permettant un meilleur temps de réponse. Une configuration en est illustrée à la figure 1. Dans ce cadre, des multiplexeurs 4 sont positionnés en aval d'un groupe de machines clients 1 de façon à gérer leurs communications avec le réseau 2.

On comprend que, si les multiplexeurs 4 viennent à tre multipliés, la gestion du réseau devient difficile. En effet, en cas d'adaptation, de développement ou d'évolution de certaines parties constitutives du réseau, il est nécessaire d'effectuer des opérations de mises à jour dans des multiplexeurs 4 qui peuvent tre éloignés, et parfois localisés chez un client, ou chez un partenaire commercial.

Pour remédier à ces inconvénients et à ceux exposés précédemment pour ce type de multiplexage, on a proposé l'usage d'intergiciels 9 tels que représentés à la figure 3.

A cette figure, un intergiciel 9 constitue un logiciel intermédiaire entre une partie client et une partie serveur.

La partie client comprend une couche d'activité client 5 où sont réalisées certains traitements, ainsi qu'une couche d'interfaçage 7 avec l'intergiciel 9.

D'autre part, une couche d'activité serveur 6 est présente et communique vers l'intergiciel 9 par le biais d'une couche d'interfaçage 8.

Les inconvénients des utilisations d'un intergiciel 9 ont déjà été évoqués précédemment.

La solution proposée par l'invention est illustrée de façon schématique aux figures 4 et 5.

D'une façon générale, on voit à la figure 4 que l'invention met en relation une couche d'activité client 10 et une couche d'activité serveur 11. Cette mise en relation est effectuée par des couches d'interfaçage réseau standard 12,13.

Pour effectuer la communication, un système de communication 15 selon l'invention est présent et connecté à une couche réseau standard 14.

De façon schématique, on a représenté le système de communication 15 en deux blocs de diagrammes faisant apparaître la modularité de l'invention.

Sont également figurés, par des flèches, les transferts de messages depuis la couche d'activité client 10 jusqu'à la couche d'activité serveur 11. Le sens des flèches, ici proposé à titre d'exemple, va dans le sens client-serveur, mais la réciproque est également bien entendu effectuée.

Une requte 20 est adressée au système de communication 15 depuis la couche d'activité client 10 et, par le biais du système de communication 15 selon l'invention, est répercutée au niveau de la couche d'activité du serveur 11 en un message client 22.

Pour la transmission d'un tel message client 22 au serveur, des fonctions de routage, et éventuellement de répartition de charge ou encore de conversion, sont effectuées.

Dans la suite de la description et pour la bonne compréhension de l'invention, le terme « requte 20 » désigne un message envoyé par le client et le mot « réponse 21 » un message reçu par le client.

En se référant maintenant à la figure 5, on voit que l'on a représenté, à titre d'exemple, une communication entre une machine client 16 et un serveur 17.

Leur mise en relation s'effectue par le biais d'une unité de multiplexage selon l'invention. Une telle unité pourra mettre en oeuvre une pluralité de machines clients 16 et serveurs 17. Par ailleurs, le système selon l'invention, qui intègre l'unité de

multiplexage ainsi présentée, pourra comporter d'autres unités similaires, selon l'invention.

Le système proposé est donc parfaitement modulaire et organisé et peut tre contrôlé et administré de façon centralisée.

On décrit ci-après des modes de réalisation particuliers de l'unité de multiplexage selon l'invention.

La figure 5 montre la formation pour chaque machine client 16 d'un module de gestion d'entrée 18. Un tel module de gestion 18 est créé pour chaque type de machine client à relier et peut tre modifié ou supprimé selon les besoins.

Le module de gestion d'entrée assure la réception des requtes 20 provenant de la machine client et la transmission des réponses 21 à ces requtes 20. On a repéré par une flèche 20 le chemin suivi par la requte issue d'un programme client supportée par la machine client 16.

Par ailleurs on affecte, dans l'unité de multiplexage, un module de gestion de sortie 19 à un ou plusieurs serveurs 17. De façon similaire, le module de gestion de sortie 19 a pour fonction de recevoir les messages à traiter par le ou les serveurs 17 et de les répercuter vers celui-ci ou ceux-ci.

Comme représenté, un système de files d'attente est opéré pour former une file de messages clients 22 à traiter au niveau du module de gestion de sortie 19. Un dispositif de files d'attente repéré 26 est illustré à ce sujet en figure 5.

Des moyens de routage sont présents afin de déterminer un ou des modules de gestion de sortie 19, vers lesquels la requte 20, issue de la machine client, va tre transférée,.

En relation d'une part, avec le module de gestion d'entrée 18 et d'autre part avec le module de gestion de sortie 19, les moyens de routage permettent de définir l'identité d'au moins un module de gestion de sortie cible pour le traitement d'une requte 20, et de façon réciproque, l'identité de la machine client à laquelle le message 23 issu du serveur cible doit tre adressé.

De façon préférée, les moyens de routage comportent des moyens de répartition de charge 27 qui permettront de définir l'identité d'un unique module de gestion de sortie 19 pour le traitement de la requte 20 selon des paramètres de charges.

Des modes de réalisation de cette répartition seront décrits plus loin, mais on indique d'ores et déjà des paramètres qui pourront tre pris en compte : I'état de défaut d'éventuels serveurs, I'étranglement des serveurs, la nature des messages à traiter.

Les conditions de charge sont essentiellement définies dans le système par des messages du nombre maximal de messages normalement issus d'agents d'étranglement. Ces derniers peuvent tre installés au niveau des serveurs ou de façon indépendante.

On décrit par ailleurs plus loin un module d'administration 36 qui peut maintenir des valeurs par défaut pour suppléer, le cas échéant, à une défaillance de l'agent d'étranglement.

Selon une possibilité avantageuse, les moyens de routage comportent un ou plusieurs modules d'application de routage 24,30. Ces modules sont reliés à des sous- systèmes de routage 29,34 en relation avec les modules de gestion d'entrée 18 et de sortie 19.

Les modules d'application de routage 24,34 sont connectables au reste des moyens de routage, ce qui assure une parfaite modularité de fonctionnement.

De façon préférée, c'est au niveau des modules d'application 24,34, que sont prises les décisions d'acheminement. Ces décisions sont ensuite appliquées par le reste des moyens de routage.

Suivant les opérations de routage à effectuer, divers modules d'application pourront tre employés et connectés.

Devant I'ampleur des réseaux informatiques mis en jeu, des problèmes de compatibilité se posent quant aux formats et aux protocoles de transfert utilisés par les applications clients et les applications des serveurs.

Pour y remédier, l'unité de multiplexage ici présentée comprend des moyens de conversion. Ces moyens assurent la conversion, si nécessaire, du contenu des requtes 20 en messages clients 22 compatibles et donc exploitables par le programme d'application du serveur cible 17. De mme, les moyens de conversion effectuent une conversion du contenu du message 23 issu du serveur cible 17 en une réponse 21 compatible avec le programme client visé.

Avantageusement, la conception des moyens de conversion est similaire à celle des moyens de routage. On entend par ta que les moyens de conversion comportent des sous-systèmes de conversion 28,33 aptes à communiquer avec des modules d'application de conversion 25,31 auxquels ils sont connectés. De façon parallèle aux moyens de routage, il sera possible d'employer et de faire évoluer les modules d'application 25,31 selon les fonctions de conversion à effectuer.

Un module d'application est associé par configuration avec un module de gestion d'entrée ou de sortie. En conséquence, il est possible de faire coexister au sein

d'une unité de multiplexage selon l'invention plusieurs modules d'application différents. 11 est également possible d'en modifier ou d'en mettre en oeuvre de nouveaux sans arrter l'unité de multiplexage.

Les sous-systèmes tels que présentés pourront invoquer un ou plusieurs modules d'applications connectables.

Au sein de l'unité de multiplexage, on formera préférentiellement un module d'administration 36. Le module d'administration 36 gère les modules de gestion d'entrée 18 et de sortie 19 de l'unité. Le module 36 crée, supprime ou modifie les modules de gestion d'entrée et de sortie. Par ailleurs, il pourra opérer des fonctions statistiques et de vérification de l'état des modules, y compris l'état de leur charge et de leur étranglement.

Selon une possibilité avantageuse, I'administration peut tre étendue par un ou plusieurs modules d'application d'administration 35. Ces modules permettent l'administration des modules d'application de routage et de conversion et en particulier de leur fournir des tables de routage et des descriptions de messages.

Plusieurs unités de multiplexage telles qu'elles viennent d'tre décrites peuvent tre employées afin de constituer un système de communication selon l'invention. Dans ce cadre, les unités de multiplexage seront utilisées en parallèle et géreront une pluralité de machines clients 16 et de serveurs 17.

De cette façon, le contrôle du système de communication s'effectue de façon centralisée pour toutes les unités de multiplexage. Ainsi, le système pourra comprendre un agent de supervision apte à commander les modules d'administration 36 des unités.

Par différents outils de gestion et de contrôle, un opérateur, par exemple par le biais d'une interface graphique, peut gérer et contrôler le système en agissant sur l'agent de supervision, lui-mme commandant les modules d'administration 36.

Par ailleurs, la mise en parallèle de plusieurs unités de multiplexage peut s'effectuer en relation avec l'utilisation d'extensions sous forme de bibliothèques à liaison dynamique (DLL-Dynamic Link Libraries). Ces extensions pourront tre chargées, sur demande, par l'une ou l'autre des unités de multiplexage afin d'étendre ses fonctionnalités. Ces fonctionnalités pourront servir aux sous-systèmes de routage 29,34, aux sous-systèmes de conversion 28,33 et à la supervision et à l'administration des unités de multiplexage.

Ces bibliothèques à liaison dynamique pourront constituer l'ensemble des éléments suivants : modules d'applications 24,25,30,31 et d'application d'administration 35.

Les fonctionnalités du système pourront également tre étendues par ce biais en ce qui concerne la gestion de l'étranglement du serveur.

On décrit ci-après le procédé de communication selon l'invention qui pourra tre mis en oeuvre, à la fois par le système de communication précédemment décrit, et par les unités de multiplexage comprises dans le système, et faisant partie intégrante de l'invention.

On se réfère encore à la figure 5 pour illustrer les étapes de ce procédé.

Comme précédemment indiqué en ce qui concerne l'unité de multiplexage, les clients se connectent à un module de gestion d'entrée. Un module de gestion de sortie se connecte à un ou plusieurs serveurs ou selon un autre mode attend les connections des serveurs. On retrouve le principe de l'invention qui est d'accommoder sans modification les clients et serveurs existants et leurs contraintes d'opération. Lorsqu'une requte 20 doit tre adressée au reste du système pour son traitement, elle est routée vers un serveur 17 en observation des données de routage. Parmi ceux-ci figure I'adresse du module de gestion d'entrée 18 et I'adresse réseau de la machine client 16.

D'autres paramètres pourront servir à déterminer l'acheminement de la requte 20, et notamment le contenu de la requte. Ainsi, le routage comprendra une opération de contrôle et d'analyse du contenu de la requte 20.

De façon préférée, l'étape de routage s'effectue en deux temps, l'un partant d'un sous-système de routage 29 en liaison avec le module de gestion d'entrée 18. Le second est réalisé en invoquant au moins un module d'application de routage 24 connectable au sous-système 29. En disposant des paramètres de routage, le module d'application 24 détermine l'identité d'un ou plusieurs modules de gestion de sortie 19.

Le routage est alors appliqué par le sous-système 29.

Dans le cas où plusieurs possibilités de serveurs cibles ont été définies, on pourra en élire un seul selon des critères de répartition de charges.

On décrira plus loin des variantes de l'invention aptes à effectuer une telle répartition de charges entre les modules de gestion de sortie 19 selon des critères d'étranglement.

Lorsque l'identité du module de gestion de sortie 19 est déterminée à la fin de l'opération de routage, on effectue une étape de conversion de la requte 20 en un message client 22 compatible avec les serveurs cibles 17.

Lorsqu'elle est nécessaire, l'opération de conversion peut s'effectuer également en deux temps. Le premier consiste à invoquer depuis un sous-système de conversion 28, un module d'application de conversion 25 qui est connecté. Le sous-système 28

invoque un ou plusieurs module d'application de conversion 25 selon la fonction de conversion à opérer.

Le module d'application de conversion 25 retourne au sous-système 28 un message client 22 compatible avec le serveur 17.

Ce message client 22 est transféré au serveur 17 via le module de gestion de sortie 19 du serveur 17.

Au niveau du module de gestion de sortie 19, une file d'attente est créée pour recevoir les messages clients 22, jouer un rôle de tampon et envoyer les messages, successivement au serveur 17.

Une file d'attente est requise dans la mesure où les modules de gestion d'entrée 18 sont « multithread : c'est-à-dire capable de déposer plusieurs requtes simultanément.

Un chemin d'exécution « thread » différent est associé à chaque serveur 17 et les différents chemins d'exécution retirent des messages en parallèle de la file d'attente 26.

Une fois le message client traité au niveau du serveur 17, celui-ci retourne un message serveur 23.

De façon correspondante à ce qui a été décrit au niveau du module de gestion 18, une opération de routage puis une opération de conversion est effectuée par invocation de modules d'application de routage 30 et de conversion 31.

Le routage du message 23 s'effectue en fonction de la reconnaissance de la nature de ce message 23.

L'opération de conversion pourrait tre effectuée avant la fonction de routage, mais elle est préférentiellement réalisée après. En effet, if s'agit d'une opération plus longue, mais d'issue moins incertaine que celle du routage.

Selon une variante préférée du procédé selon l'invention, on gère l'étranglement du ou des serveurs, ou pour le moins une partie des serveurs 17 compris dans le système.

On gère l'étranglement différemment selon le nombre et la nature des modules de gestion de sortie sélectionnés par le mécanisme de routage.

Si un seul module de gestion de sortie a été trouvé lors du routage et reçoit des messages d'étranglement, alors on gère son étranglement par : "définition, au niveau du module de gestion de sortie, d'un nombre maximal de messages pouvant tre traités par le serveur jusqu'à une nouvelle définition ;

comptage du nombre de messages reçus par le module de gestion de sortie ; soustraction du nombre de messages du nombre maximal pour obtenir un nombre de messages admissibles, afin de déterminer un niveau d'étranglement.

Si tous les modules de gestion de sortie trouvés reçoivent des messages d'étranglement, alors chaque module de gestion de sortie maintient un nombre de messages admissibles comme décrit plus haut. Le mécanisme de routage choisit le module de gestion de sortie avec le plus grand nombre de messages admissibles, c'est- à-dire le meilleur niveau d'étranglement.

Si une partie des modules de gestion de sortie trouvés reçoivent des messages d'étranglement et une autre partie n'en reçoit pas et n'est donc pas sujette à étranglement, le routage vise à utiliser au maximum, dans les limites de l'étranglement imposé, les modules de gestion de sortie étranglés puis a repartir équitablement la charge restante entre les modules de gestion de sortie non étranglés. Pour cela, on calcule pour chaque module de gestion de sortie étranglé, une fréquence de soumission de requte en divisant le nombre de messages admissibles par le temps restant jusqu'à une nouvelle définition du nombre maximal de messages admissibles et à partir de cette fréquence, à partir de quand ce module de gestion de sortie pourra accepter une requte. Le mécanisme de routage choisit le premier module de gestion de sortie étranglé pouvant accepter une requte et si il n'en trouve aucun, il choisit un module de gestion non étranglé selon le mécanisme de répartition de charge par défaut.

A cet effet, et selon une variante préférée, on maintient un compteur qui est augmente de un à chaque message reçu et réinitialise en cas de dépassement de capacité. Le mécanisme de routage construit un tableau des modules de gestion de sortie sélectionnés. II calcule le reste de la division entière du compteur par le nombre de modules de gestion de sortie sélectionnés et sélectionne le module de gestion de sortie correspondant à cet indice dans le tableau.

REFERENCES 1. Machines clients 2. Réseaux de communication 3. Serveur 4. Multiplexeur 5. Couche d'activité client 6. Couche d'activité serveur 7. Couche d'interfaçage à l'intergiciel 8. Couche d'interfaçage à l'intergiciel 9. Intergiciel 10. Couche d'activité client 11. Couche d'activité serveur 12. Couche d'interfaçage réseau 13. Couche d'interfaçage réseau 14. Couche générique de réseau 15. Système de communication 16. Machine client 17. Serveur 18. Module de gestion d'entrée 19. Module de gestion de sortie 20. Requte 21. Réponse 22. Message client 23. Message serveur 24, 30. Module d'application de routage 25, 31. Module d'application de conversion 26. Dispositif de file d'attente 27. Moyens de répartition de charge 28, 33. Sous-système de conversion 29, 34. Sous-système de routage 35. Module d'application d'administration.

36. Module d'administration