Vous êtes sur la page 1sur 68

Copyright (c) Franck VALENTIN Permission is granted to copy, distribute and/or modify this document under the terms

of the GNU Free Documentation License, Version 1.2 or any later version published by the Free Software Foundation; with no Invariant Sections, no Front-Cover Texts, and no Back-Cover Texts. A copy of the license is included in the section entitled "GNU Free Documentation License".

MMOIRE prsent en vue d'obtenir Le Mastre Spcialis en Bio-Informatique

Franck VALENTIN

Conception et programmation d'un gestionnaire graphique de processus bioinformatiques d'analyse de squences et application l'identification des rsidus encodant la spcificit de la reconnaissance de l'interleukine-2 humaine par ses rcepteurs. Institut PASTEUR Septembre 2004

Directeur de stage : Thierry ROSE Unit d'Immunogntique Cellulaire rose@pasteur.fr Tl. : 33 01.45.68.85.99 Fax. : 33 01.45.68.86.39

Rsum Les outils informatiques utiliss voire dvelopps par les biologistes sont de natures trs diverses, il peut s'agir entre autres d'applications locales, de formulaires web, de scripts personnels ou de services web. Pour rpondre leurs besoins il leur est souvent ncessaire d'enchaner ces outils manuellement. Ce travail devient fastidieux lorsqu'il s'agit de le rpter pour ne modifier que quelques paramtres par exemple. L'utilisation d'un workflow permettant l'enchanement et l'excution de ces outils devrait simplifier ce processus. De plus, une construction et une excution graphiques permettent un meilleur contrle dans la conception et dans l'enchanement et offre des qualits pdagogiques intressantes. Nous avons dans un premier temps dfini clairement nos besoins puis fait un tour d'horizon des solutions existantes. Nous avons retenu d'utiliser Ptolemy II, un workflow non ddi la bioinformatique auquel nous avons ajout nos briques et celles d'autres projets. Notre outil est initialement prvu pour analyser les bases de la reconnaissance des cytokines par leurs rcepteurs en gnral au cours de l'volution et plus prcisment la conservation des rsidus de l'interleukine-2 et de ses rcepteurs. Nous montrerons donc son intrt dans ce contexte et l'illustrerons par quelques exemples simples. Enfin, nous conclurons en proposant des volutions futures et en exposant les problmatiques de ce type de projet si ce n'est des applications de bioinformatique en gnral.

Abstract The IT tools used or even developed by biologists are diverse by nature. They can be, among other things, local applications, web forms, personal scripts or web services. To satisfy their needs, biologists often have to manually enchain these tools. This work becomes tedious when it is necessary to repeat it, for example, just to change a few parameters. The use of a workflow that can link and execute these tools ought to improve this process. Furthermore, a graphical construction and execution permit better control in the conception and in the linking, as well as offering interesting educational qualities. First the requirements were clearly defined and then an overview of existing solutions was made. Ptolemy II, a workflow not dedicated to bioinformatics, was chosen as a foundation to which custommade components and ones from other projects were added. This new tool is primarily aimed at analysing the basis of cytokine recognition by their receptors in general through evolution and more precisely residue conservation within interleukine-2 and its receptor chains. Its usefulness in this context will be shown and illustrated through some simple examples. To conclude, future developments will be suggested. Some problematical areas in this kind of project, if not in bioinformatic applications in general, will also be shown.

Mots cls

Workflow, Ptolemy, Kepler/SPA, services web, java, interleukine-2

Remerciements

Je tient tout d'abord remercier Thierry Rose qui m'a confi ce projet et qui s'est dmen pour que ce stage l'institut Pasteur se droule dans les meilleures conditions. Je le remercie de l'avoir enrichi de son optimisme et de ses innombrables ides qui m'ont effrayes plus d'une fois ! Je suis reconnaissant envers Bernard CAUDRON, responsable du groupe Logiciels et Banques de donnes qui m'a trouv une place dans les locaux de son service. Je remercie Catherine LETONDAL qui a accept que cette place se situe dans son bureau. Je la remercie aussi pour ses efforts de montrer que l'on peut aussi faire de l'informatique en pensant aux utilisateurs et mme les associer la conception des outils qu'ils vont utiliser. Je remercie Bertrand NERON qui m'a eu dans le dos pendant ces six mois, au seul sens propre j'espre, et qui a rendu cette collocation vraiment agrable. Je ne dsespre pas qu'il m'enseigne un jour au Trocadro rduire le nombre de mes serpillires et autres pizzas. Enfin, je ne peux oublier Catherine, Corinne, Daniel, Elodie, Eric, Grard, Jrme, Louis, Marc, Marie-Christine, Nicolas et Olivier des groupes Logiciels et Banques de donnes et Systmes et Rseau qui ont largement contribu l'ambiance conviviale de ce stage. Je me souviens encore des Magnums inopins de cet t.

Glossaire

ACD Anticorps Antigne

Applet BioMOBY BioPerl Cladistique Cladogramme Cluster

CVS Cytokine

DAML-S

DAML+OIL Dataflow

DTD EMBOSS FIFO Framework

GRID computing Hmatopose

(Ajax Command Definitions) format de fichier utilis par les programmes EMBOSS pour dcrire leurs paramtres. Protine synthtise par les cellules lymphodes en rponse l'introduction d'une substance trangre appele antigne. Substance trangre (microbe, toxine, matire organique, etc) capable d'induire, lors de son introduction dans un organisme animal, la formation d'anticorps spcifiques. Programme en Java conu pour tre tlcharg via un rseau chaque fois qu'on veut l'excuter, en gnral par un navigateur web. Projet pour la dcouverte, lintgration et linteroprabilit de services et de bases de donnes biologiques. Ensemble de librairies crites en langage Perl et ddies au domaine de la bioinformatique. Analyse cladistique : qui privilgie le degr de ressemblance phylognique plutt que la ressemblance morphologique. Schma exprimant des relations phylogntiques partir d'une analyse cladistique. Architecture de groupes d'ordinateurs relis entre eux et pour lesquels les changes sont rapides. l'ensemble est considr comme une seule et unique machine. (Concurrent Versions System) Outil de gestion de sources multi-utilisateurs permettant de sauver et de rcuprer les diffrentes versions de fichiers. Substance peptidique ou protique synthtise par une cellule du systme immunitaire (lymphocyte, macrophage) et agissant sur d'autres cellules immunitaires pour en rguler l'activit. (DARPA Agent Markup Language Services) Langage de description smantique de services web. Il permet la description, la recherche, la slection et l'excution d'un service web particulier mais aussi la composition de services entre eux. Langage permettant de dfinir une ontologie pour un domaine particulier. Application dans laquelle la modification de la valeur d'une variable entrane automatiquement la rvaluation des variables qui en dpendent (un tableur est un exemple de dataflow). Les termes dataflow et workflow sont quelquefois assimils. (Document Type Definition) : Document permettant de dfinir la structure d'un fichier XML. Ensemble de logiciels pour la biologie molculaire. (First In First Out) File d'attente o les premires donnes entres sont les premires sorties. Infrastructure logicielle qui facilite la conception des applications par l'utilisation de bibliothques ou de gnrateurs de programmes. En franais "un cadre de dveloppement". Architecture de groupes d'ordinateurs relis entre eux par un rseau tendu pour excuter des tches et pour lesquels les changes peuvent tre lents. Formation des cellules du sang dans la moelle rouge des os et dans le tissu lymphode.

Homologue Interleukine Kinase LSF MyGrid

Monocyte Ontologie

Orthologue

PBS proxy web

RDF

service web

SGE SOAP

Soaplab

Thread UDDI

workflow WSDL XML XQuery

L'homologie est la ressemblance hrite d'un mme anctre commun. Deux squences sont dites homologues si elles ont un anctre commun. (IL) cytokine scrte par les lymphocytes, qui active les leucocytes et dclenche la scrtion d'interfrons. Enzyme capable de fixer un groupement phosphate en prsence d'adnosine triphosphate (ATP). Nom d'une application permettant de rpartir des processus sur plusieurs machines htrognes. Projet visant dvelopper une application de calcul distribu ddie la bioinformatique. Le but est aussi de permettre la recherche de services web, et l'excution de workflows utilisant des ressources distribus sur un rseau tendu. Globule blanc du sang qui passe dans les diffrents tissus, o il se transforme en macrophage. Une ontologie est un catalogue smantique, dont les descriptions sont la fois concises, non ambigus, et qui se doit d'tre exploitable par un logiciel (description formelle) comme par un oprateur humain (description littraire) [src. www.infobiogen.fr] Gnes orthologues : gnes d'espces diffrentes dont les squences sont homologues, la divergence faisant suite une spciation. S'il s'agit d'une volution aprs duplication au sein d'un individu on parlera de paralogue. Nom d'une application permettant de rpartir des processus sur plusieurs machines Ordinateur qui s'intercale entre deux rseaux et qui permet principalement d'enregistrer dans un cache les pages web couramment utilises pour ensuite les dlivrer sans qu'il soit ncessaire de se connecter sur le serveur initial. (Resource Description Framework) Modle et description de syntaxe en vue de l'utilisation de mta donnes sur le web. Son objectif est de faciliter le traitement automatis des informations contenues sur le web en permettant leur description ans ambigut. Application disponible sur le web et accessible par une interface standardise. Elle peut interagir avec d'autres services web indpendamment du systme d'exploitation et des langages de programmation utiliss. (Sun GridEngine) Nom d'une application permettant de faire du calcul distribu. (Simple Object Access Protocol) Protocole de communication inter applicatif, au dessus de HTTP, comportant un ensemble de rgles pour structurer des messages (XML) et invoquer un service web. Ensemble de services Web permettant l'accs des applications, essentiellement d'analyse de donnes. Intgre plus particulirement la suite EMBOSS en proposant une dfinition XML des fichiers ACD. Il intgre aussi un service d'enregistrement et de recherche de services web. Portion de programme pouvant s'excuter en parallle d'autres portions. (Universal Description Discovery and Integration) Norme permettant de crer et de retrouver des services web. Un annuaire UDDI est un annuaire en ligne, bas sur la norme UDDI, rfrenant un ensemble de services Web disponibles. Application qui permet de squencer des tches suivant un modle qui dfinit en particulier comment ces tches sont synchronises. Voir aussi dataflow. (Web Service Description Language) Langage bas sur XML permettant la description de l'interface d'un service web. (eXtensible Markup Languages) Langage pour interroger et manipuler les donnes d'un document XML.

XSLT

(eXtensible Style Language Transformation) langage permettant de transformer un document XML en un nouveau document XML ayant une structure (et ventuellement une DTD) diffrente.

Sommaire

Remerciements.................................................................................................................................................................. 4 Glossaire............................................................................................................................................................................. 5 1.Introduction.................................................................................................................................................................. 11 1.1 Encadrement et environnement........................................................................................................................ 11 1.2 Problmatique du sujet...................................................................................................................................... 11 2.Nos besoins et les solutions existantes................................................................................................................. 12 2.1 Dfinition des besoins....................................................................................................................................... 12 2.2 Les solutions disponibles.................................................................................................................................. 12 2.2.1 Les solutions non graphiques................................................................................................................... 13 2.2.1.1 G-Pipe................................................................................................................................................... 13 2.2.1.2 Biopipe................................................................................................................................................. 13 2.2.2 Les solutions graphiques......................................................................................................................... 14 2.2.2.1 Taverna............................................................................................................................................... 14 2.2.2.2 ViPEr................................................................................................................................................... 16 2.2.2.3 PipeLine Pilot et VIBE.................................................................................................................... 16 2.2.2.4 Wildfire............................................................................................................................................. 18 2.2.2.5 Ptolemy II......................................................................................................................................... 18 2.2.2.6 Kepler................................................................................................................................................ 20 2.3 Choix de Ptolemy II avantages et inconvnients..................................................................................... 21 3.Fonctionnalits dveloppes.................................................................................................................................... 23 3.1 Contraintes, outils et mthodologie.............................................................................................................. 23 3.2 Applications locales.......................................................................................................................................... 23 3.3 Checkpoint.......................................................................................................................................................... 25 3.4 Mobyle et le web............................................................................................................................................... 25 3.5 Services Web..................................................................................................................................................... 29 3.6 Architecture...................................................................................................................................................... 29 4.Application la reconnaissance de l'IL-2.............................................................................................................. 31 4.1 Introduction : LIL2 et ses rcepteurs......................................................................................................... 31 4.2 Importance mdicale de lIL2, et du dveloppement dagonistes et antagonistes de lIL2R.......... 33 4.3 Recherche en cours au laboratoire dImmunogntique Cellulaire (IGC).............................................33 4.4 Approche bioinformatique............................................................................................................................... 34 4.4.1 Rechercher les squences orthologues chaque cytokine et chacune des chanes de leurs rcepteurs............................................................................................................................................................ 35 4.4.2 Produire des alignements multiples afin de prparer des reconstructions des modles structuraux.......................................................................................................................................................... 36 4.4.3 Production des profils propres aux domaines encods par ces familles..................................... 38 4.4.4 Produire des arbres phylogntiques.................................................................................................. 38 5.Conclusion - futur et rflexions............................................................................................................................. 39 5.1 Typage des donnes et services web............................................................................................................ 39 5.2 Excutions rparties........................................................................................................................................ 40 5.3 Briques internes................................................................................................................................................ 40 5.4 Ergonomie et "utilisabilit"............................................................................................................................. 41 5.5 Intgration des autres projets..................................................................................................................... 43 Bibliographie................................................................................................................................................................... 44

Rfrences Web............................................................................................................................................................ 46 Annexe A - Cahier des charges............................................................................................................................. 47 Annexe B - Diagramme statique............................................................................................................................ 55 Annexe C - Diagramme statique : MobyleApplication...................................................................................... 56 Annexe D - DTD de Mobyle................................................................................................................................... 57

Table des figures

