Intégration d’un moteur de workflow sur un environnement de grille

Lesobjectifs de ce stage sont : i l'amélioration du moteur de workflow nomméMOTEUR pour qu'il puisse travailler avec les services de l'équipe; ii La créationdes workflows pour soumettre

Stage effectué au Laboratoire de Physique Corpusculaire de Clermont-Ferrand

Directeur: M Vincent BRETON - Directeur de Recherche, CNRS

Hanoi, Octobre 2008.

Je tiens d’abord à remercier Monsieur le Directeur de Recherche Dr VincentBRETON qui m’a dirigé mon mémoire de fin d’études Sans son initiative, cestage n'aurait pas été achevé Je tiens à lui exprimer toute ma reconnaissance pourson dévouement, la confiance qu'il m'a accordée, sa rigueur et la qualité descommentaires et des suggestions sur mes travaux

Je tiens également à remercier Jean SALZEMANN, Vincent BLOCH, Ana Lucia

DA COSTA, Géraldine FÉTTAHI et Matthieu REICHSTADT pour m’avoir aidé,m’avoir donné des conseils, des encouragements importants ainsi que pour leurgentillesse

Je remercie infiniment Dr Johan MONTAGNAT, chercheur au laboratoire I3S(polytech'Nice Sophia Antipolis) pour ses conseils précieux, son soutien tout aulong de mon stage de fin d’études Ce travail n’aurait pu être accompli sans sonaide

Je voudrais exprimer un amical merci à l'ensemble des membres de l'équipe PCSV

et des amis au laboratoire I3S qui m’ont consacré du temps tout du long de monstage à Clermont-Ferrand et de mon travail à Nice

Mes gratitudes s’adressent aussi aux professeurs à l’Institut de la Francophoniepour l'Informatique (IFI) pour m’avoir transmis de bonnes connaissancesconcernant le savoir et le savoir-faire qui sont utiles pour mon mémoire

Finalement, j’exprime ma entière reconnaissance à ma famille, mes confrères, mesamis pour leurs soutiens, aides, encouragements et conseils sincères

Hanoi, le 24 Octobre 2008

TRAN Tuan Tu

L'équipe Plate-forme de Calcul pour les Sciences du Vivant (PCSV) développe etdéploie depuis 7 ans des applications biomédicales dans des environnements degrille Au sein de la plate-forme bioinformatique de l'équipe, ces applications sontimplémentées comme des services dont les tâches correspondantes sont exécutéessur la grille Il est nécessaire d'intégrer un gestionnaire de workflow à la plate-forme de l'équipe pour permettre la création d'interconnexions entre ses différentsservices et d'en permettre une exécution et un enchaînement automatique Lesobjectifs de ce stage sont : (i) l'amélioration du moteur de workflow nomméMOTEUR pour qu'il puisse travailler avec les services de l'équipe; (ii) La créationdes workflows pour soumettre et pour exécuter les tâches; (iii) Le développementd'un service bioinformatique spécifique pour la soumission des tâches del'application de recherche de nouveaux médicaments

Mots-clés : grille, PCSV, bioinformatique, MOTEUR, workflow, moteur de

Remerciements 1

Résumé 2

Sommaire 3

Liste des figures 5

Liste des tables 6

Avant-propos 7

Chapitre-1 Introduction 9

1.1 La bioinformatique sur grille 9

1.2 Plateforme Bioinformatique de l'équipe PCSV 10

1.2.1 La couche des Services Bioinformatiques 10

1.2.2 La couche de gestion 12

1.2.2.1 Task Manager 12

1.2.2.2 Information System 13

1.2.3 L'Environnement de Production WISDOM 14

1.2.4 Les opérations de la plateforme 15

1.3 Interconnexion des services 16

Chapitre-2 Gestion de workflow sur la plateforme 18

2.1 Objectifs 18

2.2 Sculf - un langage de spécification de workflow 21

2.3 Le moteur de workflow MOTEUR 22

2.3.1 Introduction 22

2.3.2 Fichier de workflow 23

2.3.3 Fichier de données 25

2.3.4 La capacité de parallélisme des services et de parallélisme des données 25 2.3.5 MOTEUR et la grille 26

2.4 Le workflow de Découverte de Médicament d'équipe 27

Chapitre-3 Implémentation d’un gestionnaire de workflow sur la plateforme 30

3.1 Objectif 30

3.2 Problèmes 33

3.2.1 Lecture du fichier de description des services bioinformatiques 33

3.2.2 Le problème avec la plateforme actuelle 34

3.3 Amélioration de MOTEUR pour traiter les web services “doc/lit wrapped” 35

3.3.1 L'Amélioration de MOTEUR 35

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 35

3.3.2.1 Les formats des fichiers de workflow 35

3.3.2.2 Le format des fichiers de données 37

3.4 Développement de docking_wf, le service bioinformatique pour les étapes du workflow de Découverte de Nouveaux Médicaments 38

3.4.1 L’Opération submitDocking 38

3.4.2 L'opération isFinished 40

3.4.3 L'opération thresholder 41

3.5 Mise en oeuvre du workflow TaskSubmision 42

3.5.1 Le processeur submitDocking 42

3.5.2 Le processeur isFinished 42

3.5.3 Le processeur thresholder 42

3.5.4 Le problème d'interconnexion des processeurs 43

3.6 Le workflow AgentSubmission 44

3.6.1 Conception de workflow 44

3.6.2 Le fichier de workflow 46

3.6.3 Le fichier de données 48

3.6.4 Les scripts utilisés par le workflow 48

3.6.4.1 Le script correspond à l'opération de chaque agent : jobAgent_wf.sh 49 3.6.4.2 Le script corespond à la simulation 51

3.6.4.3 Le script utilisé comme le fichier d'exécuter dans le fichier de description du grid-job 52

Chapitre-4 Expériences et Résultats 54

4.1 Tester l'amélioration de MOTEUR 54

4.2 Évaluation le service docking_wf 54

4.3 Évaluation deux workflows TaskSubmision et AgentSubmision 56

Chapitre-5 Conclusion et Perspectives 58

5.1 Conclusion 58

5.2 Perspectives 58

Références 59

Annexe 1 Les étapes du script docking_wf.sh 61 Annexe 2 Les résultats de tester deux workflow : TaskSubmision et

Liste des figures

Figure 1-1 La plateforme d'équipe PCSV 11

Figure 2-1: La souplesse de créer les workflow en interconnectant des services 19

Figure 2-2 : L'utilisation de moteur de workflow avec la flatforme 20

Figure 2-3 L'opérateur "dot" et l'opérateur "cross" 22

Figure 2-4 : Le workflow de faire la somme entre 2 chiffres 24

Figure 2-5 : Les ports du service GASW 26

Figure 2-6 : L'idée principale de docking moleculaire 28

Figure 2-7: Le ligand lie avec le protéine 28

Figure 3-1:L’opération du workflow Découverte de Médicament 31

Figure 3-2 : Les étapes du workflow de soumission des agents 31

Figure 3-3 Le workflow de soumission des agents fait le rôle d’environnement de production de flatforme 32

Figure 3-4 :Le schéma des résultats d’Autodock dans l'Information System 38

Figure 3-5 : Le workflow de soumission des tâches spécifié pour le Découverte de Médicament 43

Figure 3-6 : De la conception de workflow AgentSubmission à la mise en oeuvre en utilisant le processeur de MOTEUR 44

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) 65

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) 66

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 67 des agents 68

