Tải bản đầy đủ (.pdf) (74 trang)

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

Bạn đang xem bản rút gọn của tài liệu. Xem và tải ngay bản đầy đủ của tài liệu tại đây (2.8 MB, 74 trang )

L’Institut de la Francophonie pour
l’Informatique

Laboratoire de Physique
Corpusculaire de Clermont-Ferrand

Master de l’IFI

Intégration d’un Moteur De Workflow sur un
Environnement de Grille
Mémoire sur le stage de fin d'études
présenté par
TRAN Tuan Tu
Stage effectué au Laboratoire de Physique Corpusculaire de Clermont-Ferrand

Directeur: M. Vincent BRETON - Directeur de Recherche, CNRS

Hanoi, Octobre 2008.


Mémoire de fin d’étude

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

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

TRAN Tuan Tu, IFI-P12

1


Mémoire de fin d’étude

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


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

Abstract
For the past 7 years, the Computing Platform Group for the Life Sciences (PCSV)
has been developing and deploying biomedical applications on grid envronment.
In the computing platform of the group, these applications function as services
whose correspoding tasks are executed in the grid. To perfom and link such
services automatically and sequentially, an integration of a workflow management
into this platform is needed. This thesis is, therefore, dedicated on : (i) Improving
MOTEUR, a workflow engine, so that it can work with the services of the group.
(ii) Creating the workflows to submit and to perform the tasks. (III) Developing a
bioinformatic service for submitting the tasks corresponding the application of
drug discovery
Keywords : grid, PCSV, bioinformatic, MOTEUR, workflow, workflow engine

TRAN Tuan Tu, IFI-P12


2


Mémoire de fin d’étude

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

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

TRAN Tuan Tu, IFI-P12

3


Mémoire de fin d’étude

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

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
AgentSubmision .............................................................................................................. 65

TRAN Tuan Tu, IFI-P12

4


Mémoire de fin d’étude

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

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

TRAN Tuan Tu, IFI-P12


5


Mémoire de fin d’étude

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

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

TRAN Tuan Tu, IFI-P12

6


Mémoire de fin d’étude

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


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

TRAN Tuan Tu, IFI-P12


7


Mémoire de fin d’étude

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

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.
4. Expériences et Résultats
On illustre les expériences et présente les résultats.
5.Conclusion et Perspectives
On fait la conclusion et propose des idées à faire dans l'avenir.

TRAN Tuan Tu, IFI-P12

8


Mémoire de fin d’étude


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

Chapitre-1

Introduction

1.1 La bioinformatique sur grille
La bioinformatique est un champ de recherche multidisciplinaire où 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.

TRAN Tuan Tu, IFI-P12

9


Mémoire de fin d’étude

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

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 :
• Soumission des tâches

TRAN Tuan Tu, IFI-P12

10


Mémoire de fin d’étude

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

• 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.
TRAN Tuan Tu, IFI-P12

11


Mémoire de fin d’étude

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

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.
1.2.2 La couche de gestion
Cette couche peut être divisée en deux modules :
• Task Manager
• Information System
Ces deux modules sont autonomes. Ils ne s’échangent pas d’information
directement.


1.2.2.1 Task Manager
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
• Gestion d’état de la tâche : waiting, running ou done

TRAN Tuan Tu, IFI-P12

12


Mémoire de fin d’étude

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

Il y a des web services avec lesquels les utilisateurs et les applications peuvent
travailler avec le Task Manager :
• createTask
• getTask
• setTaskWaiting
• deleteTask
• getNbTaskWaiting
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 où : depuis le serveur

d'équipe, d’une machine à distance, d’un noeud de travail de grille (WN), etc

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 où.

TRAN Tuan Tu, IFI-P12

13


Mémoire de fin d’étude

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

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.
Les agents

Les jobs

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

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

Actuellement, les agents sont soumis sur la grille de calcul EGEE.
TRAN Tuan Tu, IFI-P12

14


Mémoire de fin d’étude

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

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.

TRAN Tuan Tu, IFI-P12

15


Mémoire de fin d’étude

Intégration d’un moteur de workflow sur

un environnement de grille

• 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
simulation concernant le service B. La sortie de l’étape 1 est l'entrée de l'étape 2. Il
doit:

TRAN Tuan Tu, IFI-P12


16


Mémoire de fin d’étude

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

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

TRAN Tuan Tu, IFI-P12

17


Mémoire de fin d’étude

Chapitre-2

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

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.

TRAN Tuan Tu, IFI-P12

18


Mémoire de fin d’étude

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


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

TRAN Tuan Tu, IFI-P12

19


Mémoire de fin d’étude

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

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

TRAN Tuan Tu, IFI-P12


20


Mémoire de fin d’étude

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

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

TRAN Tuan Tu, IFI-P12

21


Mémoire de fin d’étude

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

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 NiceSophia.[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.

TRAN Tuan Tu, IFI-P12

22


Mémoire de fin d’étude


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

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"?>
xmlns:s="ience/xscufl/0.1alpha"
version="0.2" log="0">
lsid="urn:lsid:net.sf.taverna:wfDefinition:4c62e0b1-c3c4-4d8f-84e1adc0b8950a86" author="" title="exampleBeanShell" />
<s:processor name="Add">
<s:beanshell>
<s:scriptvalue>result
=
(Integer.parseInt(int0)+Integer.parseInt(int1)).toString();

lue>
<s:beanshellinputlist>
s:syntactictype="'text/plain'">int0</s:beanshellinput>
s:syntactictype="'text/plain'">int1</s:beanshellinput>
</s:beanshellinputlist>
<s:beanshelloutputlist>

TRAN Tuan Tu, IFI-P12

23


Mémoire de fin d’étude

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

s:syntactictype="'text/plain'">result</s:beanshelloutput>
</s:beanshelloutputlist>
<s:dependencies s:classloader="iteration" />
</s:beanshell>
</s:processor>
<s:source name="int0" />
<s:source name="int1" />
<s:sink name="result" />
<s:link source="int0" sink="Add:int0" />
<s:link source="int1" sink="Add:int1" />

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

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

TRAN Tuan Tu, IFI-P12

24


×