1/34 Théorie et Pratique du Système d’Information Septième Chapitre: Distribution de l’information Janvier-Mars 2009 Ecole Polytechnique Yves Caseau

2/34 Plan du Cours – Distribution de l’Information Première partie: Distribution et Qualité des Données Deuxième partie: Synchronisation et Re-synchronisation Troisième partie: Architecture de données

3/34 Distribution des données Objets métiers o Implicite (un seul client), explicite (« référenciel ») ou explicité (un seul stockage) o Seul le cas de l’entreprise étendu nécéssite une approche implicite (avec formats import/exports) Eléments d’informations o Hétérogènes (XML, BD relationnelle, propriétaires, …) o Répliqués et répartis SPT (Single Point/Source of Truth) o Le plus important : qui est la « référence » o Outil: cycle de vie (cf. chap. X) Première Partie: Distribution et Qualité des données composant A même client Données locales Données partagées composant B composant C

4/34 Contraintes dans la gestion des données Contraintes de performance o Temps de réponse transactionnel (latence)  En mémoire < disque local < disque en réseau  exemple: fournir une description (partielle) d’un objet dans un message/appel de service au lieu de fournir un pointeur/identité o Volume de réponse (débit transactionnel)  Raison # 1 pour répliquer des bases de données o Temps de transfert (débit) Contraintes logicielles o Les progiciels ont leur propre stockage de données o C’est une des raisons qui en fait un choix stratégique  Ex: ERP – SAP, CRM – Siebel, etc. Contraintes de disponibilité o Aller chercher des objets métiers à l’extérieur crée une dépendance de plus Première Partie: Distribution et Qualité des données

5/34 Concept de transaction Double complexité à gérer (accès aux objets métiers) o Accès concurrents (plusieurs requêtes en même temps) o Logique métier d’un ensemble de requêtes (ex: processus) La notion de transaction répond à cette problématique o Regroupe un ensemble d’actions en garantissant une cohérence unitaire (tout ou rien) o Garantit l’exécution concurrente sans perte de cohérence  Sériabilité  Exemple type: virement bancaire ☺ Typologie o Transactions locales (DBMS) ou distribuées o Transactions courtes (DBMS) ou longues (services/processus) o Standard de transaction sur Web Services: WS-T  WS-T Atomic-transaction  WS-T Business Activity (LRA) Première Partie: Distribution et Qualité des données

6/34 Propriétés ACID Atomicité : une transaction doit s'effectuer en tout ou rien ; Cohérence : la cohérence des données doit être assurée dans tous les cas, même dans les cas d'erreur où le système doit revenir au précédent état cohérent ; Isolation : la transaction va travailler dans un mode isolé où elle seule peut voir les données qu'elle est en train de modifier, cela en attente d'un nouveau point de synchronisation ; le système garantit aux autres transactions, exécutées en parallèle sur le même système, une visibilité sur les données antérieures ; Durabilité : lorsque la transaction est achevée, le système est dans un état stable durable, soit à l'issu d'une modification transactionnelle réussie, soit à l'issue d'un échec qui se solde par le retour à l'état stable antérieur. Première Partie: Distribution et Qualité des données

7/34 Le protocole 2PC (Two Phase Commit) Sur un DBMS, la gestion des transactions relève de o l’ordonnancement des lectures/écritures o La pose des points de reprises pour exécuter le retour arrière En environnement distribué, il faut ajouter une coordination (gestion des echecs) Ex: Protocole classique de transactions courtes o Distribué (ressources) o Centralisé (coordinateur) o Court et Transaction longue: => « compensation » o Optimiste (évite le locking) o Robuste Première Partie: Distribution et Qualité des données

