Le rôle des adaptateurs

La publication des données, qu’elles soient stockées dans des fichiers plats, des bases de données ou générées à la volée par un programme, est gérée par un adaptateur ou wrapper en anglais. De manière générale, le rôle des wrappers est multiple. (i) Ils jouent un rôle de traducteur entre le médiateur et la source en transformant les données de leur modèle d’origine vers le modèle pivot (e.g. modèle relationnel dans le cas de Le Select). (ii) Ils exportent des méta-données sur les ressources qu’ils publient telles que la disponibilité des ressources, le temps d’exécution des requêtes, etc. Ils exportent également des informations sur leurs capacités d’exécution de requêtes (e.g. jointure, union). Toutes ces méta-données servent au médiateur pour optimiser les requêtes à travers un plan d’exécution. Dans le cas de Le Select les wrappers exportent de la documentation sur la resource et les données qu’elle contient.

Les adaptateurs de données Pour chaque source de données devant être publiée, unwrapper existant doit être utilisé ou crééde novosi leswrapperscommuns ne conviennent pas. Le Select contient 3 types de wrapper: texte délimité, texte tabulé et JDBC. Le premier est utilisé pour publier des données dans des fichiers plats ASCII, dans lesquels la structure est organisée en ligne avec des valeurs séparées par un caractère délimitant (i.e. les fichiers csv). Lewrapperta- bulé a les mêmes caractéristiques avec une valeur fixe de délimitation. Le wrapper JDBC permet d’accéder à n’importe quelle base de données via JDBC. La ré-utilisation de ces wrappersse fait par l’intermédiaire d’un fichier de configuration de type XML,wrapper definition file. Les wrappersutilisent ces fichiers pour accéder aux sources (e.g. paramètres de connexion, déclara- tion des types et noms des attributs de colonnes, etc), par conséquent un fichier de configuration est nécessaire pour chaque source publiée.

5.1. Description du middleware AEBG11.jpg;/picture/plant/Osmu2/large/AEBG11.jpg;image/jpg;raw

AEBG11_01.jpg;/picture/plant/Osmu2/large/AEBG11_01.jpg;image/jpg;raw AGZB12_01.JPG;/picture/plant/Osmu2/large/AGZB12_01.JPG;image/jpg;raw AGZB12_02.JPG;/picture/plant/Osmu2/large/AGZB12_02.JPG;image/jpg;raw AING04_01.JPG;/picture/plant/Osmu2/large/AING04_01.JPG;image/jpg;raw AING04_02.JPG;/picture/plant/Osmu2/large/AING04_02.JPG;image/jpg;raw

FIG. 5.2 – Exemple de fichier de données portant sur les images de plantes

La figure 5.2 représente les données contenues dans une source de type texte (i.e. pic- ture.txt). Elle même listant l’ensemble des images disponibles pour la collection de plantes du CIRAD. La figure5.3 représente un exemple de ces fichiers pour une source de type texte.

Le type dewrapper est défini par l’attribut "WrapperClass" dans la première ligne (1) du do- cument en paramètre de l’élément "Wrapper". Cet attribut est obligatoire et désigne le nom de la classe Java correspondant au type de wrapper. L’élément "Wrapper" contient deux éléments

"Parameters" et "Documents". Le premier, obligatoire, définit les éléments qui vont être publiés alors que le deuxième, facultatif, sert à attacher de la documentation auxwrapperset aux tables.

La structure de l’élément "Parameters" varie en fonction duwrapperutilisé. Dans ce cas, il pos- sède l’attribut "separator" permettant de distinguer les différents élément d’une ligne et contient au moins un élément "Table" (4). Le bloc "Table" (4 à 9) correspond aux éléments de la source picture.txt publiée. L’élément "Table" contient un attribut "name" ayant comme valeur le che- min relatif vers le fichier texte. Il contient également deux éléments nommés "Column" (5 à 8). Les éléments ont des attributs "name" et "type" correspondant respectivement aux noms et types que prennent ces colonnes. Les informations incluses entre les balises documents servent à documenter le wrapper sous la forme de méta-données (voir la section5.1.2.1).

1 <Wrapper WrapperClass="LeSelect.Wrappers.Text.TextWrapperFactory">

2

3 <Parameters separator=";">

4 <Table name="Picture" file="data/picture.txt">

5 <Column name="Nom" type="string" />

6 <Column name="Chemin" type="string" />

7 <Column name="TypeMime" type="string" />

8 <Column name="Bin" type="raw" />

9 </Table>

10 </Parameters>

11 <Documents>

12 ...

13 </Documents>

14 </Wrapper>

FIG. 5.3 – Exemple de fichier de configuration de wrapper texte

L’interrogation des données issues de ressources de type "fichier plats" s’effectue de la même manière qu’une requête SQL. Par exemple si nous souhaitons filtrer la liste d’images en effectuant une projection sur la colonne nom :

(Q1) : Trouver les noms, chemins et binaires des images dont le début du nom commence par AGZB12.

La requête se traduira dans Le Select de cette manière :

select Nom, Chemin, Bin from /picture where nom like ’AGZB12%’

FIG. 5.4 – Exemple de requête Le Select sur une source de données

