Note: Descriptions are shown in the official language in which they were submitted.
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
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
s 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 oeuvre dudit procédé.
De nombreuses informations de tous types existent dans les fichiers
~o 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
is 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
2o 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 partïellement utilisables,
nécessite
2s 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
COPIE DE CONFIRMATION
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03Z94
2
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 à
s 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" (WorIdWideWeb), par exemple. Le but de l'invention est de
io 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
is 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.
2o 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,
2s - é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
3o filtre et initialisation d'au moins une chaîne de filtres constituée d'un
ou
plusieurs composants "filtres",
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
3
- 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.
s 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
lo 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
ts 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
2o 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
2s module comprend des composants possédant chacun une interface
déterminée.
Selon une autre particularité, !a 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
3o 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
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
4
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.
s 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
io 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.
is 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
2o 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.
2s 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)
3o 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
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
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
s 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
io 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 compatible avec la source dans des structures de
is données compatible avec 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
2o à 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
2s 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
3o source et envoyées à l'application client. La couche interne (9) comporte
le
module de transformation (3) de fa requête et le module de transformation du
résultat (4). Dans un adaptateur donné, grâce à la structure homogène des
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
6
interfaces quelque soit le langage utilisé par l'application ou par la source,
il est
possible de mettre plusieurs couches internes (9) l'une au-dessus de l'autre,
chacune des couches étant adaptée à un langage différent, tout en ayant
qu'une seule couche "Client" (8) et qu'une seule couche "Source" (10).
s Cet empilage est défini par un fichier de configuration de l'adaptateur.
L'application cliente en utilisant ce fichier de configuration détermine
(adaptateur utilisé.
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
io 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.
~s 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 ia requête avec leurs
coûts lorsque cela est requis. Les métadonnées sont des données sur la
2o structure des données elle-même. Quatrièmement, il initialise dynamiquement
et configure les autres composants de Padaptateur.
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
2s 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
3o 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
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
7
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
s 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é
to 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 ia 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.
is 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
2o (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
2s "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. II
existe
quatre classes de filtres. Les filtres dits "opérateurs" (42) appliquent à la
réponse retournée par la source, des contraintes supplémentaires,
3o 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
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
8
ê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
s 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
~o 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
is format interne de la couche interne (9) de l'adaptateur. Le module de
coordination (5) avec la source (7) a deux fonctions. II envoie une requête à
la
source de données, par exemple une requête SQL (Structured Query
Language), ou HTTP. II 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
2o 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
à
2s 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 "Wapper" (annexe1), et soumet les requêtes à l'adaptateur. Le
3o composant de connexion (21 ) réceptionne la requête (71 ) et transmet la
requête (72) par l'interface "Analyse" au module (3) de transformation de la
requête. Dans une première phase, l'adaptateur utilise le composant d'analyse
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
9
(31 ) de la requête faisant partie du module (3) de transformation de la
requête
pour établir une représentation interne (73, 74) de la requête qu'il transmet
au
composant de traduction (32) dans un format compatible avec l'interface
"Request Builder". Cette représentation interne (73,74) est également
s compatible avec l'interface "Process Builder" du composant de traitement
(33).
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 compatible avec l'interface "Source"
que
la source peut comprendre. La requête traduite (75) est soumise à la source à
to 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 "Filter" (représentée annexe 1 par les
références 18
et 181 à 184) 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
is les résultats provenant de la source par utilisation des méthodes "open"
(182),
"next" (183), "close" (184). 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, le ou les filtres nécessaires pour
compléter le
premier filtrage (52) afin de produire une réponse compatible avec le format
de
20 l'adaptateur. Pour initialiser ces filtres, l'adaptateur donne à ce
constructeur de
traitement {33} d'une part la représentation interne (73) de la requête par
une
fonction qui utilise comme paramètres les résultats de l'interface "Analyse"
et
d'autre part, par la flèche référencée (76), l'objet filtre (52) produit par
le
composant source (51. Ce constructeur de traitement (33) restitue une chaîne
2s 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 à
30 l'application client {fi) l'objet réponse. L'application client utilise
l'interface
"Answer" (12) de ce composant (22), comportant des méthodes "open", "next",
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
"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
s 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 notation utilisée pour les interfaces est la suivante
"vector
~o getSelectClause( ), dans laquelle le contenu entre parenthèse exprime les
paramètres utilisés par la fonction "getSelectClause" et "vector" exprime la
forme du résultat fourni par la fonction utilisée par l'interface. Ce résultat
peut
être sous forme de chaîne (string), de booléen (boolean), de vecteur (vector)
ou
d'un objet (object). La couche "Client" définit les interfaces et les
composants
~s permettant d'utiliser un adaptateur. Les interfaces de la couche "Client"
(8)
permettent d'utiliser un adaptateur localement ou à distance. La couche
"Client"
(8) comprend deux interfaces spécifiques, une première interface à la fois de
connexion (11, annexe 1}, appelée "Wrapper" et d'aministration d'adaptateur
(13, annexe 1 ) , réalisée par le composant de connexion (21 ), et une seconde
2o 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
2s 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 égaiement de
retourner (78) à l'application client l'objet réponse (22) qui fournit un
certain
nombre de fonctions définies dans l'interface "Answer (12). Une seconde
méthode (GetCapability) (112) de la première interface "Wrapper" ne prend en
3o compte aucun argument d'entrée. Cette seconde méthode retourne une chaîne
de caractères (string) encodant la liste des opérateurs de requête supportés
par l'adaptateur et leurs conditions d'usage représentant les capacités de
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
11
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 sous-ensemble de ces
s opérateurs. En utilisant cette fonction (GetCapability) (112), 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 chaise de
to caractères constituant 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 (attribut-valeur). Les types sont
définis
is 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
2o 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
2s coûts sont transmis des adaptateurs à fappücation 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) ies 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)
30 (121) de la seconde interface "Answer" ne prend aucune entrée et retourne
un
ensemble de "tuples", liste de paires (attribut-valeur). Cette fonction
retourne un
ensemble de tous ies tuples retournés par la source et filtrés par
l'adaptateur.
CA 02320891 2000-08-16
WO 00/39709 PCTlFR99/03294
12
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
s 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 intertace "Answer" ne prend aucun argument. Elle
lo 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é
~s exécutée avant la fin de l'ensemble de réponse.
La couche "Client" (8) comprend une troisième intertace
"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
2o 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 intertace 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
2s 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 intertace JDBC (14) peut être utilisée avec tout
type de base de données à condition qu'il existe un composant de traduction
3o 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
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
13
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
s dans la quatrième interface JDBC. Les différentes interfaces de JDBC citées
ci-
après, "java.sqLDriver", "java.sqLConnection" "java.sql.ResuItSet" et
"java.sqLDatabaseMetadata" 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
~o avant la connexion de la base de données. La réalisation de l'interface
"java.sqLConnection" (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.sqLResuItSet" (143) joue le même rôle que la
réalisation de l'interface "Answer" (12) pour récupérer des résultats. Les
is 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.sqLDatabaseMetadata".
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
2o traitement (33) qui peuvent être chacun empilables. Ainsi pour un autre
langage
client l'adaptateur utilisera un autre composant d'analyse (31'), un autre
composant de traduction (32') de requête et autre composant de construction
de traitement (33'), chacun étant adapté à cet autre langage, mais utilise
pour
un composant donné les mêmes méthodes constitutives des interfaces.
2s Chacun a sa propre interface utilisée par le module de coordination (2)
pour
finalement générer un plan d'exécution, c'est-à-dire la chaîne de filtres
(46), est
définie par les composants "ProcessBuilder" à partir du fichier de
configuration
et des informations extraites de la requête par le composant analyse pour une
requête reçue. Une première interface "Analyse" (15) contient les méthodes
3o 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
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
14
"setRequest" (151). Le format de la requête est dépendant de l'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 "getSefectClause" (152) retourne une liste
s (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
io (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
~s la requête peut être effectuée en phases en empilant différents analyseurs.
Un
empilement (31, 31',...) de composants d'analyse peut être nécessaire pour
résoudre des problèmes de conversion par exemple.
Une deuxième interface "Request Builder" (16) contient les méthodes
qu'un composant traduction de requête (32) doit réaliser. La requête entrante
2o 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 retourne la valeur "vrai"
si tout se passe bien, "faux" sinon. Le format de la requête traduite dépend
du
2s type de format que la source peut accepter. une autre metnoae
"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 (32, 32',...) peuvent être empilés.
Une troisième interface "Process builder" (17) contient les signatures
3o 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
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
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
s 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
Io d'exécution (77), c'est-à-dise 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
is 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
2o contenus dans une table à accès direct (hashtable). Une deuxième méthode
"open" (182) ouvre le flot de données délivrées 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
2s 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
3o d'exemple dans l'annexe 2 permet de manipuler un tuple contenant des
données semi-structurées définies par la classe "DataFormat".
CA 02320891 2000-08-16
WO 00139709 PCT/FR99/03294
16
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
s "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
~o "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.
is 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.
2o L'interface utilise une deuxième méthode "getCanfig" (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, chaque interface reposant sur un nombre minimum de méthodes
2s soigneusement sélectionnées. 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. Seuls les objets auxquels s'appliquent les méthodes
3o sont modifiés en fonction des langages source et des langages des
applications client.
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
17
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, par exemple, de connexion (21), analyseur
(31 ), traducteur (32), filtre (42 à 45), de traitement (33) de source (5),
s 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
des composants peut ëtre facilement supportée en branchant des composants
io 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
~s 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
2o 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
2s 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.
3o 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
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
18
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.
s II est clair que d'autres modifications à la portée de l'homme du métier
entrent dans le cadre de l'invention.
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
19
ANNEXE 1
11
interface "Wrapoer" .
-Answer query (object request) i 111
-String getCapability()'112
-String getSchema(~113
-String getCost(~ 114
interface "Answer".~ 12
-Set getAlIQ 121
- open() ~22
-Tuple gefNext()-123
- close() 124
interface "Ada~terAdmin" : 13
i
interface JDBC 14
java.sqLDriver/ 141142
java.sqLConneeti~
java.sqLResuItSet /143
interface "Analyse" ~ 15
-boolean setRequest.(0bject query) 151
-Vector getSelectClause() 152 i
-Vector getFromClause() 153
-Object getWhereClause(~ 154
-Vector getGroupByClause(~ 155
-Object getHavingCiause() _ 156
interface "Reauest Builder"-"" 16
-boolean setRequest(Vector selectClause, Vector fromClause, Object
whereClause,
Vector groupbyClause, Object havingC ause ) 161
-Object getTranslatedQuery()
interface "Process Builder: -1-=._
- setRequest(Vector selectClause, Vector fromClause, Object whereClause,
Vector
groupbyClause, Object havingClause~ 171
-void setSourceFilter(Filter source )
-Filter getProcessQ 1 ~3 --~--~ ~2
interface "Filter" : _.. ~ 8
-initialize(Hashtable params, Filter previous) 181
- open() 182
-DataFormat next~ 183
-close()
CA 02320891 2000-08-16
WO 00/39709 PCT/FR99/03294
ANNEXE 2
60 / 61
classe "DataFormat~
- setAtt(String narre, Object value): "donne la valeur du nom de l'attribut
donné"
- removeAtt(String narre): "enlève l'attribut donné par son nom"
-String getAttName(int index): "retourne ie nom de (attribut correspondant à
l'index"
-int getAttlndex(String narre): "retourne l'index de l'attribut correspondant
au nom"
-Object getAttValue(int index): "retourne la valeur de (attribut correspondant
à (index"
-Object getAttValue(String narre): "retourne la valeur de (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 getCopyQ: "retourne un clone de cet objet"
-String toStringp : "retourne une représentation de type chalne, de l'objet"
62
intertace "Source" 621
-boolean checkM~dataQ 622
-DataFormat getMetaDa a~
-Filter sendQuery(Object qu~ 623
interface "Admin" : 63
setConfig(Hashtabie-p8rameters) 631
Hashtable getConfig()
632