8/34 Qualité de service et qualité des données Etudes o Sterling: « Data synchronization: What is Bad Data Costing Your Company » o DWHI: « Data Quality and the bottom line – achieving business success through a commitment to high quality data » o Taux d’erreurs allant de quelques % à quelques dizaines de % ! o Impact direct : perte de revenu Expérience Bouygues Telecom: dégradation réciproque o QoS => QoD :  Désynchronisation => erreurs fonctionnelles  Baisse QoS => détournement des processus => erreurs (cohérence/saisies) o QoD => QoS:  Erreurs dans les passerelles/adaptateurs => demandes en attente  Temps de traitement dégradé => baisse de QoS II.1 : Processus - Principes Première Partie: Distribution et Qualité des données

9/34 Problématique de la distribution de données Gestion des interactions (contrôle de la concurrence) Gestion de la synchronisation Approches par les outils: o Bases de données relationnelles o Annuaires distribués o EII  Cf. chapitre 3  Solution lourde (performance)  Probablement la solution du futur (« synchronisation as a service ») o Bases de données hétérogènes massivement distribuées Distributed DB Design Directory Management Query Processing Reliability Concurrency Control Deadlock Management Première Partie: Distribution et Qualité des données

10/34 Bases de données relationnelles Proposées par E. Codd en 1970 Tables + normalisation Algèbre relationnelle (8 opérateurs) o Sélection, jointure, projection, … Optimisation des requêtes o SQL (Structured Query Language) DBMS (Database Management System) o Gestion des requêtes o I/O, recovery, … Mécanismes de réplication o Synchrone/ asynchrones OS Communication communication Semantic Controller Query Optimizer Transaction Manager Recovery Manager Runtime Support OS database Client DBMS UI Apps.. SQL queries results Client Server Première Partie: Distribution et Qualité des données

11/34 Annuaires Distribués Annuaire: cas particulier de base de données (directory) o Entrée (distinguished name), description (un ou plusieurs attributs) o Structure hiérarchique (modèle X500 – arbres … plats) Il existe des implémentations spécialisées o Pour des raisons historiques (systèmes hiérarchiques) o Besoins différents (read vs. peu de write) o Exemple connu: DNS (Domain Name System) o Inclus dans Windows: Active Directory Il existe des protocoles de distribution plus efficaces (cas particulier): LDAP – Lightweight Directory Access Protocol o Synchronisation (LDAP Content Synchronization Protocol) o Replication (via slurpd ☺) o Version 3 - IETF Première Partie: Distribution et Qualité des données

12/34 Approches alternatives XML Store o Stockage natif de XML o Très gros volumes, hétérogènes o Requêtes: Xpath, Xquery, … o Une solution qui va s’imposer progressivement Bases de données massivement parallèles o Une solution d’avenir:  Scalabilité, redondance (fiabilité), coût des opérations (serveurs banalisés) o Ex: Google database  Google File System  Replication redondante (au moins 3) sous formes de chunks  Gestion des updates avec un mécanisme de transaction  Optimisé pour le débit (vs. latence)  Google BigTable o Aussi: Oracle sur un GRID Première Partie: Distribution et Qualité des données

13/34 Deuxième partie Introduction et Formalisation Synchronisation et Resynchronisation Pilotage des processus

14/34 Distribution et Stockage d’Information La distribution fait déjà partie des architecture modernes SAN o Architecture permettant d’utiliser des disques distants o Souvent construit sur un réseau « fibre channel » Deuxième Partie: (re) Synchronisation Serveurs applicatifs Serveurs données SAN Cluster HP

15/34 DCC (Distributed Concurrency Control) Mécanisme central de la gestion des transactions o Acteurs = transactions qui se partagent des ressources (données) Aussi appelé « Concurrency Control Services » (Cummins) o Acteurs = processus/services qui partagent des objets métiers Deux familles: o Pessimistes la synchronisation a lieu avant l’exécution ( Validate > Read > Compute > Write ) o Optimistes le test de validité est fait avant l’écriture – si il y a conflit, la transaction est « abortée » Deux mécanismes: o Locks (compteurs) des verrous assignés aux acteurs qui possèdent le droit d’écrire, et qui limitent l’accès (lecture/écriture) o Timestamps ordonnancement des accès en fonction d’une sérialisation possible Deuxième Partie: (re) Synchronisation

