L’annexe inter-opérabilité du SDET

SIGILUM UNIVERSITATIS REDONENSIS UNIVERSITE DE RENNES 1 L’annexe inter-opérabilité du SDET Pascal Aubry IFSIC – Université de Rennes 1 – Juin 2004 http://perso.univ-rennes1.fr/pascal.aubry/presentations

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

Annexe SupAnn • Recommandations pour les annuaires de l’enseignement 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 l’authentification, l’autorisation et le Single Sign-On dans le scolaire et l’enseignement 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 • Qu’as-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 l’enseignement supérieur en matière d’interopérabilité • Version 1 : avril 2004 • Participants • Le ministère • Le CRU • L’enseignements 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 d’information 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 l’outil informatique (évolutivité, performance et réactivité)

Urbanisme et interopérabilité • Interopérabilité : capacité des applications à coopérer ensemble • L’urbanisation : une question stratégique • L’interopé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 d’urbanisation

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 d’attente de message • Découplage et fiabilisation • Moniteur transactionnel • Traitement des transactions ACID • Atomique, Isolé, Cohérent, Durable

Architectures d’interopérabilité • Formats d’échange : XML • eXtended Markup Language • Intégration de systèmes complexes: EAI • Enterprise Application Integration • Modèle d’architecture 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 d’intégration d’applications • 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 d’intégration

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

Architecture « moyeu et rayons » • Moteur d’intégration : outil homogène d’administration 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 d’une 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 d’annuaires

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 d’inté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 l’interopérabilité à l’intention des maîtres d’ouvrage

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 d’un 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 l’annuaire LDAP • Cf annexe SupAnn • L’annuaire LDAP n’est pas une base de données • Authentification et habilitation seulement • Exploitation en lecture seulement • Écriture réservée à l’administration

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

Communications asynchrones • MOM : Message Oriented Middleware • Seul cas où l’on peut utiliser autre chose qu’un 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)

L’annexe inter-opérabilité du SDET