MobyleNet – – Un environnement de développement et de production de web-services BioMOBY Sébastien Carrere

MobyleNet – – BioMOBY ? ► But: fournir des ressources bioinformatiques (données, programmes) via le web ► Comment:  Des spécifications pour la description des services, la gestion des erreurs, l’implémentation de services asynchrones  Une API multi-langages (Perl / JAVA / Python)  Un annuaire pour faciliter la découverte  Un protocole de communication basé sur une ontologie ► Types de services ► DataTypes (typage métier des entrées / sorties)

MobyleNet – – DataType BioMOBY ► Spécification des entrées  spécialisation du service  Un service pouvant manipuler un fichier FASTA (ex: squizz), peut manipuler un fichier FASTA proteique  Un service analysant une proteine (ex: blastp) ne peut pas traiter une sequence nucleique ► Spécification des sorties  limitation des chaînages

MobyleNet – – Architecture BioMOBY PublierChercher Invoquer Annuaire Fournisseur Service Descriptions (RDF) Service Description (RDF) Service (fonction) WDSL, UDDI WSDL, UDDI Client

MobyleNet – – Un LIPM  on peut toujours utiliser ces programmes en ligne de commande  on peut les encapsuler via d'autres technologies (CGI, Mobyle) ► Un web-service est l'encapsulation d'un programme déjà existant ► Ce programme manipule des fichiers ► Pourquoi PlayMOBY ?  Déployer de nouveaux web-services ► Automatiquement ► pour des programmes existants (et maintenus !) ► pour les futurs programmes ► Pourquoi Mobyle  Utiliser un format pivot pour la description  Experience.acd EMBOSS  Profiter des programmes déjà décrits

MobyleNet – – PlayMOBY : les 3 étapes 1. Génération d'un fichier de description Mobyle XML Appli.pm: un module pour générer ces fichiers XML 2. Génération du web-service à partir de la description XML 3. Enregistrement et tests

MobyleNet – – PlayMOBY :Appli.pm PlayMOBY : Appli.pm ► Pourquoi ?  Avoir une description du programme embarquée  Restituer la description sous différents formats ► Mobyle ► Usage ? ACD ? ► Comment ?  Structures Perl de description embarquées  Dictionnaire BioMOBY   Mobyle

MobyleNet – – Interopérabilité

MobyleNet – – BIOS: Service Oriented Architecture in Bioinformatics dedicated to RNA-Seq External tools: tools developped by other teams (almost EMBOSS) iANT: tools for sequence annotation HeliaGene: a bioinformatics portal for Helianthus sp. genomics LEGOO: a bioinformatics gateway towards integrative legume biology Narcisse: a mirror view of conserved syntenies collaboration with Thomas Faraut - Laboratoire de Génétique Cellulaire ► Transparence  Réseau de confiance & QoS (i)

MobyleNet – – Réseau de confiance & QoS (ii) ► Test fonctionnels par défaut.... ou plus sophistiqués

MobyleNet – – ► Surveillance ► Rapport compatible QBios F. Moreews, C. Caron et al. (définit dans Projet RENABI BioWorkFlow) Réseau de confiance & QoS (iii)

MobyleNet – – Réseau de confiance & QoS (iv) ► Extension à la surveillance de services Mobyle  Pour chaque fichier XML dans une arborescence Mobyle (Programs, Local/Programs), faire un test fonctionnel. ► Nécessité d’avoir des données de test (entrées + paramètres) (dans le XML Mobyle ?) ► Inclure le test dans le XML Mobyle ? ► Surveillance des ressources hardware  NAGIOS  Redondance des services (redirection « intelligente »)

MobyleNet – – ► Auteurs  Sébastien Letort  Sébastien Carrere  Jérôme Gouzy ► Disponibilité   Licence CeCILL Merci

MobyleNet – – LIPM

MobyleNet – – LIPM Services ►  ~80 services maison + EMBOSS  36 EMBOSS   Accès a des ressources locales (HeliaGene,LeGOO, ENZYME)  Analyse de séquence (*blast*, patscan, Meme, Multalin, SeqLogo, ClustalW, autoSNP, Cap3)  Annotation de sequences (InterproAnnotation)

MobyleNet – – LIPM Datatypes ► Ces services viennent de BioMOBY  1 service n’accepte qu’un format d’entrée  le format de sortie ne peut être modifié par l’utilisateur (sauf à rester très pas niveau, mais perte de l’interopérabilité)  Utilisation d’un dictionnaire BioMOBY  Mobyle

MobyleNet – – LIPM Futur ► Reseau BIOS  accès à des ressources  1 portail frontal + portail backends ET/OU interrogation par webservices ?