Figure (Annexe) 5: Observer la table “hits” d’Information System pour vérifier l’execution des agents 69

Figure (Annexe) 6: Observer l’interface de MOTEUR pour vérifier l’opération du workflow isFinishedTest_wf 70

Figure (Annexe) 7: Observer l’interface de MOTEUR pour vérifier la liste des simulations d’entrées 71

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) 72

Figure (Annexe) 9: Observer l’interface de MOTEUR et l’attribut « mean_energy » de la table «hits» pour vérifier le workflow threholderTest_wf ( 2) 73

Liste des tables

Table 1 : Les correspondances entre les agents de platefome et les grid-job 14

Table 2 : Comparaison de la description d'un message entre le type emballé et le type non-emballé 33

Table 3 : Les entrées de l'opérations submitDocking 39

Table 4 : Les entrées de l'opérations thresholder 41

Table 5 : Les entrées du processeur AgentSubmission de workflow 45

Table 6 : Les changements par rapport à la version actulle du script correspondant à la simulation d’Autodock 52

Table 7 : :La liste des workflow de test du workflow TaskSubmission 55

Table 8 : Les étapes des tests des deux workflows 57

L'équipe Plate-forme de Calculs pour les Sciences du Vivant (PCSV) développe etdéploie depuis 7 ans des applications biomédicales dans des environnements degrille L'équipe a montré l'impact des grilles pour la recherche de nouveau