Fig. 1 G-Pipe.......................................................................................................................................................... 13 Fig. 2 Taverna, excution de BLAST.............................................................................................................. 15 Fig. 3 Taverna : Reprsentation minimale pour envoyer un mail............................................................... 15 Fig. 4 ViPEr. Visualisation d'une molcule..................................................................................................... 16 Fig. 5 PipeLine Pilot............................................................................................................................................. 17 Fig. 6 VIBE........................................................................................................................................................... 17 Fig. 7 Wildfire..................................................................................................................................................... 18 Fig. 8 Ptolemy II................................................................................................................................................. 20 Fig. 9 Kepler (SDM/SPA).................................................................................................................................. 21 Fig. 10 Configuration d'une brique "blastall"............................................................................................... 24 Fig. 11 Configuration d'une brique emacs...................................................................................................... 24 Fig. 12 Excution d'un programme de visualisation partir d'un"CheckPoint".................................... 25 Fig. 13 MobyleApplication : Configuration.................................................................................................... 26 Fig. 14 MobyleApplication : Fentre de configuration et menus disponibles........................................27 Fig. 15 MobyleApplication : excution........................................................................................................... 28 Fig. 16 Configuration et excution d'un service web................................................................................. 29 Fig. 17 Quand et par quelles cellules est produite et scrte l'IL-2 ?................................................ 31 Fig. 18 Quels sont les rcepteurs actifs de l'IL-2 ?.................................................................................. 31 Fig. 19 Comment agit l'IL-2 par la voie Jak-Stat ?.................................................................................... 32 Fig. 20 Quels sont les rles de l'IL-2 ?........................................................................................................ 32 Fig. 21 Quels usages thrapeutiques pour l'IL-2 ?..................................................................................... 33 Fig. 22 Modles de la transition de conformation...................................................................................... 34 Fig. 23 Spcificit de p1-30 par rapport l'IL-2 ?................................................................................... 34 Fig. 24 Blast en fonction de e pour l'IL-2.................................................................................................... 35 Fig. 25 Nombre de squences en fonction des puissances de e...............................................................36 Fig. 26 cluscore et hmmsearch....................................................................................................................... 37 Fig. 27 Rsultats de hmmsearch..................................................................................................................... 37 Fig. 28 Cosa. Niveau de conservation des rsidus...................................................................................... 38 Fig. 29 Affichage complet et l'excution correspondante....................................................................... 41 Fig. 30 Reprsentation des composants et exemple d'enchanement repris de [r13]........................42

10

1.Introduction
1.1 Encadrement et environnement
Le projet s'est droul l'institut PASTEUR de Paris et a t initi par Thierry ROSE de l'unit d'Immunogntique Cellulaire. Cette unit dveloppe trois grands axes de recherche :
le rle de l'interleukine-2 (IL-2) dans le contrle de l'amplitude des rponses T et le maintien de

l'homostasie;

la caractrisation des voies de signalisation de l'IL-2 et de mimtiques de l'IL-2 humaine

dveloppes des fins thrapeutiques (cancers rnaux, mlanomes, infections VIH). l'infection par le VIH.

l'impact de la drgulation du systme IL-2/RIL-2 sur l'immunodpression induite au cours de

J'ai aussi t encadr par Catherine LETONDAL du Groupe Logiciels et Banques de donnes qui a pour mission de fournir aux chercheurs de l'institut Pasteur les infrastructures, les logiciels et les banques de donnes ncessaires une recherche de pointe en biologie molculaire, y compris la gnomique et la biologie structurale.

1.2 Problmatique du sujet


Les outils informatiques utiliss voire dvelopps par les biologistes sont de nature trs diverses, il peut s'agir entre autres d'applications locales, de serveurs web ou de scripts personnels. Pour rpondre ces besoins il leur est souvent ncessaire d'enchaner ces outils manuellement. Ce travail devient fastidieux lorsqu'il s'agit de le rpter pour ne modifier que quelques paramtres par exemple. L'intrt de ce travail est donc de pouvoir utiliser des programmes de bioinformatique, de faciliter leurs interactions et de rendre possible leur enchanement tout en visualisant de manire graphique l'architecture, le flux de donnes et l'excution. En outre cela permettra de valider des workflows raliss par des experts et de les rendre accessibles des nophytes, ou aux experts de disposer d'un atelier de dveloppement et d'exploitation d'outils de bioinformatique de manire plus visuelle et plus souple autorisant des approches classiques ou plus intuitives. Enfin, une attention particulire doit tre porte aux technologies mergentes comme les services web et les formats d'changes de donnes XML ainsi que le respect des ontologies. Nous avons pour cela tout d'abord dcrit nos besoins et vrifi qu'il n'existait pas de solution qui pouvait satisfaire notre cahier des charges. Celui-ci est important pour la comprhension de ce document, il est dtaill en annexe A. Nous dcrirons ensuite les composants que nous avons dvelopps et donnerons quelques exemples dans le cadre des tudes sur l'IL-2.

11

2.Nos besoins et les solutions existantes


2.1 Dfinition des besoins
La premire partie du stage a consist entre autres prciser les fonctionnalits de l'application. Les fonctions principales ainsi que les lments graphiques ont t dfinis par Thierry ROSE. Ces lments ont volu au cours de nos diffrentes runions et des outils tudis. Afin de formaliser quelque peu les ides gnres nous avons rdig un cahier des charges de l'application (cf. Annexe A). Ce document n'est pas proprement parler un document de spcifications fonctionnelles, certaines fonctions n'tant pour le moment que des rsultats de discussions ou d'ides gnrales creuser, son rle est d'une part de formaliser les fonctions retenues et d'autre part de consigner les rflexions, analyses ou souhaits qui sont apparus au cours de ce stage. Comme nous le verrons par la suite, il est aussi indispensable pour avoir une vision de l'avancement du projet. Nous pouvons, sans rentrer dans les dtails, retenir les besoins principaux suivants :
Pouvoir glisser et dposer des applications/donnes/contrles dans un environnement de travail. Les relier entre elles pour dfinir le workflow. Excuter des workflows squentiels ou concurrents. Suivre l'tat de l'excution du workflow. Pouvoir comparer des rsultats entre plusieurs excutions. Permettre l'utilisateur de rajouter simplement de nouvelles applications (intgration de briques

PISE [w11] par exemple).

Dfinir des oprateurs de comparaison, des boucles. Pouvoir faire des excutions pas pas, ajouter des points d'arrt, faire des reprises sur erreur. Excuter partiellement un workflow. Vrifier la compatibilit des donnes, les rendre compatibles par l'ajout d'adaptateurs. Intgrer des services web. Permettre l'excution en arrire plan sans interface graphique mais pouvoir ensuite visualiser

chaque moment l'tat du workflow et le modifier.

Avoir des affichages diffrents en fonction des niveaux de reprsentation dsirs.

L'ide matresse de cette application tant de permettre l'utilisateur de concrtiser rapidement un processus de pense, de modifier rapidement le workflow et de vrifier la validit de ses hypothses. La simplicit d'utilisation et la clart du graphisme sont aussi des lments majeurs dans la mesure o cette application pourrait tre utilise comme outil pdagogique et les workflows rsultants partags voire publis.

2.2 Les solutions disponibles


Nous avons tudi les solutions existantes dans le domaine des workflows afin, soit d'utiliser une application qui rpondait majoritairement nos besoins, soit d'adapter une solution existante nos propres desiderata et ainsi viter de dfinir entirement une architecture. Nous nous sommes intresss prioritairement aux applications manipulation directe, c'est dire celles dont l'interface permettait de crer et excuter un workflow graphiquement par glisser/dposer

12

de briques (traitements, donnes ou contrles); nous utiliserons le terme "application graphique" pour la suite. Nous donnerons cependant auparavant un aperu des autres projets. Les vocabulaire pour dsigner les tches excuter est diffrent d'une application l'autre (processeur, acteur, tche, composant, etc.) nous utiliserons le terme gnrique de "brique" dans les paragraphes suivants pour dsigner une tche qui agit sur les donnes qu'elle accepte en entre. 2.2.1 Les solutions non graphiques Bien qu'elles ne rpondent pas nos attentes en terme d'interactions, nous citerons ici quelques applications. La liste n'est pas exhaustive mais mettent en vidence certaines problmatiques qui se rapprochent des ntres. 2.2.1.1 G-Pipe G-Pipe [w24] a t cr par Alexander Garcia et Samuel Thoraval. C'est un outil permettant de crer des pipelines en chanant des applications disponibles partir d'un formulaire web cr par le gnrateur d'interfaces Pise [w11]. Le pipeline est sauv dans un fichier XML dont la DTD est une volution de la DTD de Pise. Il met profit des fonctions comme la conversion automatique des donnes entres par l'utilisateur et la dtermination des applications qui peuvent traiter un type de rsultat particulier.

Fig. 1 G-Pipe Le menu en haut gauche liste les applications disponibles. Le menu en bas gauche permet de dfinir un ou des workflows et de suivre leur excution. La partie droite affiche la page de configuration d'une application (telle qu'elle apparat pour Pise) ou des informations sur les tches lances.

2.2.1.2 Biopipe Biopipe[r12] a t dvelopp par plusieurs organismes de Singapour (Institute of Molecular and Cell Biology; Genome Insitute of Singapore et Temasek Life Sciences Laboratory). Sa motivation est de faciliter l'interaction entre des applications et des donnes htrognes en proposant un cadre de dveloppement (framework) crit en Perl. Le workflow est dfini par un fichier XML mais sauv dans une base de donne pour tre excut par un "PipelineManager". Cette base reflte galement l'tat de l'excution tout moment et permet ainsi de la reprendre en cas d'arrt inopin d une erreur matrielle ou logicielle.

13

