FR2824214A1 - Serveur perfectionne de gestion de donnees entre un reseau et des terminaux d'utilisateur, et dispositif et procede de traitement de donnees associes - Google Patents

Abstract

Un dispositif de traitement de données, implantable dans un serveur informatique, comprend i) une structure (6) à couches logiques de bas niveau pour le traitement de données, raccordée à un réseau et à des terminaux d'utilisateurs, et comportant au moins une première couche (I) d'initiation de requêtes d'utilisateur destinées au réseau, une seconde couche (G) de récupération de flux de données transmis par le réseau en réponse à une requête initiée par la première couche (I), une troisième couche (T) de transformation des données des flux récupérés, et une quatrième couche (S) pour transmettre aux terminaux d'utilisateurs des données récupérées et éventuellement transformées, ii) des modules élémentaires pour traiter des flux de données, selon leur type, et pour générer des flux de données sortant comportant les données traitées, et iii) des moyens de contrôle (3) pour associer à l'une au moins des couches l'un au moins des modules en fonction d'une requête d'utilisateur, puis configurer chaque module associé à chaque couche de sorte qu'il puisse échanger des flux de données, via des moyens d'interfaçage (5), avec les autres modules associés, ces derniers étant en outre agencés pour adjoindre aux données des flux sortants qu'ils génèrent un objet requête, représentatif du type du flux, de sorte qu'à réception de ce flux un module élémentaire récepteur puisse déterminer s'il doit le traiter.

Description

génération de ladite messagerie.

L'invention concerne le domaine du traitement de données et plus particulièrement celui de la gestion des données échangées entre au moins un réseau externe, public eVou privé, et des terminaux d'utilisateurs,

éventueliement intégrés dans un réseau interne.

Ce type de gestion est généralement assuré par des serveurs informatiques équipés d'un dispositif de traitement de type pare-feu (plus connu sous le mot anglais " firewall "), qui assure la protection des terminaux d'utilisateurs contre les intrusions extérieures, eVou de type " proxy ", qui assure un filtrage eVou un enregistrement des mouvements d'information eVou une mémorisation temporaire (ou cache). Lorsque les protocoles d'échange de données utilisés par les réseaux interne et externe sont identiques, le serveur est généralement qualifié de " routeur ", tandis

que dans le cas contraire il est généralement qualifié de " passerelle ".