médicament in-silico mais les différentes étapes du criblage virtuel – docking et

dynamique moléculaire – sont traitées pour l'instant de façon indépendante etdécouplée La grille est aussi utilisée pour traiter des données de biologiemoléculaire, mais le problème du temps de réponse de la grille pour les tâchescourtes demeure un facteur limitant son impact aux sciences du vivant Dans lecadre de plusieurs projets nationaux (ANR GWENDIA) et européens (Embrace,EGEE-II), l'équipe PCSV s'intéresse à améliorer la gestion des applicationsbioinformatiques sur la grille de calcul grâce à la mise en place de traitements enpipeline ou par le développement d'approches nouvelles de gestion des tâches.Dans le cadre de mon stage, j'ai étudié le déploiement d'une applicationbioinformatique avec des services de grille développés dans le cadre du projetGWENDIA et Embrace J'ai aussi étudié le moteur de workflow MOTEUR auquelj'ai apporté des améliorations pour intégrer des services web développées dansl'équipe PCSV

Ce mémoire se compose de 5 chapitres:

1 Introduction

On présente dans ce chapitre la bioinformatique sur grille On présente ensuite laplateforme de l'équipe PCSV et le problème de l'interconnexion des services del'équipe

2 Gestion de workflow sur la plateforme

On décrit les besoins d'une gestion de workflow sur la plaforme Ensuite, on étudie

le langage de spécification de workflow Sculf et le moteur de workflow

MOTEUR A la fin de ce chapitre, on survole sur le docking moleculaire et leworkflow de Découverte de Médicament d'équipe.

3 Implémentation d’un gestionaire de workflow sur la plateforme

Dans ce chapitre, tout d'abord, on présente l'objectif d'implémentation du moteur

de workflow sur la plateforme et les problématiques Après, on présenteprofondément l'amélioration de la version actuelle de MOTEUR, le déploiement

de service pour la découverte de médicaments A la fin, ce sont la mise en œuvred’un workflow de soumission des tâches spécifié pour la découverte demédicaments et le workflow de soumission des agents qui joue le rôled'environnement de production de plateforme

Chapitre-1 Introduction

1.1 La bioinformatique sur grille

La bioinformatique est un champ de recherche multidisciplinaire ó travaillent deconcert biologistes, informaticiens, mathématiciens et physiciens, dans le but derésoudre un problème scientifique posé par la biologie Le terme bio-informatiquepeut é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 lefonctionnement 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 estapparu 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 lesgènes vont enclencher la fabrication de protéines, et comment les protéinesfabriqué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 desinformations, de plus en plus nombreuses mais aussi de plus en plus variées Ilserait mal venu de s'en plaindre! Cependant, il devient primordial de veiller à ceque la gestion même de ces informations ne soit plus l'étape limitante de cetteconsidérable – et, de ce fait, partiellement exploitée – masse de connaissancespotentielles

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 sontdes “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 quasiillimitées de calcul ou de stockage de données, grâce à un accès transparent etfacile (une simple connexion à un réseau à très haut débit de type Internet) à unvaste ensemble de ressources informatiques distribuées sur une grande échelle [1]Les applications bioinformatiques sont de très bons candidats à exécuter dansl'environnement de grille, car elles manipulent un nombre de bases de donnéesgénomiques qui sont généralement réparties géographiquement Le défi le plusimportant ici est de fournir des services bioinformatiques de grille transparents,sécurisés et extensibles Beaucoup d'efforts pour construire les plateformes decalcul utilisant des grilles spécifiées pour la bioinformatique ont été réalisésrécemment [3]