Un effort a galement t port pour abstraire l'utilisateur des diffrents formats de fichiers (en utilisant une reprsentation sous forme d'objets Bioperl) et des diffrentes interfaces des programmes (par la dfinition d'interfaces communes (wrappers)). Enfin ce projet permet de rpartir les tches sur un cluster par l'intermdiaire d'outils comme PBS [w21] ou LSF [w22] . 2.2.2 Les solutions graphiques 2.2.2.1 Taverna Taverna [w6] n'est pas proprement parler un workflow graphique manipulation directe dans la mesure o le workflow se construit partir d'un menu en arbre et une reprsentation du rsultat est reconstruite automatiquement sous forme graphique. Il est le rsultat d'une collaboration entre l'European Bioinformatics Institute (EBI), IT Innovation, the Rosalind Franklin Centre for Genomic Research (RFCGR), Newcastle Computer Science Faculty, Newcastle Centre for Life, Manchester Computer Science Faculty et le Nottingham University Mixed Reality Lab. Les briques ("processors") qui constituent les workflows sont choisies manuellement mais il est prvu terme d'intgrer des mcanismes de dcouverte de service (UDDI, BioMOBY, etc.). Elles peuvent tre de 4 types : des services web des services Soaplab [r8], un ensemble de services web associ des outils de recherche de service. des scripts Talisman [w33], permettant de facilement interagir avec des bases de donnes, des ressources diverses et d'autres workflows. des workflows Taverna. Parmi les nombreuses fonctionnalits on peut noter : un mcanisme de synchronisation entre des applications qui n'changent pas de donnes entre elles (auquel cas la synchronisation se fait naturellement); la dfinition d'applications de substitution ou des reprises du workflow en cas d'erreur sur l'excution d'une application (paramtrables en fonction du nombre de tentatives voulues et de la dure entre ces tentatives); l'itration du workflow sur une liste de donnes avec dans le cas de plusieurs entres, une possibilit de jointure sur ces entres. Ce workflow est bas sur le langage SCUFL (Simple Conceptual Unified Flow Language) reprsentable par un fichier XML (Xscufl). Ce format a l'avantage de pouvoir tre excut par les workflows de My GRID [w4] ( l'exception de fonctionnalits de coordination entre plusieurs applications). Les types de donnes ne sont pas encore pris en compte, les auteurs ont retenu de ne les considrer que comme des types MIME ventuellement regroupes en listes. Ce workflow est sous licence LGPL et cod en java. La version 0.1.beta.10 fut teste sur quelques exemples fournis. La prise en main est relativement aise, malheureusement l'ajout d'applications passe forcment par la dfinition d'un fichier de description ce qui est handicapant pour construire rapidement un workflow surtout lorsqu'il s'agit d'oprations simples. De plus l'dition et la reprsentation sont relativement lourdes. L'exemple de la figure 3 montre par exemple un workflow minimal pour envoyer un mail !

14

Fig. 2 Taverna, excution de BLAST. Ce workflow permet d'excuter BLAST pour une squence et une banque particulires. La fentre de droite reprsente les briques (processors) disponibles, retrouves ici des environnements Soaplab et BioMOBY. La fentre du haut permet de crer le workflow partir du choix des briques. L'affichage graphique est rafrachi aprs chaque modification. L'excution (par le menu Tools and Workflow Invocation) permet de visualiser les tches en cours et les rsultats intermdiaires

Fig. 3 Taverna : Reprsentation minimale pour envoyer un mail.

15

2.2.2.2 ViPEr ViPEr (Scripps Research Institute, San Diego)[r9] est un environnement de programmation visuel crit en Python et Tkinter (librairie graphique). Il permet de dfinir graphiquement une srie de transformations appliques des donnes et de visualiser le ou les rsultats, les tches et modules de visualisation disponibles sont essentiellement destins la biologie structurale. Il a la particularit de ne pas se baser sur un mode 'excution' mais de dclencher une brique ds qu'une donne en entre a volu et ainsi de propager les rsultats et les excutions, on a donc plus ici une application de dataflow. De nouvelles briques crites en Python peuvent tre ajoutes aux librairies existantes. Les workflows rsultants sont sauvs sous la forme de code Python et peuvent ainsi tre intgrs dans d'autres applications.

Fig. 4 ViPEr. Visualisation d'une molcule.

2.2.2.3 PipeLine Pilot et VIBE PipeLine Pilot de la socit Scitegic (San Diego) [w7] et VIBE de la socit Incogen (Williamsburg) [w8] sont deux produits commerciaux que nous n'avons malheureusement pas pu tester car aucune version de dmonstration n'tait facilement disponible. Pipeline Pilot a t conu plus spcifiquement pour l'industrie pharmaceutique alors que VIBE est propos avec des applications d'analyse de squence. Ils offrent tous deux la possibilit, entre autres, de construite des workflows graphiquement, de les sauver sous un format XML, de suivre l'tat de l'excution et d'ajouter des composants supplmentaires. Nous avons relev des fonctions intressantes intgrer dans notre application ou au moins prendre en compte comme fonctionnalits potentielles : Pipeline Pilot permet, aprs la dfinition d'un workflow, de l'excuter partir d'un formulaire web.

16

Pipeline Pilot permet de dfinir des briques partir d'un langage d'expressions.

VIBE propose une aide en ligne pour chaque composant et permet l'utilisateur de rajouter ses

commentaires. VIBE propose plusieurs espaces de travail Avant une excution, VIBE vrifie la validit et la compatibilit des donnes changes ainsi que l'initialisation des paramtres.

Fig. 5 PipeLine Pilot Le panel de gauche liste les briques disponibles par catgorie.

Fig. 6 VIBE Les icnes reprsentent les briques disponibles pour construire le workflow. Le panel de droite permet de changer les paramtres d'une brique, d'accder son aide ou de rajouter des commentaires.

17

2.2.2.4 Wildfire Wildfire [w18] est dvelopp par l'A-STAR (Agency for Science Technology and Research Singapour). Il se diffrencie des autres projets par une dfinition des workflows plus proche de la programmation procdurale (utilisation de boucles et de conditions). Il est fortement li la suite EMBOSS dans la mesure o il propose comme briques de base les programmes de cette bibliothque et o la dfinition d'une nouvelle brique correspondant un programme local se fait par l'intermdiaire de la dfinition d'un fichier ACD. Une partie de l'application utilise d'ailleurs JEMBOSS, l'interface graphique crite en java pour les outils EMBOSS. L'excution concurrente des programmes s'appuie sur le langage GEL [r10], pour lequel a collabor l'auteur de Wildfire. Ce langage de script permet d'utiliser diffrentes technologies de distribution de tches comme SMP, les clusters (PBS, SGE, LSF) ou le "grid computing". L'approche retenue ici est donc d'utiliser directement les applications telles quelles sans redfinir d'interface web ou de service web et de travailler sur des outils de rpartition de charge, ce qui n'est pas tonnant si l'on considre que c'est le domaine de recherche des auteurs. L'inconvnient de cette plateforme est que les communications inter tches se font exclusivement par change de fichiers.

Fig. 7 Wildfire Le panel de gauche liste les applications EMBOSS disponibles. L'excution peut tre suivie sur l'affichage du workflow et par une console.

2.2.2.5 Ptolemy II Ptolemy II [w19] est dvelopp par une quipe du dpartement EECS (Electrical Engineering and Computer Sciences) de l'universit Berkeley en Californie. Il est le rsultat de prcdents environnements et recherches crs ds 1986 et notamment destins la conception de systmes embarqus. Cet environnement n'est pas spcifique un domaine, il est principalement utilis par ces quipes pour implmenter et exprimenter divers techniques et travaux de recherche comme la dfinition de modles d'ordonnancement (la faon d'excuter les tches dans un workflow), la gnration de code partir d'un modle ou encore la conception objet.

18

Ainsi, aucune chance d'y trouver une brique de bioinformatique. Cependant, la librairie dfinie dispense de l'criture de briques quasi indispensables comme l'affichage des donnes sous plusieurs formes, les fonctions sur les chanes de caractres, les oprateurs de calcul ou encore la lecture de fichiers. tonnamment, c'est le seul environnement offrir un tel panel. Ci-dessous nous listons quelques-unes des fonctions offertes pour donner une ide de leur varit : Affichage de donnes sous la forme textuelle, en 2 dimensions et en diagrammes en barres. Opration sur les tableaux. Conversion entre types de donnes. Lecture et criture de donnes partir de fichiers ou de datagrammes IP. Oprations mathmatiques complexes (diffrentiation, intgration, etc.), oprations sur les matrices. Lecture, visualisation, transformation et filtres sur les images. valuation d'expressions issues du logiciel Matlab (a priori utile, voir par exemple [w20]) Possibilit d'intgrer des briques crites en Python (utilisation de la librairie Jython qui implmente en Java le langage Python). En dehors de ces briques l'environnement offre des fonctions intressantes comme : La possibilit de dfinir des paramtres utilisables dans l'environnement de travail et par chaque brique. Un langage qui permet d'valuer des expressions algbriques dont les termes peuvent tre des paramtres par exemple. La dfinition de types (entiers, flottants, chanes de caractres, matrices) pour les paramtres et les ports d'entre et de sortie des briques. La possibilit de dfinir un workflow comme une nouvelle brique et de la sauvegarder dans une librairie. La sauvegarde des workflows sous forme XML. La possibilit d'excuter un workflow sans interface graphique. La possibilit d'excuter un workflow dans une applet java. Enfin, il offre plusieurs modles d'ordonnancement (models of computation) qui dfinissent la manire dont interagissent les briques en fonction des donnes qu'elles reoivent ou mettent, du temps (continu ou discret) et de la manire de grer la concurrence au sein du workflow. Un composant appel 'director' permet de dfinir le modle pour un workflow donn. Par exemple, dans le modle PN (Process Network) les briques sont des tches indpendantes dont les ports d'entres sont des canaux FIFO. La brique traite les donnes en entre et envoie ventuellement des rsultats sur des ports de sortie. Elle se bloque ds que le canal est vide en attendant de nouvelles donnes. Le modle DE (Discret Event) quant lui modlise un systme pour lequel la communication entre les briques est squence par des vnements discrets au cours du temps. L'avantage ici n'est pas tant ce choix de modles, la difficult tant surtout de les comprendre et d'en choisir un qui convienne, mais la possibilit d'en crer un qui nous permette de satisfaire notre cahier des charges pour par exemple autoriser l'excution partielle d'un workflow ou rajouter des points d'arrt.

19

Fig. 8 Ptolemy II Le panel de gauche liste les briques (acteurs) disponibles ainsi que d'autres types d'objets utilisables (paramtres, commentaires, directeurs, etc). Le panel en bas gauche donne une vue d'ensemble du workflow. L'espace de travail droite donne un aperu des possibilits : la dfinition de paramtres, l'ajout de commentaires, l'inclusion d'autres workflows ou l'utilisation d'expressions algbriques.

2.2.2.6 Kepler Le projet Kepler [w16] est issu de la collaboration de plusieurs organismes de disciplines scientifiques diffrentes tels que SEEK (Science Environment for Ecological Knowledge), SDM Center/SPA (Scientific Data Management Center/Scientific Process Automation), GEON (Cyberinfrastructure for the Geosciences), ROADNet (Real-time Observatories, Applications, and Data Management Network). Son but est de faciliter aux scientifiques de ces diffrentes disciplines la cration, l'excution et le partage de workflows scientifiques. Il utilise la plateforme Ptolemy II laquelle il ajoute des fonctionnalits sous la forme de briques supplmentaires [r7] qui peuvent se classer ainsi : les services web, soit sous forme gnrique, soit associs des services particuliers (Blast, ClustalW, etc.). Une brique particulire permet aussi de retrouver les services disponibles partir d'une url ou d'un annuaire UDDI. l'accs des bases de donnes. les briques de transformation (XSLT, Xquery, Perl, etc.). Nous n'avons malheureusement pu tester certaines des fonctions listes ci-dessus que tardivement. En effet, le projet est actuellement en dveloppement (version 1 alpha en juin 2004) et certaines

20

briques sont encore "sotriques" faute de documentation. La partie dveloppe par SDM/SPA [w25] est spcifique la bioinformatique, nous verrons dans les chapitres suivants les dveloppements que nous avons pu reprendre.

Fig. 9 Kepler (SDM/SPA) Cet exemple repris de [w16] permet d'identifier les sites potentiels de fixation des facteurs de transcription pour une srie de gnes. Les briques sont essentiellement des services web. Certaines briques sont spcifiques ce workflow et permettent essentiellement une synchronisation entre les tches. On peut remarquer l'utilisation de briques composites (constitues elles-mmes de workflows).

2.3 Choix de Ptolemy II avantages et inconvnients


L'tude des diffrentes solutions nous a montr qu'aucune ne satisfaisait les fonctions principales de notre cahier des charges. Il tait raisonnablement impossible de crer une application de zro qui soit, mme en partie, rapidement fonctionnelle. Nous avons donc considr Ptolemy II et Kepler qui taient les deux candidats qui s'approchaient le plus de nos desiderata. Bien que Kepler puisse sembler le plus appropri, il intgre en effet dj des briques bioinformatiques, nous avons choisi Ptolemy II pour les raisons suivantes :
Kepler n'est pas spcifique la bioinformatique, l'espace de travail regroupe diffrents domaines

qui nous sont inutiles et nous ne pouvions anticiper les axes de dveloppements des prochaines versions (modification de l'espace de travail, architecture). Ce choix nous a donn raison par la suite car la dernire version ne prend pas encore en compte les dernires volutions de Ptolemy II.

21

Les

briques d'intrt dveloppes, essentiellement des services web, sont facilement rutilisables seules. nombre de classes et de fonctionnalits prsentes !), il existe une documentation dtaille et jour [r1][r2][r3] qui regroupe l'architecture logicielle (diagrammes statiques) et les fonctionnalits.

Ptolemy II est une application aboutie et prenne. L'architecture est claire (relativement au

Paradoxalement cette richesse est aussi un inconvnient. L'application est consquente (plus de 1300 classes) et les concepts nombreux. Ainsi, un effort important doit tre fait pour apprhender cet environnement avant de dvelopper de nouvelles applications.

22

3.Fonctionnalits dveloppes
3.1 Contraintes, outils et mthodologie
Le choix des fonctions dveloppes en priorit a t dict par les projets de Perrine Barjou1 et de Vldimir Dric2 qui ncessitient de disposer rpidement d'un environnement pour enchaner des tches. Nous avons donc privilgi les premires briques ncessaires pour ces projets qui nous permettaient de plus de valider notre approche. Les plus importantes de ces briques sont dtailles dans les paragraphes suivants. L'urgence dans les dveloppements nous a amen ne coder et dboguer que les fonctions indispensables. Cependnt, afin d'avoir une vision sur l'tat du projet nous avons associ chaque fonctionnalit un jeu de tests et chaque test les bogues correspondants (non dtaills dans ce document !). Ptolemy II est entirement crit en Java. Les environnements et les outils utiliss furent les suivants : Linux 2.6 Java JDK 1.4.2 Sources de Ptolemy II 3.0.2 puis mise jour avec Ptolemy II 4.0.1 Environnement de dveloppement Eclipse [w9]. Cration de diagrammes UML avec Posidon [w10].

3.2 Applications locales


Les applications locales (commandes en ligne ou programmes avec une interface graphique) peuvent tre excutes par l'acteur 'CmdLineApplication'. Cette brique permet de dfinir compltement et de faon trs souple la liste des paramtres d'une application. Les spcifications sont dtailles en Annexe A, fonction P8 et ne sont pas reprises ici. Les exemples simples suivants illustrent les possibilits de cette brique : Exemple 1 : recherche de squences (similaire celle d'une requte dans une base de squences par la mthode BLAST) "Je veux excuter blastall sur un fichier prsent sur le port d'entre 'fic_fasta'. Le fichier de sortie sera nomm 'blast.out' et sauv dans un rpertoire dfini par le paramtre 'dir_resu'. Il sera aussi envoy vers le port de sortie 'fic_blast'. La valeur espre (option -e) sera aussi dtermine par un port d'entre." La ligne de paramtres de blastall sera alors :
-p blastp -i in{fic_fasta} -d nr -m8 -o out{fic_blast}={exp{dir_resu+"blast_out"}} -e in{e}

La figure 10 montre la fentre de configuration et la brique rsultante. Les ports nouvellement crs ont t connects des briques contenant des valeurs pour les ports d'entre et un afficheur pour le port de sortie.

1 2

Analyse et prdiction de rseaux d'interaction de protines. Analyse et prdiction de structures de protines.

23

Fig. 10 Configuration d'une brique "blastall" Exemple 2 : dition de squences "Je veux diter une squence dans emacs. Un port en entre contient le fichier diter, lorsque je ferme l'diteur le fichier modifi est envoy sur un port de sortie. A l'ouverture de l'diteur je veux accder directement un numro de ligne dfini par le paramtre 'no_ligne'". La ligne de paramtres sera alors :
+exp{no_ligne} out{fichier_modifie}={in{fichier}}

La figure 11 montre la fentre de configuration et le rsultat de l'excution. Ici la commande est elle-mme dfinie par un paramtre de l'espace de travail ('$emacs') ce qui, dans le cas de workflows plus importants, permet de plus facilement partager des workflows et de les adapter pour sa propre configuration.

Fig. 11 Configuration d'une brique emacs

24

3.3 Checkpoint
Cette brique est une premire implmentation de la fonctionnalit "Sauvegarde et visualisation de donnes entre acteurs" (cf. Annexe A, fonction P16). Elle a t conue pour visualiser le contenu des fichiers changs entre les acteurs et ainsi dboguer plus facilement nos premiers workflows. Bien que cette fonctionnalit soit importante si ce n'est primordiale elle est souvent absente des workflows tudis. Le "CheckPoint" de la figure 12 (brique ronde) est devenu vert lorsque des donnes lui ont t prsentes, l'utilisateur peut choisir de les visualiser tout moment pendant ou aprs l'excution du workflow. Le programme de visualisation utiliser est choisi lors de la configuration de cette brique et peut tre modifi tout moment.

Fig. 12 Excution d'un programme de visualisation partir d'un"CheckPoint". Les "CheckPoints" peuvent aussi tre choisis pour toute application interactive si l'on souhaite que le workflow ne s'arrte pas sur cette tche lors de l'excution.

3.4 Mobyle et le web


Un moyen efficace d'ajouter et de configurer de nouvelles applications est d'utiliser Mobyle [w34], une volution de Pise dveloppe par Catherine LETONDAL et Bertrand NERON. PISE [w11] permet partir d'une dfinition en XML de l'interface du programme de gnrer l'interface de configuration et d'excution pour plusieurs types d'affichage (Web, SeqLab, Tcl/Tk et X11). L'interface Web est la plus rpandue, le formulaire HTML cr permet de lancer un programme CGI capable de lancer l'excution du programme et de rcuprer les rsultats. Mobyle ajoute la DTD de PISE des volutions pour l'enchanement des tches et la prise en compte de plusieurs types d'excution (local, CGI, service web) par exemple (cf. DTD annexe D). Nous avons donc dfini un acteur (cf. annexe A, fonction P7) qui, partir du formalisme utilis par Mobyle, permettrait de configurer et d'excuter une application que se soit un programme local, un CGI ou un service web. La configuration se fait par l'intermdiaire d'un formulaire html, l'utilisateur peut, pour chaque paramtre, spcifier s'il s'agit d'un port en entre, d'une expression valuer au moment de l'excution (opration entre paramtres dfinis dans l'environnement de Ptolemy II) ou d'une valeur classique. Cette configuration est faite par l'intermdiaire d'une page web similaire celle qui est gnre par

25

Pise. Nous avons de plus tendu la fonction prcdente l'excution de cgi accessibles par des pages web et dfini ainsi deux urls, la premire correspond au fichier XML (url_XML), la seconde la page html (url_presentation) de configuration de l'acteur. Nous avons alors les 3 cas suivants : url_XML seule : la page html de configuration est gnre partir du fichier XML. A partir de cette page l'utilisateur spcifie les ports d'entre, les expressions et les valeurs. Les ports de sortie sont aussi dtermins partir du fichier XML. url_html seule : la page html du site est affiche, l'utilisateur peut naviguer avec les liens hypertextes pour trouver le formulaire qui correspond au service dsir. Ensuite il spcifie le type des champs dans ce formulaire. A l'excution de l'acteur, la requte est envoye au serveur (de la mme manire que si l'utilisateur appuyait sur 'submit'). La page html retourne par le serveur est envoye sur un port de sortie. url_XML et url_html : le comportement est le mme que dans le premier cas la diffrence que l'affichage correspond url_html. Ceci permet d'offrir une interface similaire celle d'un site d'origine (plus simplement qu' partir de la dfinition du fichier XML). Cela suppose bien sr que le formulaire dfinit dans url_html soit compatible avec le fichier XML. L'exemple ci-dessous illustre une utilisation avec le logiciel GenScan disponible partir d'une interface web gnre par Pise. La figure 13 montre l'interface de configuration aprs que l'utilisateur ait choisi une url, la page html est alors prsente comme dans un navigateur classique.

Fig. 13 MobyleApplication : Configuration. L'utilisateur saisie l'url d'une page et peut naviguer de la mme manire qu'un navigateur classique.

26

L'utilisateur spcifie ensuite le type de chaque champ. Sur la figure 14, le bouton "Run genscan" est le bouton de soumission du formulaire, le champ mail reste une valeur classique, la squence ADN correspondra au contenu du port d'entre 'id_sequence' et le fichier de paramtre (boutons radio "parameter file") au contenu du paramtre 'organisme'.

Fig. 14 MobyleApplication : Fentre de configuration et menus disponibles. Cet exemple montre les menus disponibles pour chaque champ du formulaire. La valeur grise correspond au type en cours. La taille d'un champ reste inchange quel que soit le type pour conserver la mise en page initiale.

27

Aprs la validation de cette configuration, les ports sont ajouts l'acteur. La figure 15 montre le rsultat de l'excution, le fichier html reu aprs excution de la brique est affich dans un navigateur externe (brique BrowserUI).

Fig. 15 MobyleApplication : excution. Les ports ont t ajouts la brique. Aprs l'excution, le rsultat est affich dans un navigateur externe. Le prototype ralis nous a permis en partie de valider la faisabilit de notre approche pour l'intgration de MOBYLE, il reste cependant beaucoup de dveloppements raliser comme transformer un fichier XML pour gnrer l'interface html (a priori via une transformation XSLT) ainsi que vrifier la validit des paramtres entrs par l'utilisateur, crer les ports de sortie et prendre en compte le rsultat en fonction du mme fichier XML. Concernant l'intgration de n'importe quel formulaire web, l'obstacle majeur tient dans les bibliothques java standards utilises pour raliser le navigateur web. Celles-ci ne supportent en effet que la norme html 3.2 sans javascript et sans frame ce qui trs insuffisant pour les nouveaux sites qui utilisent foison html 4.0, les frames, CSS1, CSS2, etc. Il faudrait alors se tourner vers des composants comme xsmiles [w13] ou WebRendered [w14](plus abouti mais payant !) Enfin, nous n'avons valid l'excution que pour des formulaires web simples. Il reste encore beaucoup de sites incompatibles (si ce n'est la majorit !). Un gros travail d'analyse et de conception reste faire car en plus de la ncessit de respecter les recommandations W3C pour la syntaxe des formulaires [w12], de traiter les cas de connexion travers un proxy et les sites accessibles par mot de passe il faudra aussi prendre en compte les trs nombreux formulaires htroclites du web. Une dernire solution plus simple serait d'attendre que les sites web proposent une interface WSDL pour leur cgi ! Ceci dit, le projet Gowlab [w15] permet dj de dfinir dans un fichier au format ACD (format utilis pour la dfinition des programmes EMBOSS) les champs d'un formulaire web comme l'url du cgi , le type de requte (POST, GET, etc.) et les diffrents paramtres. Ce fichier permet de crer l'interface WSDL et de l'intgrer dans la liste des services web disponibles dans un environnement Soaplab.

28

3.5 Services Web


Cette brique est reprise du projet Kepler. La figure 16 montre la fois la configuration (choix de l'url, nom de la mthode, utilisateur et mot de passe) et le rsultat de la requte affich dans un diteur classique.

Fig. 16 Configuration et excution d'un service web. Cet exemple montre la fentre de configuration ainsi que la fentre d'affichage du rsultat (brique de Ptolemy II). Pour ce service, un port prend en compte la globalit des paramtres sous la forme d'une chane de caractres.

3.6 Architecture
Nous n'afficherons pas ici le code du projet (disponible l'institut Pasteur) mais seulement les diagrammes statiques UML (des scenarii ont galement t crs pour la conception de la brique 'MobyleApplication'). Une partie de l'architecture logicielle est dcrite par l'annexe B. Les attributs et les mthodes prives et protges ne sont pas reprsents pour des raisons de lisibilit. Dtaillons les classes principales pour comprendre la structure gnrale :
ExternalApplication : cette classe abstraite permet de dfinir les attributs et mthodes communes LocalApplication : classe permettant de lancer une application partir de Java et de prendre en

de nos nouvelles briques (reprsentation l'cran, nom de la brique, tat de la tche en cours, etc.).

compte les flux d'entre et de sortie. Une chane de caractre reprsente l'ensemble des paramtres de l'application. CmdLineApplication : classe drive de LocalApplication. La ligne de commande de l'application est maintenant cre lors de l'excution de la brique aprs analyse des paramtres entrs par l'utilisateur. Ces paramtres sont traits par la classe CmdLineParameters. CmdLineParameters : liste (composition) d'objets de type CLPNode. CLPNode reprsente l'interface pour les noeuds qui dfinissent un port en entre (in{nom_du_port}), une expression (exp {expression}), un port en sortie (out{nom_port}={contenu}) ou une valeur. CheckPoint : classe drive de LocalApplication (elle permet d'excuter un application locale de visualisation). Elle est associe la classe checkPointControllerFactory qui permet de dfinir un

29

menu particulier pour cette brique. L'annexe C dcrit l'architecture utilise pour la brique 'MobyleApplication'. La majeure partie du travail a consist adapter les classes permettant de grer et d'afficher les pages html (JeditorPane, HTMLEditorKit, FormView. Voir aussi [w32]). Nous trouvons en particulier les classes :
MobyleConfigurer : boite de dialogue qui affiche les pages html et qui gre l'historique.

ExtFormComponent : classe abstraite qui regroupe les mthodes et attributs communs aux classes

ExtJButton, ExtJComboBox, etc. Les instances de ces classes contiennent les widgets utiliss la place des widgets classiques d'une page html (boutons radio, cases cocher, boutons, etc.). Elles permettent entre autres soit d'afficher le composant d'origine soit la zone de saisie d'un port ou d'une expression. ExtFormComponentFactory : classe de cration qui retourne une instance d'une sous-classe de ExtFormComponent selon la valeur d'une balise html qui lui est fourni.

30

4.Application la reconnaissance de l'IL-2


Ce gestionnaire graphique de processus bioinformatiques d'analyse de squences a t conu autour dune application commande par lutilisateur final, lUnit dImmunogntique Cellulaire. Lapplication est focalise sur lidentification des rsidus encodant la spcificit de la reconnaissance de l'interleukine-2 humaine par ses rcepteurs au cours de lvolution par comparaison aux autres systmes cytokine-rcepteur.

4.1 Introduction : LIL2 et ses rcepteurs


Linterleukine-2 (IL2) est une cytokine de 133 rsidus scrte naturellement par les lymphocytes CD4 lors dune stimulation par les cellules prsentant les antignes (monocytes, cellules dendritiques, lymphocytes B) au cours dune infection ou en prsence de cellules tumorales. LIL2 est reconnue par plusieurs types de rcepteurs (IL2R) la surface des lymphocytes (Fig. 17) et stimule leur prolifration.

Fig. 17 Quand et par quelles cellules est produite et scrte l'IL-2 ?

Les rcepteurs de lIL2 comprennent jusqu trois chanes membranaires , et dont le contrle de lexpression et de la maturation varie dun type de lymphocyte lautre. La proportion relative des chanes exprimes dicte la composition oligomriques des rcepteurs. Ils se distinguent entre eux par leurs affinits pour lIL2: (10pM), (1nM) (Fig .18)

Fig. 18 Quels sont les rcepteurs actifs de l'IL-2 ?

31

Aucune structure des chanes du rcepteur na t rsolue, pas mme celles de ses domaines intra ou extra-cytoplasmiques. Seules les structures cristallographiques et par RMN de lIL2 ont t mises jour. Les bases molculaires de la reconnaissance de lIL2 par ses rcepteurs et le mcanisme de modification conformationnelle lorigine de linitiation transduction du signal ne sont pas documents exprimentalement. En particulier les hypothses de pr-assemblage du rcepteur avant la fixation de la cytokine ou le rle de lassemblage induit par la cytokine sur la transduction du signal ne sont ni dmontres ni invalides.

Fig. 19 Comment agit l'IL-2 par la voie Jak-Stat ?

Comme le dcrit la figure 19, le domaine cytoplasmique de la chane IL2R fixe JaK1 (tyrosine kinase Janus 1) et IL2R fixe JaK3. Le rapprochement des domaines cytoplasmiques met en contact JaK1 et JaK3 qui forment un complexe actif qui catalyse la phosphorylation dune tyrosine de lextrmit Cterminale de la chane IL2R. Cette tyrosine modifie est reconnue par le complexe de facteurs de transcription Stat5a-Stat5b qui sactive par auto-phosphorylation. Ces facteurs induisent lexpression de plusieurs gnes, celui de lIL2R par exemple. Lactivation du rcepteur IL2R induit aussi le blocage des mcanismes apoptotiques via Bcl2, la modification du cytosquelette par la voie Rho et la prolifration par lactivation de plusieurs gnes par la voie Ras/Raf/MapK (Fig. 20).

Fig. 20 Quels sont les rles de l'IL-2 ?

32

4.2 Importance mdicale de lIL2, et du dveloppement dagonistes et antagonistes de lIL2R


Linjection dIL2 a t teste depuis 1980 chez des patients pour provoquer la prolifration de lymphocytes et rduire le dveloppement de tumeurs (Fig. 21). La thrapie a t agre depuis une dizaine dannes pour le traitement de carcinomes rnaux et de mlanomes. Plus rcemment, lIL2 est utilise pour reconstituer le taux de CD4 chez certains patients infects par le virus VIH. Malheureusement, lIL2 induit aussi des effets secondaires indsirables. Le syndrome de fuite vasculaire (VLS) responsable entre autres doedmes pulmonaires en est un exemple. La gravit des effets secondaires oblige rduire les doses injectes ce qui diminue lefficacit des traitements. Aucun agoniste du rcepteur ni aucune IL2 modifie na permis jusqu' prsent damliorer significativement lindex thrapeutique de lIL2.

Fig. 21 Quels usages thrapeutiques pour l'IL-2 ?

La recherche dinhibiteurs du rcepteur de lIL2 offrirait des espoirs de thrapies contre certaines maladies auto-immunes ou en complment de la cyclosporine prescrite dans le cas de greffes dorganes. En effet, la cyclosporine est toxique pour le rein et le seul moyen actuellement den rduire les doses, est linjection danticorps anti-IL2R inhibiteur du rcepteur IL2R.

4.3 Recherche en cours au laboratoire dImmunogntique Cellulaire (IGC)


LUnit IGC est entre autre engage dans deux projets conjoints lun est lidentification du mcanisme de transduction induit par lIL2 sur les lymphocytes "Natural killers" et lautre de slectionner ou concevoir des molcules susceptibles de stimuler cette transduction la place de lIL2, toxique chez les patients en traitement. Ce groupe a t le premier dmontrer la prsence de rcepteurs prassembls de lIL2 spcifiques des NK [r15]. Ceux-ci sont aussi stimulables spcifiquement par des peptides mimant la structure de lIL2 entire [r16]. En absence de donnes cristallographiques Thierry Rose a reconstruit par modlisation molculaire comparative les structures tridimensionnelles du dimre de chanes IL2R libres et associs au ttramre de peptide p1-304 [r16] sur la base du complexe de lrythropotine et de son rcepteur rsolue par cristallographie. Ces simulations suggrent un mcanisme de transduction de signal travers la membrane par la modification des interactions des deux chanes pr-assembles (Fig. 22). Sous leffet de la fixation du peptide, les extrmits C-terminales des deux domaines extra-cytoplasmiques distantes de plus de 80, se rapprochent moins de 30 . Par extension de ces

33

domaines, les hlices transmembranaires uniques sont elles aussi rapproches de 80 30. Ce mouvement de plus de 50 serait responsable du rapprochement des domaines cytoplasmiques (Fig. 22). Chaque domaine cytoplasmique fixe une tyrosine kinase (JaK); le rapprochement des deux kinases permettrait de phosphoryler une tyrosine de lIL2R reconnue comme site de fixation du complexe de facteur de transcription Stat5a-Stat5b.

Fig. 22 Modles de la transition de conformation entre le rcepteur libre et li au trtramre p1-30 ?

La symtrie du ttramre p1-304 serait responsable de lassociation prfrentielle au rcepteur symtrique plutt que le rcepteur asymtrique (Fig. 23). En effet, le peptide p1-30 a la mme squence que lhlice A de lIL2 et linteraction de A avec le rcepteur IL2R, se ferait par lintermdiaire de la chane .

Fig. 23 Spcificit de p1-30 par rapport l'IL-2 ?

Ce mcanisme semble tre gnralisable toutes les IL2 et mimtiques sur leurs rcepteurs naturels , et mais aussi pour tous les systmes cytokine-rcepteur de la famille des hmatopoitines.

4.4 Approche bioinformatique


Les approches bioinformatiques que jai mises en application dans le cadre du stage ont pour objet de Rechercher les squences orthologues chaque cytokine et chacune des chanes de leurs rcepteurs. Produire des alignements multiples afin de prparer des reconstructions des modles structuraux. Produire des profils propres aux domaines encods par ces familles pour retrouver par des mthodes types chane de Markov, de nouvelles squences de systmes homologues de familles

34

proches ou loignes. Produire des arbres phylogntiques au sein des systmes cytokines-rcepteurs et dune sousfamille lautre au sein des hmatopoitines. 4.4.1 Rechercher les squences orthologues chaque cytokine et chacune des chanes de leurs rcepteurs Nous avons slectionn les squences suivantes : Cytokine : IL2 ; Rcepteur : IL2R, IL2R, IL2R. Cytokine : IL4 ; Rcepteur : IL4R, IL2R. Cytokine : IL7 ; Rcepteur : IL7R, IL2R. Cytokine : IL9 ; Rcepteur : IL9R, IL2R. Cytokine : IL13 ; Rcepteur : IL13R, IL4R, IL2R. Cytokine : IL15 ; Rcepteur : IL15R, IL2R, IL2R. Cytokine : IL21 ; Rcepteur : IL21R, IL2R. Les paramtres de recherche des squences (matrice de substitution, esprance e, cration et extension de lacune) dans la base de squences Nrprot (NCBI) par la mthode Blast (NCBI) ont t optimiss par le workflow dcrit dans la figure 24. Le niveau de dtection de squence nest pas amlior dans les cas prsents par lutilisation de la mthode itrative PSI-Blast.

Fig. 24 Blast en fonction de e pour l'IL-2. La brique 'valeurs de e' est une liste de 12 valeurs de 10-10 10. BLAST est excut pour chacune de ces valeurs. Les identifiants des squences rsultantes sont retrouvs par blast2list puis compts. La courbe est affiche par une brique de Ptolemy II.

35

Fig. 25 Nombre de squences en fonction des puissances de e.

4.4.2 Produire des alignements multiples afin de prparer des reconstructions des modles structuraux Les fichiers rsultats de recherche de squences par Blast ont t filtrs par le programme blast2list crit par le groupe IGC et qui permet de sortir, filtrer et classer les squences par score ou organismes. Les listes ont t utilises pour produire des fichiers o figurent les squences compltes au format fasta avec le programme fastacmd du package Blast (NCBI). Ce fichier est alors utilis en entre par le programme ClustalW [w35] pour produire un fichier dalignements multiples. Les paramtres dalignement ont aussi t tests (matrices de substitution, esprance e, cration et extension de lacune) en vue doptimiser le taux didentit par paire et le taux de similitude sur la totalit du multialignement calcul par le programme cluscore comme dcrit dans la figure 26.

36

Fig. 26 cluscore et hmmsearch Ce workflow montre la fois l'utilisation de cluscore et la gnration de profils par hmmsearch.

Fig. 27 Rsultats de hmmsearch

Les fichiers aln produits par clustal ont t utiliss comme point de dpart pour comparer plusieurs logiciels interactifs dalignement multiples Clustal X [r17], Jalview [w36], Indonesia [w37], T-coffee [w38], 3D-coffee [w39]. Lensemble de squences Bali et lvaluateur cluscore nous ont permis de choisir les mthodes en fonction des cas. Nous avons cart Indonesia, retenu ClustalX et Jalview dans les cas gnraux, T-coffee dans les cas plus difficiles et 3D-coffee lors de lintgration de donnes structurales, sur les structures secondaires non-scables en particulier.

37

Les fichiers aln ont t utiliss pour valuer le niveau de conservation de chaque rsidu pour chaque sous-famille au moyen du programme Cosa dvelopp par le groupe IGC. Cosa produit une image dun modle molculaire tridimensionnel (Fig. 28) affichant le niveau de conservation des rsidus partir dun fichier au format clustal contenant parmi toutes les squences au moins la squence dune protine de structure connue.

Fig. 28 Cosa. Niveau de conservation des rsidus. Les zones en rouge sont fortement conserves, les zones en bleu le sont faiblement.

Ces fichiers d'alignements multiples au format clustal ont t utiliss pour reconstruire les modles molculaires des cytokines et des diffrentes combinaisons de leurs rcepteurs dans le cadre du projet de Vldimir Dric. De mme, ces fichiers ont t utiliss par Perrine Barjou pour identifier les rsidus impliqus dans l'affinit et la slectivit des reconnaissances cytokine-rcepteur. 4.4.3 Production des profils propres aux domaines encods par ces familles La production des profils propres aux domaines encods par ces familles permettent de retrouver par des mthodes types chane de Markov, de nouvelles squences de systmes homologues de familles proches ou loignes Les alignements multiples ont t utiliss pour gnrer avec le programme HMMER [w40] des profils qui rendent compte des proprits des acides amins par position le long de la squence. Ces profils ont t utiliss pour rechercher des squences distantes dans la database Nrprot avec le programme HMMERsearch. 4.4.4 Produire des arbres phylogntiques ClustalW produits des arbres phylogntiques par une mthode neighbor-jonction. Sans tre excellente cette mthode cest avre suffisante dans notre tude afin de produire les cladogrammes. Perrine Barjou a explor ces arbres afin de rechercher dans leur superposition en multicouche, une couche par organisme, dventuelles corrlations entre lvolution de la cytokine et de son rcepteur.

38

5.Conclusion - futur et rflexions


5.1 Typage des donnes et services web
Un des aspects abords dans le cahier des charges est le typage des donnes changes entre les applications qui composent un workflow. L'ide premire tait d'une part d'attirer l'attention de l'utilisateur sur d'ventuelles incompatibilits (les connexions sont autorises mais affiches diffremment) et d'autre part de transformer automatiquement ces donnes pour les rendre compatibles par l'intermdiaire d'outils comme readseq [w1] ou squizz [w2] par exemple. Le typage des donnes permet de plus de guider l'utilisateur en lui proposant les applications disponibles pour un certain type de donnes. Ptolemy II dfinit dj des types pour les donnes changes entre les acteurs (boolens, entiers, flottants, chanes de caractres, matrices, compositions...) [r2] et dispose d'un mcanisme automatique de conversion et d'oprations polymorphiques entre ces types. Une solution serait donc d'tendre cette hirarchie aux types de donnes biologiques (squence, squence d'ADN, squence protique, etc.), mais on se trouve alors confront leur dfinition voire leur smantique (on peut dfinir un type 'protine' en voulant toutefois diffrencier une enzyme d'une cytokine) et on se rapproche au problme connu de cration d'ontologies. La dfinition d'ontologies aussi bien pour les donnes que pour les services est un domaine en pleine mergence mais ne couvre cependant pas tous les domaines. Gene Ontology [w3] par exemple dcrit les processus biologiques, les fonctions molculaires et les composants cellulaires mais n'aborde pas la structure des domaines protiques ou les structures tridimensionnelles. Cependant les fonctionnalits offertes ou prvues par des projets comme myGRID [w4] ou BioMOBY [w5] permettrait de profiter des capacits offertes par les services web associs ces ontologies. BioMOBY [r11] permet par exemple de dfinir des tches complexes associant la dcouverte, la distribution et le traitement de donnes biologiques via des services disponibles sur le web (enregistrs en tant que tel sur un serveur 'MOBY Central') [r4]. On pourrait ainsi imaginer des workflows composs de briques "services web" clientes dcouvertes et proposes au fur et mesure des donnes analyser ou des workflows entiers leur tour services web. Cependant les objectifs de ces projets sont ambitieux et les notions utilises pour les ontologies (comme l'utilisation de langages d'ontologies DAML+OIL ou DAML-S, une ontologie permettant de dcrire les services web [r6]) et l'architecture sont non triviales assimiler et donc encore moins implmenter ! On peut aussi noter l'approche de [r5] qui propose une ontologie dont les donnes sont dfinies par un type structural (similaire aux types utiliss par les langages de programmation et qui dtermine les valeurs autorises) et un type smantique (type de haut niveau, conceptuel). Ils aspirent ainsi combiner des services structurellement diffrents mais qui sont smantiquement compatibles. Cette approche est intressante dans la mesure o ils comptent utiliser et tendre Ptolemy II avec cette dmarche. Enfin, grce aux rcents dveloppements de Kepler, nous avons d'ores et dj intgr des services web notre plateforme et par exemple test les services offerts par l'Institut Nationale de Gntique du Japon [w17]. L'utilisation d'acteurs de transformation (XSLT, Xquery) devrait par la suite permettre de relier des services web syntaxiquement incompatibles [r7] .

39

5.2 Excutions rparties


Il s'agit ici de rpartir l'excution d'un workflow sur des "clusters" (rseau d'ordinateurs pour lesquels les changes sont rapides) ou des grilles de calcul (grid computing) pour lesquels les noeuds peuvent tre htrognes, distants et les changes de donnes lents. Chaque brique est alors excute sur un noeud particulier. Ce domaine n'en est pas moins ambitieux, surtout si l'on considre plusieurs aspects du problme lis au choix de la rpartition en fonction de l'htrognit des noeuds. Reprenons par exemple les points abords par [r10] :
les noeuds peuvent tre diffrents en terme de capacit de mmoire.

les architectures peuvent tre diffrentes (machines vectorielles ou scalaires par exemple), les

tches peuvent s'excuter plus ou moins efficacement selon ces architectures. Les tches doivent tre "proches" des donnes de taille importantes qu'elles utilisent car il peut tre prohibitif de les rpliquer sur les noeuds travers la grille de calcul. Certains logiciels possdent des licences. Il serait coteux de les installer sur tous les noeuds. Sans entrer dans toutes ces considrations et sans prtendre proposer une solution et des comparaisons exhaustives nous pourrions nous inspirer des projets tels que Biopipe, Wildfire ou Pise et intgrer des outils de soumissions de tches comme PBS [w21], LSF [w22] ou SGE[w23]. Une autre fonctionnalit implmenter est la reprise sur erreur que ce soit pour les services web ou les tches reparties. Par exemple, des projets comme Biopipe ou Taverna permettent de retenter l'excution de chaque tche un certain nombre de fois si celle-ci a chou.

5.3 Briques internes


La possibilit d'utiliser des services web ou des acteurs gnriques comme 'CmdLineApplication' ou 'MobyleApplication' pour les applications ou scripts locaux couvre a priori de nombreux domaines et donc dcharge du besoin de coder des briques spcifiques Ptolemy II. Cependant, il peut tre avantageux de construire des briques ddies (codes en java et intgres dans l'environnement) pour les raisons suivantes :
Il est plus convivial pour l'utilisateur d'avoir une bibliothque d'applications disponibles et Il est plus simple de partager des workflows sans avoir se soucier du chemin des applications Dans le cas d'application locales ('CmdLineApplication'), l'change de donnes se fait par fichiers.

facilement paramtrables. locales.

L'intgration de composants permettrait de se dgager de cette contrainte en changeant directement les flux de donnes. La sauvegarde dans un fichier ne s'effectuant que lorsque c'est ncessaire ou voulu (cf. P16). Enfin, l'ajout de briques de visualisation intgres l'environnement de Ptolemy II permettrait de profiter d'un mode d'excution qui permet d'excuter un workflow sous une forme plus concise en n'affichant que les entres et sorties (textuelles ou graphiques). La figure 29 montre par exemple un workflow entier et son excution.

40

Fig. 29 Affichage complet et l'excution correspondante. Les briques d'affichage existantes sont, relativement nos besoins, lmentaires mais on peut imaginer de crer ou adapter d'autres projets de composants java de visualisation (ou autres) comme par exemple FPV [w26] (structures protiques), BugBrowser [w27] (squences ADN), SstructView [w28] (structures secondaires d'ARN), JaMBW [w29] (squences), ATV [w30] (arbres phylogntiques) ou Cytoscape [w31] (interactions protines-protines).

5.4 Ergonomie et "utilisabilit"


Ce projet a t conu autour d'un ensemble de critres dfinis par un utilisateur final le laboratoire d'Immunogntique cellulaire - pour enchaner des tches dfinies et rpondre des questions prcises. Avant une diffusion plus large de ce projet et pour une utilisation plus aise il conviendra d'adapter l'espace de travail pour le rendre plus convivial comme par exemple laguer les branches du menu listant les acteurs (enlever les acteurs et les directeurs inutiles a priori), classer les applications et masquer les menus et les fonctionnalits abscons. Enfin, qu'en est-il de la robustesse de cet environnement et de sa gnralisation aux tches courantes en bioinformatique ?" [r13] permet de nous aiguiller sur ce point. Entre autres cette tude fait ressortir partir de consultations d'utilisateurs les composants principaux que devrait contenir une application de

41

bioinformatique, soit : Des collections d'objets (ordonnes ou non et avec redondance ou non). Des filtres avec en entre la collection d'objets filtrer, une collection de restrictions (mots- cls, identifiants de squences, etc.) appliquer sur ces objets et une collection qui dtermine les champs des objets slectionns retourner. Des convertisseurs qui transforment chaque objet de la collection en entre et retourne une collection d'objets transforms. Des composants associant les fonctions de filtre et de convertisseur. Des branches conditionnelles ou non permettant les excutions concurrentes. La figure 30 donne une reprsentation graphique et un exemple de l'assemblage de ces composants.

Fig. 30 Reprsentation des composants et exemple d'enchanement repris de [r13] Le point dlicat ici est l'intgration des collections dans nos workflows et plus prcisment leur traitement lors de l'excution. Comment en effet combiner la fois des traitements sur des objets (ex. partir d'un identifiant, rechercher dans GenBank la squence correspondante) et des collections d'objets (ex. partir d'un tableau d'identifiants construire le tableau de squences correspondantes). Ce sujet est abord par le projet Kepler/SPA dans [r14] qui propose d'amliorer un workflow construit sous Ptolemy II permettant l'identification de promoteurs [w25]. Ce workflow est reprsent par la figure 9 du chapitre 2.2.2.6, ses principaux inconvnients sont de ncessiter des relations supplmentaires entre les briques pour contrler le flux et donc d'avoir construire des briques spcifiques et difficilement rutilisables. Deux solutions sont proposes, la premire est d'intgrer des fonctions (briques) fcollection->liste et flistequi permettent respectivement les transformation d'une collection d'objets en une liste >collection d'objets (objets envoys les uns la suite des autres) et une liste en collection. La seconde solution propose de traiter les tableaux comme des listes et d'insrer des marqueurs de dbut et de fin de tableau.

42

A noter que dans tous les cas prcdents le modle d'ordonnancement choisi est PN (Process Network), dans ce modle les briques sont des tches indpendantes dont les ports d'entres sont des canaux FIFO. La brique traite les donnes en entre et envoie ventuellement des rsultats sur des ports de sortie. Elle se bloque ds que le canal est vide en attendant de nouvelles donnes. Il nous faudra aussi adapter ce modle pour implmenter l'excution partielle d'un workflow [P4] (reprise sur erreur ou choix par l'utilisateur d'un sous-ensemble par exemple).

5.5 Intgration des autres projets


Les paragraphes prcdents nous ont montr que nous avions la possibilit de profiter de dveloppements extrieurs avec bien sr principalement les projets Ptolemy II et Kepler/SPA qui sont trs actifs. Un des aspects ne pas ngliger est l'intgration de ces projets et la prise en compte de leurs volutions dans nos dveloppements. Par exemple, un dfaut du projet Kepler est d'tre bas sur une version antrieure de Ptolemy II (version 3) et donc de ne pas offrir les amliorations de la version 4. L'inclusion de leurs composants s'est fait par copier/coller avec quelques modifications dans le code, ce qui devient ingrable pour l'intgration de bibliothques et de mises jour nombreuses. Ceci passe videmment par une gestion des sources (par CVS par exemple) mais aussi par des dveloppements qui ne bouleversent pas l'architecture logicielle en place. Par exemple, Ptolemy II permet de personnaliser les diffrents menus et l'environnement de travail par l'ajout de nouvelles classes, il ne serait pas judicieux de modifier celles existantes. Plus simplement, un nouveau directeur PN sera dfini plutt que de modifier celui existant. Gageons cependant que nous aurons contourner ces voeux pieux. L'utilisation d'un gestionnaire de sources nous permettra aussi de ne garder que les composants utiles (est-il ncessaire par exemple de prendre en compte les systmes temps continu dans notre environnement) est de rduire significativement la taille de l'application.

43

Bibliographie

[r1]

[r2]

[r3]

[r4] [r5] [r6]

[r7] [r8] [r9]

[r10] [r11]

[r12]

[r13] [r14]

[r15]

S. Bhattacharyya. C. Brooks, E. Cheong, J. Davis, M. Goel, B. Kienhuis, E. A. Lee, J. Liu, X. Liu, L. Muliadi, S. Neuendorffer, J. Reekie, N. Smyth, J. Tsay, B. Vogel, W. Williams, Y. Xiong, Y. Zhao, H. Zheng. PTOLEMY II. Heterogeneous Concurent Modeling and Design in Java. Volume 1: Introduction to Ptolemy II. July 29, 2004. S. Bhattacharyya. C. Brooks, E. Cheong, J. Davis, M. Goel, B. Kienhuis, E. A. Lee, J. Liu, X. Liu, L. Muliadi, S. Neuendorffer, J. Reekie, N. Smyth, J. Tsay, B. Vogel, W. Williams, Y. Xiong, Y. Zhao, H. Zheng. PTOLEMY II. Heterogeneous Concurent Modeling and Design in Java. Volume 2: Ptolemy II Software Architecture. June 24, 2004. S. Bhattacharyya. C. Brooks, E. Cheong, J. Davis, M. Goel, B. Kienhuis, E. A. Lee, J. Liu, X. Liu, L. Muliadi, S. Neuendorffer, J. Reekie, N. Smyth, J. Tsay, B. Vogel, W. Williams, Y. Xiong, Y. Zhao, H. Zheng. PTOLEMY II. Heterogeneous Concurent Modeling and Design in Java. Volume 3: Ptolemy II Domains. June 24, 2004. M. D. Wilkinson and M. Links. BioMOBY: An Open Source Biological Web Services Proposal. Briefing In bioinformatique, vol. 3 331-341, december 2002 S. Bowers and B. Ludscher. An Ontology-Driven Framework for Data Transformation in Scientific Workflows. DILS 2004, LNBI 2994, pp 1-16, 2004 Chris Wroe, Robert Stevens, Carole Goble, Angus Roberts and Mark Greenwood. A Suite of DAML+OIL Ontologies To Describe Bioinformatics Web Services And Data. International Journal Of Cooperative Information Systems Vol. 12 No.2 197-224 Ilkay Altintas, Chad Berkley, Efrat Jaeger, Matthew Jones, Bertram Ludscher, Steve Mock. Kepler: An Extensible System for Design and Execution of Scientific Workflows. 2004 Martin Senger, Peter Rice, Tom Oinn Soaplab - a unified Sesame door to analysis tools pages 509-513 Sanner M.F., Stoffler D. and Olson A.J. (2002). ViPEr, a visual Programming Environment for Python. In Proceedings of thre 10th International Python conference. 103-115. February 4-7, 2002. ISBN 1-930792-05-0 Chua Chung Lian, Francis TANG, Praveen Issac, Arun Krishnan. GEL: Grid Execution Language. Bioinformatics Institute, Matrix#07-01-30 Biopolis St., Singapore. May 21, 2004 Wilkinson MD., Gessler D., Farmer A., Stein L. The BioMOBY project Explores Open-source, Simple, Extensible Protocols for Enabling Biological Database Interoperability. Proceedings of the Virtual Conference on Genomics and Bioinformatics. 2003 Shawn Hoon, Kiran Kumar Ratnapu, Jer-ming Chia, Balamurugan Kumarasamy, Xiao Juguang, Michele Clamp, Arne Stabenau, Simon Potter, Laura Clarke, Elia Stupka. Biopipe: A flexible Framework for Protocol_Based Bioinformatics Analysis. May 2003 Robert Stevens, Carole Goble, Patricia Baker and Andy Brass. A Classification of Tasks in Bioinformatics. July 26, 2000 Bertrand Ludscher, Ilkay Altintas. Technical Note: SciDAC-SPA-TN-2003-01. On Providing Declarative Design and Programming Constructs for Scientific Workflows based on Process Networks. August 2003 Eckenberg R, Rose T, Moreau JL, Weil R, Gesbert F, Dubois S, Tello D, Bossus M, Gras H, Tartar A, Bertoglio J, Chouaib S, Goldberg M, Jacques Y, Alzari PM, Theze J. The first alpha helix of interleukin (IL)-2 folds as a homotetramer, acts as an agonist of the IL-2 receptor beta chain, and induces lymphokine-activated killer cells. J Exp Med. 2000;191:529-40.

44

[r16]

[r17]

Rose T, Moreau JL, Eckenberg R, Thze J. Structural Analysis and Modeling of a Synthetic Interleukin-2 Mimetic and Its Interleukin-2R2 Receptor. Journal Biol Chem. 2003 278:2286876. Thompson,J.D., Gibson,T.J., Plewniak,F., Jeanmougin,F. and Higgins,D.G. (1997) The ClustalX windows interface: flexible strategies for multiple sequence alignment aided by quality analysis tools. Nucleic Acids Research, 24:4876-4882.

45

Rfrences Web

[w1] [w2] [w3] [w4] [w5] [w6] [w7] [w8] [w9] [w10] [w11] [w12] [w13] [w14] [w15] [w16] [w17] [w18] [w19] [w20] [w21] [w22] [w23] [w24] [w25] [w26] [w27] [w28] [w29] [w30] [w31] [w32] [w33] [w34] [w35] [w36] [w37] [w38]

readseq squizz Gene Ontology (GO) MyGRID BioMOBY Taverna PipelinePilot VIBE Eclipse Poseidon Pise Forms X-smiles WebRendered Gowlab Kepler XML central of DDBJ Wildfire / GEL Ptolemy II Matlab open PBS LSF SGE G_Pipe Kepler/SPA FPV BugBrowser SstructView JaMBW ATV Cytoscape HTMLEditorKit Talisman Mobyle ClustalW Jalview Indonesia T-Coffee

[w39] 3DCoffee [w40] HMMER

http://bioweb.pasteur.fr/docs/man/doc/readseq2.1 http://bioweb.pasteur.fr/seqanal/interfaces/squizz.html http://www.geneontology.org/ http://www.mygrid.org.uk/ http://biomoby.org/ http://taverna.sourceforge.net/ http://www.scitegic.com/products_services/pipeline_pilot.htm http://www.incogen.com/index.php?type=Product&param=VIBE http://www.eclipse.org http://www.gentleware.com/ http://www.pasteur.fr/recherche/unites/sis/Pise/ http://www.w3.org/TR/REC-html40/interact/forms.html http://www.xsmiles.org/ http://www.webrenderer.com/ http://industry.ebi.ac.uk/soaplab/Gowlab.html http://kepler.ecoinformatics.org/ http://xml.nig.ac.jp/wsdl/index.jsp http://web.bii.a-star.edu.sg/~francis/WildfireGEL/ http://ptolemy.eecs.berkeley.edu/ptolemyII/index.htm http://www.mathworks.com/access/helpdesk/help/toolbox/bioinfo/ug/a1 057170551.html http://www.openpbs.org/about.html http://www.platform.com/products/LSF/ http://gridengine.sunsource.net/ http://sirio.sanmartin.edu.co/Pise/gpipe.html http://130.102.113.135/gpipe.htm http://kepler.ecoinformatics.org/spa.html http://www.cs.ucsb.edu/~tcan/fpv/ http://www.stdgen.lanl.gov/genomeMap/GenomeMapDocSTD.html http://www.smi.stanford.edu/projects/helix/sstructview/ http://hometown.aol.com/lucatoldo/myhomepage/JaMBW/ http://www.genetics.wustl.edu/eddy/atv/ http://www.cytoscape.org/ examples.oreilly.com/jswing2/code/goodies/HtmlEdKit.pdf http://talisman.sourceforge.net/ http://www.pasteur.fr/recherche/unites/sis/Pise/pise-new.html http://www.ebi.ac.uk/clustalw http://www.ebi.ac.uk/~michele/jalview http://xray.bmc.uu.se/dennis/ http://igs-server.cnrsmrs.fr/~cnotred/Projects_home_page/t_coffee_home_page.html http://igs-server.cnrs-mrs.fr/Tcoffee/tcoffee_cgi/ http://hmmer.wustl.edu

46

Annexe A - Cahier des charges

Fonctionnalits de la plate forme de construction des workflows de programmes de manipulation et d'analyse de squences

Cette page prsente les fonctionnalits de l'application. Elle sert de base de discussion et est amene voluer et se dtailler en fonction des nouveaux besoins et choix. Elle permet aussi de suivre plus aisment l'avancement des dveloppements et des tests. Les fonctionnalits sont rparties en 2 groupes : Px : fonctionnalits du workflow proprement dit. Ax : fonctionnalits de la partie graphique (interaction et affichage)
P?x/A?x : propositions de fonctionnalits discuter (ides, fonctions optionnelles, etc.).

Dfinitions : TBD (To Be Defined) : voir. acteur Bloc de traitement pouvant tre une fonctionnalit interne l'application (test, affichage, boucle, comparateur,...) ou une application externe en local sur la machine ou dporte (service web, ...) donne Donne en entre ou en sortie d'un acteur (ex. une squence, une liste de squences). La donne peut tre l'information elle mme (squence FASTA, sortie XML d'un service web, ...) ou une rfrence vers cette donne (nom du fichier, URL). signifie que la fonctionnalit est ajoute et disponible l'tat actuel du projet.