16/34 Synchronisation et Processus Deux flux d’informations circulent: Il est important qu’ils soient synchronisés (pour la bonne exécution du processus) o Exemple Pernod (« propagation trop rapide des processus ») o Exemple Bouygues Telecom: messages « contextuels » qui combinent les deux flux  Plus gros  Plus complexe composant A Données locales Données partagées composant B Référence OM (1) Changement sur OM1 Moteur de Processus (2) Fin d’activité (?) Mise à jour replicat OM1 (3) Nouvelle activité (?) Mise à jour référence OM1 Deuxième Partie: (re) Synchronisation

17/34 The Snapshot Problem « Distributed Snapshots : Determining Global States of Distributed Systems » K. Chandy & L. Lamport o Comment capturer une image de l’état global du système au travers de processus distribués ? o Modèle de système distribué = ancêtre du pi-calcul - systèmes non synchronisés avec des mémoires distinctes qui communiquent par envoi de message « An introduction to snapshot algorithms in distributed computing » A. Kshemkalyani & al. o Le problème est difficile ☺ o Pas de solution générale (any snapshot) efficace (overhead prohibitif – cf. expérience Peter Tabeling) Lien avec le problème précédent: garantir que le « snapshot » n’est pas faussé par la propagation des « updates » o Avoir résolu le problème signifie qu’on peut garantir la consistance des objets métiers sans assurer une synchronisation permanente o Pas de solution générale =>  « Plus petits snapshots » - limiter la concurrence  Ne pas chercher à séparer les deux flux process/syncho Deuxième Partie: (re) Synchronisation

18/34 Orchestration de Processus Pour voir plus clair, il faut distinguer (Cummins): Le processus L’instance de processus La requête Process A Definition Requester Process Manager Process A instance Process B instance Ressource Assignement Facilites CCS La gestion des demandes (Requester) joue un rôle clé: vérifier la validité sémantique des paramètres (cf. QoD) CCS Lieu d’implémentation de règles (enrichissement) BPRMS (easy) BPRMS (hard) Deuxième Partie: (re) Synchronisation

19/34 Architecture de données: les questions À traiter: 1.Synchronisation de copies o Gérer le flux de synchronisation o Garantir la cohérence des « snapshots »  Impossible dans le cas général  OK si on se limite à une cohérence modulo les observations des processus 2.Interactions o Les activités interagissent via (1) messages/services (2) ressources partagées (objets) o La cohérence => signalisation / exclusion / sérialisation o Axiome: toute activité qui modifie un objet métier partagé est encapsulée dans un processus (= éviter les IHM de saisie sauvage ☺) composant A Réferentiel Technique broker cache Bus Référentiel : Modèle commun message Données locales Données partagées composant B composant C Deuxième Partie: (re) Synchronisation