1.2 Plateforme Bioinformatique de l'équipe PCSV

La plateforme bioinformatique de l'équipe comprend 3 couches :

1.2.1 La couche des Services Bioinformatiques

Cette couche comprend des web services qui correspondent aux applications ouaux 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

Figure 1-1 La plateforme d'équipe PCSV

Si nécessaire, un web service peut avoir des opérations suplémentaires Parexemple, pour executer le workflow de découverte de nouveau médicament, leweb service d'autodock a en plus l'opération “thresholder” qui teste si l'énérgied'un docking moleculaire passe un certain seuil

Grâce à ces couches, l'utilisateur peut travailler avec la plateforme à distance Lesautres composants de plateforme sont transparents pour les utilisateurs Ils utilisentjuste les opérations des services pour soumettre et gérer leurs tâches desimulations, ils ne doivent pas connaître en détail comment cela se passe L'usagedes services est aussi très souple, les utilisateurs peuvent interconnecter desservices différents pour créer des workflows bioinformatiques qui comprennentplusieurs simulations.

Les composants serveurs de ces services sont écrits en langage Java avec labibliothèque Axis Ils sont déployés sur le serveur d'équipe

Les rôles du Task Manager sont :

des informations suplémentaires

Il y a des web services avec lesquels les utilisateurs et les applications peuvent travailler avec le Task Manager :

1.2.2.2 Information System

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éepour la grille Il contient les descriptions et les localisations matérielles desfichiers 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 peudiffé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 Lerơle principal du système est de garder tous les résultats des simulations etd’exécutions des tâches de la plateforme

Il y a des API clientes pour requêter, ajouter et mettre à jour les contenus dansl'Information System Ces API sont écrites en 3 langages : soit C++, soit Java etsoit Python Comme les services web du Task Manager, on peut les lancern'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

utilisées par des agents

1.2.3 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 à ladécouverte de médicaments contre la malaria Grâce à l'Environnement de ProductionWisdom, les chercheurs peuvent soumettre et gérer des milliers de jobs sur la grille Cesjobs font des millions de simulations de docking moleculaire afin de trouver les ligandsqui peuvent se lier à la protéine plasmepsin du parasite de la malaria pour inhiber sonaction.[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 degrille

calcul

Table 1 : Les correspondances entre les agents de platefome et les grid-job

1.2.4 Les opérations de la plateforme

Il y a deux opérations pricipales sur la plateforme : soumission des tâches et

soumission des agents

Soumission des tâches

• 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

une nouvelle entrée dans la table “simulations” de la base de données de l'InformationSystem

• En fonction du service bioinformatique, la sortie est soit l'identificateur detâche, soit l'identificateur de simulation, soit l'identificateur de projet, etc Avec unidentificateur, l'utilisateur peut vérifier l'état et récupérer les résultats de tâche (ou desimulation, de projet, etc) correspondant

Soumission des agents

• L'utilisateur spécifie les arguments nécessaires (nombre d’agents, nomd'organisation virtuelle, etc) dans le fichier de configuration d'Environnement deProduction 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 simulationcorrespondant

• Il utilise l'identificateur de la simulation pour récupérer les informationsconcernant la simulation Avec ces informations, l'agent peut télécharger les données etles applications nécessaires pour effectuer la simulation.

• 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 lesdeux modes : PUSH (pousser) et PULL (tirer) L'Environnement de ProductionWISDOM pousse les agents à la grille Les agents tirent les tâches pour lesexecuter

1.3 Interconnexion des services