P1

Liste des acteurs crire en priorit Les fonctionnalits suivantes doivent tre disponibles en priorit pour pouvoir tester les autres projets (sous la forme d'une brique interne ou d'une application externe) :

P1.1 P1.2 P1.3 P1.4 P1.5 P1.6 P1.7 P1.8

BLAST, PSI-BLAST, BLAST2P FastA ClustalW, ClustalX Smith-Waterman SignalP TMHMM ProSite HMMER, pfam

47

P1.9 P2 P2.1 P2.2

TCoffee / 3DCoffe Chargement et sauvegarde d'un workflow Le workflow cr par l'utilisateur doit pouvoir tre sauv sous la forme d'un fichier XML. Le fichier sauv doit pouvoir tre lu pour recrer un workflow ou dfinir un nouvel acteur (lments et enchanements du workflow cachs dans une "boite noire"). Moteur de workflow Les fonctionnalits de traitement de l'application sont directement dpendantes des possibilits du moteur de workflow (excutions concurrentes, boucles, branchement, ...). Ci-dessous sont listes les contrles implmenter (TBD liste affiner et mettre jour en fonction des besoins). Remarque : les fonctions de 'boucle' ne sont pas prsentes telles quelles dans Ptolemy II qui repose sur des itrations d'un workflow.