20/34 Différentes Approches Concurrent o Une infra (ex: LDAP) effectue le travail de mise à jour Lazy o La référence unique suffit Optimistic o Les données lues localement sont bonnes = ce qui change est contenu dans les paramètres de service Interlaced o Le même flux pour la signalisation (exécution du processus) et la mise à jour des objets métiers o Option: sous-processus technique ParallèleparesseuxInsouciantentrelacé propagationComplète, avec un flux séparé Mode « pull » : pas de propagation mais une requête si besoin Limitée au périmètre du processus, incluse dans le flux de messages ad hoc, complète qui utilise l’infrastructure EAI lectureLecture locale, sous le contrôle d’une « garde » qui vérifie la fraîcheur Lecture par requête synchrone si besoin, locale sinon Lecture locale Cohérence intra-processus Utilisation de « gardes » à partir d’un time-stamp qui est poussé dans le flux processus Explicite : appel de la référence si besoin Implicite : l’ensemble des données poussées dans les messages doivent garantir cette cohérence Explicite : le sous- processus assure la cohérence Cohérence inter- processus (lorsqu’elle est implémentée …) Composant de contrôle des demandes : exclusion par ordonnancement sur la base des time- stamps Explicite : appel de la référence … peut devenir lourd s’il existe de nombreuses dépendances Composant de contrôle des demandes : exclusion par ordonnancement des exécutions de processus Composant de contrôle des demandes : exclusion par ordonnancement des sous-processus de mise-à-jour Contexte d’utilisationPermet d’utiliser une infrastructure de synchronisation spécifique Modèle simple à implémenter pour des petits périmètres sans grosse contrainte de performance La solution la plus simple mais suppose des processus les plus indépendants possibles Solution performante un peu plus complexe que sa voisine mais mieux adaptée à des inter-dépendances Deuxième Partie: (re) Synchronisation

21/34 Processus et Transactions Longues Les processus servent à implémenter les transactions longues L’implémentation s’appuie sur la (re)synchronisation Etat S1 initial cohérent : Une référence unique + Toutes les copies sont synchronisées Etat final cohérent (modification de la référence) Retour à S1 par re-synchronisation des systèmes impliqués dans la Transaction depuis la référence succès échec Début du processusFin du processus Etat temporaire : deux parties= les systèmes qui participent à la transactions et les autres Participants : l’état des objets est contenu dans les messages qui circulent Non-participants : l’état des objets est défini par la référence avec un « lock » sur l’écriture 21 Deuxième Partie: (re) Synchronisation

22/34 Re-synchronisation Désynchronisation: o Erreurs durant le processus o Crash/ incidents /reprises / retard de planification o Erreurs de saisie La désynchronisation est une condition récurrente ☺ Besoins: 1.Outils de re-synchronisation  Utilisation régulière  Reprise sur incident 2.Processus permanent de nettoyage des données  Administration de données  Implication MOA (propriétaire) (rappel : les mauvaises données coûtent cher aux entreprises) Deuxième Partie: (re) Synchronisation

23/34 Synchronisation et Processus: la cible (entrelacée) broker CCS Re-sync Annuaire Référentiel Moteur de Processus infrastructure Autres composants Gestion des demandes composant Données locales Non partagées Données partagées Import (référence = ref.) Sauf état temporaire Données partagées Export (référence) Audit Re-synchro Cible (possible) incluant: patterns multiples de distribution (système référent ou annuaire) Moteur de processus avec gestion des demandes en amont Moteur de re-synchro pour compensation/ réparation Gestion de la concurrence sur les processus (exclusion) Deuxième Partie: (re) Synchronisation

24/34 Troisième Partie Introduction et Formalisation Synchronisation et Re-synchronisation Architecture de Données

25/34 Design Patterns: Pas de solution unique Sur un domaine de données, avec des contraintes fortes de performance: o Moniteur transactionnel (gestion de la concurrence) o OLTP (On Line Transaction Processing) o Ex: Tuxedo Multi-domaine, multi-processus, contraintes performances modérées o SOA + annuaire (ex: MDM) o Ou (ponctuellement) replicat LDAP Multi-domaine, multi-processus, contraintes performances modérées o Contrôle de concurrence sur processus o Point clé: tout appel de service d’écriture passe par la gestion des demandes. Gros volumes, pas de contrainte de latence: EII Troisième Partie: Architecture de données Tuxedo – composants: System/T: serveur de noms et gestionnaire de transactions System/WS: partie client (Windows/Unix) System/Q: gestion de la queue des message + gestion des ressources System/Tdomain: gestion transactionnelle multi-domaine