Actuellement, les utilisateurs doivent invoquer chaque opération de servicebioinformatique de façon indépendante Cela veut dire qu’il n'y a pas d'applicationdans la plateforme qui permet de créer et gérer les interconnexions entre lesopérations des services (ces opérations du même service ou des servicesdiffé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 lasimulation 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;

• Récupérer la sortie de cette simulation;

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

2.1 Objectifs

Actuellement, il manque une gestion de workflow sur la plateforme Pour executerdes workflows qui comprenent plusieurs étapes successives à réaliser, il y a deuxmaniè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 desservices » 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 difficiled’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 ungestionnaire de workflow pour gérer les interconnexions entres les opérations desservices 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 defaçon in-vitro (Drug Discovery Workflow)

Grâce à la participation au projet GWENDIA, le moteur de workflow, choisi parl'é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 dedonnées sur des infrastructures de grille

Figure 2-2 : L'utilisation de moteur de workflow avec la flatforme

2.2 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'uneapplication.[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 doittraiter de façon interactive Leurs contenus ne sont pas spécifiés à l'intérieur dudocument Scufl : ils sont indépendants de la description du workflow et ne sontconnus que lors de l'exécution

Les processeurs Scufl ont des ports d'entrée et des ports de sortie qui peuventcontenir plusieurs éléments de données Les ports se relient avec des liaisons dedonnées Une liaison de donnée est juste un tuyau (pipe) entre le port de sortie d'unprocesseur 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 portsd'entrée connectés De même, plusieurs ports de sortie peuvent être connectés à unseul port d'entrée Dans ce cas, les données sont mises dans le tampon d'entréeselon 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 estactivé si et seulement si tous ses ports contiennent des données adéquates Il n'estpas possible de définir des variables dans Scufl Les opérateurs de compositionpermettent de définir les stratégies d’itération entre les ports d'entrée d'unprocesseur 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 lapremière série avec l'autre élément correspondant de la deuxième série selon l'ordre deleur 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"

2.3 Le moteur de workflow MOTEUR

2.3.1 Introduction

MOTEUR (home-Made OpTimisEd scUfl enactoR) est un moteur de workflow

qui est développé par l'équipe RAINBOW du laboratoire I3S, Polytech Sophia.[11] Les fonctions principales de MOTEUR sont d’interpréter et d'exécuterdes workflow écrits en langage Sculf MOTEUR exploite plusieurs niveaux deparallélisme et groupe les tâches à réaliser pour réduire le temps d'éxecution desapplications De plus, MOTEUR utilise un service web générique d'encapsulationpour faciliter la réutilisation de codes développés sans prise en compte desspécificités des grilles de calcul

Nice-2.3.2 Fichier de workflow

Pour mettre en oeuvre un workflow, on doit spécifier :

• 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 sontstockées dans un fichier texte L'ensemble des tags utilisé par MOTEUR n'est pascomplexe mais efficace pour que les utilisateurs puissent facilement spécifier desworkflows

Actuellement, MOTEUR n'a pas d'outil particulier pour la spécification desworkflows Les utilisateurs peuvent utiliser n'importe quel éditeur de texte (vim,nano, screems, etc) pour écrire le workflow selon le standard XML en utilisant lestags et le format défini par MOTEUR

Par exemple, ci-dessous c'est un workflow simple qui fait la somme des deuxchiffres :

Il y a 4 processeurs dans ce workflow : deux sources, un Beanshell et un sink

lsid="urn:lsid:net.sf.taverna:wfDefinition:4c62e0b1-c3c4-4d8f-84e1-<s:processor name="Add">

<s:beanshell>

(Integer.parseInt(int0)+Integer.parseInt(int1)).toString();</s:scriptva lue>

<s:beanshellinputlist>

<s:beanshellinput s:syntactictype="'text/plain'">int0</s:beanshellinput>

<s:beanshellinput s:syntactictype="'text/plain'">int1</s:beanshellinput>

</s:beanshellinputlist>

<s:beanshelloutputlist>

<s:link source="int0" sink="Add:int0" />

<s:link source="int1" sink="Add:int1" />

<s:link source="Add:result" sink="result" />

</s:scufl>

2.3.3 Fichier de données

Le fichier de données est écrit aussi comme un fichier de texte selon le standardXML Il y a trois tags définis pour spécifier le nom des sources et la valeur deséléments des données

• 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éessimultanément

2.3.5 MOTEUR et la grille

Pour travailler avec la grille de calcul, l'équipe RAINBOW développe un serviceweb nommé GASW (Generic Application Service Wrapper) Grâce à la fonctionGASWexecution de ce service, MOTEUR peut soumettre et gérer les états desjobs sur la grille En utilisant l'interface JNI (Java Native Interface), tous les cotésclient et serveur de GASW sont intégrés à MOTEUR

MOTEUR peut travailler avec 2 grille : EGEE et Grid5000

<s:processor name="CreateTask" workers="10" jobSize="1">

Ci-dessous, c’est un exemple d’un fichier de description concernant un job qui exécute le script CreateTask.sh :

<executable name="CreateTask">

<access type="URL">

<path value="http://egee1.unice.fr/dd"/></access>

<value value="CreateTask.sh"/>

<input name="input0" option="-min"></input>

<input name="input1" option="-max"></input>

<output name="output0" option="-f">

2.4 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’ellessont 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 entreune 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]

