Cours sur le système d'information en 9 chapitres

1. Théorie et Pratique du Système d’Information
Septième Chapitre: Distribution de l’information
Janvier-Mars 2012
Ecole Polytechnique
Yves Caseau
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
1/28

2. 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

Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
2/28

3. Première Partie: Distribution et Qualité des données
Distribution des données
Données
locales
composant
A
composant
B
même
client
composant
C
Données
partagées

Objets métiers



Eléments d’informations



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)
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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
3/28

4. Première Partie: Distribution et Qualité des données
Contraintes dans la gestion des données

Contraintes de performance




Contraintes logicielles



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)
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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
4/28

5. Première Partie: Distribution et Qualité des données
Concept de transaction

Double complexité à gérer (accès aux objets métiers)



La notion de transaction répond à cette problématique



Accès concurrents (plusieurs requêtes en même temps)
Logique métier d’un ensemble de requêtes (ex: processus)
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)
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
5/28

6. Première Partie: Distribution et Qualité des données
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.

Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
6/28

7. Première Partie: Distribution et Qualité des données
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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
7/28

8. Première Partie: Distribution et Qualité des données
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
Directory
Management
Query
Processing
Distributed
DB Design
Reliability
Concurrency
Control
Deadlock
Management
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
8/28

9. Première Partie: Distribution et Qualité des données
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)

OS
UI
Apps..
Client
Client DBMS
communication
SQL
queries
results
Communication
Semantic Controller
Server
Query Optimizer

DBMS
(Database Management System)
 Gestion des requêtes
 I/O, recovery, …
Parallélisme: (Oracle RAC)
 Mécanismes de réplication
 Synchrone/ asynchrones

Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
Transaction Manager
Recovery Manager
Runtime Support
OS
database
9/28

10. Première Partie: Distribution et Qualité des données
Annuaires Distribués

Annuaire: cas particulier de base de données (directory)



Il existe des implémentations spécialisées





Entrée (distinguished name), description (un ou plusieurs attributs)
Structure hiérarchique (modèle X500 – arbres … plats)
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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
10/28

11. Première Partie: Distribution et Qualité des données
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


Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
11/28

12. Deuxième partie
Introduction et Formalisation
 Synchronisation et Resynchronisation
 Pilotage des processus

Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
12/28

13. Deuxième Partie: (re) Synchronisation
Distribution et Stockage d’Information

La distribution fait déjà partie des architecture modernes
Serveurs applicatifs
Serveurs données
Cluster HP

SAN
SAN


Architecture permettant d’utiliser
des disques distants
Souvent construit sur un réseau
« fibre channel »
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
13/28

14. Deuxième Partie: (re) Synchronisation
DCC (Distributed Concurrency Control)

Mécanisme central de la gestion des transactions


Aussi appelé « Concurrency Control Services » (Cummins)


Acteurs = processus/services qui partagent des objets métiers
Deux familles:



Acteurs = transactions qui se partagent des ressources (données)
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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
14/28

15. Deuxième Partie: (re) Synchronisation
Synchronisation et Processus
(1) Changement sur OM1
Données
locales
composant
A
(?) Mise à jour replicat OM1
composant
B
Données
partagées
(2) Fin d’activité
(3) Nouvelle activité
Référence
OM
(?) Mise à jour référence OM1
Moteur de Processus

Deux flux d’informations circulent:



Séquencement des processus
Mise à jour des objets métiers
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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
15/28

16. Deuxième Partie: (re) Synchronisation
The Snapshot Problem

« 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.



Lien avec le problème précédent: garantir que le « snapshot » n’est pas faussé
par la propagation des « updates »



Le problème est difficile 
Pas de solution générale (any snapshot) efficace (overhead prohibitif – cf. expérience
Peter Tabeling)
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
Résultat connu dans le monde du « cloud » sous le nom de Théorème de Brewer
(CAP : Coherence – Availability – Partition Tolerance)
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
16/28

17. Deuxième Partie: (re) Synchronisation
Processus et Transactions Longues
Les processus servent à implémenter les transactions longues
 L’implémentation s’appuie sur la (re)synchronisation

Début 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
Non-participants : l’état des
objets est défini par la référence
avec un « lock » sur l’écriture
Fin du processus
succès
échec
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
Etat temporaire : deux parties= les systèmes qui
participent à la transactions et les autres
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
17/28

18. Deuxième Partie: (re) Synchronisation
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:
1.
1.
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)
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
18/28

19. Troisième Partie



Introduction et Formalisation
Synchronisation et Re-synchronisation
Architecture de Données
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
19/28

20. Troisième Partie: Architecture de données
Design Patterns: Pas de solution unique
Sur un domaine de données, avec des contraintes fortes de
performance:
Tuxedo – composants:
 Moniteur transactionnel
•System/T: serveur de noms et
gestionnaire de transactions
(gestion de la concurrence)
•System/WS: partie client
 OLTP (On Line Transaction Processing)
(Windows/Unix)
•System/Q: gestion de la queue des
 Ex: Tuxedo
message + gestion des ressources
 Multi-domaine, multi-processus,
•System/Tdomain: gestion
transactionnelle multi-domaine
contraintes performances modérées
 SOA + annuaire (ex: MDM)
 Ou (ponctuellement) replicat LDAP
 Multi-domaine, multi-processus,
contraintes performances modérées
 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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
20/28

21. Troisième Partie: Architecture de données
Une « bonne » architecture de données (résumé)

Un modèle


Un cycle de vie et des propriétaires



Où sont les copies et pourquoi ?
Qui est la référence (SPT)
Des mécanismes (audit / synchro / etc.)



Qui crée, qui lit, qui modifie, qui supprime ?
Un plan de distribution


Global, partagé, compris, entretenu
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 »
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
21/28

22. Troisième Partie: Architecture de données
MDM (Master Data Management)

Solution informatique en cours d’émergence pour la gestion des
« données de références »



Une méthode (MDM Alliance Group = MAG)





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)
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
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
22/28

23. Troisième Partie: Architecture de données
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).
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
23/28

24. Troisième Partie: Architecture de données
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.
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
24/28

25. Troisième Partie: Architecture de données
Exigence sur les données

Gouvernance



CNIL



Ex: COBIT
 DS11 : gérer les données
 PO2 : définir l’architecture
de l’information
Impact des crises
(ex: Sarbanes- Oxley)
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 
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
25/28

26. Troisième Partie: Architecture de données
Cycle de vie
Lecture
Destruction
Création
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

Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
26/28

27. Troisième Partie: Architecture de données
Processus de Gestion de Données
Bon
usage
1.
2.
3.
4.
5.
6.
Filtrage
Vérification
Cohérence
Echanges
Synchronisation
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 resynchronisation 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 resynchronisation exceptionnelle (réparation)
Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII)
Audit
Nettoyage
Réparation
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
27/28