Janvier-Mars 2009 Ecole Polytechnique Yves Caseau Théorie et Pratique du Système d’Information Septième Chapitre: Distribution de l’information Janvier-Mars 2009 Ecole Polytechnique Yves Caseau 1/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 2/34

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

Contraintes dans la gestion des données Contraintes de performance 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é Volume de réponse (débit transactionnel) Raison # 1 pour répliquer des bases de données Temps de transfert (débit) Contraintes logicielles Les progiciels ont leur propre stockage de données C’est une des raisons qui en fait un choix stratégique Ex: ERP – SAP, CRM – Siebel, etc. Contraintes de disponibilité 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 4/34

Concept de transaction Double complexité à gérer (accès aux objets métiers) Accès concurrents (plusieurs requêtes en même temps) Logique métier d’un ensemble de requêtes (ex: processus) La notion de transaction répond à cette problématique Regroupe un ensemble d’actions en garantissant une cohérence unitaire (tout ou rien) Garantit l’exécution concurrente sans perte de cohérence Sériabilité Exemple type: virement bancaire ☺ Typologie Transactions locales (DBMS) ou distribuées Transactions courtes (DBMS) ou longues (services/processus) 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 5/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 6/34

Le protocole 2PC (Two Phase Commit) Sur un DBMS, la gestion des transactions relève de l’ordonnancement des lectures/écritures 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 Distribué (ressources) Centralisé (coordinateur) Court et Transaction longue: => « compensation » Optimiste (évite le locking) Robuste Première Partie: Distribution et Qualité des données 7/34

Qualité de service et qualité des données Etudes Sterling: « Data synchronization: What is Bad Data Costing Your Company » DWHI: « Data Quality and the bottom line – achieving business success through a commitment to high quality data » Taux d’erreurs allant de quelques % à quelques dizaines de % ! Impact direct : perte de revenu Expérience Bouygues Telecom: dégradation réciproque QoS => QoD : Désynchronisation => erreurs fonctionnelles Baisse QoS => détournement des processus => erreurs (cohérence/saisies) QoD => QoS: Erreurs dans les passerelles/adaptateurs => demandes en attente Temps de traitement dégradé => baisse de QoS Première Partie: Distribution et Qualité des données II.1 : Processus - Principes 8/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: Bases de données relationnelles Annuaires distribués EII Cf. chapitre 3 Solution lourde (performance) Probablement la solution du futur (« synchronisation as a service ») Bases de données hétérogènes massivement distribuées Première Partie: Distribution et Qualité des données Directory Management Query Processing Distributed DB Design Reliability Concurrency Control Deadlock Management 9/34

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

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

Approches alternatives XML Store Stockage natif de XML Très gros volumes, hétérogènes Requêtes: Xpath, Xquery, … Une solution qui va s’imposer progressivement Bases de données massivement parallèles Une solution d’avenir: Scalabilité, redondance (fiabilité), coût des opérations (serveurs banalisés) 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 Aussi: Oracle sur un GRID Première Partie: Distribution et Qualité des données 12/34

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

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

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

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

The Snapshot Problem Deuxième Partie: (re) Synchronisation « Distributed Snapshots : Determining Global States of Distributed Systems » K. Chandy & L. Lamport Comment capturer une image de l’état global du système au travers de processus distribués ? 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. Le problème est difficile ☺ 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 » Avoir résolu le problème signifie qu’on peut garantir la consistance des objets métiers sans assurer une synchronisation permanente 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 17/34

Orchestration de Processus Pour voir plus clair, il faut distinguer (Cummins): Le processus L’instance de processus La requête BPRMS (easy) Deuxième Partie: (re) Synchronisation Requester Process A Definition CCS Process A instance Process Manager BPRMS (hard) Process B instance Ressource Assignement Facilites 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) 18/34

Architecture de données: les questions Données locales composant A composant B composant C Données partagées Bus message Deuxième Partie: (re) Synchronisation broker cache Référentiel : Modèle commun Réferentiel Technique À traiter: Synchronisation de copies Gérer le flux de synchronisation 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 Interactions Les activités interagissent via (1) messages/services (2) ressources partagées (objets) La cohérence => signalisation / exclusion / sérialisation Axiome: toute activité qui modifie un objet métier partagé est encapsulée dans un processus (= éviter les IHM de saisie sauvage ☺) 19/34