• 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 inversementproportionnelle à la valeur d'énergie moyenne

À propos de découverte de médicament, le docking nous permet de cribler un grandnombre de ligands pour trouver ceux qui peuvent se lier à et inhiber une proteineimportante du virus, du parasite, etc Par exemple, pour trouver un médicament contre lamalaria, 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 2phases de simulation de docking :

• Étape 1 (Phase 1 de docking) Faire le docking entre un ligand et une protéinecible Les entrées sont l'énergie moyenne et la meilleure conformation du ligand Avec lameilleure conformation, on peut créer le meilleur fichier description de ligand Onl'appelle “nouveau ligand”

• Étape 2 (Thresholder) comparer l'energie moyenne de phase 1 avec un seuil Sil'énergie est inférieur au seuil, la liaison est stable et on passe à phase 2 Sinon, ons'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

• Les administrateurs de la plateforme qui lance l'Environnement de ProductionWISDOM 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'estmieux 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çonautomatique Les opérations du service qui sont invoquées dans chaque étape deworkflow peuvent être soit la soumission des tâches soit la fonctionsupplé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éationd’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 adeux 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 deProduction 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 projetGWENDIA

Figure 3-3 Le workflow de soumission des agents fait le rôle d’environnement de production de

flatforme

3.2 Problèmes

3.2.1 Lecture du fichier de description des services bioinformatiques

Tous les fichier de description (WSDL) des services bioinformatiques de l'équipesont é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 populaired'écrire un fichier WSDL [14]

les caractéristiques de base du type “document/litteral wrapped” sont lessuivantes :

• L’élément de type complexe n’a pas d'attributs

Jusqu'à maintenant, MOTEUR a déjà été testé avec les services web dont lesdescriptions sont écrites en type de “non wrapped” En type de “wrapped”, tous lesmessages d'entrée et de sortie ont toujours une seule partie, ceci provoque deuxdifficulté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 compositionentre 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 lesservices web décrits par tout type de WSDL

3.2.2 Le problème avec la plateforme actuelle

Dans la plateforme actuelle, il y a un service préexistant nommé “docking” pour lasimulation d'Autodock Cependant, ce service n'est pas convenable pour êtreutilisé directement pour mettre en oeuvre le workflow de découverte de nouveauxmédicaments avec deux phases d'Autodock Ce service est spécifié pour soumettreplusieurs tâches de simulation d'Autodock Il n'a pas l'opération pour faire lacomparaison entre l'énergie moyenne et un seuil (thresholder)

Ce n'est pas possible de vérifier ou d’améliorer ce service car les changementsvont causer des conflits avec son utilisation actuelle dans la plateforme Donc, ilfaut développer un nouveau service bioinformatique nommé “docking_wf” qui estspécialisé pour la création de workflow dans GWENDIA

3.3 Amélioration de MOTEUR pour traiter les web services

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 lesnoms 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 fautajouter 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 lefichier 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 3ecaractè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)

<xsd:complexType name="inputType">

<xsd:sequence>

<xsd:element name="ligand_id" type="xsd:string" />

<xsd:element name="target_id" type="xsd:string" />

<xsd:element name="request" type="tns:inputType" />

<xsd:element minOccurs="0" name="project_id" type="xsd:string" />

<xsd:element minOccurs="0" name="path" type="xsd:string" />