FR 2814827 A1 20020405 FR 0012629 A 20001002 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. 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 même si la manière de le représenter sur un réseau est standardisée. Il 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 requêtes 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'estpas 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. Il 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 l'EDIFACT. Il 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 gêne 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 même 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 même protocole et utilisé dans les mêmes conditions, ils pourront partager un même 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 requête, l'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 requêtes 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 requête 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 requête 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 requête, 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 requêtes 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 requête par reconnaissance des données de la requête dont l'adresse du module de gestion d'entrée et l'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 requête 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 requête reconnues pour son routage comprennent la nature de son contenu. pour le routage de la requête 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 requête 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 requêtes 'on ajoute au temps courant la fréquence de soumission de requêtes 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 l'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 l'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. Il pourra également s'agir de serveurs informatiques. Les réseaux mettent couramment en jeu de très nombreuses machines clients. Il 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 même 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 se ! on 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 requête 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 requête 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 requêtes 20 provenant de la machine client et la transmission des réponses 21 à ces requêtes 20. On a 0 repéré par une flèche 20 le chemin suivi par la requête issue d'un programmèrent 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 requête 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 requête 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 requête 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 : l'état de défaut d'éventuels serveurs, l'é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 l'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 requêtes 20 en messages clients 22 compatibles et donc exploitables par le programme d'application du serveur cible 17. De même, 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 là 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. Il est également possible d'en modifier ou d'en mettre en oeuvre de nouveaux sans arrêter 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, l'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-même 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 attena (es 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 requête 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 l'adresse du module de gestion d'entrée 18 et l'adresse réseau de la machine client 16. D'autres paramètres pourront servir à déterminer l'acheminement de la requête 20, et notamment le contenu de la requête. Ainsi, le routage comprendra une opération de contrôle et d'analyse du contenu de la requête 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 requête 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 soussystè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'attenfe e'sï creé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 requêtes 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, il 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 requête 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 requête. Le mécanisme de routage choisit le premier module de gestion de sortie étranglé pouvant accepter une requête 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. Il 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. Multiplexer 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. Requête 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 REVENDICATIONS 1. Unité de multiplexage pour la communication dans un réseau informatique entre une pluralité de machines clients (16) supportant des programmes clients et un ou plusieurs serveurs (17) 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 (16), un module de gestion d'entrée (18) recevant les requêtes (20) des programmes client et leur transmettant les réponses (21) ; - pour un serveur (17) ou un groupe de serveurs, un module de gestion de sortie (19) transmettant au serveur les messages clients (22) qui lui sont adressés et transmettant les réponses (21) aux modules de gestion d'entrée (18) des machines clients (16) ; - des moyens de routage connectés aux modules de gestion d'entrée (18) et de sortie (19) et aptes à définir l'identité d'au moins un module de gestion de sortie (19) pour le traitement d'une requête (20) et à déterminer l'identité de la machine client (16) à laquelle le message (23) issu du serveur cible (17) doit être adressé ; - et des moyens de conversion aptes à convertir, si nécessaire, le contenu de la requête (20) en un message client (22) compatible avec le programme d'application du serveur cible (17) et le contenu du message (23) issu du serveur cible (17) en une réponse (21) compatible avec le programme client. 2. Unité, selon la revendication 1, caractérisée par le fait que les moyens de routage comportent des moyens de répartition de charge (27) aptes à définir l'identité d'un serveur cible (17) pour le traitement d'une requête (20), selon des conditions de charge. 3. Unité, selon la revendication 1 ou 2, caractérisée par le fait que les moyens de routage comportent au moins un module d'application de routage (24,30) connectable au reste des moyens de routage et apte à effectuer des fonctions de routage selon des règles prédéterminées. 4. Unité, selon l'une quelconque des revendications 1 à 3, caractérisée par le fait que les moyens de conversion comportent au moins un module d'application de conversion (25, 31) connectable au reste des moyens de conversion et apte à effectuer des fonctions de conversion prédéterminées. 5. Unité, selon l'une quelconque des revendications 1 à 4, caractérisée par le fait que les modules de gestion de sortie comportent un dispositif de file d'attente (26) apte à concentrer les entrées vers les serveurs (17). 6. Unité, selon l'une quelconque des revendications 1 à 5, caractérisée par le fait qu'elle comporte un module d'administration (36) apte à gérer la création, la suppression, la modification et l'état de fonctionnement des modules de gestion d'entrée (18) et de sortie (19). 7. Système de communication dans un réseau informatique entre une pluralité de machines clients (16) supportant des programmes clients et un ou plusieurs serveurs (17) 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'une quelconque des revendications 1 à 6. 8. Système de communication dans un réseau informatique entre une pluralité de machines clients (16) supportant des programmes clients et un ou plusieurs serveurs (17) supportant des programmes d'application, les programmes clients et d'application pouvant être incompatibles, caractérisé par le fait que - il intègre au moins une unité de multiplexage selon la revendication 6 - il comporte un agent de supervision apte à commander le module d'administration de la ou des unités de multiplexage. 9. Système de communication dans un réseau informatique entre une pluralité de machines clients (16) supportant des programmes clients et un ou plusieurs serveurs (17) 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 la revendication 3 ou la revendication 4, qu'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 (24,30 ; 25, 31). 10. Procédé de communication dans un réseau informatique entre une pluralité de machines clients (16) supportant des programmes clients et un ou plusieurs serveurs (17) supportant des programmes d'application, les programmes clients et d'application pouvant être incompatibles, apte à être mis en oeuvre par le système selon les revendications 7,8 ou 9, caractérisé par le fait que - on connecte chaque machine client (16) d'un type considéré à un module de gestion d'entrée (18) recevant les requêtes (20) du programme client et lui transmettant les réponses (21) ; - on connecte à un serveur (17) un module de gestion de sortie (19) transmettant au serveur (17) les messages clients (22) qui lui sont adressés et transmettant les réponses (21) aux modules de gestion d'entrée (18) des machines clients (16) ; - on route la requête (20) par reconnaissance des données de la requête (20) dont l'adresse du module de gestion d'entrée (18) et l'adresse réseau de la machine client (16) d'où elle provient, puis on détermine au moins un serveur cible (17) selon ces données ; - on convertit la requête (20) en un message client (22) de format compatible avec le ou les serveurs cibles (17) ; - on achemine le message client (22) au module de gestion de sortie (19) du serveur cible (17) pour transmission ; - on route le message (23) issu du serveur cible (17) et transmis par le module de gestion de sortie (19) par reconnaissance du message (23) issu du serveur cible (17), puis on détermine la machine client correspondante (16) selon le résultat de cette reconnaissance ; - on convertit, si nécessaire, avant ou après son routage, le message (23) issu du serveur cible (17) en une réponse (21) de format compatible avec la ou les machines clients (16) ; - on achemine la réponse (21) au module de gestion d'entrée (18) de la machine client (16) pour transmission. 11. Procédé de communication, selon la revendication 10, caractérisé par le fait que les données de la requête (20) reconnues pour son routage comprennent la nature de son contenu. 12. Procédé de communication, selon la revendication 10 ou 11, caractérisé par le fait que pour le routage de la requête (20) et du message (23) issu du serveur cible (17), on invoque au moins un module d'application de routage (24,30) connectable pour effectuer des fonctions de routage prédéterminées. 13. Procédé de communication selon l'une quelconque des revendications 10 à 12, caractérisé par le fait que pour la conversion de la requête (20) et du message (23) issu du serveur cible (17), on invoque au moins un module d'application de conversion (25,31) connectable pour effectuer des fonctions de conversion prédéterminées. 14. Procédé de communication, selon l'une quelconque des revendications 10 à 13, caractérisé par le fait que si un seul module de gestion de sortie 19 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 19, d'un nombre maximal de messages pouvant être traités par le serveur 17 jusqu'à une nouvelle définition ; 'comptage du nombre de messages reçus par le module de gestion de sortie 19 ; 'soustraction du nombre de messages du nombre maximal pour obtenir un nombre de messages admissibles, afin de déterminer un niveau d'étranglement. 15. Procédé de communication, selon l'une quelconque des revendications 10 à 13, caractérisé par le fait que si tous les modules de gestion de sortie 19 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 19, d'un nombre maximal de messages pouvant être traités par le serveur 17 jusqu'à une nouvelle définition ; . comptage du nombre de messages clients 22 reçus par le module de gestion de sortie 19 ; 'soustraction du nombre de messages clients 22 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 19 qui a le meilleur niveau d'étranglement. 16. Procédé de communication, selon l'une quelconque des revendications 10 à 13, caractérisé par le fait que si une partie seulement des modules de gestion de sortie 19 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 19 recevant des messages d'étranglement, les opérations suivantes : 'définition, au niveau du module de gestion de sortie 19, d'un nombre maximal de messages pouvant être traités par le serveur 17 jusqu'à une nouvelle définition ; 'comptage du nombre de messages clients 22 reçus par le module de gestion de sortie 19 ; 'soustraction du nombre de messages clients 22 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 requêtes 'on ajoute au temps courant la fréquence de soumission de requêtes pour déterminer à partir de quand le module de gestion de sortie 19 pourra accepter un nouveau message client 22. 2. on oriente le message client 22 vers le premier module de gestion de sortie 19 recevant des messages d'étranglement pouvant l'accepter 3. on oriente le message client 22 vers un autre module de gestion de sortie 19, si aucun module de gestion de sortie 19 recevant des messages d'étranglement ne peut l'accepter. 17. Procédé de communication, selon la revendication 16, caractérisé par le fait qu'on répartit la charge entre les modules de gestion de sortie 19 ne recevant pas des messages d'étranglement, par les opérations suivantes : 1. construction d'un tableau des modules de gestion de sortie 19 ne recevant pas de messages d'étranglement 2. incrémentation d'un compteur à chaque message client 22 reçu 3. division entière du nombre du compteur par le nombre de modules de gestion de sortie 19 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 19 ne recevant pas de messages d'étranglement à utiliser.