L' invention concerne plus particulièrement les serveurs proxys (ou passerelles). zo Les serveurs proxys actuels sont dédiés à des services, par exemple Internet, spécifiques. Il existe ainsi, pour les services Internet, des proxys web, des proxys ftp et des proxys teinet, notamment. De par leur conception, ces serveurs proxys ne tolèrent que très peu d'ajout de fonctionnalités (ou " plugin >>). Ils ne peuvent donc pas être reconfigurés pour assurer un

s service différent de celui pour lequel ils ont été conçus.

Les sociétés Inktomi et IBM ont récemment proposé des proxys, respectivement sous les noms " Traffic Server " et " WBI ", qui améliorent la situation, dans la mesure o l'un est équipé d'une Interface de type API permettant à un superviseur de communiquer avec lui, et l'autre offre la o possibilité d'ajouter des points d'entrée (ou " hooks ") permettant à un superviseur de modifier son comportement. Cependant, ces proxys demeurent associés à un unique protocole (HTTP), non modifiable, et ne permettent pas de contrôler le chemin suivi par le flux de données en leur

sein. De ce fait, toute utilisation avancée de ces proxys demeure impossible.

L'invention a donc pour but de résoudre tout ou partie des inconvénients précités. Elle propose à cet effet un dispositif de traitement de données, destiné à être implanté dans un serveur informatique, et comprenant: * une structure à couches logiques de bas niveau, pour le traitement de données, destinée à être raccordée à un ou plusieurs réseaux et à un ou plusieurs terminaux d'utilisateur, et comportant au moins une première couche pour initier des requêtes d'utilisateurs destinées à un réseau, une seconde couche pour la récupération des flux de données qui sont transmis par le réseau en réponse à une requête initiée au niveau de la première couche, une troisième couche pour la transformation des données des flux récupérés, et une quatrième couche pour la transmission des données récupérces et éventuellement transformées au terminal de l'utilisateur requérant, * une multiplicité de modules élémentaires pour appliquer des traitements spécifiques à des flux de données entrant, selon leurs types respectifs, et o pour générer des flux de données sortant qui comportent les donnéss traitées, ,. * des moyens de contrôle pourvus de moyens d'interfaçage de modules (fonctionnant de préférence selon le mode " Java Management eXtension (JMX) ") et capables d'associer à l'une au moins des couches l'un au moins des modules élémentaires pour satisfaire aux requêtes des utilisateurs, puis de configurer chaque module associé à chaque couche pour qu'il puisse échanger des flux de données, via le module d'interfaçage, avec l'un au moins des modules qui sont associés à sa couche eVou à la couche suivante, o * les modules configurés et associés à chaque couche étant en outre agencés pour adjoindre aux données du flux sortant qu'ils génèrent un objet requête, qui est représentatif de son type et qui s'enrichit, éventuellement, lors de son passage dans chacune des couches, de sorte qu'à réception de ce flux le module élémentaire récepteur puisse déterminer immédiatement s'il doit le traiter ou bien le transmettre, sans traitement, à un autre module, de la même couche ou de la couche suivante. Chaque couche de bas niveau est ainsi chargée de gérer certains traitements effectués spécifiquement par le ou les modules élémentaires (ou canoniques) qui lui ont été associés et ces modules constituent des espèces de " bo^'tes noires " qui échangent des données entre elles via une interface

commune, par exemple de type API.

On constitue ainsi un dispositif de traitement hautement modulaire, adaptable à chaque instant aux besoins (requêtes) de ses utilisateurs, et

facilement reconfigurable.

Les modules élémentaires peuvent être soit initialement regroupés dans des classes associces chacune à une couche prédéfinie (ils sont ensuite sélectionnés au sein de leur classe et configurés), soit destinés à être intégralement configurables pour assurer des traitements dans plusieurs couches. Selon une autre caractéristique de l' invention, chaque module 2 0 élémentaire associé à la quatrième couche est agencé de manière à supprimer l'objet requête qui est attaché à un flux avant que celui-ci ne soit

transmis au terminal de l'utilisateur qui avait émis la requête initiale.

Ces modules élémentaires sont de préférence choisis dans un groupe comprenant au moins trois modules de gestion du protocole d'échange de donnces du réseau, propres à être associés sélectivement aux première, seconde et quatrième couches, un premier module de gestion de mémoire cache pour la récupération de données au niveau de l'une au moins des couches de la structure (et de préférence au niveau de la seconde couche), un second module de gestion de mémoire cache pour le so stockage temporaire de données au niveau d'au moins l'une desdites couches de la structure (et de préférence au niveau de la seconde couche eVou de la troisième couche), un module de sauvegarde pour stocker des données d'information portant sur l'utilisation du dispositif et permettant l'édition de journaux paramétrables, un premier module de transformation de pages de données, dans un format choisi, en d'autres pages de données, dans le même format choisi (il pourra notamment s'agir de modifier des tags, de retirer une ou plusieurs images, de réécrire des adresses pointées par des liens hypertexte, ou plus généralement d'ajouter ou de retirer des données), un second module de transformation destiné à être associé à la troisième couche pour transformer des données récupérées par un module élémentaire associé à la seconde couche et placées dans un premier format (par exemple de type XML) en données dans un second format (par exemple de type WML pour un protocole de type WAP), et un module pour authentifier des opérateurs par confrontation avec une liste mémorisée (de

préférence associé à l'une au moins des première et troisième couches).

Cette liste n' est pas exhaustive. Elle concerne d' une manière générale tout type de module capable d'effectuer des traitements élémentaires sur des données. Le dispositif selon l'invention pourra également comporter les caractéristiques suivantes, prises séparément et en combinaison: o * une mémoire tampon (éventuellement de type circulaire dynamique) pour stocker de façon temporaire des données qui sont parvenues au niveau de la seconde couche eVou de la troisième couche; * des moyens de contrôle permettant également de gérer sensiblement simultanément plusieurs (au moins deux) requêtes d'utilisateurs provenant de plusieurs (au moins deux) terminaux d'utilisateurs différents; * des moyens de contrôle permettant également d'associer plusieurs fois un même module élémentaire à une même couche, selon des configurations éventuellement différentes, de sorte qu'ils puissent assurer des traitements en série ou en parallèle, identiques ou différents; o * des moyens de contrôle permettant également de gérer la répartition de tâches de traitement, soit au sein d'un serveur de type multitâches, soit entre plusieurs serveurs (au moins deux) . Dans ce dernier cas, I'un des serveurs peut être prévu pour effectuer les traitements associés à une ou plusieurs couches, par exemple la seconde couche (récupération de données), tandis qu'au moins un autre serveur est destiné à effectuer les traitements associés à une ou plusieurs autres couches, par exemple la troisième couche (transformation des données récupérées); * un module d'interfaçage graphique permettant à un utilisateur de gérer, sur l'écran de son terminal d'utilisateur, I'association des différents modules élémentaires aux différentes couches, ainsi que leur configuration. Dans ce cas, le module d'interfaçage graphique peut être également agencé de manière à fournir à un terminal d'utilisateur, qui est raccordé au serveur dans lequel il est implanté, des informations sur l'état de chaque module élémentaire qui a été associé à une couche logique; *des moyens d' encapsulation pour adapter (ou encapsuler) des modules élémentaires, qui sont issus d'un serveur informatique équipé d'un dispositif de traitement d'un autre type et par conséquent incompatible, de sorte que ce module élémentaire puisse fonctionner dans l'une au moins des couches

de la structure.

Le dispositif selon l' invention est de préférence implanté dans un o serveur informatique de type " proxy ", ou dans un bo^'tier (tel qu'un équipement informatique), raccordé à un (ou plusieurs) réseau(x) de télécommunications public(s) eVou privé(s) et à un (ou plusieurs) terminau(x) d'utilisateur, éventuellement en réseau. Tous ses modules, et ses moyens de contrôle, peuvent être réalisés sous la forme de circuits électroniques (" hardware ") eVou de modules logIciels (" softwere "). Dans le cas de modules logiciels, certains au moins d'entre eux peuvent être réalisés en langage informatique JAVA, en particulier utilisé en mode de programmation

de type non bloqu ant, ou bien en la ngage informatiq u e C ou C++.

L'invention concerne en outre un procédé de traitement de données o comptables comprenant au moins les étapes suivantes: a) prévoir une structure à couches logiques de bas niveau pour le traitement de données, cette structure comportant au moins une première couche pour initier des requêtes d'utilisateur destinces à un réseau, une seconde couche pour récupérer des flux de données transmis par le réseau en réponse à une requête initiée par la première couche, une troisième couche pour transformer des données de flux récupérés au niveau de la seconde couche, et une quatrième couche pour transmettre les données transformées à l'utilisateur qui avait émis une requête, b) prévoir une multiplicité de modules élémentaires pour appliquer des traitements spécifiques à des flux de données entrant, selon leurs types respectifs, et pour générer des flux de données sortant comportant les données traitées, c) associer à l'une au moins des couches l'un au moins des modules élémentaires pour satisfaire à la requête de l'utilisateur, puis configurer chaque module associé à chaque couche de sorte qu'il puisse échanger des flux de données avec l'un au moins des modules qui sont associés à sa couche eVou à la couche suivante, et d) adjoindre au flux de données qui sort de chaque module élémentaire, configuré et associé à une couche, un objet requête, représentatif du t,vpe dudit flux sortant et destiné, éventuellement, à s'enrichir lors de son passage dans chacune des couches, de sorte qu'à réception de ce flux le module élémentaire récepteur puisse déterminer immédiatement s'il doit le traiter ou bien le transmettre, sans traitement, à un autre module, de la même couche

ou de la couche suivante.

D'autres caractéristiques et avantages de l'invention appara^'tront à

I'examen de la description détaillée ci-après, et des dessins annexés, sur

lesquels: - la figure 1 illustre de façon très schématique une installation équipée d'un serveur proxy selon l'invention, - la figure 2 est un diagramme bloc illustrant de façon très schématique so une partie d'un dispositif de traitement selon l'invention implanté dans un serveur proxy, - la figure 3 est un schéma illustrant un procédé d' association et de configuration de modules selon i' invention, adapté à une requête d'utilisateur, dans une application de type " proxy cache >>, - la figure 4 est un schéma illustrant un procédé d' association et de configuration de modules selon l' invention, adapté à une requête d'utilisateur, dans une application de type " proxy cache >> avec authentification de l'utilisateur, et - la figure 5 est un schéma illustrant un procédé d' association et de configuration de modules selon l' invention, adapté à une requête d'utilisateur, dans une application de type " proxy cache " avec authentification de l'utilisateur et transformation des données récupérées. Les dessins annexés sont, pour l'essentiel, de caractère certain. En conséquence, ils pourront non seulement servir à compléter l'invention, mais

aussi contribuer à sa définition, le cas échéant.

Dans la description qui suit, il sera fait référence à une installation de

traitement de donnces, du type de celle illustrce sur la figure 1. Cette installation comprend notamment un serveur proxy 1, dans lequel est implanté un dispositif de traitement 2 selon l'invention, qui sera décrit plus loin en référence à la figure 2, raccordé, d'une part, à un réseau pubiic, de type Internet et, d'autre part, à un réseau privé de type Intranet, via un serveur SRI1 raccordé à une multiplicité de terminaux d'utilisateurs T1 i (ici i =

1 àN).

Bien entendu, le dispositif pourrait être implanté dans un bo^'tier s externe, de type équipement auxiliaire, raccordé au serveur SRI1, celuici

étant alors directement raccordé au réseau externe Internet.

Comme cela est bien connu de l'homme de l'art, de nombreux sites Web SWj (ici j = 1 à 3) sont raccordés au réseau public Internet. Un terminal d'utilisateurs peut donc, en émettant une requête d'accès à une page de données stockées dans un site Web SWj, accéder à ces données, ou en d'autres termes les récupérer, via le réseau Internet, le serveur proxy 1 et le serveur SRI1. Le serveur proxy 1 ou le serveur SRI1 peut éventuellement

assurer la fonction de coupe-feu (ou " firewall ").

D'autres serveurs de réseaux privés (ici SRI2) peuvent être également raccordés au réseau public Internet, éventuellement via un autre serveur proxy 10 équipé soit d'un dispositif de traitement selon l'invention,

soit d'un dispositif de traitement de données standard 20.

Comme indiqué dans l'introduction, un serveur proxy, ou passerelle, est un dispositif informatique qui sert d'interface entre un réseau externe, tel qu'lnternet, qui utilise un premier protocole d'échange de données, et un ou plusieurs terminaux d'utilisateurs, éventuellement raccordés à un réseau privé qui utilise un second protocole d'échange de données. Lorsque le protocole d'échange de données utilisé dans le réseau externe est identique à celui utilisé dans le réseau privé, le serveur informatique est qualifié de routeur. Comme cela est bien connu de l'homme du métier, un serveur proxy assure généralement l'une au moins des trois fonctions principales suivantes: - la mémorisation temporaire de don nées, pl us con nue sou s le terme "cache", qui consiste à conserver localement, dans une mémoire adaptée à cet effet, les pages qui sont les plus couramment visitées par les utilisateurs, de manière à en accélérer le chargement sur leurs terminaux; - I'enregistrement des informations qui sont échangées entre les terminaux d'utilisateurs et le réseau externe. Généralement, il s'agit de sauvegarder dans une mémoire, adaptée à cet effet, I'adresse de l'utilisateur, les adresses (par exemple URL) des pages consultées sur les différents sites, la date et l'heure de la consultation; - le filtrage des do n nces q u i le traversent, de sorte que seu les les don nées qui correspondent aux critères prédéfinis (et paramétrables) de filtrage soient transmises à l'utilisateur requérant. Tout type de filtrage peut être envisagé. Il so peut être généralisé à l'ensemble d'un réseau, ou à des sous-parties d'un réseau, ou encore adapté à chaque utilisateur. Dans ce dernier cas, le

filtrage porte également sur l'authentification de l'utilisateur.

Parfois, le serveur proxy peut également assurer la fonction de coupe-feu, de manière à protéger les terminaux d'utilisateurs, ou le réscau privé, des agressions provenant du réseau extérieur. Dans l'exemple illustré sur la figure 1, le serveur proxy sert d'interface entre le réseau Internet et un réseau privé comportant un serveur interne SRI1. Mais, le serveur proxy peut étre implanté en de nombreux autres endroits, comme par exemple chez un

prestataire de services, ou chez un câble-opérateur.

On se réfère maintenant à la figure 2 pour décrire en détail un

dispositif de traitement selon l'invention.

Ce dispositif comporte, tout d'abord, un module de contrôle 3, une multiplicité de modules élémentaires de traitement, de préférence stockés dans une mémoire 4, des moyens 5 d'interfaçage des modules élémentaires

de traitement, et une structure 6 à couches logiques de bas niveau.

Cette structure multicouches 6 comporte au moins quatre couches 1, - G. T et S destinées à assurer des traitements de données spécifiques. La couche I est prévue pour initier des requêtes d'utilisateurs destinées au réseau externe Internet (dans cet exemple), ou en d'autres termes pour prendre en compte les requêtes des utilisateurs et initier les traitements qui leurs sont associés au sein du dispositif. La couche G est prévue pour la récupération des flux de données qui sont communiqués par le réscau externe en réponse à une requête initise par la couche 1, ou bien des flux de donnces qui ont été précédemment récupérés et qui ont été stockés dans une mémoire cache ou tampon. La couche T est prévue pour la transformation, sur requête, des données des flux précédemment récupérés sur le réseau externe ou dans une mémoire tampon ou cache. La couche S est prévue pour la transmission au terminal de l'utilisateur des donnces récupérées au niveau de la couche G. et qu'il a requises, après une éventuelle transformation dans la couche T. o Chaque module élémentaire de traitement, stocké dans la mémoire 4, est destiné à appliquer un traitement spécifique à un flux de donnces ( entrant "), en fonction de son type, puis à générer un flux de données " sortant " comportant les données traitées accompagnées d'un objet requête. On entend ici par " objet requete ?) I' ensemble des informations

nécessaires à la description du flux de données qu'il accompagne, et

s l'organisation de son cheminement au travers du dispositif (ou de la structure). Par exemple, un objet requete peut comporter l'adresse de l'utilisateur final (qui requiert les données) et une liste de traitements à effectuer (comme par exemple appliquer un filtre, ou changer le protocole, ou encore retirer les images d'une page de données). A réception d'un flux entrant, le module élémentaire de traitement analyse l'objet requete qui l'accompagne, de manière à déterminer si il doit traiter le flux, ou non, puis il délivre un flux sortant accompagné du méme objet requête ou d'un objet

requête " enrichi ".

Un certain nombre de modules élémentaires de traitement sont s indiqués ci-après, seulement à titre d'exemples non limitatifs: - un premier module "HTTPI", responsable de la gestion du protocole d'échange de données HTTP au sein de la couche d' initiation de requête l; - un module "HTTPG", responsable de la gestion du protocole o d'échange de données HTTP au sein de la couche de récupération de données G; - un module "HTTPS", responsable de la gestion du protocole d'échange de données HTTP au sein de la couche de transmission de données S; z - un module "CACHEG", permettant de gérer un cache à travers des fonctions de récupération (par exemple en association avec la couche de récupération de données G); - un module "CACHES", destiné à gérer un cache à travers des fonctions de stockage (par exemple en association avec l'une eVou l'autre o des couches de récupération de données G et de transformation de donnéss T); - un module "LOG" permettant de conserver des traces de l'utilisation du serveur proxy sous la forme de fichiers journaux dont les types d'informations et les formats de stockage, notamment, sont configurables par l'utilisateur ou par un superviseur; - un module "XSLT" permettant de transformer, au niveau de la couche de transformation de données T. un flux de données récupéré dans un premier format, par exemple de type XML, en un second format, par exemple de type WML (adapté aux terminaux d'utilisateur de type portable fonctionnant selon le protocole WAP), grâce à un langage de transformation, par exemple de type XSLT; - un module "REGEX" permettant la modification du contenu d'un flux de données récupérées et/ou transformées, selon une liste d'expression régulière (ou expression obéissant à une syntexe particulière); - un module "TAG TRANSLATOR" permettant de convertir une page de données récupérée, par exemple dans le format "HTML", en une autre page de données dans le méme format, grâce à une modification des balises (ou " tags ") contenues dans cette page. Un tel module permet, par exemple, de retirer une ou plusieurs images contenues dans une page de données WEB, ou de rcécrire des adresses pointées par des liens o hypertextes, ou plus généralement de supprimer ou d'ajouter des informations à l'intérieur d'une page de données WEB récupérce; - un module "AUTH" permettant de gérer l'authentification des différents utilisateurs du serveur proxy 1. Un tel module comporte une liste d'utilisateurs autorisés à utiliser le proxy, éventuellement selon des critères différents, et permet de générer une page d'erreur si un accès non autorisé est demandé. Un tel module peut permettre également d'installer un serveur proxy équipé de la fonction coupe-feu au sein d'une entreprise, de sorte qu'un employé une fois rentré à son domicile, ou utilisant un portable en dehors du réseau privé de l'entreprise, puisse avoir accès aux documents

o internes de l'entreprise après avoir été authentifié.

Bien entendu, d'autres modules élémentaires de traitement peuvent

être envisagés, comme notamment la gestion de différents protocoles.

Selon l'invention, on effectue des copies des modules élémentaires de traitement qui sont stockés dans la mémoire 4 et qui sont nécessaires au traitement d'une requête d'utilisateur, puis on associe ces différents modules élémentaires aux différentes couches logiques de bas niveau (I, G. T. S) de la structure 6 et enfin on configure, à l'aide des moyens d'interfaçage de modules 5, chaque module associé à chaque couche, de sorte que les différents modules associés puissent échanger des données les uns avec les autres dans leurs couches respectives. Bien entendu, comme on le verra plus loin, il n'est pas toujours nécessaire d'utiliser les quatre couches de bas niveau de la stnucture 6. Généralement, on utilise les couches 1, G et S. la couche de transformation T n'étant utilisée qu'en cas de besoin de

transformation des données récupérées, sur requête de l'utilisateur.

L'invention permet ainsi de constituer, en temps réel, des sous structures modulaires adaptées spécifiquement aux besoins des utilisateurs, c'est-à-dire propres à assurer des combinaisons de fonctions, reconfigurables et paramétrables à volonté, et de préférence en temps réel

(ou dynamiquement).

De préférence, le dispositif 2 comporte également des moyens zo d'encapsulation 7 permettant de rendre compatible avec les autres modules élémentaires de traitement, stockés dans la mémoire 4, un module élémentaire de traitement appartenant à un autre dispositif de traitement 20, implanté dans un serveur proxy distant 10. En fait, les moyens d'encapsulation 7 sont destinés à encapsuler, dans le sens informatique du s terme, un module élémentaire de traitement, externe, de sorte qu'il apparaisse comme un module élémentaire de traitement du dispositif 2, et

puisse être réutilisé ultérieurement après avoir été stocké dans la mémoire 4.

Le dispositif 2 comporte également, de préférence, une mémoire tampon 8 permettant de stocker temporairement, selon des critères choisis, o notamment de durce, les données (ou pages de données) récupérées au niveau de la couche G eVou au niveau de la couche T. et provenant du réseau extérieur (ici, Internet). Cette mémoire tampon 8, qui est par exemple du type dit "circulaire dynamique", est utile, notamment, pour réaliser la fonction cache. Elle permet en effet de stocker localement des données ou pages de données qui sont régulièrement demandées par le ou les utilisateurs, pour leur faire gagner du temps. En d'autres termes, à réception d'une requête d'utilisateur, le module de contrôle 3 va tout d'abord vérifier si la page requise par l'utilisateur est stockée dans la mémoire tampon 8, ou bien s'il faut émettre une requête, via la structure multicouches 6, à destination du réseau extérieur pour récupérer les données demandées par

I'utilisateur.

Egalement de préférence, le dispositif 2 comporte un module d'interfaçage graphique 9 qui permet à un utilisateur, ou à un superviseur du serveur proxy 1, de gérer en temps réel (ou dynamiquement) I'association des différents modules élémentaires de traitement aux différentes couches logiques, ainsi que leurs configurations respectives, à la place du module de contrôle 3 ou en complément de celui-ci. Grâce à ce module d'interfaçage graphique 9, I'utilisateur peut obtenir sur l'écran de son terminal T1i, en temps réel, des informations sur l'état de chaque module élémentaire de traitement qui a été associé à une couche logique de la structure o multicouches 6. L'utilisateur, ou le superviseur, peut ainsi à tout moment décider de retirer et/ou d'ajouter à la structure multicouches qui lui est

spécifiquement dédice un ou plusieurs modules élémentaires de traitement.

Les moyens de contrôle 3 sont préférentiellement agencés de manière à gérer, sensiblement simultanément, plusieurs requêtes

s d'utilisateurs qui proviennent de plusieurs terminaux d'utilisateurs différents.

Cela est dû notamment au fait que chaque requête d'utilisateur aboutit à la génération d'une structure multicouches qui lui est spécifiquement dédiée, et dans laquelle sont util isées d es "copies" d es mod u les élémenta ires de traitement stockés dans la mémoire 4, avec des configurations spécifiques

aux besoins desdits utilisateurs.

Le module de contrôle 3 peut également, de préférence, associer plusieurs fois un même module élémentaire de traitement à une même couche, mais avec des configurations différentes, afin qu'ils puissent assurer

des traitements en série ou en parallèle, selon les besoins.

Le dispositif de traitement 2 selon l'invention n'est pas nécessairement localisé dans un unique serveur prox,v 1. Il peut en effet être réparti sur plusieurs serveurs distants. Par exemple, un premier serveur peut être dédié aux traitements de données qui sont effectués dans la couche de récupération G. tandis qu'un second serveur n'est dédié qu'aux traitementsde données qui sont effectués dans la couche de transformation T. et qu'un troisième serveur est dédié aux traitements de données effectués dans les couches d'initiation I et de transmission S.

En variante, le serveur proxy peut fonctionner en mode multitâches.

Dans ce cas, il est subdivisé en sous-parties destinées chacune à assurer une tâche spécifique. Par exemple, les différentes couches de la structure multicouches 6 peuvent être associées à différentes parties du serveur, de manière à permettre des traitements en parallèle, lorsque cela s'avère nécessaire. Dans cette situation, le module de contrôle 3 est donc agencé de manière à gérer la répartition des tâches au sein des différentes parties du serveur multitâches, ou bien au sein des différents serveurs dédiés aux

différentes tâches.

Les différents modules élémentaires de traitement qui sont associés aux différentes couches logiques pour satisfaire les requêtes des utilisateurs, échangent des données via une interface commune, par exemple de type

API (pour " Application Program Interface ").

Les différents modules élémentaires de traitement, qui sont stockés dans la mémoire 4, peuvent faire l'objet de différents regroupements. En effet, ils peuvent être initialement regroupés dans des classes qui sont associées chacune à l'une des couches de la structure multicouches 6. Dans ce cas, ils sont sélectionnés au sein d'une classe associée à une couche so logique requise, puis configurés. Les modules élémentaires de traitement peuvent être également de type "générique". Dans ce cas, ils doivent être intégralement configurés de manière à pouvoir assurer des traitements dans plusieurs couches logiques. Mais, ces modules élémentaires de traitement peuvent être également regroupés dans des classes associées chacune à

un protocole d'échange de données spécifique, comme par exemple HTTP.

Dans ce cas, on sélectionne les modules élémentaires de traitement en fonction de leur appartenance à une classe désignant un protocole particulier, puis on les associe et on les configure en fonction des couches

auxquelles ils doivent être associés.

Préférentiellement, la structure multicouches 6, le module de contrôle 3 et la plupart des modules élémentaires de traitement (au moins) sont des modules logiciels (ou software) réalisés en langage java. Ce langage est connu pour son caractère hautement dynamique permettant de charger ou décharger des classes, efficacement, et de relier des modules sans perte de performance. Bien entendu, certains modules ne pouvant pas être efficacement écrits en langage java, par exemple du fait que la gestion d'un réseau en langage java (réalisée par le package "java.net") est très peu efficace en terme de ressources, certains modules élémentaires de traitement sont donc rédigés en langage C ou C++. Mais, que les modules soient rédigés en C, C++ ou en java, il est particulièrement avantageux que

o leur mode de programmation soit de type non bloquant.

Egalement de préférence, les moyens d'interfaçage de modules 5 fonctionnent selon le mode "java management eXtension (J MX)", bien con nu de l'homme du métier. Ce type d'interface JMX permet d'effectuer une administration "à la volée" des modules élémentaires de traitement, et

notamment leur chargement, leur déchargement et leur configuration.

Par ailleurs, I'interface (API) utilisoe pour permettre aux modules élémentaires, associés et configurés, d'échanger des données entre eux, est de préférence du type "java native interface (JNI)". Cette interface permet en effet d'interfacer indifféremment des modules élémentaires écrits en C ou

o C++ ou en java, sans que cela ne nuise aux performances.

On se réfère maintenant aux figures 3 à pour décrire différents exemples de procédé d'association et de configuration de modules, selon l'invention. Dans ces figures, les rectangles en gris clair représentent des couches de la structure multicouches 6, les rectangles en gris foncé représentent des modules élémentaires de traitement associés aux différentes couches, les flèches en pointillés représentent des flux de données vides accompagnés d'un objet requête, les flèches en continu représentent des flux de données non vides accompagnés d'un objet requête, et les textes inscrits dans des bulles ovales représentent des objets requêtes attachés au flux de données sortant des modules élémentaires de

traitement.

Il est important de noter que dans cette invention on entend par " flux de données " tout type de flux, qu'il soit plein de données ou vide de données mais accompagné d'un objet requête. En d'autres termes, tant que l'on n'a pas récupéré des données, dans une mémoire cache ou sur le réseau extérieur, le flux de données est dit " vide ", tandis qu'il est dit

" plein >' dans le cas contraire.

L'exemple illustré sur la figure 3 représente une structure dédice à

un serveur proxy de type "cache".

L'utilisateur transmet, à l' aide de son terminal utilisateur, u ne requête au serveur proxy 1. Ici, la requête est "Pierre veut voir ce qui se trouve à l'adresse www.toto.fr". A réception de cette requête d'utilisateur, le module de contrôle 3 en déduit que le protocole d'échange de données utilisé est du type HTTP. Par conséquent, il transmet la requête au module HTTPI qui a été associé à la couche d'initiation de requête I et configuré pour y fonctionner. Le module HTTPI génère alors un flux de données sortant au

format HTTP et comportant un objet requête de type "www.toto.fr; Pierre".

Ce flux de données sortant est ensuite transmis à la couche de récupération de données G. et plus précisément au module CACHE qui lui est associé. Il s'agit en fait d'examiner le contenu de la mémoire cache pour déterminer si o la page de donnces, demandée par l'utilisateur, s'y trouve déjà stockée. Si tel est le cas, le module CACHE génère un flux de données sortant auquel il adjoint un objet requête, ici le même que celui généré par le module HTTPI, et le communique à la couche de transmission de données S. et plus précisément au module HTTPS qui lui est associé, de sorte que la page de donnces "www.toto.fr" soit transmise à l'utilisateur désigné par l'objet requête, ici, "Pierre"", après suppression dudit objet requête. En revanche, si la page de données n'est pas stockée dans la mémoire cache, le module CACHE génère un flux de donnces sortant comportant un objet requête, ici le même que celui généré par le module HTTPi, qu'il transmet au module HTTPG qui est comme lui associé à la couche de récupération G. Le module HTTPG récupère alors sur le web (ou réseau Internet) la page de données désignée par l'objet requête, et génère un flux de données sortant comportant les données de cette page récupérée, accompagnées par un objet requête, qui est ici toujours identique à celui généré par le module HTTPI. Ce flux sortant est transmis à la couche de transmission de donnses S. et plus précisément au module HTTPS qui lui est associé de sorte que les données de la page désignée par la requête soient transmises à l'utilisateur "Pierre", après suppression de l'objet requête. La configuration de la structure dédiée à l'utilisateur, ou à un groupe o d'utilisateurs, peut être préalablement effectuée par le superviseur du serveur proxy 1. Elle peut ensuite être adaptée en fonction des besoins de chaque utilisateur, en temps réel, soit par l'utilisateur lui-même, soit par le superviseur. Mais, cette structure dédiée peut également être générée à réception de la requête de l'utilisateur, par le module de contrôle 3 eVou par I'utilisateur ou le superviseur. Dans ce cas, c'est le type méme de la requête qui déclenche la sélection des modules élémentaires de traitement qui doivent être associés aux différentes couches nécessaires au traitement requis par l'utilisateur (par exemple la récupération des données d'une page WEB). so L'exemple illustré sur la figure 4 correspond également à un serveur proxy de type cache, mais cette fois-ci une fonction d'authentification de I'utilisateur a été ajoutée au niveau de la couche de récupération de données G. A réception de la requête de l'utilisateur (ici, I'utilisateur Pierre veut voir le contenu de la page "ww.toto.fr"), le module de contrôle 3 la transmet à la couche d'initiation de requête 1, et plus précisément à son module HTTPI

(qui est spécifiquement adapté au protocole d'échange de donnces HTTP).

Ce module génère un flux sortant, comprenant l'objet requête " wvvw.toto. fr; Pierre ", qu'il transmet à la couche de récupération de données G. et plus précisément au module élémentaire d'authentification AUTH. Celui-ci vérifie dans une liste si l'utilisateur "Pierre" est autorisé à récupérer les données de

la page " www.toto.fr ".

Si ce n'est pas le cas, le module élémentaire d'authentification AUTH génère un flux de données sortant comportant un objet requête de type "ERREUR Pierre" qu'ii transmet à la couche de transmission de donnses S. et plus précisément au module HTTPS qui lui est associé de sorte que le message d'erreu r soit transm is à l'util isateu r "Pierre" désig né d ans la req uête objet. En revanche, si l'utilisateur"Pierre" est autorisé à récupérer les données désignées par sa requête, le module élémentaire d'authentification AUTH génère un flux de données sortant comportant un objet requête, ici o identique à celui généré par le module HTTPI, et le transmet au module CACHE. Celui-ci vérifie si la page de données requise est stockée dans la

mémoire cache.

Si tel est le cas, le module CACHE génère un flux de données sortant, à partir des données de la page requise par l'utilisateur, accompagné d'un objet requête, ici le même que celui généré par le module HTTPI. Ce flux sortant est transmis à la couche de transmission S et plus précisément au module HTTPS qui lui est associé, de sorte que ce dernier transmette les données de la page requise à l'utilisateur "Pierre" qui est

désigné par l'objet requête, après suppression dudit objet requête.

o Si la page de données requise n'est pas stockée dans la mémoire cache, le module CACHE génère un flux de données sortant comportant un objet requête, ici le même que celui généré par le module HTTPI, et le transmet au module HTTPG, de sorte qu'il récupère sur le WEB, à l'adresse

désignée par l'objet requête, les données de la page requise. Une fois celles-

ci récupérées, le module HTTPG génère un flux de données sortant s accompagné d'un objet requête, ici le même que celui généré par le module HTTPI, et le transmet à la couche de transmission de données S. et plus précisément à son module HTTPS, de sorte qu'il transmette la page de donnces requise à l'utilisateur"Pierre", désigné par l'objet requête, après

suppression dudit objet requête.

L'exemple illustré sur la figure concerne également une application de type "cache" avec authentification, mais complétée par une transformation sélective des données récupérces au niveau de la couche de récupération de données G. soit par le module CACHE (lorsque les données requises sont déjà stockées dans la mémoire cache), soit par le module

HTTPG (bien entendu lorsque le protocole d'échange est de t,vpe HTTP).

A réception de la requête de l'utilisateur (ici, I'utilisateur Pierre veut voir le contenu de la page "www.toto.fr"), le module de contrôle 3 la transmet à la couche d'initiation de requête 1, et plus précisément à son module HTTPI

(qui est spécifiquement adapté au protocole d'échange de données HTTP).

o Ce module génère un flux sortant, comprenant l'objet requête " www.toto. fr; Pierre ", qu'il transmet à la couche de récupération de données G. et plus précisément au module élémentaire d'authentification AUTH. Celui-ci vérifie dans une liste si l'utilisateur"Pierre" est autorisé à récupérer les donnces de

la page " www.toto.fr ".

s Si ce n'est pas le cas, le module élémentaire d'authentification AUTH génère un flux de données sortant comportant un objet requête de type "ERREUR Pierre" qu'il transmet à la couche de transmission de données S. et plus précisément au module HTTPS qui lui est associé de sorte que le message d'erreur soit transmis à l'utilisateur "Pierre" désigné dans la requête o objet. En revanche, si l'utilisateur "Pierre" est autorisé à récupérer les données désignées par sa requête, le module élémentaire d'authentifcation AUTH génère un flux de données sortant comportant un objet requête de type " www.toto.fr; Pierre; Transformation sélective XX " (c'est en fait l'objet requête généré par le module HTTPI et enrichi localement par le module AUTH sur la base des informations de transformation choisies par I'utilisateur ou le superviseur), et le transmet au module CACHE. Celui-ci

vérifie si la page de données requise est stockée dans la mémoire cache.

Si tel est le cas, le module CACHE génère un flux de données sortant, à partir des données de la page requise par l'utilisateur, accompagné d'un objet requête, ici le même que celui généré par le module o AUTH. Ce flux sortant est transmis à la couche de transformation T et plus précisément au module " Transformation sélective " qui lui est associé, de sorte qu'il effectue le ou les traitements spécifiés dans l'objet requête, et génère un flux sortant comportant les données transformoes et un objet requête, ici le même que celui généré par le module AUTH, à destination de la couche de transmission de données S. et plus précisément à son module HTTPS, de sorte qu'il transmette la page de données requise à l'utilisateur

"Pierre", désigné par l'objet requête, après suppression dudit objet requête.

Si la page de données requise n'est pas stockée dans la mémoire cache, le module CACHE génère un flux de données sortant comportant un o objet requête, ici le même que celui généré par le module AUTH, et le transmet au module HTTPG, de sorte qu'il récupère sur le WEB, à l'adresse

désignce par l'objet requête, les donnces de la page requise. Une fois celles-

ci récupérées, le module HTTPG génère un flux de données sortant accompagné d'un objet requête, ici le même que celui généré par le module AUTH. Ce flux sortant est transmis à la couche de transformation T et plus précisément au module " Transformation sélective " qui lui est associé, de sorte qu'il effectue le ou les traitements spécifiés dans l'objet requête, et génère un flux sortant comportant les données transformoes et un objet requête, ici le même que celui généré par le module AUTH, à destination de so la couche de transmission de données S. et plus précisément à son module HTTPS, de sorte qu'il transmette la page de données requise à l'utilisateur Les trois exemples qui viennent d'être décrits, en référence aux figures 3 à 5, ne sont en aucune façon limitatifs. Par exemple, le protocole d'échange de données peut être différent du protocole http, notamment lorsque les données sont transmises en node a streaming " audio eVou vidéo. De même, plusieurs modules de transformation, identiques ou différents, peuvent être utilisés au niveau de la couche de transformation T. en parallèle ou en série, afin de satisfaire aux besoins des utilisateurs. On peut notamment effectuer une conversion de format en associant le module XSLT, ou un équivalent, à la couche de transformation T. ou une modification du contenu d'un flux de données récupérces eVou transformées, selon une liste d'expression réqulière, en associant le module REGEX, ou un équivalent, à la couche de transformation T; ou encore une conversion de page de données récupérée, par exemple dans le format "HTML", en une autre page de données dans le même format, grâce à une modification des tags dans la page régulière, en associant le module TAG TRANSLATOR, ou un équivalent, à la couche de transformation T. Mais, on peut également effectuer un filtrage des données récupérées sur le web (ou sur tout autre réseau), en associant un module de filtrage à la couche de transformation T (par exemple). On peut également associer à la structure le zo module LOG, ou un équivalent, pour éditer des journaux récapitulant, de façon spécifique, les échanges de données entre le réseau externe et le

réscau interne, ou un ou plusieurs utilisateurs du réseau interne.

D'autres modules élémentaires peuvent également être envisagés comme par exemple u n mod u le d' optimisation de la bande passante, un module de développement d'outils de transformation destinés à assurer le

suivi des utilisateurs.

Mais l' invention peut également perrnettre de réaliser un dispositif de génération de proxys (ou " proxy factory >), de manière i) à permettre la production et l'intégration dans une installation d'un ou plusieurs serveurs o d'entreprises, dédiés, ou ii) à permettre aux fabricants ou assembleurs de serveurs de générer ou d'adapter lesdits serveurs aux besoins de leurs

clients, sans manipulation manuelle.

Comme indiqué précédemment, les différents modules et moyens d'interfaçage qui constituent le dispositif selon l'invention peuvent être réalisés sous la forme de module logiciel ("software"). Mais ils peuvent être également réalisés, au moins en partie, sous la forme de circuits électroniques ("hardware"), ou encore sous la forme de combinaisons de

modules logiciels et de circuits électroniques.

L'invention ne se limite pas aux modes de réalisation de dispositif, d'installation et de procédé décrits ci-avant, seulement à titre d'exemple, mais elle englobe toutes les variantes que pourra envisager l'homme de l'art

dans le cadre des revendications ci-après.

Claims (22)

REVEN DICATIONS

1. Dispositif de traitement de données (2), implantable dans un serveur informatique (1), caractérisé en ce qu'il comprend: * une structure (6) à couches logiques de bas niveau pour le traitement de donnces, propre à être raccordée à au moins un réseau et à au moins un terminal d'utilisateur (T1i), et comportant au moins une première couche (I) permettant d'initier des requêtes d'utilisateur à destination dudit réseau, une seconde couche (G) destinée à récupérer des flux de données transmis par ledit réseau en réponse à une requête initice par la première couche (I), une troisième couche (T) destinée à transformer des données de flux récupérés, et une quatrième couche (S) destinée à transmettre au terminal de l'utilisateur lesdites données récupérées et éventuellement transformées, * une multiplicité de modules élémentaires agencés pour appliquer des traitements spécifiques à des flux de données entrant, selon leur type, et pour générer des flux de données sortant comportant lesdites données traitées, * des moyens de contrôle (3) comportant des moyens d'interfaçage de modules (5) et agencés pour associer à l'une au moins des couches l'un au moins des modules en fonction d'une requête d'utilisateur, puis à configurer chaque module associé à chaque couche de sorte qu'il puisse échanger des flux de donnces, via lesdits moyens d'interfaçage (5), avec au moins un module de la couche qui suit la sienne et/ou au moins un autre module de sa couche, * lesdits modules configurés et associés à chaque couche étant en outre agencés pour adjoindre aux données du flux sortant qu'ils génèrent un objet requête, représentatif du type dudit flux sortant et s'enrichissant de couche en couche, de sorte qu'à réception de ce flux un module élémentaire récepteur puisse déterminer s'il doit traiter ledit flux ou le

transmettre sans traitement à un autre module.

2. Dispositif selon la revendication 1, caractérisé en ce que chaque module élémentaire associé à la quatrième couche (S) est agencé pour supprimer l'objet requête attaché à un flux avant qu'il ne soit transmis à

un terminal d'utilisateur (T1 i).

3. Dispositif selon l'une des revendications 1 et 2, caractérisé en

ce que lesdits modules élémentaires sont choisis dans un groupe comprenant au moins un premier (HTTPI), un second (HTTPG) et un troisième (HTTPS) modules de gestion du protocole d'échange de données du réseau, propres à étre associés sélectivement aux première (I), seconde (G) et quatrième (S) couches, respectivement, un premier module (CACHEG) de gestion de mémoire cache pour la récupération de données au niveau de l'une desdites couches de la structure, un second module (CACHES) de gestion de mémoire cache pour le stockage temporaire de données au niveau de l'une desdites couches de la structure, un module de sauvegarde (LOG) destiné à stocker des données d'information portant sur I'utilisation du dispositif et permettant l'édition de journaux paramétrables, un premier module (TAG TRANSLATOR) de transformation d'une page de données, dans un format choisi, en une autre page de donnces, dans ledit format choisi, un second module de transformation (XSLT) propre à être associé à la troisième couche (T) et agencé pour transformer des donnces o récupérées par un module élémentaire associé à la seconde couche (G) et placées dans un premier format en données dans un second format, et un module d'authentification (AUTH) agencé pour authentifier des opérateurs

par confrontation à une liste mémorisée.

4. Dispositif selon la revend ication 3, caractérisé en ce que led it premier module de gestion de mémoire cache (CACHEG) est destiné à

récupérer des données au niveau de la seconde couche (G).

5. Dispositif selon l'une des revendications 3 et 4, caractérisé en

ce que ledit second module de gestion de mémoire cache (CACHES) est destiné à stocker des données au niveau de l'une au moins des seconde (G)

o et troisième (T) couches.

6. Dispositif selon l'une des revendications 3 à 5, caractérisé en

ce que ledit module d'authentification (AUTH) est destiné à être associé à

l'une au moins des première (I) et troisième (T) couches.

7. Dispositif selon l'une des revendications 1 à 6, caractérisé en

ce qu'il comprend un module d'interfaçage graphique (9) agencé pour permettre à un utilisateur de gérer en temps réel, sur un écran de son terminal d'utilisateur (T1i), ladite association des modules élémentaires aux

différentes couches et leur configuration.

8. Dispositif selon la revendicatio n 7, caractérisé en ce que led it module d'interfaçage graphique (9) est agencé pour fournir en temps réel à lO un terminal d'utilisateur (T1i) raccordé audit serveur (1) des informations sur

l'état d'au moins chaque module élémentaire associé à une couche logique.

9. Dispositif selon l'une des revendications 1 à 8, caractérisé en

ce qu'il comprend une mémoire tampon (8) agencée pour stocker de façon temporaire des données parvenues au niveau de la seconde couche (G)

eVou de la troisième couche (T).

10. Dispositif selon la revendication 9, caractérisé en ce qu'il

comprend ladite mémoire tampon (8) est de type circulaire dynamique.

11. Dispositif selon l'une des revendications 1 à 10, caractérisé en

ce que lesdits moyens de contrôle (3) sont agencés pour gérer sensiblement zo simultanément au moins deux requêtes d'utilisateurs provenant d'au moins

deux terminaux d'utilisateurs différents (T1 i).

12. Dispositif selon l'une des revendications 1 à 11, caractérisé en

ce que lesdits moyens de contrôle (3) sont agencés pour associer plusieurs fois un même module élémentaire à une même couche, selon des configurations éventuellement différentes, de sorte qu'ils puissent assurer

des traitements en série ou en parallèle.

13. Dispositif selon l'une des revendications 1 à 12, caractérisé en

ce que led it serveu r ( 1) dans lequ el il est im planté est de type multitâches, et en ce que lesdits moyens de contrôle (3) sont agencés pour gérer la

so répartition de tâches de traitement au sein dudit serveur (1).

14. Dispositif selon l'une des revendications 1 à 12, caractérisé en

ce qu'il est implanté dans au moins deux serveurs informatiques sous forme de parties complémentaires, et en ce que lesdits moyens de contrôle (3) sont agencés pour gérer la répartition de tâches de traitement entre lesdits serveurs.

15. Dispositif selon l'une des revendications 1 à 14, caractérisé en

ce que lesdits moyens d'interfaçage de modules (5) fonctionnent selon le

mode Java Management eXtension (JMX).

16. Dispositif selon l'une des revendications 1 à 15, caractérisé en

ce qu'il comprend des moyens d' encapsulation (7) agencés pour adapter un module élémentaire reçu d'un serveur informatique (10) équipé d'un dispositif de traitement (20) d'un autre type, de sorte qu'il puisse fonctionner

dans l'une au moins des couches de la structure (6).

17. Dispositif selon l'une des revendications 1 à 16, caractérisé en

ce que certains au moins des modules élémentaires eVou des modules 1S auxiliaires eVou des moyens de contrôle eVou des moyens d'interfaçage

sont d es mod u l es logiciels réal isés en la ngage info rmatiq u e JAVA.

18. Dispositif selon la revendication 17, caractérisé en ce que ledit langage informatique est utilisé dans un mode de programmation de type

non bloquant.

zo

19. Dispositif selon l'une des revendications 1 à 18, caractérisé en

ce que certains au moins des modules élémentaires eVou des moyens de contrôle eVou des moyens d'interfaçage sont des modules logiciels réalisés

en langage informatique C ou C++.

20. Serveur informatique de type " proxy ", caractérisé en ce qu'il

s comporte un dispositif de traitement (2) selon l'une des revendications

précédentes.

21. Procédé de traitement de données, caractérisé en ce qu'il comprend les étapes suivantes: a) prévoir une structure (6) à couches logiques de bas niveau pour le o traitement de données, comportant au moins une première couche (I) permettant d'initier des requêtes d'utilisateur à destination d'un réseau, une seconde couche (G) destinée à récupérer des flux de données transmis par ledit réseau en réponse à une requête initiée par la première couche (I), une troisième couche (T) destinée à transformer des données de flux récupérés, et une quatrième couche (S) destinée à transmettre à l'utilisateur requérant lesdites données transformées, b) prévoir une multiplicité de modules élémentaires agencés pour appliquer des traitements spécifiques à des flux de données entrant, selon leur type, et pour générer des flux de donnces sortant comportant lesdites données traitées, c) associer à l'une au moins des couches l'un au moins des modules en fonction d'une requête d'utilisateur, puis configurer chaque module associé à chaque couche de sorte qu'il puisse échanger des flux de données avec au moins un module de la couche qui suit la sienne eVou au moins un autre module de sa couche, et d) adjoindre au flux de données sortant de chaque module élémentaire configuré et associé à une couche un objet requête, représentatif du type dudit flux sortant et s'enrichissant de couche en couche, de sorte qu'à réception de ce flux un module élémentaire récepteur puisse déterminer s'il

doit traiter led it flux ou le transmettre sans traitement à u n autre module.

zo

22. Utilisation du dispositif (2), du serveur proxy (1) et du procédé

selon l'une des revendications précédentes, dans le domaine des réseaux

de télécommunications choisis dans un groupe comprenant les réseaux