6.2 Développement d’une application intégrée utilisant des services web
6.2.4 Résultats
6.2.4.1 Création des services web
6.2. Développement d’une application intégrée utilisant des services web les traitements de données. Les workflows de services ont pour fonction d’enchaîner ces pro- grammes les uns après les autres tout en gérant la transmission de données.
Des applications ont été développées autour de BioMoby pour pouvoir enchaîner les ser- vices web. Il y a tout d’abords GBrowse MOBY, développé par les concepteurs de la plate- forme BioMoby [Wil06]. L’application web permet d’exécuter et d’enchaîner des services de type MOBY mais pas de manière automatique. Le projet Rémora [CG06] est également un ap- plication web qui permet la composition de workflow à partir de services MOBY. Le projet a la spécificité de pouvoir sauvegarder les workflows et les partager parmi les utilisateurs. En- fin, Biowep [RBB+07] est une application web qui permet d’exécuter des workflows prédéfinis composés à partir des services MOBY et MyGrid. L’application permet également de soumettre des workflows développés avec un logiciel comme Taverna.
Utilisation de Taverna L’enchaînement de services web peut être réalisé avec un logiciel comme Taverna. Cette application permet aux biologistes ou bioinformaticien de construire, sans grande connaissances en programmation, des analyses complexes sur des ressources pu- bliques ou privées. Initialement conçu dans le cadre du projet MyGrid (voir section6.1.2) le rapprochement des projets MyGrid et BioMoby [LBW+04], permet d’utiliser Taverna pour des services déployés sur l’annuaire central de BioMoby.
FIG. 6.8 – Architecture de l’application intégrée
6.2. Développement d’une application intégrée utilisant des services web
FIG. 6.9 – Illustration du Modèle CGP (extrait de Bruskiewich et al, [BDH+06])
Description du Génération Challenge Programme Le GCP est un consortium international de recherche qui oeuvre pour l’amélioration des plantes utiles aux pays en développement. Le consortium facilite le transfert des avancées technologiques dans les multiples domaines de la biologie vers les pays dépourvus de ressources. Parmi les grands objectifs, l’accent est mis sur l’amélioration des problèmes de résistance des plantes à la sécheresse et aux maladies. Dans ce contexte, le consortium a mis en place une plateforme informatique dont l’objectif, à long terme, est de permettre l’échange d’information et de ressources [BDH+06]. Pour cela, le GCP a modélisé son domaine tout en réutilisant des modèles existant comme Chado pour la génomique [MEC07] et FUGE pour la génomique fonctionnelle [JPS+06]. Comme le montre la figure6.9, de nombreux domaines sont représentés (i.e. génotypage, génomique, cartographie génétiques, géographie). Compte tenu du consensus de l’approche, la réutilisation de tels objets à travers des data types BioMoby déjà réalisés est intéressante pour notre application.
Le choix des Data types a représenté une étude approfondie du modèle GCP63. En effet, le projet GCP contient de multiples classes Java, traduites du modèle de représentation, pour exprimer les données biologiques. Une correspondance des objets du modèle avec les data types Moby a été récemment mise à disposition 64. Nous avons identifié le paquetage illustré en figure6.11comme modèle générique pouvant contenir nos types de données. Trois Data types différents ont été choisis en fonctions de nos besoins :
– l’objet unique GCP_SimpleIdentifier est utilisé pour caractériser les données locus, nom de lignées, localisation chromosomique et domaine protéique (représentation d’un objet GCP_SimpleIdentifier en figure6.6),
– L’objet GCP_Feature est utilisé lorsqu’un service est destiné à renvoyer une collection de plusieurs informations à partir d’une entrée ; par exemple, pour un locus donné, on souhaite renvoyer sa position sur le chromosome, son sens sur le brin, sa fonction. . . – L’objet GCP_Value est un objet hérité de GCP_Feature. Un GCP_Feature peut donc
63Site web du GCP : http ://pantheon.generationcp.org/
64Mapping entre le modèle GCP et le data type BioMoby : http ://pantheon.generationcp.org/moby/
<moby:GCP_Feature moby:id="Os01g10900.1"
moby:namespace="OryGenesDB_Oryza">
<moby:GCP_Value moby:id="pseudochromosome_id" moby:articleName="values">
<moby:String moby:articleName="name">1</moby:String>
</moby:GCP_Value>
<moby:GCP_Value moby:id="start_model" moby:articleName="values">
<moby:String:articleName="name">5811583</moby:String>
</moby:GCP_Value>
<moby:GCP_Value moby:id="end_model" moby:articleName="values">
<moby:String:articleName="name">5816009</moby:String>
</moby:GCP_Value>
<moby:GCP_Value moby:id="strand_tu" moby:articleName="values">
<moby:String moby:articleName="name">-</moby:String>
</moby:GCP_Value>
<moby:GCP_Value moby:id="com_name" moby:articleName="values">
<moby:String moby:articleName="name">ATP binding protein, putative, expressed</moby:String>
</moby:GCP_Value>
<moby:GCP_Value moby:id="feat_name_tu" moby:articleName="values">
<moby:String:articleName="name">12001.t00963</moby:String>
</moby:GCP_Value>
<moby:GCP_Value moby:id="feat_name_model" moby:articleName="values">
<moby:String moby:articleName="name">12001.m07710</moby:String>
</moby:GCP_Value>
</moby:GCP_Feature>
FIG. 6.10 – Description d’un service Web de type BioMoby.
contenir plusieurs GCP_Value, ce qui est utile dans notre cas, car chaque GCP_Value représentera une information (position chromosomique, sens du brin, fonction. . .), toutes rassemblées sous l’autorité d’un seul GCP_Feature (représentatif d’un locus par exemple ; voir figure6.10).
Connexion aux bases de données Pour les services qui effectuent une connexion à des bases de données (e.g. OryGenesDB, Oryza Tag Line, GreenPhylDB) plusieurs moyens sont envisa- gés. Par exemple, une connexion peut être réalisée avec l’API JDBC qui permettra d’encapsuler directement des requêtes SQL dans le service web. Mais il y a également des applications qui permettent de gérer la persistance des objets en bases de données relationnelles. Hibernate65est une application open source qui a ses caractéristiques. Elle permet de créer des objets qui sont connectés à la structure et aux données d’une base de données relationnelle. Hibernate existe en tant que plugin Eclipse66. La création d’objets spécifiques d’une source nécessite la confi- guration de fichiers de configuration (figure6.12) et de mapping (figure6.13). Dans le premier
65Hibernate : http ://www.hibernate.org/
66Eclipse est un environnement de développement intégré open source principalement dédié au développement en Java
6.2. Développement d’une application intégrée utilisant des services web
FIG. 6.11 – Partie du modèle GCP utilisée dans notre application
sont répertoriés les paramètres de connexion, les drivers spécifiques du RDBMS67ainsi que les références vers les fichiers de mapping. La figure6.13représente les correspondances entre les colonnes de la base de données et les attributs des classes. Chaque classe contient un élément identifiant <id> et plusieurs éléments <property>. En plus d’effectuer le mapping ces derniers permettent de typer et contraindre les attributs. Non représenté dans ce cas, les relations entre classes peuvent être représentées dans le fichier de mapping. La figure6.14présente un exemple de requête pouvant être effectuée sur une base de données en utilisant Hibernate. Dans ce cas la requête est effectuée avec la méthode find qui renvoi tous les enregistrements. Par la suite, le code permet de naviguer dans les enregistrements pour n’afficher que le numéro du chromo- some grâce à la méthodegetChromosome(). Un exemple de service web développé est donné en annexeA. Dans la figure 6.4nous pouvons voir comment les différents fichiers sont organisés sur le serveur du fournisseur afin d’exécuter un service web.
<hibernate-configuration>
<session-factory>
<!-- local connection properties -->
<property name="hibernate.connection.url">
jdbc:mysql://valois.cirad.fr/ORYGENESDB_PUBLIC
</property>
<property name="hibernate.connection.driver_class">
org.gjt.mm.mysql.Driver
</property>
<property name="hibernate.connection.username"></property>
<property name="hibernate.connection.password"></property>
<!-- dialect for MySQL -->
<property name="dialect">
net.sf.hibernate.dialect.MySQLDialect
</property>
<property name="hibernate.transaction.factory_class">
net.sf.hibernate.transaction.JDBCTransactionFactory
</property>
<mapping resource="Pseudochromosome.hbm" />
<mapping resource="Dna.hbm" />
</session-factory>
</hibernate-configuration>
FIG. 6.12 – Exemple de fichier hibernate de configuration
Synthèse des services web développés Une liste de 14 services Web a été établie pour ré- pondre aux besoins du projet. Le tableau6.1 détaille, pour chaque service créé et implémenté, la base de données visée (source), les données que prennent en entrée les services (input), ainsi que leur sorties (output). Le termegene reportsignifie qu’une collection de plusieurs informa- tions différentes va être renvoyée. Il correspond aussi aux 8 services Web terminaux, c’est-à-dire ceux qui renvoient des résultats dont les données seront ensuite intégrés dans un seul et même fichier XML.
67RDBMS : relational database management system
6.2. Développement d’une application intégrée utilisant des services web N˚ Nom du service Web Source Entrée (input) Sortie (output)
1 getGeneInfoByGeneId OryGenesDB Gene id(s) Gene report
2 getFSTInfoByGeneId OryGenesDB Gene id(s) Gene report
3 getSwissprotDetailsByGeneId OryGenesDB Gene id(s) Gene report 4 getESTDetailsByGeneId OryGenesDB Gene id(s) Gene report
5 getGeneIdByLocation OryGenesDB Location Gene id(s)
6 getOTLFSTByGeneId OryGenesDB Gene id(s) FST id(s)
7 getGeneIdByGO OryGenesDB Go id ene id(s)
8 getGeneIdByFST OryGenesDB FST id Gene id(s)
9 getPhyloGenomicInformationByGeneId GreenPhyl Gene id(s) Gene report 10 getInterproDetailsByGeneId GreenPhyl Gene id(s) Gene report
11 getGeneIdByInterpro GreenPhyl IPR id Gene id(s)
12 getExpressionByGermplasm OryzaTagLine Germplasm id Gene report 13 getPhenotypeByGermplasm OryzaTagLine Germplasm id Gene report 14 getGermplasmByFST OryzaTagLine Germplasm id FST id(s)
15 getFSTByGermplasm OryzaTagLine FST id Germplasm id
16 getGenesByKo KEGG KO id Gene id(s)
17 getGenesByEnzyme KEGG Enzyme id Gene id(s)
TAB. 6.1 – Liste des services web développés
Développement de clients d’appel des services web Les services web sont des programmes indépendants qui fonctionnent grâce à un serveur web spécifique. Dans notre cas les services ont été installés sur un serveur apache tomcat68 avec axis69 pour pouvoir exécuter les services.
Ces programmes peuvent être invoqués de différentes manières, par exemple avec Dashboard, ou bien enchaînés avec Taverna, Rémora ou GBrowse Moby. Dans notre cas, nous avons inclus ces clients dans une interface web existante qui était réalisée en perl.
La figure6.15représente un exemple de client invoquant le service getGeneIdByLocation.
Le programme fait appel à une API perl spécifique à BioMoby ainsi que des parseurs XML. Les variables MOBY_SERVER et MOBY_URI indiquent l’endroit où se situe le central registry.
Dans ce cas, les services ne sont pas directement enregistrés sur le central registry BioMoby d’origine, mais sur un central du domaine GCP. Ce client effectue plusieurs actions : il recherche un service dont le nom est donné en paramètre(1), en récupère ses paramètres (2), et fait appel au service (4) avec une donnée d’entrée (3). Le client utilise des packages développés dans le cadre du projet BioMoby (5).