26/34 Une « bonne » architecture de données (résumé) Un modèle o Global, partagé, compris, entretenu Un cycle de vie et des propriétaires o Qui crée, qui lit, qui modifie, qui supprime ? Un plan de distribution o Où sont les copies et pourquoi ? o Qui est la référence (SPT) Des mécanismes (audit / synchro / etc.) o Si il y a distribution (copies), il y aura des problèmes ☺ o purge Des outils o La gestion des données distribuées est difficile (surtout du point de vue des performances) – éviter de réinventer la roue ! o Il vaut mieux simplifier l’architecture de données (diviser pour régner) et utiliser des solutions « du commerce » Troisième Partie: Architecture de données

27/34 MDM (Master Data Management) Solution informatique en cours d’émergence pour la gestion des « données de références » o Référentiel = Modèle + Annuaires + processus/services  Ambigüité (collection de BD vs. Service)  Première brique = modèle commun o Master Data = objets métiers transverses (partagés) Une méthode (MDM Alliance Group = MAG) o 1 er temps : modéliser le métier / les cycles de vie o 2 ème temps: créer un modèle logique de donnée urbanisation des donnée (ex: repérer les couplages) o 3 ème temps: implémentation o Cf. Pierre Bonnet: le promoteur de MDM ☺ Exemple: EXB.platform (Orchestra Networks) o Plateforme logicielle pour manipuler des modèles de données et interagir avec des services SOA o Vidéo: Troisième Partie: Architecture de données

28/34 Modélisation de données - Principes « Penser objet » : encapsulation et hiérarchisation de classes. Il s’agit de se concentrer sur le « quoi avant le comment » et de décrire l’ontologie des objets avant de penser à leur description. L’encapsulation propre à l’approche objet signifie qu’un objet n’est pas défini à partir de ses données internes mais par sa position ontologique et par ses interfaces (les services qu’il peut rendre). « Penser méta » signifie qu’il faut construire et formaliser le méta-modèle de données pour: o mieux communiquer (on peut échanger des diagrammes en sachant de quoi on parle), o pouvoir échanger des données entre modèles, ou faire émerger des modèles communs plus facilement, o obtenir une modélisation plus précise en se forçant à se poser des bonnes questions. « Penser générique » consiste à faire abstraction du positionnement de l’entreprise au sein de son industrie et s’imaginer que le modèle de données peut être partagé par d’autres membres de cette même industrie. Il s’agit de se demander en quoi le modèle serait différent si : o nous étions une autre entreprise (choisir un concurrent), o nous décidions d’opérer nos services pour le compte d’autres entreprises, o nous décidions d’acheter une partie des services à l’extérieur (outsourcing). Troisième Partie: Architecture de données

29/34 Modélisation de données - Conseils Réification des liens. La réification du lien consiste à introduire un objet qui représente ce lien, ce qui va permettre d’attribuer des propriétés modales à ce lien (degré de fiabilité, durée de validité, éléments constitutifs de preuve, etc.). En utilisant une hiérarchie de classe pour représenter ce lien réifié, nous allons pouvoir faire évoluer la sémantique du lien au cours des évolutions du modèle. Produits de hiérarchies. Il faut utiliser des décompositions en éléments typés, ce qui signifie mettre à profit la notion de « sous-objets » pour décrire un objet complexe. La hiérarchie induite par ces sous-objets s’appelle une hiérarchie « produit » et elle remplace avantageusement la notion d’héritage multiple qui n’est pas supportée par de nombreux outils de modélisation ou de développement. Réification des rôles. C’est l’application du principe de réification des liens au cas particulier des rôles. Représenter les rôles par un ensemble d’objets qui peut évoluer, par ajout ou par enrichissement, conduit à un modèle très extensible. Substitution groupe/individu. Une des limites les plus courantes d’évolutivité des modèles est liée précisément à l’évolution des rôles, en particulier à leur cardinalité. Par exemple, on peut découvrir qu’un rôle que l’on croyait individuel peut être partagé par un groupe. Troisième Partie: Architecture de données

