Brevet FR2787957A1 — publié le 20000630

Procédé de traitement d'une requête La présente invention concerne un procédé de traitement d'une requête. L'invention concerne plus particulièrement un procédé de transformation de requête et de résultats entre une application cliente et une pluralité de sources hétérogènes de données par un dispositif adaptateur d'architecture donnée, spécifique à chaque source de données, et l'architecture donnée d'adaptateur permettant la mise en #uvre dudit procédé. De nombreuses informations de tous types existent dans les fichiers des entreprises ou du domaine public, par exemple. La plupart de ces informations ne peuvent pas être exploitées car elles se trouvent dans des bases de données multiples qui sont difficiles à intégrer ou dans de multiples fichiers de traitement de texte. Des solutions ont été apportées pour rendre les données brutes accessibles par des environnements Intranet ou Internet. Ces solutions ne résolvent pas les problèmes critiques se présentant aux gestionnaires de transfert de données. L'information est gardée dans un ensemble mélangé de systèmes, chaque système ayant ses propres protocoles d'accès et ses propres interfaces. Lorsqu'une information est demandée par un client sous forme d'une requête, seule une partie de l'information est généralement utile aux besoins de l'application client. Les données ne sont jamais dans la bonne forme. La plupart du temps un programme ad hoc doit être écrit pour transformer les données dans un format utilisable. De nombreuses informations utiles sont enfermées dans des fichiers privés, et l'extraction manuelle d'informations, même partiellement utilisables, nécessite beaucoup de temps. L'intégration de nouveaux serveurs ou de bases de données représente un travail laborieux et le résultat est généralement peu flexible et peu compréhensible. Les principaux problèmes sont d'accéder à l'information là où elle est, dans sa forme originale, de la transformer dans un format utilisable et de la délivrer aux applications qui en ont besoin. Le traitement de la requête d'un client s'effectue par un adaptateur. Un adaptateur spécifique est associé à chaque source de donnée. La présente invention a donc pour objet de pallier les inconvénients de l'art antérieur en proposant un procédé de traitement d'une requête, commun à tous les adaptateurs. Le procédé selon l'invention procure une interface d'accès uniforme aux sources d'informations telles que les DBMSs relationnelles (DataBase Management System), les fichiers système, les bases de données "Lotus Notes", les systèmes de gestion de document et les serveurs "Web" (WorldWideWeb), par exemple. Le but de l'invention est de proposer un procédé qui permette d'extraire des informations en travaillant directement, par exemple, à partir d'un compte rendu, d'appels d'offre ou de documents similaires dans des formats hétérogènes tels que HTML (HyperText Markup Language) ou ASCII (Americain Standard Code for Information Interchange), pour obtenir un objet, une date de publication ou la place par exemple, d'un appel d'offre publié sur un serveur ayant un protocole déterminé tel que HTTP (HyperText Transmission Protocol). Le procédé proposé doit permettre de filtrer l'information pour sélectionner l'information utile, au lieu d'ajouter une autre fonction spécifique pour chaque application qui a besoin de l'information. Ce but est atteint par le fait que le procédé de traitement de requêtes et de résultat entre un client et une pluralité de sources hétérogènes de données par un dispositif adaptateur spécifique à chaque source, d'architecture donnée, réalise les étapes suivantes de façon indépendante : - réception de la requête émise par l'application client, - établissement d'une représentation interne de la requête par l'adaptateur, - utilisation de cette représentation interne de la requête pour réécrire la requête en un format compréhensible par la source, - transmission de la requête traduite à la source, production d'un objet filtre et initialisation d'au moins une chaîne de filtres constituée d'un ou plusieurs composants "filtres", - récupération par l'objet filtre des résultats provenant de la source pour les transmettre et les faire filtrer à travers la chaîne de composants "filtres", - production d'un objet réponse pour transférer les résultats provenant du module de transformation du résultat à l'application client. Selon une autre particularité, l'initialisation de chaîne de filtre s'effectue à partir de la représentation interne de la requête et de l'objet filtre. Selon une autre particularité, l'objet réponse est produit à partir de la chaîne de filtres. Selon une autre particularité, l'objet réponse est retourné à l'application client pour lui permettre de récupérer les résultats. Selon une autre particularité, des métadonnées concernant le schéma des données dans la source, les opérateurs supportés par la source et les coûts associés à ces opérateurs, sont fournies à l'application client. Un autre but de l'invention est de proposer un adaptateur d'architecture donné permettant la mise en oeuvre dudit procédé. Ce but est atteint par le fait que l'adaptateur comprend quatre modules, un module de coordination servant d'interface avec l'application client comprenant un composant de connexion et un composant "réponse", un module de transformation de la requête, comprenant au moins un composant d'analyse, au moins un composant de traduction et un composant de construction de traitement, un module de communication avec la source comprenant un premier composant "source" et un second composant "Filtre d'accès source" et un module de transformation du résultat comprenant des troisièmes composants filtres possédant tous la même interface, chaque module comprend des composants possédant chacun une interface déterminée. Selon une autre particularité, la même interface de programmation d'application (API), le même langage de requête et le même modèle de données sous forme de métadonnées de la source sont utilisés pour traiter chaque source. Selon une autre particularité, le module de transformation du résultat est constitué d'un jeu de composants choisis parmi quatre sortes de troisièmes composants filtres, des composants "opérateurs" appliquant des contraintes supplémentaires à la réponse, des filtres d'extraction, des filtres de traduction de structure et des filtres de construction de la réponse transformant la réponse au format de donnée de l'application client. Selon une autre particularité, des composants d'analyse et/ou des composants de traduction sont empilés. D'autres particularités et avantages de la présente invention apparaîtront plus clairement à la lecture de la description ci-après faite en référence au dessin annexé dans lequel la figure 1 représente l'architecture d'un adaptateur selon l'invention et le procédé de traitement d'une requête. En référence à la figure 1, les adaptateurs (1) sont basés sur la transformation de requêtes et de résultats entre une application (6) et une source (7) de données par un double procédé de réécriture de la requête et de transformation du résultat. Un adaptateur est associé à une source. L'adaptateur est chargé de donner une vue relationnelle de la source à laquelle il est attaché. Les requêtes provenant de l'application client (6) sont analysées, puis transformées en requêtes supportées par le gestionnaire de la source (7) de données, les paramètres de la requête sont extraits et utilisés pour guider la transformation du résultat. Les résultats sont transformés par des processus d'extraction d'information et de restructuration. Les adaptateurs peuvent être utilisés directement pour accéder à des sources de données à partir d'applications. L'application client (6) peut être une application quelconque ayant besoin d'accéder à une source de données sous une forme relationnelle structurée. L'architecture de l'adaptateur (1) selon l'invention peut se décomposer en quatre principaux modules : un module de coordination (2), un module de transformation (3) de la requête, un module de transformation du résultat (4) et un module de communication avec la source (5). Le module de coordination (2) sert d'interface avec l'application client (6). Le module de coordination (2) communique avec l'application client (6) en échangeant des requêtes et des réponses avec l'application client (6). Le module de transformation de la requête (3) est responsable de l'analyse de la requête reçue et de la traduction de celle-ci en opérations supportées par le gestionnaire de la source de données (7). Le module de transformation du résultat (4) est responsable de la restructuration des résultats, de la traduction des types de données de la source en des types de données de l'application client (6) d'une manière générale, et de l'élaboration de la réponse envoyée à l'application client (6). Les adaptateurs offrent des caractéristiques de requête et des modèles de données basés sur une technologie de base de données relationnelle afin de procurer un accès uniforme à différentes sources de données. Ce qui implique une traduction d'une requête de type base de données en une requête qui n'est pas de type base de données et la traduction de résultats non-structurés en des résultats structurés de manière relationnelle. Le module de communication (5) avec la source est responsable de la communication avec la source (7) et encapsule des réponses dans des structures de données de l'adaptateur (1). Son rôle est d'une part, d'envoyer la requête à la source et d'autre part, de récupérer les résultats que la source (7) renvoie. Chaque module est composé d'un jeu de composants. La fonctionnalité de chaque module et les différents composants utilisés pour les construire vont à présent être décrits. Les modules composant l'architecture peuvent être classés en trois différentes couches : la couche "Client" (8), la couche interne (9) de l'adaptateur, et la couche "Source" (10). La différence entre ces trois couches est basée sur leur rôle. La couche "Client" (8) et la couche "Source" (10) traitent avec les contenants, c'est-à-dire l'interface procurée à l'application client et la manipulation des interfaces des sources. La couche "Client" (8) comporte le module de coordination (2) et la couche "Source" comporte le module de communication (5) avec la source. La couche interne (9) de l'adaptateur traite avec le contenu, c'est-à-dire avec les requêtes reçues de l'application client et envoyées à la source (7), et les données reçues de la source et envoyées à l'application client. La couche interne (9) comporte le module de transformation (3) de la requête et le module de transformation du résultat (4). Dans un adaptateur donné, il est possible de mettre plusieurs couches internes (9) l'une au-dessus de l'autre, tout en ayant qu'une seule couche "Client" (8) et qu'une seule couche "Source" (10). La couche "Client" (8) regroupe les composants qui traitent avec l'application client au niveau de l'accès. Son rôle est de servir d'interface avec l'application client. Les composants de la couche client réalisent une interface utilisée par l'application client (6). Le module de coordination (2) de cette couche client a quatre principales responsabilités. Premièrement, un composant de connexion (21) accepte une requête (71) d'une application client et passe (72) la requête au module de transformation (3) de requête. Deuxièmement, un composant "Réponse" (22) permet de transférer le résultat, provenant du module de transformation (4) du résultat, à l'application client (6). Troisièmement, il délivre à l'application client des métadonnées, concernant le schéma des données dans la source, les opérateurs de la requête avec leurs coûts lorsque cela est requis. Les métadonnées sont des données sur la structure des données elle-même. Quatrièmement, il initialise dynamiquement et configure les autres composants de l'adaptateur. La couche interne (9) de l'adaptateur regroupe les composants qui traitent de la transformation des données. Deux modules sont associés aux deux principales transformations effectuées qui sont le module de transformation de la requête (3) et le module de transformation des résultats (4). Les principales fonctions du module de transformation de la requête (3) sont d'une part, de réécrire la requête provenant du module de coordination en une requête qui peut être soumise à la source de données (7) et d'autre part, d'initialiser le module de transformation de résultats (4) qui traitera les résultats récupérés de la source (7). Ceci est effectué en trois phases. Premièrement, la requête entrante est analysée pour identifier les éléments utilisés, pendant l'élaboration d'une requête acceptée par la source et pendant la transformation des résultats. Ces éléments sont les noms de la relation, les attributs de la projection, et les prédicats de sélection ou de jointure. Cette étape, consistant à établir une représentation interne de la requête, est réalisée par un composant d'analyse (31). Deuxièmement, l'information constituée par ces éléments est utilisée dans un composant de traduction (32) qui réécrit la requête dans une forme pouvant être acceptée par le gestionnaire de la source de données (5). Troisièmement, l'information est utilisée par un composant "constructeur de traitement" (33) pour initialiser tous les filtres nécessaires. La requête soumise à la source de données fournit un ensemble de réponses qui est ensuite filtré pour produire une réponse correcte à l'application client. Le passage de cet ensemble de réponses à travers les filtres peut être requis pour étendre ou augmenter les capacités de traitement de la requête d'un gestionnaire de source de données. L'analyse de la requête, par le composant (33), permet d'initialiser des filtres en fonction des besoins de l'application client. Le module de transformation du résultat (4) est responsable de l'extraction des informations pertinentes dans les réponses obtenues par le module de communication avec la source (5). Ce module (4) est également chargé de l'accomplissement de transformation sur celles-ci, si c'est nécessaire, et ensuite du formatage de la réponse au format de données de l'application client (6). Ce module est constitué d'un empilement de composants (42 à 45) appelés filtres. Le passage à travers cette chaîne (46) de filtres correspond à de l'extraction de données, à de la vérification par rapport à la requête de départ et à des conversions. Les filtres du module de transformation des résultats (4) possèdent tous la même interface incluant des méthodes "open", "get-next", "close" et manipulent les données dans un même format interne. Ainsi, les filtres peuvent être enchaînés dans n'importe quel ordre en fonction des besoins en extraction, en vérification et en conversion. Il existe quatre classes de filtres. Les filtres dits "opérateurs" (42) appliquent à la réponse retournée par la source, des contraintes supplémentaires, correspondant à des opérateurs de sélection ou de projection par exemple. Des filtres dits d'extraction (43) réalisent une chaîne d'extraction d'information et de méthodes de structuration. Un filtre (44) de traduction de structure peut être utilisé pour récupérer le schéma des données. Ces trois types de composants peuvent être utilisés plusieurs fois dans la chaîne avec différentes initialisations pour réaliser des transformations qui se révèlent impossibles en n'utilisant qu'un seul filtre. Un filtre (45) de construction de la réponse termine la chaîne. Ce filtre transforme la réponse du format de données interne de l'adaptateur (1) au format de données de l'application client. La couche "Source" (10) regroupe les composants, qui gèrent l'accès de la source (7), afin d'envoyer une requête à la source et de récupérer les résultats. Un premier composant "Source" (51) accepte les requêtes au format de la source de données provenant du composant de traduction de la requête (32). Un second composant "Filtre d'accès source" (52) récupère les résultats que la source renvoie suivant le protocole de la source, ces résultats étant sous la forme, dans le format et dans le codage utilisés par la source. Ce composant (52) transforme ces résultats pour les envoyer à la chaîne de filtres (46) au format interne de la couche interne (9) de l'adaptateur. Le module de coordination (5) avec la source (7) a deux fonctions. Il envoie une requête à la source de données, par exemple une requête SQL (Structured Query Language), ou HTTP. Il utilise l'interface "filtre" du module de transformation du résultat (4) pour retourner le prochain élément de la réponse de la source de données au format de données interne de l'adaptateur. Une description du traitement par l'adaptateur de requêtes reçues des clients va à présent être effectuée en référence à la figure 1 sur laquelle les flèches continues à tête pleine représentent le chemin d'une requête, d'une représentation d'une requête ou d'une information particulière et les flèches à trait discontinu et à tête pleine représentent le flux de données et les flèches à trait discontinu et à tête creuse représentent les opérations de création d'un objet du procédé. Quand un client (6) a des requêtes à envoyer à un adaptateur (1), il ouvre une connexion vers l'adaptateur en utilisant une interface, et soumet les requêtes à l'adaptateur. Le composant de connexion (21) réceptionne la requête (71) et transmet la requête (72) au module de transformation de la requête (3). Dans une première phase, l'adaptateur utilise le composant d'analyse (31) de la requête faisant partie du module de transformation de la requête pour établir une représentation interne (73,74) de la requête. Dans la seconde phase, la représentation (74) de la requête est utilisée par le composant de traduction de la requête (32) pour traduire la requête initiale (71) de l'application client dans un format que la source peut comprendre. La requête traduite (75) est soumise à la source à travers un composant "Source" (51) de la couche source, et un objet filtre correspondant au composant "Filtre d'accès source" (52) est produit. Cet objet filtre (52) réalise l'interface "Filtre" du module de transformation de résultat. Cet objet filtre (52) est le premier élément de la chaîne de filtres qui filtrera et permettra de récupérer les résultats provenant de la source. Dans une troisième étape, l'adaptateur utilise un composant "constructeur de traitement" ou "initialisateur de filtre" (33), pour initialiser dans la chaîne de filtres, les filtres nécessaires pour compléter le premier filtrage (52) afin de produire une réponse compatible avec le format de l'adaptateur. Pour initialiser ces filtres, l'adaptateur donne à ce constructeur de traitement (33) la représentation interne (73) de la requête et l'objet filtre (52) produit par le composant source (51). Cette étape est représentée sur la figure par la flèche référencée (76). Ce constructeur de traitement (33) restitue une chaîne de filtres (46) constituée de différents composants filtres (42 à 45). La phase terminale est la construction d'un objet réponse, correspondant au composant "Réponse" (22). Cet objet réponse est produit par le composant de connexion (21) en utilisant la chaîne de filtres (46) que le constructeur de traitement (33) lui fournit par la liaison (77). Ensuite, le composant de connexion (21) donne à l'application client (6) l'objet réponse. L'application client utilise l'interface de ce composant (22), comportant des méthodes "open", "next", "close", pour récupérer les résultats dans le format de données particulier de l'interface. Une description des interfaces utilisées entre les différentes couches et les différents modules va à présent être effectuée. Ces interfaces font partie de la définition d'une architecture commune pour tous les adaptateurs. Les interfaces des différents composants sont communes à tous les adaptateurs. Les interfaces suivantes figurant en annexe 1 et 2 permettent de soumettre une requête, de récupérer des résultats et de gérer un adaptateur en fonctionnement. La couche "Client" définit les interfaces et les composants permettant d'utiliser un adaptateur. Les interfaces de la couche "Client" permettent d'utiliser un adaptateur localement ou à distance. La couche "Client" comprend deux interfaces spécifiques, une première interface de connexion (11, annexe 1), appelée "Wrapper", réalisée par le composant de connexion (21), et une seconde interface (12) "Answer" réalisée par le composant "réponse" (22). La première interface "Wrapper" procure à l'application client un accès aux services de base d'un adaptateur (1). Cette interface comprend une première méthode "requête" (query) (111) qui utilise un objet comme argument d'entrée. Cette méthode "requête" (query) permet de recevoir la requête de l'application client en utilisant comme argument d'entrée un objet représentant la requête émise par l'application client. Cette méthode "requête" (query) permet également de retourner (78) à l'application client l'objet réponse (22). Une seconde méthode (GetCapability) (112) de la première interface "Wrapper" ne prend en compte aucun argument d'entrée. Cette seconde méthode retourne une chaîne de caractères encodant la liste des opérateurs de requête supportés par l'adaptateur et leurs conditions d'usage et représentant les capacités de l'adaptateur. La chaîne de caractères décrit les opérateurs que l'adaptateur supporte et la façon dont ils peuvent être combinés. Les opérateurs utilisables sont des opérateurs d'exploration, de sélection, de projection, d'union et de combinaison. Chaque adaptateur supporte un sousensemble de ces opérateurs. En utilisant cette fonction, l'application client sait quels sont les opérateurs de requête supportés par chacun des adaptateurs utilisés par l'application client et peut ainsi optimiser sa requête. Une troisième méthode (getSchema) (113) de la première interface "Wrapper" ne prend en compte aucun argument d'entrée et retourne une liste de types. Chaque type décrit la représentation interne d'une classe du schéma des données sur la source. Les types sont construits en utilisant d'une part, des types de base tels que entier, réel, booléen, chaîne et d'autre part, des constructeurs pour ensembles et uplets ou "tuples". Un tuple est une liste de paires (attributvaleur). Les types sont définis au moment de la création de l'adaptateur. Cette troisième méthode est utilisée pour transmettre à l'application client la structure des données dans la source et permettre ainsi à l'application client de récupérer les résultats. Une quatrième méthode (getCost) (114) de la première interface "Wrapper" (11) ne prend pas en compte d'argument et retourne une chaîne encodant les informations de coût associées à chaque opérateur. Les informations de coût permettent d'évaluer le temps et la taille mémoire du résultat d'une requête. L'application client maintient un modèle de coût afin de sélectionner le meilleur plan d'exécution, c'est-à-dire la meilleure chaîne de filtres. Un modèle de coût par défaut est défini sur l'application client. Afin d'améliorer ce modèle, les coûts sont transmis des adaptateurs à l'application client en utilisant la fonction de la quatrième méthode (getcost) (114). La seconde interface "Answer" (12, annexe 1) procure à l'application client (6) les services pour récupérer les résultats de la requête soumise. Cette interface comprend différentes méthodes. Une première méthode (getAll) (121) de la seconde interface "Answer" ne prend aucune entrée et retourne un ensemble de "tuples". Cette fonction retourne un ensemble de tous les tuples retournés par la source et filtrés par l'adaptateur. La deuxième méthode (open) (122) de la seconde interface "Answer" ne prend aucune entrée et ne produit aucune sortie. Elle exécute la procédure d'initialisation nécessaire avant que le premier "tuple" puisse être envoyé à l'application client. Une troisième méthode (getNext) (123) de la seconde interface "Answer" ne prend en compte aucun argument et retourne un objet "Tuple". Cet objet fixe un "tuple" qui est une partie de la réponse aux sous-requêtes passée à l'objet réponse du composant "Réponse" (22). S'il n'y a pas d'autres tuples dans la réponse, il retourne un "nul". Une quatrième méthode (close) (124) de la seconde interface "Answer" ne prend aucun argument. Elle exécute des opérations de nettoyage. Elle ne fait rien si elle est appelée avant un appel d'ouverture. Cette fonction peut être appelée avant la récupération du dernier "tuple". Quand un appel d'ouverture par la première méthode (open) apparaît après un appel de fermeture de la quatrième méthode (close), la troisième méthode (getnext) retourne un "nul", même si la fermeture a été exécutée avant la fin de l'ensemble de réponse. La couche "Client" (8) comprend une troisième interface "AdaptaterAdmin" (13, annexe 1) permettant d'initialiser et de configurer les composants de l'adaptateur en fonction des paramètres d'accès de la source. Cette troisième interface procure des services d'administration permettant de gérer un adaptateur pendant ou après l'initialisation. Les différentes interfaces de la couche "Client" décrites précédemment peuvent être remplacées par une interface JDBC (Java DataBase Connectivity). Le "Java" est un nouveau language de programmation, conçu par la société "Sun", basé sur le C++. JDBC constitue un utilitaire pour la connexion de "Java" aux bases de données. Cette quatrième interface JDBC (14, annexe 1) est une interface d'accès aux bases de données SQL standard, procurant un accès uniforme à une large gamme de base de données. La requête étant un objet, cette interface JDBC (14) peut être utilisée avec tout type de base de données à condition qu'il existe un composant de traduction sous-jacent. Un gestionnaire JDBC a besoin de manipuler des requêtes SQL, ce qui ne peut pas être assuré au niveau de l'interface. Si le choix du programmeur d'adaptateur pour le composant d'analyse (31) dans le module de transformation de la requête (3) est un analyseur grammatical SQL, l'adaptateur sera totalement conforme à JDBC. Bien que les interfaces ne soient pas les mêmes, des caractéristiques trouvées dans les interfaces (11, 12,13) de la couche "Client" décrites précédemment peuvent être trouvées dans la quatrième interface JDBC. Les différentes interfaces de JDBC citées ci- après, "java.sql.Driver", "java.sql.Connection" "java. sql. ResultSet" et "java. sq 1. Data basemetad ata" font partie de la norme JDBC. La réalisation de l'interface "java.sql.Driver" (141) remplace la troisième interface (AdaptaterAdmin) décrite précédemment. La configuration doit être effectuée avant la connexion de la base de données. La réalisation de l'interface "java.sql.Connection" (142) joue le même rôle que la réalisation de l'interface "Wrapper" pour la récupération de métadonnées et la soumission de la requête. La réalisation de "java. sql. ResultSet" (143) joue le même rôle que la réalisation de l'interface "Answer" (12) pour récupérer des résultats. Les méthodes pour récupérer les capacités de l'adaptateur et les informations de coût correspondent à des méthodes de l'interface "java.sql.DatabaseMetadata". Le module de transformation de la requête (9) doit contenir trois éléments pour chaque adaptateur : un composant d'analyse (31), un composant de traduction (32) de requête et un composant de construction de traitement (33). Chacun a sa propre interface utilisée par le module de coordination pour finalement générer un plan d'exécution, c'est-à-dire la chaîne de filtres (76), pour une requête reçue. Une première interface "Analyse" (15) contient les méthodes qu'un analyseur de requête (31) doit réaliser. La requête est considérée comme quelque chose de similaire à des requêtes SQL. La requête est donnée à l'analyseur (31) au moment de la création ou avec une première méthode "setRequest" (151). Le format de la requête est dépendant del'interface réalisée. L'analyseur doit extraire différents éléments de la requête et utilise les différentes méthodes ci-après. Une deuxième méthode "getSelectClause" (152) retourne une liste (nom, alias), de type chaîne, des attributs projetés ("selectclause"). Une troisième méthode "getFromClause" (153) retourne une liste (nom, alias) de type chaîne des relations ("from clause"). Une quatrième méthode "getWhereClause" (154) retourne un prédicat décrivant la condition de sélection ("where clause"). Le format du prédicat est dépendant de l'implémentation. Une cinquième méthode "getGroupByClause" (155) retourne une liste (nom, alias), de type chaîne, des attributs (groupby clause). Une sixième méthode "getHavingClause" (156) retourne un prédicat utilisant l'ensemble des opérateurs permettant de sélectionner les groupes (having clause). Le format du prédicat est dépendant de l'implémentation. L'analyse de la requête peut être effectuée en phases en empilant différents analyseurs. Un empilement de composant d'analyse peut être nécessaire pour résoudre des problèmes de conversion par exemple. Une deuxième interfaceinterface "Request Builder" (16) contient les méthodes qu'un composant traduction de requête (32) doit réaliser. La requête entrante est définie comme la sortie de l'analyseur précédemment décrit ("select clause", "from clause", "where clause", "groupby clause" and "having clause"). La requête est donnée au composant de traduction au moment de la création ou avec la méthode "setRequest" (161). Cette méthode retoume la valeur "vrai" si tout se passe bien, "faux" sinon. Le format de la requête traduite dépend du type de format que la source peut accepter. Une autre méthode "getTranslatedQuery" (162) retourne la traduction de la requête précédemment donnée. De la même façon que les composants d'analyse, différents composants de traduction peuvent être empilés. Une troisième interface "Process builder" (17) contient les signatures de la méthode qu'un constructeur de traitement (33) doit réaliser. Le constructeur de traitement (33) a besoin de produire le plan d'exécution. Le constructeur de traitement fournit la chaîne (46) de filtres, qui constitue le composant principal du plan d'exécution correspondant à la requête donnée. Une première méthode (171) permet de donner au constructeur de traitement (33) les informations nécessaires, extraites par le composant analyse (31), pour générer le plan d'exécution. Une deuxième méthode (172) permet de donner au constructeur de traitement (33) le premier élément filtre du plan d'exécution. Ce premier élément est l'objet filtre correspondant au composant "Filtre d'accès source" (52), fourni par le composant source (51) après la soumission de la requête traduite, et permettant de récupérer les résultats de la source. Une troisième méthode (173) retourne au composant de connexion (21) le plan d'exécution (77), c'est-à-dire la chaîne (46) de filtres calculée pour la requête. Le module de transformation du résultat (4) contient des interfaces et des classes permettant de construire une chaîne de filtres qui traite les données venant de la source avant de les envoyer à l'application client. Les interfaces et les classes suivantes sont utilisées par chaque composant de ce module afin de réduire la dépendance des composants et de favoriser la réutilisation de ces composants. Chaque composant filtre (42 à 45) doit réaliser une interface "Filtre" (18). Cette interface permet de composer une chaîne de filtre (46) en insérant tout composant filtre à toute position. Une première méthode "initialize" (181) initialise le filtre avec la liste donnée des paramètres. Une deuxième méthode "open" (182) ouvre le flot de donnée délivrée par la chaîne. Une troisième méthode "next" (183) retourne un objet de la classe "DataFormat" représentant un tuple. Cette méthode permet de prendre l'un après l'autre les tuples d'une même requête. Une quatrième méthode "close" (184) ferme le flot de données délivré par la chaîne. Une classe "DataFormat" (60) définit la structure de traitement des données communes dans l'adaptateur. Dans le cas des filtres, elle correspond à une liste de paires attribut-valeur ou "tuples" qui est transmise d'un filtre de la chaîne au filtre suivant. Un ensemble de méthodes (61), données à titre d'exemple dans l'annexe 2 permet de manipuler un tuple contenant des données semi-structurées. Le module de transformation du résultat peut comprendre des interfaces supplémentaires pour permettre, par exemple, d'effectuer des traitements en parallèle. Les composants de la couche source (10) doivent réaliser une interface "Source" (62, annexe 2) afin d'être utilisés par le composant de connexion (21) du module de coordination pour récupérer les informations sous forme de métadonnées et pour envoyer la requête à la source. Cette interface comprend une première méthode "checkMetadata" (621) qui vérifie la disponibilité des métadonnées. Cette interface comprend une deuxième méthode "getMetaData" (622) récupère les métadonnées délivrées par la source et les traduit en quelque chose de compréhensible par la couche client supérieure. Une troisième méthode "sendQuery" (623) reçoit une requête compréhensible par la source, produit et retourne (76) au constructeur de traitement (33) un objet filtre (52) afin de récupérer les résultats. Si le composant source (51) est configurable pendant la durée d'exploitation, il doit réaliser une autre interface (63), appelée interface "Admin". Cette interface comprend une première méthode "setConfig" (631) pour donner le paramètre de configuration au composant source. Le programmeur de composant source doit fournir le format et la forme de ce ou ces paramètres. L'interface utilise une deuxième méthode "getConfig" (632) pour récupérer les paramètres de configuration disponibles dans l'adaptateur. Les adaptateurs selon l'invention présentent de nombreux avantages. Ils proposent une interface d'accès uniforme aux sources hétérogènes d'information. La même interface de programmation d'application (API), le même langage de requête et le même modèle de données sont utilisés pour traiter chaque source, même si ces sources sont totalement différentes au niveau du protocole d'accès, du langage de la requête et du modèle de données. La définition d'une architecture générique avec des interfaces communes pour les composants inclus dans les modules de l'adaptateur permet de réaliser des composants réutilisables. Ces composants peuvent être réutilisés dans plusieurs adaptateurs sans modifications. La composition des composants réutilisables dans des chaînes de composants permet aux programmeurs de réaliser facilement des adaptateurs. L'évolution des sources de données et l'évolution de composants peut être facilement supportée en branchant des composants dans des chaînes de composants déjà existantes dans l'adaptateur ou en remplaçant un composant par un autre. La création rapide d'adaptateurs robustes s'appuie sur ces composants réutilisables. L'architecture commune selon l'invention peut être utilisée avec des bibliothèques de composants réutilisables pour créer des familles d'adaptateur caractérisées par un gestionnaire de données commun, par exemple "Lotus Notes", ou pour créer des adaptateurs spécialisés fabriqués pour une source de données spécifique. Trois types de composants peuvent être distingués en fonction de leur dépendance au gestionnaire de donnée de la source associée. Cette dépendance dicte la manière dont les composants peuvent être réutilisés d'un adaptateur à l'autre. Certains composants sont spécifiques à un adaptateur et ne peuvent pas être réutilisés. Par exemple, la construction de requête pour un moteur de recherche WWW (World Wide Web) dépend du langage que cette source particulière accepte. Certains composants sont communs à une famille d'adaptateur. Par exemple, le module de communication HTTP peut être réutilisé pour tous les adaptateurs associés à une source de données basée sur un site Web. Certains composants sont communs à tous les adaptateurs. Par exemple, les filtres de projection et de sélection appliqués sur les données obtenues à partir de la source ne dépendent pas de la source, et peuvent être potentiellement réutilisés pour construire chaque adaptateur. Le procédé selon l'invention permet de fournir des "métadonnées" à l'application client pour optimiser les requêtes et permettre une meilleure utilisation de la source. L'adaptateur procure des métadonnées sur la source de données, ce qui permet à un programmeur de construire des applications utilisant dynamiquement ces métadonnées, rendant ainsi les applications réutilisables avec des sources totalement différentes. La construction et la gestion de ces applications sont ainsi plus faciles. Il est clair que d'autres modifications à la portée de l'homme du métier entrent dans le cadre de l'invention. ANNEXE #11 interface "Wrapper" : 111 -Answer query (object request) -String getCapability()#112 -String getSchema()#113 -String getCost()#114 interface "Answer":#12 -Set getAll()- 121 - open() #122 -Tuple getNext()#123 - close() #124 interface "AdapterAdmin" #13 interface JDBC#14 -java. sql. Driver -#*' 142 -java .sql. Connection,/' -java.sqLResuItSet 143 interface "Analyse" : #15 #151 -boolean setRequest (Object query) -Vector getSelectClause() #152 -Vector getFromClause() #153 -Object getWhereClause() #154 -Vector getGroupByClause() # 155 -Object getHavingClause()- 156 interface "Request Builder" - #16 -boolean setRequest(Vector selectClause, Vector fromClause, Object whereClause, Vector groupbyClause, Object havingClause)# 161 -Object getTranslatedQuery() # 162 interface "Process Builder: # 17 - setRequest(Vector selectClause, Vector fromClause, Object whereClause, Vector groupbyClause, Object havingClause ) #171 -void setSourceFilter(Filter source ) -Filter getProcess() # 173 # 172 interface "Filter" : 18 -initialize(Hashtable params, Filter previous) #181 - open() #182 -DataFormat next() # 183 -close() - 184 ANNEXE classe "DataFormat"#60 # 61 - setAtt(String name, Object value): "donne la valeur du nom de l'attribut donné" - removeAtt(String name): "enlève l'attribut donné par son nom" -String getAttName(int index): "retourne le nom de l'attribut correspondant à l'index" -int getAttlndex(String name): "retourne l'index de l'attribut correspondant au nom" -Object getAttValue(int index): "retourne la valeur de l'attribut correspondant à l'index" -Object getAttValue(String name): "retourne la valeur de l'attribut avec le nom donné" -boolean isAttribute(String attrName) : "pour savoir si un attribut est déjà défini" -int getNumAtt() : "retourne le nombre des attributs dans le tuple" - appendsLast(DataFormat toAdd): "ajoute le Dataformat donné à l'objet présent" -DataFormat getCopy(): "retourne un clone de cet objet" -String toString() : "retourne une représentation de type chaîne, de l'objet" interface "Source' 62 #621 -boolean checkMetadata()#6 622 -DataFormat getMetaData()# 23 -Filter sendQuery(Object query)#6 interface "Admin"#63 631 setConfig(Hashtable parameters) # Hashtable getConfig() # 632 REVENDICATIONS 1. Procédé de traitement de requêtes et de résultat entre un client et une pluralité de sources hétérogènes de données par un dispositif adaptateur (1) spécifique à chaque source, d'architecture donnée, caractérisé en ce qu'il réalise les étapes suivantes de façon indépendante : - réception de la requête (71) émise par l'application client, - établissement d'une représentation interne (73,74) de la requête par l'adaptateur, - utilisation de cette représentation interne de la requête pour réécrire la requête en un format compréhensible par la source, - transmission de la requête traduite (75) à la source (7), production d'un objet filtre (52) et initialisation d'au moins une chaîne de filtres (46) constituée d'un ou plusieurs composants "filtres" (45,44, 43,42), - récupération par l'objet filtre (52) des résultats provenant de la source pour les transmettre et les faire filtrer à travers la chaîne (46) de composants "filtres", - production d'un objet réponse (22) pour transférer les résultats provenant du module de transformation du résultat à l'application client. 2. Procédé de traitement selon la revendication 1, caractérisé en ce que l'initialisation de chaîne de filtre s'effectue à partir de la représentation interne de la requête et de l'objet filtre (52). 3. Procédé de traitement selon la revendication 1 ou 2, caractérisé en ce que l'objet réponse (22) est produit à partir de la chaîne de filtres (46). 4. Procédé selon l'une des revendications précédentes, caractérisé en ce que l'objet réponse (22) est retourné à l'application client (6) pour lui permettre de récupérer les résultats. 5. Procédé de traitement selon l'une des revendications précédentes, caractérisé en ce que des métadonnées concernant le schéma des données dans la source, les opérateurs supportés par la source et les coûts associés à ces opérateurs, sont fournies à l'application client. 6. Architecture donnée d'adaptateur permettant la mise en #uvre du procédé selon la revendication 1, caractérisée en ce que l'adaptateur comprend quatre modules, un module de coordination (2) servant d'interface avec l'application client (6) comprenant un composant de connexion (21) et un composant "réponse" (22), un module de transformation de la requête, comprenant au moins un composant d'analyse (31), au moins un composant de traduction (32) et un composant de construction de traitement (33), un module de communication (5) avec la source comprenant un composant "source" (51) et un composant "Filtre d'accès source" (52) et un module de transformation du résultat (4) comprenant des composants "filtres" (42,43, 44,45) possédant tous la même interface, chaque module comprend des composants possédant chacun une interface déterminée. 7. Architecture donnée d'adaptateur selon la revendication 6, caractérisée en ce que la même interface de programmation d'application (API), le même langage de requête et le même modèle de données sous forme de métadonnées de la source sont utilisés pour traiter chaque source. 8. Architecture donnée d'adaptateur selon la revendication 6 ou 7, caractérisé en ce que le module de transformation du résultat est constitué d'un jeu de composants choisis parmi quatre sortes de composants filtres, des composants "opérateurs" (42) appliquant des contraintes supplémentaires à la réponse, des filtres d'extraction (43), des filtres de traduction de structure (44) et des filtres de construction de la réponse (45) transformant la réponse au format de donnée de l'application client. 9. Architecture donnée d'adaptateur selon l'une des revendications 5 à 7, caractérisé en ce que des composants d'analyse et/ou des composants de traduction sont empilés.