P3

P3.1 P3.2 P3.3.1 P3.3.2 P3.3.3 P3.4 P?3.5

Excutions squentielles. Excutions parallles. Boucle avec incrmentation d'un compteur. Boucle avec incrmentation des objets dans une liste de donnes ou une liste de listes de donnes. Boucle qui permet de faire voluer les paramtres des acteurs qui la composent et dont la condition d'arrt peut-tre dtermine par ces paramtres. Cration d'une bifurcation logique. Dfinit l'acteur excut en fonction du rsultat vrai/faux d'une analyse des rsultats de l'acteur prcdent. La synchronisation doit tre possible entre des acteurs qui ne sont pas relis entre eux (qui ne convergent pas vers le mme acteur ou qui n'changent pas de donnes). Excution partielles et reprise sur erreur. Plusieurs options d'excution du workflow doivent tre disponibles :

P4

P4.1 P4.2 P4.3 P4.4 P?4.5

Excution globale partir du ou des points de dpart. Excution acteur par acteur avec attente de validation chaque pause ou chaque tour de boucle (mode pas pas). Excution d'une sous partie du workflow dtermine par une slection d'une zone sur l'interface graphique. Possibilit d'ajouter des points d'arrt. Pouvoir choisir les ressources o excuter les processus. A priori cette fonction peut tre relgue une application extrieure (solution de cluster de type PBS par exemple). Benchmark Un ordre de grandeur du temps d'excution d'une partie ou de la globalit du workflow doit pouvoir tre fourni (TBD : possible ?)

P?5

48

P6 P6.1

acteurs supplmentaires acteur STOP : arrt avec reprise ventuelle (TBD : ce n'est pas trivial car cela dpend du mode d'ordonnancement choisi dans Ptolemy II et donc serait implmenter pour chaque directeur). acteur END : arrt de l'ensemble du workflow Arrt du workflow l'issue de l'excution d'un acteur. Envoi d'un mail (cet acteur est disponible dans Kepler mais est trs basique). Les cas d'utilisation sont dtailler. Ajout d'une application Mobyle Rutilisation du formalisme utilis par Mobyle (prochaine volution de Pise) : une application externe doit pouvoir tre dfinie par le fichier XML respectant la DTD de Mobyle. Ce fichier dcrit les paramtres d'entre et de sortie et le type de l'application (service web, application locale, CGI). L'utilisateur peut, pour chaque paramtre d'entre, spcifier s'il s'agit d'un port en entre, d'une expression valuer au moment de l'excution (oprations entre paramtres dfinis dans l'environnement de Ptolemy II) ou d'une valeur classique. Cette configuration est faite par l'intermdiaire d'une page web similaire celles qui sont gnres par Pise. TBD : Un prototype est en cours pour valider la faisabilit. Il tend la fonction prcdente l'excution de cgi accessibles par des pages web. Il dfinit deux urls, la premire correspond au fichier XML (url_XML), la seconde la page html (url_presentation) de configuration de l'acteur. Nous avons alors les 3 cas suivants : url_XML seule : la page html de configuration est gnre partir du fichier XML. A partir de cette page l'utilisateur spcifie les ports d'entre, les expressions et les valeurs. Les ports de sortie sont aussi dtermins partir du fichier XML. url_html seule : la page html du site est affiche, l'utilisateur peut naviguer avec les liens hypertexte pour trouver le formulaire qui correspond au service dsir. Ensuite il spcifie le type des champs dans ce formulaire. A l'excution de l'acteur, la requte est envoye au serveur (de la mme manire que si l'utilisateur appuyait sur 'submit'). La page html retourne par le serveur est envoye sur un port de sortie. url_XML et url_html : le comportement est le mme que dans le premier cas la diffrence que l'affichage correspond url_html. Ceci permet d'offrir une interface similaire celle d'un site d'origine (plus simplement qu' partir de la dfinition du fichier XML). Cela suppose bien sr que le formulaire dfinit dans url_html soit compatible avec le fichier XML. Les restrictions et les diffrentes normes prendre en compte sont dtailler partir de l'exprience du prototype !

P6.2 P6.3 P6.4

P7 P7.1

49

P8 P8.1

Ajout d'une application externe L'acteur qui permet de dfinir une application externe a comme nom 'CmdLineApplication'. Il permet l'utilisateur d'excuter une application locale avec les paramtres suivants : Le chemin vers l'application. La liste des paramtres de l'application. Le rpertoire de travail. Les variables d'environnement. La liste des paramtres permet en fait de prendre en compte l'environnement Ptolemy II comme par exemple les ports en entre et en sortie et les paramtres de l'espace de travail (workspace). Elle est de la forme suivante :
parameters_list in_port expression exprstring out_port port_name out_port_value out_port_string string ::::::::(string | in_port | expression | out_port )* in{port_name} exp{exprstring} "Expression valide dans l'environnement de Ptolemy" out{port_name}={out_port_value} "Nom de port valide dans l'environnement de Ptolemy" (string | expression | in_port)+ "chane de caractres quelconque qui ne contient pas les expressions dfinies pour in_portname ou expression." :- "chane de caractres quelconque non nulle qui ne contient pas les expressions dfinies pour in_portname, expression ou out_port."

Aprs la saisie de ces paramtres, les ports d'entre (dfinis par in{port_name}) et de sortie (dfinis par out{port_name}) sont ajouts ou supprims conformment ce qui est rentr sur la ligne de commande. Lors de l'excution : Les chanes de type in{port_name} sont remplaces par le contenu des ports en entre. Les chanes de type 'exp{expstring}' sont remplaces par le rsultat de l'valuation de 'expstring' par Ptolemy. Les chanes 'val_out' dfinies par out{port_out}={val_out} sont envoyes sur leur port correspondant 'port_out'. Ces chanes peuvent tre le rsultat d'une premire valuation (cas o la valeur est de type 'parameter' ou port_in). Deux ports supplmentaires sont automatiquement crs : 'trigger' : port en entre qui permet d'attendre un lment quelconque en entre avant d'excuter l'application. Ce port est inactif s'il n'est pas reli. 'exit_value' : port en sortie qui contient la valeur retourne par l'application aprs l'excution. Exemple : Programme cosa
nom de l'application : /usr/bin/cosa paramtres : in{port_aln} exp{position} in{port_pdb} out{sortie_pdb}={resu_pdb.pdb} out{sortie_txt}={exp{fichier_txt}} rpertoire de travail : /home/user/tmp/ variables d'environnement : {{name = "", value = ""}}

Aprs l'entre des paramtres les ports d'entre 'port_aln', et 'port_pdb' sont crs et le port de sortie 'sortie_pdb' est cr. 'position' et 'fichier_txt' sont des paramtres dfinis dans l'espace de travail par l'utilisateur. A l'excution, les chanes de type in{nom_port} sont remplaces par le contenu du port 'nom_port', les expressions sont values et les chanes de type out{port_out}= {val_out} sont remplaces par 'val_out' (ventuellement value). La ligne de commande relle excute est, avec position=4, fichier_txt="~/tmp/resu.txt" et port_aln="fichier.aln", fichier_pdb="fichier.pdb" :
cosa fichier.aln 4 fichier.pdb resu_pdb.pdb ~/tmp/resu.txt

A la fin de l'excution, les chanes "resu_pdb.pdb" et "~/tmp/resu.txt" sont envoyes respectivement sur les ports sortie_pdb et sortie_txt.

50

P?9

Ajout de types de donnes Des types doivent pouvoir tre dfinis pour les donnes changes dans un workflow. Ces types peuvent tre primitifs (entiers, boolens,..), des types "biologiques" (squence d'ADN ou protique, structures ,...), des collections de types (collections ordonnes ou non, avec doublons ou non...) ou encore une rfrence vers une donne (ex. nom de fichier ou URN dcrivant une squence). Cette fonctionnalit permet d'une part d'attirer l'attention de l'utilisateur sur d'ventuelles incompatibilits (les connexions sont autorises mais affiches diffremment) et d'autre part de transformer automatiquement ces donnes pour les rendre compatibles par l'intermdiaire d'outils comme readseq ou squizz par exemple. Le typage des donnes permet de plus de guider l'utilisateur en lui proposant les applications disponibles pour un certain type de donnes. Cette fonctionnalit est approfondir : l'utilisateur peut-il rajouter ses types de donnes, dfinir leurs compatibilits et les outils de transformations ? comment peut-on utiliser les ontologies dj dfinies (cf. BioMOBY, myGRID, GeneOntology, ...)

P10 P10.1 P10.2

Liens entre donnes et acteurs Le lien (entre ou sortie) entre une donne et le port d'entre d'un acteur peut se faire mme s'ils ne sont pas compatibles. Si la donne et l'acteur ne sont pas compatibles, le lien est reprsent de manire diffrente. L'utilisateur a la possibilit de demander l'application d'ajouter un ou des acteurs intermdiaires (wrappers) pour les rendre compatibles. Si plusieurs possibilits existent une liste est propose. Les acteurs intermdiaires ne font que de la traduction de donnes (adaptation de formats par exemple). Support des services web A dfinir en fonction des solutions retenues pour les types de donnes. En plus du service proprement dit, il serait intressant d'utiliser des mcanismes de dcouverte de ces services ( voir en fonction des solutions disponibles). Remarque : Kepler implmente dj des services web, voir comment les adapter notre plateforme.

P10.3

P?11

P?12

Rpartition de la charge d'excution L'application doit permettre une rpartition de la charge si plusieurs ressources de calcul sont disponibles. Cette fonctionnalit est approfondir ! Nous pouvons a priori considrer au moins trois cas : les acteurs lancent des programmes locaux (cration de processus). Un outil externe comme PBS peut tre utilis. Les acteurs font partie intgrante de l'application (ils sont lancs sous forme de threads). Les acteurs sont des services web ou font appel des cgi.

51

P13 P13?.1

Comportement des acteurs Sur erreur, il doit y avoir une possibilit d'avoir une alternative (soit arrt du workflow soit re-tentative avec un nombre dfinissable de tentatives et de dures entre ces tentatives). Remarque : fonctionnalits implmentes dans Taverna. Excution de plusieurs instances d'un modle workflow, comparaison des rsultats L'utilisateur doit pouvoir faire tourner plusieurs instances d'un modle de workflow. Plusieurs modles de workflow peuvent tre ouvert et excuts en mme temps. Les rsultats des diffrentes excutions (issus d'un mme modle ou de modles diffrents) peuvent tre compars entre eux. Applications et donnes locales L'utilisateur doit pouvoir choisir un ou des chemins par dfaut pour l'excution des applications. L'utilisateur doit pouvoir choisir un ou des chemins par dfaut pour la localisation des donnes locales. Sauvegarde et visualisation de donnes entre acteurs Un acteur particulier permet de sauver sous la forme d'un fichier des donnes changes entre deux acteurs (il s'insre entre les deux acteurs), ceci permet de pouvoir visualiser ces donnes et de dfinir des points de sauvegarde sur lesquels le workflow pourra redmarrer (cas d'une excution partielle ou d'une reprise sur erreur). Il peut :

P14 P14.1 P14.2 P14.3

P15 P15.1 P15.2

P16

P16.1

Sauver les donnes qu'il reoit en entre et les fournir en sortie sans modification si l'utilisateur n'y a apport aucune modification. Remarque : il sera certainement souhaitable d'empcher la modification des donnes pour viter des incohrences dans le workflow (il faut s'assurer que c'est toujours la mme donne pour les diffrents traitements !). En fonction du type de donne on peut tre amen enregistrer seulement la rfrence (cas d'un fichier ou d'une URN par exemple) ou 'srialiser' la donne (cas d'une squence reprsente par une chane de caractres par exemple) dans un fichier ou une base de donne puis la reconvertir dans son format d'origine en sortie de l'acteur. Visualiser ces donnes en fonction de leur type en proposant plusieurs outils de visualisations et/ou d'dition disponibles. Associer ces donnes une instance particulire du workflow. Sauver ces donnes sous un format compress selon le choix de l'utilisateur. Plateformes supportes L'excution sera indpendante de la nature du matriel et du systme d'exploitation.

P16.2 P16.3 P16?.4 P17

52

P18 P18.1 P18.2

Excution en arrire plan Les workflows crs par l'utilisateur doivent pouvoir tre lancs en arrire plan, leur excution ne sera alors pas interrompue par la fermeture du gestionnaire graphique. L'utilisateur pourra partir du gestionnaire graphique rouvrir une instance partir de la liste des workflows lancs en arrire plan (issu de cette session graphique ou d'une autre) par cet utilisateur. Le workflow ouvert affichera l'tat en cours et sera modifiable comme un workflow classique. Donnes Les donnes en entre (i.e. : qui ne sont pas issue d'une acteur) suivantes doivent tre dfinies en priorit, cette fonction est cependant dpendante du choix retenu pour P?9 :

P18.3

P19

P19.1 P19.2 P19.3 P19.4 A1

Une squence de protines, son identificateur ou une liste de squences de protines. Une structure de protines, son identificateur ou une liste de squences de protines. Une ou des listes de paires de squences de protines formant un rseau continu ou disjoint. Un arbre phylogntique ou une liste d'arbres. Affichage des liens Lors de la cration d'un lien entre une donne et un acteur, le trait est continu si la compatibilit est confirme et discontinu sinon.

A2 A2.1

Zooms Zoom sur un acteur qui contient un workflow : les acteurs qui contiennent des workflows peuvent tre visualiss sous leur forme condense (un acteur) ou clate (lments du workflow). Les lments du workflow ont plusieurs reprsentations en fonction du zoom (avec plus ou moins de dtails). A confirmer cependant, il semble plus judicieux de garder la mme reprsentation quel que soit le zoom. Il doit tre possible d'afficher un ensemble d'lments sous la forme d'un seul (diffrent de la transformation d'un workflow en acteur) par exemple aprs slection avec un menu (view as box) puis ensuite revenir la vue clate. Reprsentation arborescente Les lments du workflow (donnes, acteurs, liens) seront aussi reprsents et modifiables sous forme d'arbres. Facilits de visualisation Un espace affichera une vue gnrale du workflow. Une fentre "tip" affichera une aide sur l'acteur slectionn dans le workflow ou dans la liste des applications (voir le workflow VIBE).

A2.2

A2.3

A3 A3.1

A4 A4.1 A?4.2

53

A?4.3 A4.4

Des commentaires peuvent tre ajouts par l'utilisateur un acteur (voir le workflow VIBE). Un espace affichera les vnements lis au workflow et aux acteurs (tat de l'excution, warnings, erreurs,...) Recherche d'un acteur Un menu doit permettre de rechercher les acteurs par le nom ou leur description.

A5

54

Annexe B - Diagramme statique

55

Annexe C - Diagramme statique : MobyleApplication

56

Annexe D - DTD de Mobyle

<!-- DTD for Mobyle descriptions <!ENTITY <!ENTITY <!ENTITY <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT <!ELEMENT % word % number % boolean "CDATA"> "CDATA"> "CDATA">

-->

mobyle (program|pipeline)> program (head, parameters)> head (name, version?, doc, category*, command, layout?)> name (#PCDATA)> <!-- the name of the program ex : blast2 --> version (#PCDATA)> <!-- the version of the program --> doc (title, description?, authors?, reference*, doclink*, help?)>

<!ELEMENT category (#PCDATA)> <!-- to classified the programs in group ex :DNA analysis, phylogeny ... --> <!ELEMENT title (#PCDATA)> <!ELEMENT description (text)+> <!-- a short description of the program (1 line) ex for melting it's: enthalpie, entropy and melting temperature --> <!ELEMENT authors (#PCDATA)> <!ELEMENT reference (#PCDATA)> <!ELEMENT doclink (#PCDATA)> <!-- the list of the authors --> <!-- the bibliographics references --> <!-- a link to the documentation --> -->

<!ELEMENT help (text)+> <!-- a general help on the program

<!ELEMENT command (#PCDATA)> <!ATTLIST command name %word; #REQUIRED type (local|GET|POST|POSTM|soap|xml-rpc) #IMPLIED path %word; #IMPLIED > <!-for local program: name is the name of the command type is local (by default) path the path where is the program (by default the PATH variable) for cgi: name is the name of the script eg: myScript.cgi type is the method to call the cgi (GET|POST|POSTM) path is the url where is the script http://www.myDomain.org for web service: name is the method name type is the protocol to call the ws soap|xml-rpc ... path is the url of the wsdl --> <!ELEMENT parameters (parameter|paragraph|info)+> <!ELEMENT paragraph (name,prompt,precond?,argpos?,format?,comment?,parameters, layout?)> <!ELEMENT info (text)+> <!-- permit to insert text or code --> <!ELEMENT layout (hbox|vbox)+> <!-- specified a layout to display a set of parameter --> <!ELEMENT hbox (#PCDATA|(hbox|vbox)+)> <!-- to display the parameters horizontaly --> <!ELEMENT vbox (#PCDATA|(hbox|vbox)+)> <!-- to display the parameters vertically --> <!ELEMENT parameter (name,attributes,interface?)> <!ATTLIST parameter type (InFile|Sequence|Structure|OutFile|Results|Switch|Excl|List|Integer|Float|String) #REQUIRED ismandatory %boolean; #IMPLIED iscommand %boolean; #IMPLIED ishidden %boolean; #IMPLIED isstandout %boolean; #IMPLIED issimple %boolean; #IMPLIED

57

formfield %word; #IMPLIED > <!-ismandatory : if true this parameter should be specified iscommand : if true, this parameter specify the line of command to run the program used when the command line is more complicated isstandout : usualy the cgi redirect the output in a file programName.out.some programs have already a text output and the cgi should not redirect the output. issimple : specify if this parameter will be displayed only in the simple web form. formfield : specify the look of this parameter in the interface ex: in html :select, checkbox ... --> <!ELEMENT attributes (prompt|format|vdef|argpos|vlist|flist|comment|seqfmt|seqtype|ctrl|precond| paramfile|filenames|scalemin|scalemax|scaleinc|separator|width|height|pipe|withpipe|example)+> <!ELEMENT prompt (#PCDATA)> <!ATTLIST prompt lang %word; #REQUIRED > <!-- suggestion xml:lang NMTOKEN iso639-1 --> <!ELEMENT format (code)> <!ELEMENT vdef ((value)+|(code)+)> <!-- the default value for the parameter -->

<!ELEMENT argpos (#PCDATA)> <!-in parameter: specify the position of this parameter on the commad line in paragraph: specifiy the position on the command line for all parameters of this paragraph --> <!ELEMENT vlist (value,label)+> <!ELEMENT label (#PCDATA)> the form --> <!-- a list of the available values for this parameter --> <!-- the text associated to a value which will be display on

<!ELEMENT flist (value,code)+> <!-- it's used in conjonction with vlist, permit to associate code to a value of the vlist. (flist it's an easy way to have a code associated whith each value in a list ) --> <!ELEMENT comment (text)+> <!ELEMENT seqfmt (value)+> 2. GenBank/GB 3. NBRF 4. EMBL <!ELEMENT seqtype (#PCDATA)> gapprotein, any, gapany --> <!-- it's used to generate an help --> <!-- the number of the sequence format in readseq etc ... --> 1. IG/Stanford

<!-- the common values: dna, puredna, protein, pureprotein, specified the possible values -->

<!ELEMENT ctrl (message,code)+)> <!-<!ELEMENT message (#PCDATA)>

<!ELEMENT precond (code)+> <!-- in parameter : the parameter is link to a condition ex : this parameter could be used only if an other paramater has been specified --> <!ELEMENT paramfile (#PCDATA)> <!-- the name of the file when the parameters are specified in a file instead on command line --> <!ELEMENT filenames (#PCDATA)> <!-- the unix mask to retrieve the results files ex: *.aln ,*.dnd ... --> <!ELEMENT scalemin (value|(code)+)> <!ELEMENT scalemax (value|(code)+)> <!ELEMENT scaleinc (#PCDATA)> <!ELEMENT separator (#PCDATA)> <!ELEMENT width (#PCDATA)> <!-- the width of an input or textarea in the html form --> <!ELEMENT height (#PCDATA)> <!-- the height of an input or textarea in the html form --> <!ELEMENT pipe (pipetype,(code)+)+> <!ELEMENT withpipe (pipetype,(pipeparameter)+)+> <!ELEMENT pipeparameter (#PCDATA)> <!ELEMENT value (#PCDATA)> <!ELEMENT code (#PCDATA)> <!-- a part of code in programmation language --> <!ATTLIST code proglang %word; #REQUIRED> <!-- proglang: the language in wich the code is written--> <!ELEMENT name (#PCDATA)>

58

<!ELEMENT pipetype (#PCDATA)> <!ELEMENT text (#PCDATA)> <!ATTLIST text proglang %word; #IMPLIED lang %word; #IMPLIED href %word; #IMPLIED > <!ELEMENT pipeline name, title?, (stage)+> <!ELEMENT stage (arg*, pipe)> <!ATTLIST stage id %word; #REQUIRED name %word; #REQUIRED server %word; #REQUIRED > <!-id : the identifier of the stage name : a name of a program or a pipline (any xml file in pise) server: the address where the service will be executed --> <!ELEMENT arg (#PCDATA)> <!ATTLIST arg name %word; #REQUIRED> <!-- a value for a parameter --> <!-- name: the name of a parameter --> -->

<!ELEMENT pipe (in|out)+> <!ELEMENT in (#PCDATA)> <!-- the previous stage id <!ATTLIST in id %word; #REQUIRED pipetype %word; #REQUIRED parameter %word; #REQUIRED > <!ELEMENT out (#PCDATA)> <!-- the next stage id --> <!ATTLIST out id %word; pipetype %word; parameter %word; > #REQUIRED #REQUIRED #REQUIRED

<!ELEMENT interface (field+|layout?)> <!ELEMENT field (name|prompt?|comment?) > <!ATTLIST field formfield (upload|textarea|text)>

59

GNU Free Documentation License Version 1.2, November 2002

Copyright (C) 2000,2001,2002 Free Software Foundation, Inc. 59 Temple Place, Suite 330, Boston, MA 02111-1307 USA Everyone is permitted to copy and distribute verbatim copies of this license document, but changing it is not allowed.

0. PREAMBLE The purpose of this License is to make a manual, textbook, or other functional and useful document "free" in the sense of freedom: to assure everyone the effective freedom to copy and redistribute it, with or without modifying it, either commercially or noncommercially. Secondarily, this License preserves for the author and publisher a way to get credit for their work, while not being considered responsible for modifications made by others. This License is a kind of "copyleft", which means that derivative works of the document must themselves be free in the same sense. It complements the GNU General Public License, which is a copyleft license designed for free software. We have designed this License in order to use it for manuals for free software, because free software needs free documentation: a free program should come with manuals providing the same freedoms that the software does. But this License is not limited to software manuals; it can be used for any textual work, regardless of subject matter or whether it is published as a printed book. We recommend this License principally for works whose purpose is instruction or reference.

1. APPLICABILITY AND DEFINITIONS This License applies to any manual or other work, in any medium, that contains a notice placed by the copyright holder saying it can be distributed under the terms of this License. Such a notice grants a world-wide, royalty-free license, unlimited in duration, to use that work under the conditions stated herein. The "Document", below, refers to any such manual or work. Any member of the public is a licensee, and is addressed as "you". You accept the license if you copy, modify or distribute the work in a way requiring permission under copyright law.

A "Modified Version" of the Document means any work containing the Document or a portion of it, either copied verbatim, or with modifications and/or translated into another language. A "Secondary Section" is a named appendix or a front-matter section of the Document that deals exclusively with the relationship of the publishers or authors of the Document to the Document's overall subject (or to related matters) and contains nothing that could fall directly within that overall subject. (Thus, if the Document is in part a textbook of mathematics, a Secondary Section may not explain any mathematics.) The relationship could be a matter of historical connection with the subject or with related matters, or of legal, commercial, philosophical, ethical or political position regarding them. The "Invariant Sections" are certain Secondary Sections whose titles are designated, as being those of Invariant Sections, in the notice that says that the Document is released under this License. If a section does not fit the above definition of Secondary then it is not allowed to be designated as Invariant. The Document may contain zero Invariant Sections. If the Document does not identify any Invariant Sections then there are none. The "Cover Texts" are certain short passages of text that are listed, as Front-Cover Texts or Back-Cover Texts, in the notice that says that the Document is released under this License. A Front-Cover Text may be at most 5 words, and a Back-Cover Text may be at most 25 words. A "Transparent" copy of the Document means a machine-readable copy, represented in a format whose specification is available to the general public, that is suitable for revising the document straightforwardly with generic text editors or (for images composed of pixels) generic paint programs or (for drawings) some widely available drawing editor, and that is suitable for input to text formatters or for automatic translation to a variety of formats suitable for input to text formatters. A copy made in an otherwise Transparent file format whose markup, or absence of markup, has been arranged to thwart or discourage subsequent modification by readers is not Transparent. An image format is not Transparent if used for any substantial amount of text. A copy that is not "Transparent" is called "Opaque". Examples of suitable formats for Transparent copies include plain ASCII without markup, Texinfo input format, LaTeX input format, SGML or XML using a publicly available DTD, and standard-conforming simple HTML, PostScript or PDF designed for human modification. Examples of transparent image formats include PNG, XCF and JPG. Opaque formats

include proprietary formats that can be read and edited only by proprietary word processors, SGML or XML for which the DTD and/or processing tools are not generally available, and the machine-generated HTML, PostScript or PDF produced by some word processors for output purposes only. The "Title Page" means, for a printed book, the title page itself, plus such following pages as are needed to hold, legibly, the material this License requires to appear in the title page. For works in formats which do not have any title page as such, "Title Page" means the text near the most prominent appearance of the work's title, preceding the beginning of the body of the text. A section "Entitled XYZ" means a named subunit of the Document whose title either is precisely XYZ or contains XYZ in parentheses following text that translates XYZ in another language. (Here XYZ stands for a specific section name mentioned below, such as "Acknowledgements", "Dedications", "Endorsements", or "History".) To "Preserve the Title" of such a section when you modify the Document means that it remains a section "Entitled XYZ" according to this definition. The Document may include Warranty Disclaimers next to the notice which states that this License applies to the Document. These Warranty Disclaimers are considered to be included by reference in this License, but only as regards disclaiming warranties: any other implication that these Warranty Disclaimers may have is void and has no effect on the meaning of this License.

2. VERBATIM COPYING You may copy and distribute the Document in any medium, either commercially or noncommercially, provided that this License, the copyright notices, and the license notice saying this License applies to the Document are reproduced in all copies, and that you add no other conditions whatsoever to those of this License. You may not use technical measures to obstruct or control the reading or further copying of the copies you make or distribute. However, you may accept compensation in exchange for copies. If you distribute a large enough number of copies you must also follow the conditions in section 3. You may also lend copies, under the same conditions stated above, and you may publicly display copies.

3. COPYING IN QUANTITY

If you publish printed copies (or copies in media that commonly have printed covers) of the Document, numbering more than 100, and the Document's license notice requires Cover Texts, you must enclose the copies in covers that carry, clearly and legibly, all these Cover Texts: Front-Cover Texts on the front cover, and Back-Cover Texts on the back cover. Both covers must also clearly and legibly identify you as the publisher of these copies. The front cover must present the full title with all words of the title equally prominent and visible. You may add other material on the covers in addition. Copying with changes limited to the covers, as long as they preserve the title of the Document and satisfy these conditions, can be treated as verbatim copying in other respects. If the required texts for either cover are too voluminous to fit legibly, you should put the first ones listed (as many as fit reasonably) on the actual cover, and continue the rest onto adjacent pages. If you publish or distribute Opaque copies of the Document numbering more than 100, you must either include a machine-readable Transparent copy along with each Opaque copy, or state in or with each Opaque copy a computer-network location from which the general network-using public has access to download using public-standard network protocols a complete Transparent copy of the Document, free of added material. If you use the latter option, you must take reasonably prudent steps, when you begin distribution of Opaque copies in quantity, to ensure that this Transparent copy will remain thus accessible at the stated location until at least one year after the last time you distribute an Opaque copy (directly or through your agents or retailers) of that edition to the public. It is requested, but not required, that you contact the authors of the Document well before redistributing any large number of copies, to give them a chance to provide you with an updated version of the Document.

4. MODIFICATIONS You may copy and distribute a Modified Version of the Document under the conditions of sections 2 and 3 above, provided that you release the Modified Version under precisely this License, with the Modified Version filling the role of the Document, thus licensing distribution and modification of the Modified Version to whoever possesses a copy of it. In addition, you must do these things in the Modified Version:

A. Use in the Title Page (and on the covers, if any) a title distinct from that of the Document, and from those of previous versions (which should, if there were any, be listed in the History section of the Document). You may use the same title as a previous version if the original publisher of that version gives permission. B. List on the Title Page, as authors, one or more persons or entities responsible for authorship of the modifications in the Modified Version, together with at least five of the principal authors of the Document (all of its principal authors, if it has fewer than five), unless they release you from this requirement. C. State on the Title page the name of the publisher of the Modified Version, as the publisher. D. Preserve all the copyright notices of the Document. E. Add an appropriate copyright notice for your modifications adjacent to the other copyright notices. F. Include, immediately after the copyright notices, a license notice giving the public permission to use the Modified Version under the terms of this License, in the form shown in the Addendum below. G. Preserve in that license notice the full lists of Invariant Sections and required Cover Texts given in the Document's license notice. H. Include an unaltered copy of this License. I. Preserve the section Entitled "History", Preserve its Title, and add to it an item stating at least the title, year, new authors, and publisher of the Modified Version as given on the Title Page. If there is no section Entitled "History" in the Document, create one stating the title, year, authors, and publisher of the Document as given on its Title Page, then add an item describing the Modified Version as stated in the previous sentence. J. Preserve the network location, if any, given in the Document for public access to a Transparent copy of the Document, and likewise the network locations given in the Document for previous versions it was based on. These may be placed in the "History" section. You may omit a network location for a work that was published at least four years before the Document itself, or if the original publisher of the version it refers to gives permission. K. For any section Entitled "Acknowledgements" or "Dedications", Preserve the Title of the section, and preserve in the section all the substance and tone of each of the contributor acknowledgements and/or dedications given therein. L. Preserve all the Invariant Sections of the Document, unaltered in their text and in their titles. Section numbers or the equivalent are not considered part of the section titles. M. Delete any section Entitled "Endorsements". Such a section may not be included in the Modified Version. N. Do not retitle any existing section to be Entitled "Endorsements" or to conflict in title with any Invariant Section.

O. Preserve any Warranty Disclaimers. If the Modified Version includes new front-matter sections or appendices that qualify as Secondary Sections and contain no material copied from the Document, you may at your option designate some or all of these sections as invariant. To do this, add their titles to the list of Invariant Sections in the Modified Version's license notice. These titles must be distinct from any other section titles. You may add a section Entitled "Endorsements", provided it contains nothing but endorsements of your Modified Version by various parties--for example, statements of peer review or that the text has been approved by an organization as the authoritative definition of a standard. You may add a passage of up to five words as a Front-Cover Text, and a passage of up to 25 words as a Back-Cover Text, to the end of the list of Cover Texts in the Modified Version. Only one passage of Front-Cover Text and one of Back-Cover Text may be added by (or through arrangements made by) any one entity. If the Document already includes a cover text for the same cover, previously added by you or by arrangement made by the same entity you are acting on behalf of, you may not add another; but you may replace the old one, on explicit permission from the previous publisher that added the old one. The author(s) and publisher(s) of the Document do not by this License give permission to use their names for publicity for or to assert or imply endorsement of any Modified Version.

5. COMBINING DOCUMENTS You may combine the Document with other documents released under this License, under the terms defined in section 4 above for modified versions, provided that you include in the combination all of the Invariant Sections of all of the original documents, unmodified, and list them all as Invariant Sections of your combined work in its license notice, and that you preserve all their Warranty Disclaimers. The combined work need only contain one copy of this License, and multiple identical Invariant Sections may be replaced with a single copy. If there are multiple Invariant Sections with the same name but different contents, make the title of each such section unique by adding at the end of it, in parentheses, the name of the original author or publisher of that section if known, or else a unique number. Make the same adjustment to the section titles in the list of

Invariant Sections in the license notice of the combined work. In the combination, you must combine any sections Entitled "History" in the various original documents, forming one section Entitled "History"; likewise combine any sections Entitled "Acknowledgements", and any sections Entitled "Dedications". You must delete all sections Entitled "Endorsements".

6. COLLECTIONS OF DOCUMENTS You may make a collection consisting of the Document and other documents released under this License, and replace the individual copies of this License in the various documents with a single copy that is included in the collection, provided that you follow the rules of this License for verbatim copying of each of the documents in all other respects. You may extract a single document from such a collection, and distribute it individually under this License, provided you insert a copy of this License into the extracted document, and follow this License in all other respects regarding verbatim copying of that document.

7. AGGREGATION WITH INDEPENDENT WORKS A compilation of the Document or its derivatives with other separate and independent documents or works, in or on a volume of a storage or distribution medium, is called an "aggregate" if the copyright resulting from the compilation is not used to limit the legal rights of the compilation's users beyond what the individual works permit. When the Document is included in an aggregate, this License does not apply to the other works in the aggregate which are not themselves derivative works of the Document. If the Cover Text requirement of section 3 is applicable to these copies of the Document, then if the Document is less than one half of the entire aggregate, the Document's Cover Texts may be placed on covers that bracket the Document within the aggregate, or the electronic equivalent of covers if the Document is in electronic form. Otherwise they must appear on printed covers that bracket the whole aggregate.

8. TRANSLATION Translation is considered a kind of modification, so you may

distribute translations of the Document under the terms of section 4. Replacing Invariant Sections with translations requires special permission from their copyright holders, but you may include translations of some or all Invariant Sections in addition to the original versions of these Invariant Sections. You may include a translation of this License, and all the license notices in the Document, and any Warranty Disclaimers, provided that you also include the original English version of this License and the original versions of those notices and disclaimers. In case of a disagreement between the translation and the original version of this License or a notice or disclaimer, the original version will prevail. If a section in the Document is Entitled "Acknowledgements", "Dedications", or "History", the requirement (section 4) to Preserve its Title (section 1) will typically require changing the actual title.

9. TERMINATION You may not copy, modify, sublicense, or distribute the Document except as expressly provided for under this License. Any other attempt to copy, modify, sublicense or distribute the Document is void, and will automatically terminate your rights under this License. However, parties who have received copies, or rights, from you under this License will not have their licenses terminated so long as such parties remain in full compliance.

10. FUTURE REVISIONS OF THIS LICENSE The Free Software Foundation may publish new, revised versions of the GNU Free Documentation License from time to time. Such new versions will be similar in spirit to the present version, but may differ in detail to address new problems or concerns. See http://www.gnu.org/copyleft/. Each version of the License is given a distinguishing version number. If the Document specifies that a particular numbered version of this License "or any later version" applies to it, you have the option of following the terms and conditions either of that specified version or of any later version that has been published (not as a draft) by the Free Software Foundation. If the Document does not specify a version number of this License, you may choose any version ever published (not as a draft) by the Free Software Foundation.