30/34 Exigence sur les données Gouvernance o Ex: COBIT  DS11 : gérer les données  PO2 : définir l’architecture de l’information o Impact des crises (ex: Sarbanes- Oxley) CNIL o Déclarer tout ce qui touche à « la personne » o Contraintes max sur la durée de vie Exigences légales o Ex: données financières o Contraintes min sur la durée de vie ☺ Troisième Partie: Architecture de données

31/34 Cycle de vie Naissance o Un seul système est responsable de la création (cohérence) o Le système référent n’est pas forcément le lieu de la création Lecture o Il faut maintenir la liste des lecteurs d’une donnée métier Ecriture o Une seule référence ☺ o Qui dit écriture dit transaction (retour arrière ? Log ? Backup …) Mort o La destruction relève de la responsabilité du propriétaire de la donnée Purge o Une donnée qui ne sert plus n’est pas automatiquement purgée ! o La gestion des purges fait partie des responsabilités du propriétaire Création Lecture PurgeDestruction Ecriture Troisième Partie: Architecture de données

32/34 Architecture Décisionnelle & Connaissance client Back-office Front-office Multi-canal Assistance téléphonique Web Distribution Middle-Office Datawarehouse Datamining Profil client Catalogue produit/ services Configurateur Marketing Opérationnel (1) (2) Données accumulées Données calculées Demandes & interactions Réponses & préconisations appétences Décisionnel : datamarts Troisième Partie: Architecture de données

33/34 Rôles et missions sur la gestion des données L’administrateur de données partage le modèle métier avec les architectes du système d’information, il le renseigne suivant les axes métiers suivants : Propriété : qui est habilité à prendre des décisions sur cette donnée ? obligations en terme de conservation : quelles sont les obligations légales, les besoins opérationnels en terme de durée de stockage ? Dans le cas d’une restauration, quel est le temps disponible pour exploiter une sauvegarde ? niveau de criticité, besoin de sécurisation des accès, contraintes CNIL, etc. : l’administrateur de données collecte les exigences qui vont permettre de construire le plan de secours et le plan de sécurité informatique. L’architecte de données exerce trois responsabilités principales : Il pilote l’ensemble des modèles de données des composants logiciels et construit la correspondance entre le modèle métier global et sa vision distribuée. Il définit la stratégie de synchronisation entre les localisations, en fonction des besoins exprimés par les architectes en charge des processus. Il anime le plan de fiabilisation de la qualité des données. Troisième Partie: Architecture de données

34/34 Processus de Gestion de Données 1.Le bon usage des applications.: très souvent, les données incorrectes sont introduites par un usage inapproprié d’une application. 2.La validation des entrées, qui doit être effectuée par chaque application. Il est beaucoup plus coûteux d’extraire des données fausses que d’éviter de les faire rentrée. 3.La conception des échanges doit garantir la cohérence à tous les niveaux (format et sémantique). 4.Le protocole de synchronisation (et de re- synchronisation continue) doit être cohérent avec le bon déroulement des processus de l’entreprise. 5.Des audits de qualité et de synchronisation doivent être menés de façon continue 6.Les purges (données inutiles) et la re- synchronisation exceptionnelle (réparation) Bon usage Filtrage Vérification Cohérence Echanges SynchronisationNettoyage Réparation Audit 1.Architecture de données 2.Bonne utilisation des outils (responsabilité conjointe MOA) 3.Filtrage des entrées (implémenter les contrôles de cohérence) 4.Cohérence des échanges et distribution correcte du MIM (conception) 5.Fonctionnement synchronisation (responsabilité conception système) 6.Fonctionnement re-synchro 7.Supervision de la QoS fonctionnelle et des rejets 8.Nettoyage et purge des systèmes 9.Qualité des données : on n ’ améliore que ce que l ’ on mesure Troisième Partie: Architecture de données