L’annexe inter-opérabilité du SDET Pascal Aubry IFSIC – Université de Rennes 1 – Juin 2004 http://perso.univ-rennes1.fr/pascal.aubry/ presentations
Jan 14, 2016
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)