Intégration de sources de données par le biais de services web

Le choix d’une d’intégration de sources de données par le biais de services web permet aussi de rendre accessible des données et des traitements à travers des systèmes hétérogènes et distribués (cf chapitre6).

L’utilisation d’un annuaire de services n’est pas obligatoire, mais il permet néanmoins de centraliser le référencement des services web. En outre, l’enregistrement dans un annuaire cen- tral, ouvert et public, tel que celui du projet BioMoby permet de partager et mutualiser l’en- semble des web services développés dans le cadre d’une communauté internationale, consé- quente, de bioinformaticiens. De nombreux projets du domaine de la biologie végétale déve- loppent et enregistrent des services web sur l’annuaire central BioMoby. Nous pouvons citer parmi les plus importants, le Consortium Planet qui intègre les ressources génomiques de l’es- pèce modèle A. thaliana, ainsi que le Generation Challenge Programme qui centralise les infor- mations biologiques liées à la résistance des plantes tropicales aux stress abiotiques, tels que la sécheresse. Le développement de web services par l’intermédiaire de l’API BioMOBY favorise ainsi la diffusion rapide de données génomiques à une large communauté de biologistes et de bioinformaticiens.

L’enregistrement des services web sur l’annuaire central BioMOBY (Central Registry) né- cessite la définition préalable des types de données ou "data types". Les data types (par exemple integer, float, string) représentent le type de contenu que peuvent prendre les données en entrée et sortie des services web. Ces data types sont structurés dans une ontologie écrite en RDF, qui

contient des relations de spécialisation "ISA" et des relations de composition "HAS et HASA". Les data types définis peuvent être complexes : le type CommentedDNASequence est défini à partir d’une spécialisation du type DNASequence et d’une composition du type Descrip- tion(String). Nous avons cependant constaté que cette ontologie n’est pas correctement structu- rée car de nombreux types sont organisés sur un premier niveau de spécialisation. En outre, de nombreuses redondances existent parmi les data types. En effet les noms des types sont souvent préfixés pour garantir leurs unicité, malgré d’évidentes similarités ; ainsi TropGene_accession, IMGA_Accession, GCP_Identifier correspondent, en réalité, à des objets de même type. Ces in- cohérences dans la structure de l’ontologie des objets BioMoby ont pour conséquence de limiter la découverte automatique de services web. La connexion efficace de services web susceptibles d’être complémentaires nécessite encore l’intervention manuelle de l’utilisateur. Cette étape de définition correcte des data types est donc primordiale pour le référencement des services ainsi que leurs enchaînements. Dans ce contexte, la réutilisation de types existants est fortement re- commandée lorsque les conditions s’y prêtent, notamment lorsque la description des types est déjà suffisante.

A l’image de l’intégration navigationnelle ou de l’exécution de pipeline d’analyses, les ser- vices web ont besoins d’être enchaînés pour répondre à des questions biologiques complexes. Or l’utilisation de logiciels de composition de workflows, tels que Taverna, est généralement beaucoup plus accessible à des utilisateurs experts comme des développeurs ou des bioinfor- maticiens. Nous avons donc développé un nouveau gestionnaire de workflows, plus adapté aux utilisateurs biologistes, qui permet de proposer une liste de workflows disponibles ou qui sélec- tionne les workflows adaptés aux données soumises en entrée.

Ce type d’application doit tenir compte des faiblesses des web services BioMOBY et doit s’appuyer sur le modèle relationnel pour la manipulation de données. Elle doit donc développer des fonctions permettant (i) d’éliminer la redondance (équivalent d’un distinct en SQL), (ii) de faire une différence, (iii) de cumuler des conditions (OR ou AND). Par ailleurs, un effort doit être porté sur l’optimisation des temps d’exécution pour un workflow. Dans ce domaine, nous nous sommes orientés vers la parallélisation des appels de services. Les workflows étant conçus préalablement, il est facile de déterminer quels services peuvent être appelés simultanément à partir des données soumises en entrée. Toujours au niveau de l’optimisation, il est important de distinguer dans leurs utilisations, des services appelés une fois, de ceux qui sont appelés plusieurs fois dans un même processus. Dans ce dernier cas, il est préférable de modifier les services pour qu’ils gèrent des collections de data types en entrée ce qui permet de n’utiliser le service qu’une seule fois et donc de supprimer les multiples temps d’appels vers l’annuaire central BioMoby.

Le développement d’interfaces dans ce type d’application joue un rôle important. Tout d’abords au niveau de la gestion des recherches. Par exemple, les biologistes doivent pouvoir sauvegarder plusieurs recherches ainsi que les résultats correspondants. Afin de pouvoir affiner leurs recherches et trier les résultats, des fonctions d’édition doivent être mises en place. En ef- fet, les chercheurs compilent fréquemment des résultats nettoyés issues de plusieurs recherches. La notion de partage est également introduite à ce niveau, puisque ces résultats peuvent être partagés au sein d’un groupe. Intervient alors, la question de la gestion des groupes. En ef- fet, comme c’est le cas pour le partage des données expérimentales, les scientifiques désirent

7.2. Discussion

partager les résultats selon différents niveaux de confidentialité. Enfin, pour compléter les fonc- tionnalités de ces interfaces de gestion, la mise en place de systèmes d’alertes permet de garder une veille sur les recherches sauvegardées. Des alertes peuvent être placées pour les mises à jour des sources impliquées dans les workflows sauvegardés mais aussi sur l’ajout de nouvelles sources pouvant compléter l’information qui est recherchée.

Au niveau de la gestion des résultats, les outils de visualisation sont à prendre en considéra- tion. Lorsque les workflows génèrent des listes importantes de résultats, ils doivent dans un premier temps être présentés de manière synthétique (souvent une information booléenne pour les données obtenues est suffisante) afin que les scientifiques puissent réaliser des tris. Dans un deuxième temps, les résultats peuvent être affichés de manière détaillée (c’est à dire avec toutes les données obtenues par les services). Dans ce cas, l’interface doit pouvoir construire à partir des résultats, des liens vers des sources externes ce qui permet d’augmenter l’information intégrée par les services. Par exemple le numéro d’accession Genbank permet de construire un lien vers la source Genbank d’Entrez qui détaille les caractéristiques de la séquence nucléique.