Les adaptateurs de programmes Le Select possède également les fonctions nécessaires à la publication de programmes. Unwrapper de programme convertit les données d’entrées en tables de manière équivalente aux données publiées et dans un format convenable pour le pro- gramme, puis exécute le programme à partir d’une requête SQL. La particularité du middleware est de permettre l’exécution de programmes de manière distribuée (par exemple, un programme local sur données distantes). L’exécution de programme est traitée de manière asynchrone, pal- liant ainsi à un délai de réponse trop long. Un identifiant d’exécution est alors généré par le wrapper, il s’agit du $jobID dans la figure 5.6. Il permet alors de vérifier l’état d’exécution du programme (par exemple, en attente, erreur, terminé. . .). Les données sont retournées sous forme de tables au même titre que les données publiées. Pour que cela soit possible, unwrap- per de données est utilisé. En effet, après que le wrapper de programme termine l’exécution, le médiateur lui demande un wrapper de données pour accéder aux résultats. Leswrappersde programmes possèdent également d’autres fonctions. Par exemple, ils permettent d’informer le médiateur du coût d’exécution du programme, de la gestion des accès concurents, et de la gestion des résultats.

La figure 5.5 représente le fichier de configuration pour le wrapper de programme (wdf) adapté à la recherche de similarité de séquences au travers du programme BLAST. Le fichier de configuration indique dans sa première ligne le type de wrapper utilisé "GenericXMLPr- Factory". L’élément "Parameters" contient 3 sous éléments qui correspondent aux commandes ("ProgPath") et fichiers de transformation pour les données d’entrées ("XSLInPath") et sorties ("XSLOutPath"). Les informations saisies dans la balise "Documents" permettent de documen- ter le wrapper de programme.

<ProgramWrapper

WrapperClass="programwrapper.generic.GenericXMLPrWrFactory">

<Parameters>

<ProgPath value="java BlastCommand"/>

<XSLInPath value="wrapperconf/BlastProgram_in.xsl"/>

<XSLOutPath value="wrapperconf/BlastProgram_out.xsl"/>

</Parameters>

</ProgramWrapper>

FIG. 5.5 – Exemple de fichier wdf pour un programme BLAST

(Q2) : Exécuter le programme BLAST en utilisant les séquences de la table temporaire fasta

5.1. Description du middleware Dans l’exemple d’exécution d’un programme BLAST (figure5.6), nous pouvons détailler trois instructions typiques ; le lancement du programme effectué par la commande EXECUTE.

Dans ce cas c’est le wrapper de programme qui est appelé avec les paramètres nécessaires à son exécution ainsi que les données d’entrée ici extraites d’une table temporaire (input dataset is se- lect * from /temp/fasta). Le deuxième ordre consiste à vérifier l’état d’exécution du programme avec la commande QUERY. Si le résultat n’est pas terminé le même identifiant est retourné sinon le chemin de la table résultat est renvoyé. La dernière instruction permet la consultation des résultats stockés dans une table temporaire.

JOB EXECUTE /programs/blast parameter prog = ’blastn’

parameter db = rice_genome parameter evalue = 5

input dataset is select * from /temp/fasta JOB QUERY $jobID

SELECT * FROM $tmpTableName

FIG. 5.6 – Exemple de requête Le Select sur un programme BLAST

Les mécanismes de vues Le Select possède des fonctionnalités qui lui permettent d’effectuer des transformations sur les données publiées. C’est un mécanisme de vues. Elles permettent d’effectuer des transformations sur les données ou d’intégrer des données issues de différentes sources. Par exemple, dans la vue définie en figure 5.8 nous intégrons les noms de plantes provenant de deux sources sous le même nom d’attribut (i.e. name). Comme nous pouvons le voir sur la figure, elles se construisent de la même manière que des requêtes SQL ordinaires et peuvent bénéficier de l’utilisation des opérateurs ensemblistes comme l’opérateur d’UNION qui va permettre de faire l’union entre deux relations de même schéma. Une fois définies, elles peuvent être utilisées par des clients comme s’il s’agissait d’une table sans distinction avec les données publiées.

<view>

<definition query=

"select a.name as name from /bcrddb/material a union

select b.NAME_LINE as name from /oryzatagline/line b" />

</view>

FIG. 5.7 – Exemple de vue Le Select sur l’intégration de données issues de sources différentes

L’attachement de méta-données Le middleware possède des outils de documentation des ressources publiées. Par exemple des informations sur l’unité de mesure d’une valeur ou l’auteur de la donnée et sa date de création peuvent être stockées dans un document spécifique. Ce document est mis en ligne de la même manière que les données elles même servant alors de base pour des recherches par un moteur de recherche. La documentation peut décrire les wrappers ou les tables d’unwrapper(unwrapperpeut définir plusieurs tables). Il peut être inclus dans le

fichier de configuration duwrapper ou inséré dans un autre fichier dont le lien est indiqué dans le fichier de configuration.

FIG. 5.8 – Exemple de documentation duwrappertexte picture

<Documents>

<WrapperDocument>

<attribute name="picture" value="Source listant toutes les images de plantes disponibles dans la collection de mutant d’insertion" />

</WrapperDocuments>

<TableDocument tableName="picture">

<attribute name="Nom" value="Nom de l’image correspondant au mutant">

<attribute name="Chemin" value="Chemin de la localisation des images">

<attribute name="TypeMime" value="TypeMime des images">

<attribute name="Bin" value="Accès aux binaires des images">

</TableDocument>

</Documents>

L’élément "Documents" comprend les parties nécessaires pour décrire leswrappers(Wrap- perDocument) et les tables (TableDocument) associées aux wrappers. Un élément "Wrapper- Document" possède obligatoirement au moins un élément "attribute" qui est lui-même décrit par une paire "name" et "value". Dans ce cas, l’attribut "name" correspond aux noms des sources publiées par lewrapper. Dans le cas de l’element TableDocument l’attribut "name" correspond aux noms des colonnes publiées.