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

Les objectifs 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éation des workflows pour soumett

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

Directeur: M Vincent BRETON - Directeur de Recherche, CNRS

Hanoi, Octobre 2008

Remerciements

Je tiens d’abord à remercier Monsieur le Directeur de Recherche Dr Vincent BRETON qui m’a dirigé mon mémoire de fin d’études Sans son initiative, ce stage n'aurait pas été achevé Je tiens à lui exprimer toute ma reconnaissance pour son dévouement, la confiance qu'il m'a accordée, sa rigueur et la qualité des commentaires 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 leur gentillesse

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

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 mon stage à Clermont-Ferrand et de mon travail à Nice

Mes gratitudes s’adressent aussi aux professeurs à l’Institut de la Francophonie pour l'Informatique (IFI) pour m’avoir transmis de bonnes connaissances concernant 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, mes amis pour leurs soutiens, aides, encouragements et conseils sincères

Hanoi, le 24 Octobre 2008

TRAN Tuan Tu

Résumé

L'équipe Plate-forme de Calcul pour les Sciences du Vivant (PCSV) développe et déploie depuis 7 ans des applications biomédicales dans des environnements de grille Au sein de la plate-forme bioinformatique de l'équipe, ces applications sont implémentées comme des services dont les tâches correspondantes sont exécutées sur 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érents services et d'en permettre une exécution et un enchaînement automatique Les objectifs 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éation des workflows pour soumettre et pour exécuter les tâches; (iii) Le développement d'un service bioinformatique spécifique pour la soumission des tâches de l'application de recherche de nouveaux médicaments

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

Sommaire

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 67

Figure (Annexe) 4 : Observer le Task Manager pour vérifier les éxecutions des tâches 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

Avant-propos

L'équipe Plate-forme de Calculs pour les Sciences du Vivant (PCSV) développe et déploie depuis 7 ans des applications biomédicales dans des environnements de grille 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 et découplée La grille est aussi utilisée pour traiter des données de biologie moléculaire, mais le problème du temps de réponse de la grille pour les tâches courtes demeure un facteur limitant son impact aux sciences du vivant Dans le cadre de plusieurs projets nationaux (ANR GWENDIA) et européens (Embrace, EGEE-II), l'équipe PCSV s'intéresse à améliorer la gestion des applications bioinformatiques sur la grille de calcul grâce à la mise en place de traitements en pipeline 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 application bioinformatique avec des services de grille développés dans le cadre du projet GWENDIA et Embrace J'ai aussi étudié le moteur de workflow MOTEUR auquel j'ai apporté des améliorations pour intégrer des services web développées dans l'é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 la plateforme de l'équipe PCSV et le problème de l'interconnexion des services de l'é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 le workflow 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ésente profondé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 œuvre d’un workflow de soumission des tâches spécifié pour la découverte de médicaments et le workflow de soumission des agents qui joue le rôle d'environnement de production de plateforme

Chapitre-1 Introduction

1.1 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]

1.2 Plateforme Bioinformatique de l'équipe PCSV

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

• La couche des Services Bioinformatiques

• La couche de gestion

• L'Environnement de Production WISDOM

1.2.1 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

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

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 :

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é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

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 à 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

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

• 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

Soumission des agents

• 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 execute 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

1.3 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

• 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

2.1 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

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'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"

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é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

Nice-2.3.2 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

<?xml version="1.0" encoding="UTF-8"?>

<s:scufl xmlns:s="http://org.embl.ebi.escience/xscufl/0.1alpha" version="0.2" log="0">

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

• 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

2.3.5 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

<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’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

• Le fichier des paramètres

• 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

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

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

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'é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

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

3.2.2 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

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 :

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 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" />

wsaw:Action="docking/submitOneDocking" />

<wsdl:output xmlns:wsaw="http://www.w3.org/2006/05/addressing/wsdl"