Différentes Approches Parallèle paresseux Insouciant entrelacé Concurrent Une infra (ex: LDAP) effectue le travail de mise à jour Lazy La référence unique suffit Optimistic Les données lues localement sont bonnes = ce qui change est contenu dans les paramètres de service Interlaced Le même flux pour la signalisation (exécution du processus) et la mise à jour des objets métiers Option: sous-processus technique propagation Complè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 lecture Lecture 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 Lecture locale Deuxième Partie: (re) Synchronisation 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’utilisation Permet 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 20/34

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

Re-synchronisation Désynchronisation: Erreurs durant le processus Crash/ incidents /reprises / retard de planification Erreurs de saisie La désynchronisation est une condition récurrente ☺ Besoins: Outils de re-synchronisation Utilisation régulière Reprise sur incident 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 22/34

Synchronisation et Processus: la cible (entrelacée) 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 Référentiel broker Moteur de Processus Référentiel CCS Gestion des demandes Audit Re-synchro Annuaire Re-sync infrastructure composant Données locales Non partagées Données partagées Import (référence = ref.) Sauf état temporaire Autres composants Données partagées Export (référence) 23/34

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

Design Patterns: Pas de solution unique Sur un domaine de données, avec des contraintes fortes de performance: Moniteur transactionnel (gestion de la concurrence) OLTP (On Line Transaction Processing) Ex: Tuxedo Multi-domaine, multi-processus, contraintes performances modérées SOA + annuaire (ex: MDM) Ou (ponctuellement) replicat LDAP Contrôle de concurrence sur processus Point clé: tout appel de service d’écriture passe par la gestion des demandes. Gros volumes, pas de contrainte de latence: EII 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 Troisième Partie: Architecture de données 25/34

Une « bonne » architecture de données (résumé) Un modèle Global, partagé, compris, entretenu Un cycle de vie et des propriétaires Qui crée, qui lit, qui modifie, qui supprime ? Un plan de distribution Où sont les copies et pourquoi ? Qui est la référence (SPT) Des mécanismes (audit / synchro / etc.) Si il y a distribution (copies), il y aura des problèmes ☺ purge Des outils La gestion des données distribuées est difficile (surtout du point de vue des performances) – éviter de réinventer la roue ! 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 26/34

MDM (Master Data Management) Solution informatique en cours d’émergence pour la gestion des « données de références » Référentiel = Modèle + Annuaires + processus/services Ambigüité (collection de BD vs. Service) Première brique = modèle commun Master Data = objets métiers transverses (partagés) Une méthode (MDM Alliance Group = MAG) 1er temps : modéliser le métier / les cycles de vie 2ème temps: créer un modèle logique de donnée urbanisation des donnée (ex: repérer les couplages) 3ème temps: implémentation Cf. Pierre Bonnet: le promoteur de MDM ☺ Exemple: EXB.platform (Orchestra Networks) Plateforme logicielle pour manipuler des modèles de données et interagir avec des services SOA Vidéo: http://www.orchestranetworks.com/product/index.cfm Troisième Partie: Architecture de données 27/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: mieux communiquer (on peut échanger des diagrammes en sachant de quoi on parle), pouvoir échanger des données entre modèles, ou faire émerger des modèles communs plus facilement, 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 : nous étions une autre entreprise (choisir un concurrent), nous décidions d’opérer nos services pour le compte d’autres entreprises, nous décidions d’acheter une partie des services à l’extérieur (outsourcing). Troisième Partie: Architecture de données 28/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 29/34

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

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

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

Processus de Gestion de Données Bon usage Filtrage Vérification Cohérence Echanges Synchronisation Audit Nettoyage Réparation Le bon usage des applications.: très souvent, les données incorrectes sont introduites par un usage inapproprié d’une application. 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. La conception des échanges doit garantir la cohérence à tous les niveaux (format et sémantique). Le protocole de synchronisation (et de re-synchronisation continue) doit être cohérent avec le bon déroulement des processus de l’entreprise. Des audits de qualité et de synchronisation doivent être menés de façon continue Les purges (données inutiles) et la re-synchronisation exceptionnelle (réparation) Troisième Partie: Architecture de données Architecture de données Bonne utilisation des outils (responsabilité conjointe MOA) Filtrage des entrées (implémenter les contrôles de cohérence) Cohérence des échanges et distribution correcte du MIM (conception) Fonctionnement synchronisation (responsabilité conception système) Fonctionnement re-synchro Supervision de la QoS fonctionnelle et des rejets Nettoyage et purge des systèmes Qualité des données : on n’améliore que ce que l’on mesure 34/34