La bioinformatique sur grille
La bioinformatique est un champ de recherche multidisciplinaire ó travaillent de concert biologistes, informaticiens, mathématiciens et physiciens, dans le but de résoudre un problème scientifique posé par la biologie Le terme bio-informatique peut également décrire toutes les applications informatiques résultant de ces recherches Cette discipline constitue la ô biologie in-silico ằ , par analogie avec ô in-vitro ằ (dans le verre) ou ô in-vivo ằ (au sein du vivant)
La bioinformatique a pour but de produire de nouvelles connaissances sur le fonctionnement des cellules des organismes vivants, leur évolution, leur état sain ou pathologique Pour faire cela, elle s'est tout d'abord limitée à la “génomique”, qui étudie la structure, le fonctionnement et l'évolution des génomes Mais il est apparu que la représentation de la cellule donnée par la génomique est statique, et ne permet pas de rendre compte de son évolution au cours du temps Ainsi est née la “post-génomique”, qui cherche à savoir quand et dans quelles conditions les gènes vont enclencher la fabrication de protéines, et comment les protéines fabriquées interviennent dans le fonctionnement de la cellule
La consultation et l'enrichissement permanent des bases de données sont au centre du travail des chercheurs En résulte un phénomène de multiplication des informations, de plus en plus nombreuses mais aussi de plus en plus variées Il serait mal venu de s'en plaindre! Cependant, il devient primordial de veiller à ce que la gestion même de ces informations ne soit plus l'étape limitante de cette considérable – et, de ce fait, partiellement exploitée – masse de connaissances potentielles
La bioinformatique hérite donc deux tâches lourdes : [2]
• Élever la vitesse de traitement en utilisant des infrastructures de calcul puissantes ou en concevant de nouveaux algorithmes
• Faire en sorte que les nouvelles données soient structurées et facilement accessibles
Tous les deux besoins peuvent être atteints grâce à l'utilisation de la grille Ce sont des “hyper-ordinateurs” (des grilles de calcul) et des “bases de données distribuées et gigantesques” (des grilles de données)
Une grille est un dispositif logiciel qui offre aux utilisateurs des puissances quasi illimitées de calcul ou de stockage de données, grâce à un accès transparent et facile (une simple connexion à un réseau à très haut débit de type Internet) à un vaste ensemble de ressources informatiques distribuées sur une grande échelle [1]
Les applications bioinformatiques sont de très bons candidats à exécuter dans l'environnement de grille, car elles manipulent un nombre de bases de données génomiques qui sont généralement réparties géographiquement Le défi le plus important ici est de fournir des services bioinformatiques de grille transparents, sécurisés et extensibles Beaucoup d'efforts pour construire les plateformes de calcul utilisant des grilles spécifiées pour la bioinformatique ont été réalisés récemment [3]
Plateforme Bioinformatique de l'équipe PCSV
La couche des Services Bioinformatiques
Cette couche comprend des web services qui correspondent aux applications ou aux simulations bioinformatiques de la platforme (autodock, blast, clustalw, etc)
Ces services sont déployés selon la recommandation technique du projet Embrace (A European Model for Bioinformatics Research and Community Education) [4]
Chaque web service a un ensemble d’opérations pricipales telles que :
• Vérification de l'état d'une tâche
• Récupération du résultat d'une tâche
Figure 1-1 La plateforme d'équipe PCSV
Si nécessaire, un web service peut avoir des opérations suplémentaires Par exemple, pour executer le workflow de découverte de nouveau médicament, le web service d'autodock a en plus l'opération “thresholder” qui teste si l'énérgie d'un docking moleculaire passe un certain seuil
Grâce à ces couches, l'utilisateur peut travailler avec la plateforme à distance Les autres composants de plateforme sont transparents pour les utilisateurs Ils utilisent juste les opérations des services pour soumettre et gérer leurs tâches de simulations, ils ne doivent pas connaợtre en dộtail comment cela se passe L'usage des services est aussi très souple, les utilisateurs peuvent interconnecter des services différents pour créer des workflows bioinformatiques qui comprennent plusieurs simulations
Les composants serveurs de ces services sont écrits en langage Java avec la bibliothèque Axis Ils sont déployés sur le serveur d'équipe.
La couche de gestion
Cette couche peut être divisée en deux modules :
Ces deux modules sont autonomes Ils ne s’échangent pas d’information directement
Les rôles du Task Manager sont :
• Conservation des informations concernant les tâche: o Service : le nom de service bioinformatique qui a soumis la tâche o User : Le nom d'utilisateur qui a soumis la tâche o TaskId : l'identitficateur de la tâche o Arguments : une chaợne de caractốre qui permet à l'utilisateur d’ajouter des informations suplémentaires
Il y a des web services avec lesquels les utilisateurs et les applications peuvent travailler avec le Task Manager :
Les services web ont été écrits en langage C avec la bibliothèque gSOAP La partie serveur est déployée sur le serveur d'équipe Leurs clients sont liés aux applications binaires Ils peuvent être lancés de n'importe ó : depuis le serveur d'équipe, d’une machine à distance, d’un noeud de travail de grille (WN), etc
Basé sur la grille de donnée d'EGEE (Enabling Grids for E-sciencE) [5], ce système est construit avec le catalogue de métadonnée AMGA et le gestionnaire de base de données MySQL Généralement, AMGA est un service de métadonnée pour la grille Il contient les descriptions et les localisations matérielles des fichiers Il permet aux jobs de requeter et de mettre à jour les données stockées sur la grille [7]
Cependant, dans la plateforme d'équipe, le but et l'usage d'AMGA est un peu différent En coordination avec MySQL, AMGA crée une “base de donnée” unique pour stocker tous les schémas concernant les simulations et les tâches Le rôle principal du système est de garder tous les résultats des simulations et d’exécutions des tâches de la plateforme
Il y a des API clientes pour requêter, ajouter et mettre à jour les contenus dans l'Information System Ces API sont écrites en 3 langages : soit C++, soit Java et soit Python Comme les services web du Task Manager, on peut les lancer n'importe ó
Les API de client d'AMGA sont utilisées dans toutes les autres couches de la plateforme : z Dans la couche des Services Bioinformatiques, les API en Java sont intégrées dans les services webs z Dans l'Environnement de Production WISDOM, les API en Python sont utilisées par des agents.
L'Environnement de Production WISDOM
L'Environnement de Production WISDOM (Wide In Silico Docking On Malaria)
[6] a été développé par l'équipe depuis quelques années Au début, il servait à la découverte de médicaments contre la malaria Grâce à l'Environnement de Production Wisdom, les chercheurs peuvent soumettre et gérer des milliers de jobs sur la grille Ces jobs font des millions de simulations de docking moleculaire afin de trouver les ligands qui peuvent se lier à la protéine plasmepsin du parasite de la malaria pour inhiber son action.[8] Maintenant, le but d'utilisation de l'environnement est étendu à plusieurs types de simulations ou d’outils d’analyse bioinformatiques [6]
Les capacités générales de l'environnement sont la création et la gestion les
“agents” qui récupèrent et traitent les tâches En fait, les agents sont des job de grille
Créer les agents Soumettre les jobs sur la grille de calcul Gérer les agents Gérer les états des jobs Comportements d'agent Charges des jobs
Les opérations de la plateforme
Il y a deux opérations pricipales sur la plateforme : soumission des tâches et soumission des agents
• L'utilisateur spécifie les arguments d'entrée d'une tâche et la soumet par le service bioinformatique correspondant
• Le service bioinformatique invoque le client de service web createTask pour créer une nouvelle tâche dans le Task Manager
• Le service web bioinformatique invoque les API de client d'AMGA pour créer une nouvelle entrée dans la table “simulations” de la base de données de l'Information System
• En fonction du service bioinformatique, la sortie est soit l'identificateur de tâche, soit l'identificateur de simulation, soit l'identificateur de projet, etc
Avec un identificateur, l'utilisateur peut vérifier l'état et récupérer les résultats de tâche (ou de simulation, de projet, etc) correspondant
• L'utilisateur spécifie les arguments nécessaires (nombre d’agents, nom d'organisation virtuelle, etc) dans le fichier de configuration d'Environnement de Production WISDOM
• L'utilisateur lance l’Environnement de Production WISDOM
• L'Environnement de Production WISDOM soumet les agents (les grid-job) et gére leurs états
• Chaque agent exécute une boucle infinie avec ces étapes (sur le noeud de la grille de calcul):
• Il utilise le client de service getTask pour récupérer la nouvelle tache auprès du Task Manager Dans cette tâche, il y a aussi l'identificateur de simulation correspondant
• Il utilise l'identificateur de la simulation pour récupérer les informations concernant la simulation Avec ces informations, l'agent peut télécharger les données et les applications nécessaires pour effectuer la simulation
• Il traite les résultats de simulation : o Il stocke les fichiers de sortie sur la grille de données; o Il met à jour l'Information System
• Il effacer la tâche dans le Task Manager si la simulation est réussie
• Il remet la tâche dans la file d'attentte si la simulation est échouée
Puisque chaque agent exécute une boucle infinie, son temps de vie est basé sur la configuration de la grille EGEE Cette durée est généralement de 24 heures
Un agent peut éxecuter plusieurs tâches Cette approche est un hybride entre les deux modes : PUSH (pousser) et PULL (tirer) L'Environnement de Production WISDOM pousse les agents à la grille Les agents tirent les tâches pour les executer.
Interconnexion des services
Actuellement, les utilisateurs doivent invoquer chaque opération de service bioinformatique de faỗon indộpendante Cela veut dire qu’il n'y a pas d'application dans la plateforme qui permet de créer et gérer les interconnexions entre les opérations des services (ces opérations du même service ou des services différents)
Par exemple, si le biologiste veut faire un workflow qui comprend 2 étapes
L'étape 1 utilise la simulation concernant le service A, l'étape 2 utilise la simulation concernant le service B La sortie de l’étape 1 est l'entrée de l'étape 2 Il
• Soumettre la simulation du service A;
• Attendre la fin de cette simulation;
• Récupérer la sortie de cette simulation;
• Soumettre la simulation du service B
Il faut implémenter sur la plateforme une gestion de workflow qui permet de créer l'interconnexion entre les services et l’exộcuter de faỗon automatique
Chapitre-2 Gestion de workflow sur la plateforme
Objectifs
Actuellement, il manque une gestion de workflow sur la plateforme Pour executer des workflows qui comprenent plusieurs étapes successives à réaliser, il y a deux manières de procéder :
• Utiliser les services bioinformatiques : Il faut lancer les opérations des services bioinformatiques les unes après les autres (cf la partie
“interconnexion des services ằ dans le chapitre prộcộdent)
• Travailler directement avec la couche de gestion : l'utilisateur écrit un script qui comprend toutes les étapes du workflow et le soumet directement au Task Manager Toutes les étapes sont emballées dans une tâche unique
C'est néanmoins plus difficile d’observer l'avancement de chaque étape et ce n'est pas souple
Pour résoudre ce problème au moyen de la plateforme, on doit utiliser un gestionnaire de workflow pour gérer les interconnexions entres les opérations des services Il y a deux avantages à cette solution :
• Souplesse : Les utilisateurs peuvent créer n'importe quel workflow celui-ci est interprété par le gestionnaire et executé au fur et à mesure
• Simplicité : Le worflow exécuté sur la grille est très proche du workflow utilisateur
Figure 2-1: La souplesse de créer les workflow en interconnectant des services
Une autre raison de l’implémentation d'un gestionnaire de workflow sur la plateforme est la participation de l'équipe PCSV au projet ANR GWENDIA [9]
(Grid Workflow Efficient Enacment for Data Intensive Applications) GWENDIA vise à fournir des systèmes de gestion de workflow efficaces afin de manipuler et de traiter de grandes quantités de données scientifiques sur des infrastructures à grande échelle telles que les grilles de calcul Le rôle de l'équipe dans ce projet est de créer un workflow qui permet la découverte de nouveaux médicaments de faỗon in-vitro (Drug Discovery Workflow)
Grâce à la participation au projet GWENDIA, le moteur de workflow, choisi par l'équipe pour intégrer sur la plateforme, est MOTEUR C'est un logiciel développé par l'équipe RAINBOW, qui participe également au projet MOTEUR est optimisé pour traiter efficacement des applications manipulant de grandes masses de données sur des infrastructures de grille
Figure 2-2 : L'utilisation de moteur de workflow avec la flatforme
Sculf - un langage de spécification de workflow
Scufl (Simple Conceptual Unified Flow Language) est un langage orienté flux de données (data-flow oriented language) qui essentiellement décrit le pineline d'une application.[10] Les participants des workflow Scufl sont les processeurs
Beaucoup d'entre eux sont spécifiés, par exemple :
• String constants : processeurs qui sont activés seulement une fois dont la sortie est une chaợne des caractốres constante
• web service : des processeurs qui peuvent invoquer une opération d'un service web
• Beanshells : des processeurs qui peuvent exécuter une pièce de code de Java
• Source : des processeurs qui représentent des entrées de workflows
• Sink : des processeurs qui représentent des sorties de workflows
Chacun d'eux peut contenir quelques segments de données que le workflow doit traiter de faỗon interactive Leurs contenus ne sont pas spộcifiộs à l'intộrieur du document Scufl : ils sont indépendants de la description du workflow et ne sont connus que lors de l'exécution
Les processeurs Scufl ont des ports d'entrée et des ports de sortie qui peuvent contenir plusieurs éléments de données Les ports se relient avec des liaisons de données Une liaison de donnée est juste un tuyau (pipe) entre le port de sortie d'un processeur et le port d'entrée d'un autre Un port de sortie peut être connecté à plusieurs ports d'entrée Dans ce cas, les données sont diffusées à tous les ports d'entrée connectés De même, plusieurs ports de sortie peuvent être connectés à un seul port d'entrée Dans ce cas, les données sont mises dans le tampon d'entrée selon leurs ordres d'arrivée Le workflow est complètement conduit par la présence ou l'absence de données dans les ports d'entrée d'un processeur Un processeur est activé si et seulement si tous ses ports contiennent des données adéquates Il n'est pas possible de définir des variables dans Scufl
Les opérateurs de composition permettent de définir les stratégies d’itération entre les ports d'entrée d'un processeur Ces stratégies sont utilisées pour contrôler la faỗon dont plusieurs ộlộments de donnộes sont combinộs à l'intộrieur des ports d'entrée
Il y a deux opérateurs de composition “dot” et “cross” z Dot : c'est un opérateur “un-à-un” qui traite chaque élément de données de la première série avec l'autre élément correspondant de la deuxième série selon l'ordre de leur définition z Cross : c'est un opérateur “tout-à-tout” qui traite tous les éléménts de données de la première série avec tous les éléments de données de la deuxième série
Figure 2-3 L'opérateur "dot" et l'opérateur "cross"
Le moteur de workflow MOTEUR
Introduction
MOTEUR (home-Made OpTimisEd scUfl enactoR) est un moteur de workflow qui est développé par l'équipe RAINBOW du laboratoire I3S, Polytech Nice-Sophia.[11] Les fonctions principales de MOTEUR sont d’interpréter et d'exécuter des workflow écrits en langage Sculf MOTEUR exploite plusieurs niveaux de parallélisme et groupe les tâches à réaliser pour réduire le temps d'éxecution des applications De plus, MOTEUR utilise un service web générique d'encapsulation pour faciliter la réutilisation de codes développés sans prise en compte des spécificités des grilles de calcul.
Fichier de workflow
Pour mettre en oeuvre un workflow, on doit spécifier :
• Les processeurs avec leurs ports
• Les compositions entres les ports d'un processeur
• Les liaisons entre les ports des processeurs
Tous les informations dessus sont décrites en utilisant les tags XML et sont stockées dans un fichier texte L'ensemble des tags utilisé par MOTEUR n'est pas complexe mais efficace pour que les utilisateurs puissent facilement spécifier des workflows
Actuellement, MOTEUR n'a pas d'outil particulier pour la spécification des workflows Les utilisateurs peuvent utiliser n'importe quel éditeur de texte (vim, nano, screems, etc) pour écrire le workflow selon le standard XML en utilisant les tags et le format défini par MOTEUR
Par exemple, ci-dessous c'est un workflow simple qui fait la somme des deux chiffres :
Il y a 4 processeurs dans ce workflow : deux sources, un Beanshell et un sink
(Integer.parseInt(int0)+Integer.parseInt(int1)).toString();
int0
int1
result
Fichier de données
Le fichier de données est écrit aussi comme un fichier de texte selon le standard XML Il y a trois tags définis pour spécifier le nom des sources et la valeur des éléments des données
Par exemple, le fichier des données du workflow au-dessus est comme suit:
La capacité de parallélisme des services et de parallélisme des données 25
• Parallélisme des services : MOTEUR peut lancer les processeurs indépendants simultanément
• Parallélisme des données : MOTEUR peut traiter simultanément les éléments de donnée des ports d’un processeur Quand cette capacité de MOTEUR est activée, MOTEUR va créer plusieurs instances de processeur pour qu’il puisse traiter les données simultanément.
MOTEUR et la grille
Pour travailler avec la grille de calcul, l'équipe RAINBOW développe un service web nommé GASW (Generic Application Service Wrapper) Grâce à la fonction GASWexecution de ce service, MOTEUR peut soumettre et gérer les états des jobs sur la grille En utilisant l'interface JNI (Java Native Interface), tous les cotés client et serveur de GASW sont intégrés à MOTEUR
MOTEUR peut travailler avec 2 grille : EGEE et Grid5000
http://egee1.unice.fr/gasw_service.wsdl
Avec les ports de ce service, l'utilisateur peut spécifier les arguments pour le job et récupérer leurs sorties Par exemple, pour le job de la grille EGEE; on doit spộcifier : le fichier d'ộxecution, les entrộes des ô sandboxes ằ, etc) Tous ces arguments sont mis dans le fichier de description C'est aussi un port de service:
Ci-dessous, c’est un exemple d’un fichier de description concernant un job qui exécute le script CreateTask.sh :
Le workflow de Découverte de Médicament d'équipe
Le workflow de découverte de médicament de l'équipe PCSV se base notamment sur la simulation de docking moleculaire Docking, c'est une méthode de prédiction de la meilleure orientation d'une molécule à une seconde lorsqu’elles sont liées l’une à l’autre pour former un complexe stable [12]
Figure 2-6 : L'idée principale de docking moleculaire
Le docking est fréquemment utilisé pour prédire l’orientation de la liaison entre une petite molécule à une plus grande (la cible) Pour la découverte de nouveaux médicaments, les petites molecules sont appelées ligand et la molécule cible est généralement une protéine.[12]
Figure 2-7: Le ligand lie avec le protéine
Les arguments d'entrée d'une simulation de docking sont [13]
• Le fichier description de ligand
• Le fichier description de target
• La meilleure conformation de ligand
• L'énergie moyenne qui est consommée pour créer la liaison Car c'est l'énergie de consommation, sa valeur est négative La stabilité de liaison est inversement proportionnelle à la valeur d'énergie moyenne À propos de découverte de médicament, le docking nous permet de cribler un grand nombre de ligands pour trouver ceux qui peuvent se lier à et inhiber une proteine importante du virus, du parasite, etc Par exemple, pour trouver un médicament contre la malaria, on peut faire le docking pour trouver le ligand qui peut inhiber la protéine plasmepsin Si la plasmepsin est inhibée, le parasite de la malaria ne peut pas attaquer les globules rouges du sang.[8]
Il y a plusieurs logiciels de docking: Dock, Autodock, Flexx L'équipe utilise la version 3.1 d'Autodock
Généralement, le workflow de découverte de médicament de l'équipe se base sur 2 phases de simulation de docking :
• Étape 1 (Phase 1 de docking) Faire le docking entre un ligand et une protéine cible Les entrées sont l'énergie moyenne et la meilleure conformation du ligand Avec la meilleure conformation, on peut créer le meilleur fichier description de ligand On l'appelle “nouveau ligand”
• Étape 2 (Thresholder) comparer l'energie moyenne de phase 1 avec un seuil Si l'énergie est inférieur au seuil, la liaison est stable et on passe à phase 2 Sinon, on s'arrête
• Étape 3 (Phase 2 de docking) : Faire le docking entre le nouveau ligand et la même protéine
Chapitre-3 Implémentation d’un gestionnaire de workflow sur la plateforme
Objectif
La plateforme de l'équipe permet l'utilisation d'environnement de grille par deux types d'utilisateurs:
• Les biologistes qui utilisent les services bioinformatiques pour soumettre des tâches de simulations qui seront exécutées sur la grille Les biologistes ne doivent pas avoir le certificat pour utiliser la grille Ils ne doivent qu'avoir le droit d'utiliser les services de la plateforme
• Les administrateurs de la plateforme qui lance l'Environnement de Production WISDOM pour soumettre des agents qui executent des tâches sur la grille
La soumission des tâches et la soumission des agents sont indépendantes, c'est mieux de créer 2 workflows séparés :
Le workflow de soumission des tâches : TaskSubmision Le but général de ce workflow est de mettre en oeuvre l'interconnexion des services de faỗon automatique Les opérations du service qui sont invoquées dans chaque étape de workflow peuvent être soit la soumission des tâches soit la fonction supplémentaire (tester la fin d'une tâche, récupérer les résultats, etc) Cependant, dans le cadre de ce stage, le workflow TaskSubmision est spécifique à la création d’un workflow de découverte de médicament pour le projet GWENDIA
Figure 3-1:L’opération du workflow Découverte de Médicament
Le workflow de soumission des agents : AgentSubmission Le but général de ce workflow est de mettre en oeuvre un environnement de production Ce workflow a deux fonctions : soumettre des agents et les gérer
Figure 3-2 : Les étapes du workflow de soumission des agents
Les deux workflows sont lancés et gérés par MOTEUR
On peut utiliser le workflow de TaskSubmision avec soit l'Environnement de Production WISDOM soit le workflow AgentSubmission Dans le cadre de ce stage, AgentSubmission est utilisé avec la couche des Services Bioinformatiques et la couche de Gestion pour créer une nouvelle plateforme pour le projet GWENDIA
Figure 3-3 Le workflow de soumission des agents fait le rôle d’environnement de production de flatforme
Problèmes
Lecture du fichier de description des services bioinformatiques
Tous les fichier de description (WSDL) des services bioinformatiques de l'équipe sont écrits en type "Document/Litteral Wrapped" (Document/Littéral emballé, doc/lit wrapped) En fait, ce type est le plus avancé et est la manière la plus populaire d'écrire un fichier WSDL [14] les caractéristiques de base du type “document/litteral wrapped” sont les suivantes :
• Chaque message d'entrée a une seule partie
• La partie est un élément
• L'élément a le même nom que l'opération
• L’élément de type complexe n’a pas d'attributs non Wrapped Wrapped
Table 2 : Comparaison de la description d'un message entre le type emballé et le type non-emballé
Jusqu'à maintenant, MOTEUR a déjà été testé avec les services web dont les descriptions sont écrites en type de “non wrapped” En type de “wrapped”, tous les messages d'entrée et de sortie ont toujours une seule partie, ceci provoque deux difficultés pour MOTEUR:
• Si on utilise le processeur avec un seul port d'entrée et un seul port de sortie, comment peut-on préciser le fichier de données, comment peut-on créer la composition entre les ports d'entrée du processeur?
• Si on utilise le format traditionnel du fichier de workflow, la version actuelle de MOTEUR ne peut pas lire exactement les paramètres d'entrée
Il faut améliorer la version actuelle de MOTEUR pour qu’il puisse invoquer les services web décrits par tout type de WSDL.
Le problème avec la plateforme actuelle
Dans la plateforme actuelle, il y a un service préexistant nommé “docking” pour la simulation d'Autodock Cependant, ce service n'est pas convenable pour être utilisé directement pour mettre en oeuvre le workflow de découverte de nouveaux médicaments avec deux phases d'Autodock Ce service est spécifié pour soumettre plusieurs tâches de simulation d'Autodock Il n'a pas l'opération pour faire la comparaison entre l'énergie moyenne et un seuil (thresholder)
Ce n'est pas possible de vérifier ou d’améliorer ce service car les changements vont causer des conflits avec son utilisation actuelle dans la plateforme Donc, il faut développer un nouveau service bioinformatique nommé “docking_wf” qui est spécialisé pour la création de workflow dans GWENDIA.
Amélioration de MOTEUR pour traiter les web services “doc/lit wrapped”
L'Amélioration de MOTEUR
La version actuelle de MOTEUR identifie le nombre, les noms et les types de ports de chaque processeur en utilisant la méthode org.apache.axis.wsdl.symbolTable.Parameter::getQName().getLocalPart()
Avec le type "non wrapped", ỗa marche Neanmoins, avec ceux en type
“wrapped”, le nom de la partie de chaque message n'est pas égal aux noms des éléments que nous utilisons comme les ports de chaque processeur de MOTEUR
Pour résoudre ce problème, il faut remplacer la méthode ci-dessus par la méthode : org.apache.axis.wsdl.symbolTable.Parameter::getName ()
Cette mộthode permet à MOTEUR de reconnaợtre exactement les nombres et les noms des sous éléments dans chaque partie de message
Par rapport à la version originale (version 080417), il faut modifier les 3 méthodes de la classe DynamicInvoker
3.3.2 Examiner la possibilité d'utiliser les formats des fichiers de workflow et des fichiers de données avec la nouvelle version de MOTEUR
3.3.2.1 Les formats des fichiers de workflow
Le format actuel de fichier de workflow de MOTEUR est efficace, il ne faut ajouter ni tag, ni propriété Il n'y a qu'une seule note que l'utilisateur doit préciser à propos de l'entrée et de la sortie des ports du processeur pour lire manuellement le fichier WSDL Le nombre, les noms et les types de ports d'entrée sont les mêmes avec des sous éléments dans les éléments correspondant à l'opération (voir la 3 e caractère de type “doc/lit wrapped” ci-dessus)
Par exemple, le processeur correspondant à l'opération submitOneDocking dispose de 3 ports d'entrée:
• request : type complexe (tns: inputType)
• path : type de base (xsd: string)
• project_id : type de base (xsd: string)
= eval, retourner "MOTEUR_VOID" au squelette.
Mise en oeuvre du workflow TaskSubmision
Le processeur submitDocking
Ce processeur invoque l’opération submitDocking Il dispose de 4 ports d'entrée: ligand_id, target_id, project_id et l'utilisateur Il a seulement 1 port de sortie qui est l'identificateur de la simulation présentée.
Le processeur isFinished
Ce processeur invoque l'opération ifFinished Il a seulement 1 port d'entrée: simulationId et 1 port de sortie qui est le rộsultat (ôfalseằ ou simulationId).
Le processeur thresholder
Ce processeur invoque l’opération submitDocking Il dispose de 2 ports d'entrée:
“simulationId” et “eval” Il y a seulement 1 port de sortie qui est le résultat ("MOTEUR_VOID" ou la ligand_id de celui qui l'a créé au cours de la phase 1)
Figure 3-5 : Le workflow de soumission des tâches spécifié pour le Découverte de Médicament
Le problème d'interconnexion des processeurs
Il a besoin d'invoquer l'opération isFinished après chaque intervalle de temps jusqu'à ce que la tâche correspondante soit finie Dans la version actuelle de MOTEUR, il n'y a pas exactement de type de processeur qui permet de faire comme ỗa Il n'y a qu’un type de processeur qui est un peu similaire: GASW Mais les processeurs GASW sont spécialisés pour la vérification des états des jobs À cause de la limite de la durée du stage, actuellement, les processeurs ne sont que testộs de faỗons isolộes On ne pourra que mettre en oeuvre le workflow de soumission des tâches complet après ce type de processeur aurait créé.
Le workflow AgentSubmission
Conception de workflow
Il n'y a qu'un seul processeur dans ce workflow nommé AgentSubmission avec 3 ports d'entrée et 1 port de sortie Les noms et les rôles de chaque port sont les suivants:
2 input1 Nom d'élément de stockage de la grille de donnée (SE)
3 input2 Nom d'organisation virtuelle de la grille (VO)
4 result le nom d'un fichier texte qui est le fichier de log d'exécution d'agent
Table 5 : Les entrées du processeur AgentSubmission de workflow
Le fichier exécutable de ce processeur nommé AgentSubmission.sh
Il y a 2 entrộes pour la boợte de sable (sand box) de ce processeur:
• jobAgent_wf.sh: il est le script correspondant à toutes les étapes d'exécution d'un agent pendant son temps de vivre (égal à la durée que le grid-job correspondant est gardé dans le noeud de travail (worker node) de la grille de calcul)
• scripts.tar.gz: cette archive se compose de tous les fichiers binaires des côtés client des services web qui travaillent avec les Task Manger (getTask, deleteTask, setTaskWating, etc)
Tous ces 2 fichiers sont conservés dans le serveur egee1.unice.fr MOTEUR pouvez les télécharger avec ces chemins:
• http://egee1.unice.fr/dd/jobAgent_wf.sh
• http://egee1.unice.fr/dd/scripts.tar.gz Ainsi, le fichier de description XML de ce processeur est :
Le fichier de workflow
Car il y a seulement un processeur dans le workflow, le fichier de workflow est très simple
Le premier est utilisé pour lancer l'opération GASWexecution Le second est simplement une chaợne de caractốres constante qui spộcifie l'adresse du descripteur de fichier de service web GASWexecution En fait, lorsque nous lanỗons ce workflow, il n'y a que la figure AgentSubmission processus dans l'interface car la AgentSubmission_Descriptor est une constante
Il y a 3 processeurs de source nommé: JobNumber, SE et VO correspondant aux 3 entrées du port de la AgentSubmission processeur
Il n'y a qu'un seul processeur de sink nommé résultat qui est le nom du fichier de sortie Notez que le fichier de sortie est stocké dans l'élément de stockage de Biomed, nous pouvons copier à l'aide de commande lcg-cp
http://egee1.unice.fr/dd/AgentSubmission_Descriptor.xml
Service definition of function ns GASWexecution
http://egee1.unice.fr/gasw_service.wsdl
Le fichier de données
La forme du fichier de données est comme suit :
cirigridse01.univ-bpclermont.fr
Dans ces 3 sources ci-dessus, la valeur de la SE et de la VO sont des constantes
Le nombre des "" de la source JobNumber indique le nombre des agents qui seront lancés simultanément dans la grille (grâce à la capacité de parallélisme de données de MOTEUR).
Les scripts utilisés par le workflow
• jobAgent_wf.sh: le script qui correspond à l'opération de chaque agent
• docking_wf.sh: le script qui correspond à la simulation (dans ce cas, c'est Autodock)
3.6.4.1 Le script correspond à l'opération de chaque agent : jobAgent_wf.sh
Le lien vers ce script afin MOTEUR peut l'obtenir: http://egee1.unice.fr/dd/jobAgent_wf.sh
Ce script exécute une boucle indéfinie Après la commande getTask obtient les informations nécessaires du TaskManger, il invoque le service (service).sh (dans ce cas, il est: docking_wf.sh) Basé sur l'état d'exécution de ce service (réussite ou échoué), la tâche correspondante sera effacée ou sera remise à la file d'attente Ce script est exécuté dans tous les temps de vie de chaque agent jobAgent_wf.sh utilise 3 paramètres:
• $ 1: pour créer les jobName avec la forme: MOTEUR_J $ 1
• $ 2: nom d'élément de storage (SE)
# $4 JOB RETRY COUNT, not used in this file
# job=MOTEUR_J$1 se=$2 vo=$3 tar -zxf scripts.tar.gz mv scripts/* chmod -R 755 * while [ true ] do task=`./getTask -j $1 -f docking_wf -c docking_wf` taskArray=(`echo $task`) service=${taskArray[1]} user=${taskArray[3]} taskId=${taskArray[5]} arguments=`echo $task | awk '{print substr($0, index($0,$8)) }'` taskName=`echo $service.$user.$taskId` echo $taskName echo service user taskId arguments echo $service $user $taskId $arguments if [ ! $service = "none" ] then isDeployed=0 if [ -e service ] then cd service if [ -e $service ] then isDeployed=1 fi cd fi if [ $isDeployed -eq 0 ] then if [ -e service ] then rm -rf service fi mkdir service # Copy the autodock archive here from Storage Element lcg-cp vo $vo lfn:DDMoteur/services/${service}.tar.gz file:`pwd`/${service}.tar.gz tar -xzf $service.tar.gz chmod -R 755 * mv $service service/ fi cd service/$service if [ $? -eq 0 ] then
/usr/bin/time -p -o time.txt /$service.sh $job $se $vo $user $taskId
/deleteTask $job else echo failure cd /
/setTaskWaiting $job fi else echo failure /setTaskWaiting $job fi else echo no task fi done
3.6.4.2 Le script corespond à la simulation
Ce script est enregistré dans le paquet compressé docking_wf.tar.gz Il est stocké dans la grille de données avec le chemin logique : lfn:DDMoteur/services/docking_wf.tar.gz
Ce script est modifié du script ancien de l'équipe:
1 Travailler avec la grille de données au lieu d'un répertoire dans le serveur d'équipe
Utiliser la chemin lfn:DDMoteur au lieu de ftp://osguser:fAHb5lt9@amga02.lpc-rd.fr
2 Créer et stocker le nouveau ligand basé sur le résultat de simulation autodock
Ajouter les nouvelles commandes dans le script
3 Ajouter la nouvelle entrée dans la base de données de l'Information System Écrire une novelle application en Python : ligand_insert.py Cette application est invoquée dans ce script pour ajouter une nouvelle entrée avec les trois attributs : name, pdbq_file et src à la table “ligand” de l'Information System
L'attribut src est la chemin à l'entrée correspondante dans la table “simulation” qui a déjà créé ce nouveau ligand
Table 6 : Les changements par rapport à la version actulle du script correspondant à la simulation d’Autodock
En détail sur les étapes de ce script, on peut voir l'annexe-1
3.6.4.3 Le script utilisé comme le fichier d'exécuter dans le fichier de description du grid-job
Le script jobAgent_wf.sh peut être utilisé directement comme le “fichier d'exécuter” dans le fichier de description du grid-job Cependant, pour adapter avec MOTEUR, il faut changer un peu sur la liste des paramètres Donc, on utilise un autre script nommé AgentSubmission.sh pour invoquer le script jobAgent_wf.sh
AgentSubmission.sh est utilisé comme le fichier d'exécution du grid-job La commande pour lancer ce script est :
./AgenSubmission -jobNumber number -SE se -vo VO -f result
Donc, la valeur de jobNumber est $2, la valeur de SE est $4 et la valeur de VO est
/AgenSubmission -jobNumber 1 -SE cirigridse01.univ-bpclermont.fr
Le script est très simple :
#!/bin/bash /jobAgent_wf.sh $2 $4 $6 > tmp mv tmp $8
Après avoir amélioré, la nouvelle version de MOTEUR peut invoquer les opérations des services d'équipe MOTEUR est aussi utilisé pour tester le service docking_wf et les processeurs dans le workflow de TaskSubmission Le workflow de AgentSubmission est aussi testé sur la grille de calcul EGEE
Ces résultats ont été présentés dans la session du poster et de la démonstration, dans la conférence d'EGEE 2008, Istanbul, Turquie.
Tester l'amélioration de MOTEUR
La version ancienne de MOTEUR marche bien avec les services dont les fichiers de description sont écrits en type “rpc/encoded” Les types des ports sont soit le type de base soit le type complexe
Après l'amélioration, la version actuelle de MOTEUR est réussie de tester avec les services dont les fichiers de description sont écrits en tous les deux types
“rpc/encoded” et “document/litteral wrapped” Les types des ports sont aussi soit le type de base soit le type complexe
La nouvelle version de MOTEUR est aussi testée avec quelques workflows préexistants de l'équipe RAINBOW Elle peut les lancer bien, n’a pas besoin de modifier ces workflows.
Évaluation le service docking_wf
Le service docking_wf est déployé sur le serveur d'équipe On peut l'utiliser avec l'adresse http://amga02.lpc-rd.fr:8080/axis2/services/docking_wf?wsdlToutes les opérations de service (submitdocking, isFinished et thresholder) sont testées en utilisant MOTEUR Pour chaque opération, il y a un workflow de test :
Workflow de test Opération correspondante
1 submitTest_wf submitDocking Ce workflow dispose de 4 sources dont les noms sont ligand_id, target_id, project_id et user
Le sink de ce workflow est l'identificateur de la nouvelle simulation
2 isFinishedTest_wf isFinished Ce workflow dispose 1 source dont le nom est simulationId
Dépendre sur l'état de l'exécution de la simulation, la valeur du sink de ce workflow est soit “false” soit l'identificateur de la simulation
3 thresholderTest_wf thresholder Ce workflow dispose de 2 sources dont les noms sont simulationId et eval
Dépendre sur la comparaison entre l'énergie moyenne et le seuil, la valeur de sink est soit
“MOTEUR_VOID” ou l'identificateur de nouveau ligand
Table 7 : :La liste des workflow de test du workflow TaskSubmission
Tous ces workflows sont testés avec succès En regardant la valeur du sink, on peut vérifier la marche de chaque opération.
Évaluation deux workflows TaskSubmision et AgentSubmision
À ce moment, le workflow de soumission des tâches (TaskSubmision) n'est pas complet On ne peut pas lancer le workflow AgentSubmission simultanément avec les processeurs du workflow TaskSubmission Mais, on peut les tester l'un après autre
L’entrée Comme vérifier la marche
• Observer le Task Manager pour vérifier la création des nouvelles tâches
• Observer le Information System pour vérifier la création des nouvelles simulations
2 AgentSubmission jobNumber = 20, pour soumettre 20 agents sur la grille EGEE
• Observer l'interface graphique de MOTEUR pour vérifier les états des agents
• Observer le TaskManager pour vérifier si les tâches sont exécutées
• Observer l'Information System pour vérifier les mises à jour identificateurs des
30 simulations soumises avant l'interface graphique de MOTEUR et la liste d'entrées de la table
4 thresholderTest_wf La liste des identificateurs des
Comparer les valeurs du sink dans l'interface graphique de MOTEUR avec
• les valeurs d'attributs mean_energy dans la table
• les valeurs d'attributs src dans la table ligand
Table 8 : Les étapes des tests des deux workflows
Le workflow AgentSubmission et les workflows de test des processeurs du workflow TaskSubmission sont testés avec succès En détail, on peut voir l'annexe-2
Conclusion
Mon sujet de mémoire de fin d'étude concerne l'intégration du moteur de workflow MOTEUR sur l'environnement de grille en l'implémentant sur la plateforme d'équipe PCSV MOTEUR est amélioré pour que il puisse invoquer les services bioinformatiques d'équipe Les deux workflows de soumission des tâches et de soumission des agents sont mis en oeuvre En consultant les services bioinformatiques développés pour le projet Embrace, le service docking_wf est déployé sur la plateforme pour créer le workflow de découverte de médicament pour le projet GWENDIA.
Perspectives
Il faut ajouter à la version actuelle de MOTEUR une nouvelle classe des processeurs qui invoquent une opération de service après chaque intervalle du temps Ces processeurs sont utilisés pour vérifier si une tâche est finie dans le workflow de soumission des tâches Puis que cette classe de processeurs est créée, on pourra finir la mise en oeuvre du workflow TaskSumission
On peut aussi modifier l’interconnexion des services pour créer les autres workflows bioinformatiques, pas seulement le workflow de découverte de médicaments
Actuellement, deux fonctions de soumettre et de gérer des agents se basent sur la capacité du processeur GASW de MOTEUR Donc, ce workflow peut seulement gérer les états des agents comme les grid-job Un agent est resoumis quand il y a des erreurs dans le noeud de travail (worker node) de la grille Mais, il a besoin d'améliorer ce workflow pour que il puisse resoumettre les agents selon le nombre des tâches dans la plateforme
Après les deux améliorations au dessus sont finies, on peut entrer à la phase de production avec très grand nombre des tâches et des agents
[1] IN2P3, CNRS, “Grille de calcul : l'internet du calcul intensif” , http://www.in2p3.fr/presentation/thematiques/grille/grille.htm
[2] Interstices, Découvrir la Recherche en Informatique, “Entre biologie, informatique et mathématiques : la bioinformatique” , 03/2004, http://interstices.info/jcms/c_6607/entre-biologie-informatique-et-mathematiques- la-bioinformatique
[3] El-Ghazali Talbi, Albert Y Zomaya, “Grid Computing for Bioinformatics and Computational Biology”, 2008, John Wiley & Sons, Inc, ISBN 978-0-471- 78409-8
[4] The EMBRACE project, “Partner Details, Vincent Breton” , http://www.embracegrid.org/page.php?page=person&pid7
[5] Portal d'EGEE (Enabling Grids for E-sciencE), http://www.eu-egee.org/
[6] LPC Clermont-Ferrand, © 2006 , “WISDOM - Initiative for grid-enabled drug discovery against neglected and emergent diseases”, http://wisdom.eu-egee.fr/
[7] ARDA project, “Amga – Overview” , 2008, http://amga.web.cern.ch/amga/
[8] Danielle Venton, “WISDOM unplugged: malaria drug-leads graduate to the wet lab” , 05/2008 iSGTW – Internal Science Grid This Week, http://www.isgtw.org/?pid00993
[9] GWENDIA WikiSite, http://gwendia.polytech.unice.fr/doku.php
[10] Tristan Glatard, “Description, deployment and optimization of medical image analysis work fl ows on production grids” , mémoire de thèse au niveau Docteur en Science, novembre 2007 Université de Nice Sophia-Antipolis
[11] Site web de MOTEUR, http://www.i3s.unice.fr/~johan/
[12] Wikipedia, 09/2008, “ Docking Molecular ,” http://en.wikipedia.org/wiki/Docking_(molecular)
[13] Site web d'Autodock, http://autodock.scripps.edu/
[14] Russell Butek, “Which style of WSDL should I use?” , 10/2003, http://www.ibm.com/developerworks/webservices/library/ws-whichwsdl/
Les étapes du script docking_wf.sh 61 Annexe 2 Les résultats de tester deux workflow : TaskSubmision et
1 Assigner les valeur aux variables et l'argument d'environnement
Notez qu’au début de ce script, il y a une commande qui décompresse l'archive autodock.tar.bz2 C'est une archive qui compose tous les application de la simulation autodock Elle est stockée dans l'archive docking_wf.tar.gz qui est copié précédement par le script jobAgent_wf.sh
SE=$2 VO=$3 tar -jxf autodock.tar.bz2 export AUTODOCK_UTI= export LD_LIBRARY_PATH=$LD_LIBRARY_PATH:./libstdc++-libc6.1-2.so.3 ulimit -s unlimited
2 Obtenir les informations correspondantes à : z fichier des paramètres z ligand z cible (la protéine) de l'Information System et les télécharger au répertoire actuel
# get the parameters files from the database project_id=`./getAttr_query.py /moteur/testMoteurDD/results/autodock/simulation/entry_$i project_id` tmp=`./selectAttr_query.py
"/moteur/testMoteurDD/results/autodock/project:project_id =
/moteur/testMoteurDD/results/autodock/project:program_options` software=`echo $tmp | tr '|' ' ' | awk '{print $1}' | tr '/' ' ' | awk '{print $NF}'` echo software = $software # download the parameters file from the lfn lcg-cp vo $VO lfn:${software} file:`pwd`/dpf3gen.awk
# get the information about the ligand and target ligand_id=`./getAttr_query.py
/moteur/testMoteurDD/results/autodock/simulation/entry_$i ligand_id` echo ligand_id = $ligand_id ligandSearchResults=`./getAttr_query.py /moteur/testMoteurDD/results/autodock/ligands/entry_${ligand_id} name pdbq_file` ligand=`echo $ligandSearchResults | awk '{print $1}'` ligandName=`basename $ligand pdbq` target_id=`./getAttr_query.py /moteur/testMoteurDD/results/autodock/simulation/entry_$i target_id` targetSearchResults=`./getAttr_query.py /moteur/testMoteurDD/results/autodock/target/entry_${target_id} name pdbqs` target=`echo $targetSearchResults | awk '{print $1}'` echo target = $target echo ligand = $ligand # download the target if [ ! -e ${target}.tar.gz ] then lcg-cp vo $VO lfn:DDMoteur/targets/${target}.tar.gz file:`pwd`/${target}.tar.gz tar -zxf ${target}.tar.gz fi
# download the ligand from the lfn if [ ! -e ${ligand} ] then lcg-cp vo $VO lfn:DDMoteur/ligands/${ligand}.pdbq file:`pwd`/${ligand}.pdbq fi
3 Faire le docking et vérifier le résultat
$AUTODOCK_UTI/mkdpf3 ${ligand}.pdbq ${target}.pdbqs $AUTODOCK_UTI/autodock3 -p ${ligandName}.${target}.dpf -l
${ligand}_${target}_$i.dlg if grep "autodock3: Successful Completion" ${ligand}_${target}_$i.dlg then echo "-successful autodock run of ${ligand} with ${target}: valid echo "-unsuccessful autodock run with ${i} either dlg was not found, either autodock did not run" exit 1 fi
4 Créer le nouveau ligand et le stocker dans l'élément de storage, mettre à jour l'Information System
# create the new ligand and store it on the lfn
/get_best_docking.sh ${ligand}_${target}_$i.dlg lcg-del vo $VO -a lfn:DDMoteur/ligands/${ligand}_${target}_$i.pdbq lcg-cr -v vo $VO -d $SE -l lfn:DDMoteur/ligands/${ligand}_${target}_$i.pdbq file:`pwd`/${ligand}_${target}_$i.pdbq
/ligand_insert.py ${ligand}_${target}_$i.pdbq DDMoteur/ligands/${ligand}_${target}_$i.pdbq /moteur/testMoteurDD/results/autodock/simulation/entry_$i
3.5 Compresser et stocker le fichier dlg dans l'élément de storage et mettre à jour l'Information System
#zip and store dlg file gzip `pwd`/${ligand}_${target}_$i.dlg dlg_fileoteur/dlgs/${ligand}_${target}_$i.dlg.gz echo dlg_file = ${dlg_file} lcg-del vo $VO -a lfn:${dlg_file} lcg-cr -v vo $VO -d $SE -l lfn:${dlg_file} file:`pwd`/${ligand}_${target}_$i.dlg.gz /setAttr_query.py
/moteur/testMoteurDD/results/autodock/simulation/entry_$i dlg_file
6 Décompresser le fichier dlg et extraire les informations pour mettre à jour les tables “hits” et “file” dans l'Information System gunzip `pwd`/${ligand}_${target}_$i.dlg.gz hitid=0 numrunP for (( run=1; run< $numrun; run++ )) do /get-run ${ligand}_${target}_$i.dlg $run > output if [ $? = 0 ] then rank=`grep Rank output | cut -d "=" -f 2` echo rank $rank >> bkp if [ $rank = 1 ] then energy_level=`grep Docked output | cut -d "=" -f 2 | awk '{print $1}'` mean_energy=`./PickLowestofCL.py ${ligand}_${target}_$i.dlg | grep "\_1 " | awk '{print $5}'` echo meanenergy $mean_energy >> bkp cluster_count=`grep cluster output | cut -d "=" -f 2`
/get-coordinates ${ligand}_${target}_$i > coordinates /hits_insert.py $hitid $i $rank $energy_level $run
$mean_energy $cluster_count coordinates
7 Éffacer le fichier de paramètres et les résultats actuels pour préparer la nouvelle simulation
# remove some files rm ${ligandName}* rm dpf3gen.awk if [ `grep "success" ${1}.status | wc -l` -gt 0 ] then exit 0 else exit 1 fi
Annexe 2 Les résultats de tester deux workflow :
1 Soumettre des simulations avec le workflow submitTest_wf
Figure (Annexe) 1 : Observer l’interface de MOTEUR, le TaskManager et la table Simulation de
Information System pour vérifier le workflow submitTest_wf ( 1)
Figure (Annexe) 2 : Observer l’interface de MOTEUR, le TaskManager et la table Simulation de
Information System pour vérifier le workflow submitTest_wf (2)
2 Lancer des agents avec le workflow AgentSubmission
Figure (Annexe) 3 : Observer l'interface de MOTEUR pour vérifier les états des agents
Figure (Annexe) 4 : Observer le Task Manager pour vérifier les éxecutions des tâches des agents
Figure (Annexe) 5 : Observer la table “hits” d’Information System pour vérifier l’execution des agents
3 Lancer le workflow isFinishedTest_wf
Figure (Annexe) 6 : Observer l’interface de MOTEUR pour vérifier l’opération du workflow isFinishedTest_wf
4 Lancer le workflow thresholderTest_wf
Figure (Annexe) 7 : Observer l’interface de MOTEUR pour vérifier la liste des simulations d’entrées
Figure (Annexe) 8 : Observer l’interface de MOTEUR et l’attribut ô mean_energy ằ de la table ôhitsằ pour vộrifier le workflow threholderTest_wf ( 1)