Lannexe inter-opérabilité du SDET Pascal Aubry IFSIC – Université de Rennes 1 – Juin

Le SDET Schéma Directeur des Espaces numériques de Travail Version 1 : mars annexes –SupAnn –AAS –Interopérabilité

Annexe SupAnn Recommandations pour les annuaires de lenseignement supérieur –Version 1 : juillet 2003 Compatibilité entre annuaires aux niveaux : –international (internet2, eduPerson) –inter-ministériel (ADAE, scolaire/supérieur) –inter-établissements (enseignement supérieur) –applicatif Uniformisation –Visibilité des personnels et étudiants (pages blanches) –Authentification (inter-établissements/externe) –Caractérisation des utilisateurs (profils, rôles, …)

Annexe AAS Recommandations pour lauthentification, lautorisation et le Single Sign-On dans le scolaire et lenseignement supérieur –Version 1 : juillet 2003 Portée des recommandations –Identification Qui es-tu ? –Authentification Prouve-moi que tu es bien celui que tu prétends être –Autorisation Quas-tu le droit de faire ? –Single Sign-On (propagation des identités) Authentification unique et unifiée

Annexe interopérabilité Recommandations pour les applications du scolaire et de lenseignement supérieur en matière dinteropérabilité –Version 1 : avril 2004 Participants –Le ministère –Le CRU –Lenseignements supérieur (les 4 ENT) –Le scolaire

Urbanisation du SI Ouverture du SI –Apport de nouveaux services –Nouvelles relations avec les partenaires Dématérialisation –Objectif « zéro papier » Modernisation du SI

Urbanisation du SI

Enjeux de la modernisation du SI Modèle événementiel et partenarial –Ouvrir le système dinformation aux citoyens, aux usagers, aux administrés, aux partenaires Modèle des processus métier –Transformer le métier, modifier les façons de faire Modèle des objets métier et des formats déchange –Valoriser le patrimoine informationnel –Dématérialiser les échanges Cartographie applicative –Moderniser loutil informatique (évolutivité, performance et réactivité)

Urbanisme et interopérabilité Interopérabilité : capacité des applications à coopérer ensemble Lurbanisation : une question stratégique Linteropérabilité : une question technique

Interopérabilité et middleware Intégration et communication entre composants applicatifs Deux modes de communication –Sans connexion (asynchrone, couplage faible) –Avec connexion (synchrone, couplage fort) Mise en œuvre systématique dans un cadre durbanisation

Les types de middleware Accès aux bases de données –Abstraction des bases de données Appel de procédures distantes –Masquage de la répartition File dattente de message –Découplage et fiabilisation Moniteur transactionnel –Traitement des transactions ACID Atomique, Isolé, Cohérent, Durable

Architectures dinteropérabilité Formats déchange : XML –eXtended Markup Language Intégration de systèmes complexes: EAI –Enterprise Application Integration Modèle darchitecture cible : SOA –Service Oriented Architecture

Formats déchange Modélisation UML Production de schémas XML Langages XML verticaux –mathématiques : MathML (Mathematical Markup Language) –astronomie : AIML (Astronomical Instrument Markup Language) –santé : HL7 (Health Level Seven) –banque : IFX (Interactive Financial eXchange) –commerce : cXML, xCBL, ebXML Enjeu : définition des formats déchange propres aux métiers de léducation –Formation, cursus, support pédagogique, …

Solutions dintégration dapplications Recréer le SI de toute pièce –Généralement impossible Générer des passerelles inter-applications –Au coup par coup, très vite ingérable Fédérer les applications –Via un moteur dintégration

Architecture « plat de spaghetti » Développements couteux Interconnexions redondantes (point à point) Grande complexité Maintenance difficile

Architecture « moyeu et rayons » Moteur dintégration : outil homogène dadministration des flux Nécessité de définir des formats déchange internes

Architectures de services (SOA) Ouverture du SI : mise à disposition de services pour des utilisateurs externes Exposition dune interface fonctionnelle Problématique des autorisations –Cf annexe AAS

Service logiciel Module logiciel utilisable par programmation –IHM pour utilisation humaine –Séparation traitement/interface Autonome, complet et cohérent –Fonctions liées à un même objet métier Auto-descriptif, permet la réutilisation –Véritable contrat de service –Indépendant des plateformes et outils Recensement au sein dannuaires

Service vs composant logiciel Service logiciel –Fonction de haut niveau –Dédié à un objet métier –« Autonome, complet et cohérent » Composant logiciel –Fonction de bas niveau –Technique –Doit être « composé »

Avantages des SOA Portabilité –Interfaces indépendantes des plates-formes technologiques –Communications sur des couches de transport hétérogènes (HTTP, SMTP, FTP, JMS…) Granularité –Échanges de niveau « métier » Fluidité des échanges –Synchrone ou asynchrone

Tendance actuelle des architectures ESB : Enterprise Service Bus Principes des EAI –Moteurs dintégration, bus logiciels Architectures de services –Communications basées sur des services web –WSOA : Web Services Oriented Architectures

Conduite de projet et interopérabilité Ouverture => attaques possibles Consultation des destinataires des services Disponibilité des services Qualité de service Accès pour tous Changement des façons de faire Risque technologique

Recommandations Doivent être suivies pour les développements internes Fournissent des critères de jugement de linteropérabilité à lintention des maîtres douvrage

Architecture Liaisons point-à-point prohibées Architecture de type « bus logiciel »

Mise en œuvre des services logiciels Utilisation de Web Services (XML) Description WSDL Publication UUDI –Mise en place souhaitable dun annuaire UUDI au niveau du ministère

Mise en œuvre des composants logiciels Protocoles de haut niveau –WebDAV pour les échanges de fichiers Middlewares –Pour accès aux bases de données

Publication de ressources Format source : XML Séparation forme et fond : XSLT –En différé ou à la volée, côté serveur –Toléré sur poste client en intranet

Gestion des profils et droits Dans lannuaire LDAP –Cf annexe SupAnn Lannuaire LDAP nest pas une base de données –Authentification et habilitation seulement –Exploitation en lecture seulement –Écriture réservée à ladministration

Accès aux bases de données Uniquement à travers un middleware –ODBC –JDBC –JDO

Communications asynchrones MOM : Message Oriented Middleware Seul cas où lon peut utiliser autre chose quun Web Service pour implémenter un service logiciel

Modélisation : UML UML : Unified Modeling Language Développements applicatifs Définition des formats déchanges

Intégration dans un portail Utilisation du socle des ENT Conformité WSRP –Web Services for Remote Portals (OASIS)