L’annexe inter-opérabilité du SDET

Pascal AubryIFSIC – 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)