Théorie et Pratique du Système d’Information
Septième Chapitre: Distribution de l’information
Janvier-Mars 2012
Ecole Poly...
Plan du Cours – Distribution de l’Information

Première partie:
Distribution et Qualité des Données
 Deuxième partie:
Syn...
Première Partie: Distribution et Qualité des données

Distribution des données
Données
locales

composant
A

composant
B

...
Première Partie: Distribution et Qualité des données

Contraintes dans la gestion des données


Contraintes de performanc...
Première Partie: Distribution et Qualité des données

Concept de transaction


Double complexité à gérer (accès aux objet...
Première Partie: Distribution et Qualité des données

Propriétés ACID
Atomicité : une transaction doit s'effectuer en tout...
Première Partie: Distribution et Qualité des données

Le protocole 2PC (Two Phase Commit)


Sur un DBMS, la gestion des t...
Première Partie: Distribution et Qualité des données

Problématique de la distribution de données
Gestion des interactions...
Première Partie: Distribution et Qualité des données

Bases de données relationnelles
Proposées par E. Codd en 1970
 Tabl...
Première Partie: Distribution et Qualité des données

Annuaires Distribués


Annuaire: cas particulier de base de données...
Première Partie: Distribution et Qualité des données

Approches alternatives


XML Store







Stockage natif de XM...
Deuxième partie
Introduction et Formalisation
 Synchronisation et Resynchronisation
 Pilotage des processus


Copyright...
Deuxième Partie: (re) Synchronisation

Distribution et Stockage d’Information


La distribution fait déjà partie des arch...
Deuxième Partie: (re) Synchronisation

DCC (Distributed Concurrency Control)


Mécanisme central de la gestion des transa...
Deuxième Partie: (re) Synchronisation

Synchronisation et Processus
(1) Changement sur OM1
Données
locales

composant
A

(...
Deuxième Partie: (re) Synchronisation

The Snapshot Problem


« Distributed Snapshots : Determining Global States of Dist...
Deuxième Partie: (re) Synchronisation

Processus et Transactions Longues

Les processus servent à implémenter les transact...
Deuxième Partie: (re) Synchronisation

Re-synchronisation


Désynchronisation:







Erreurs durant le processus
Cr...
Troisième Partie




Introduction et Formalisation
Synchronisation et Re-synchronisation
Architecture de Données

Copyr...
Troisième Partie: Architecture de données

Design Patterns: Pas de solution unique
Sur un domaine de données, avec des con...
Troisième Partie: Architecture de données

Une « bonne » architecture de données (résumé)


Un modèle




Un cycle de v...
Troisième Partie: Architecture de données

MDM (Master Data Management)


Solution informatique en cours d’émergence pour...
Troisième Partie: Architecture de données

Modélisation de données - Principes






« Penser objet » : encapsulation e...
Troisième Partie: Architecture de données

Modélisation de données - Conseils








Réification des liens. La réific...
Troisième Partie: Architecture de données

Exigence sur les données


Gouvernance






CNIL






Ex: COBIT
 DS11...
Troisième Partie: Architecture de données

Cycle de vie
Lecture
Destruction

Création

Purge

Ecriture

Naissance
 Un seu...
Troisième Partie: Architecture de données

Processus de Gestion de Données
Bon
usage

1.

2.

3.

4.

5.

6.

Filtrage
Vér...
Prochain SlideShare
Chargement dans…5
×

Cours chapitre7 2012

1 852 vues

Publié le

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

Publié dans : Formation
0 commentaire
0 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

  • Soyez le premier à aimer ceci

Aucun téléchargement
Vues
Nombre de vues
1 852
Sur SlideShare
0
Issues des intégrations
0
Intégrations
2
Actions
Partages
0
Téléchargements
206
Commentaires
0
J’aime
0
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • From: http://fr.wikipedia.org/wiki/Transaction_informatique
  • What is a transaction? Actually, the concept of a transaction was invented as early as
    6000 years ago, when Sumerians noted down and scribed on clay tablets in order to
    keep records of the changes of royal possessions
    From: http://fp.tm.tue.nl/beta/publications/working%20papers/Beta_wp138.pdf
  • Figure: fig 1.10 du livre de Ozsu p 23
  • http://en.wikipedia.org/wiki/Directory_service
    The Domain Name System (DNS) is a hierarchical naming system for computers, services, or any resource participating in the Internet. It associates various information with domain names assigned to such participants. Most importantly, it translates human meaningful domain names to the numerical (binary) identifiers associated with networking equipment for the purpose of locating and addressing these devices world-wide. An often used analogy to explain the Domain Name System is that it serves as the "phone book" for the Internet by translating human-friendly computer hostnames into IP addresses. For example, www.example.com translates to208.77.188.166.
  • XML Query Languages
    XPath [4, 19] is a basic XML query language, used to select nodes from XML documents so
    that the path from the root to each selected node satisfies a specified pattern. A XPath query is
    specified by a sequence of alternate axes and tags.
    The XML queries can be basically divided into two main groups: path queries and twig
    queries [3]. Path queries are simple queries against XML documents, which contain path
    expressions, i.e child axis “/” and descendant axis “//”. An example of a path query is
    “/Publisher//title”, that returns all books' titles of all publishers. The tree queries (also called twig
    queries) are more complex since they contain selection predicates into path expressions. One such
    example is “/Publisher[@name='Studentlitteratur']/book/title” that returns the titles of all books,
    published by the Publisher, called “Studentlitteratur”. Generally, multiple predicates might be
    involved in a tree query.
    XQuery [1, 2, 4] is another popular XML query language, which is an extension to XPath. It
    is a functional language, comprised of FLOWR (For-Let-Where-Return) clauses that can be nested
    and composed. The following is an example of simple XQuery, defined by a FLOWR constructor
    that returns all the titles of the books in a bookstore that cost cheaper than 30:
    for $x in /bookstore/book
    where $x/price>30
    return $x/title.
    From this example is visible that XQuery includes two parts: twig pattern matching, defined
    by FLW in the case and result construction, defined by Return.
    http://en.wikipedia.org/wiki/Google_File_System :
    GFS is optimized for Google's core data storage and usage needs (primarily the search engine), which can generate enormous amounts of data that need to be retained;[2] Google File System grew out of an earlier Google effort, "BigFiles", developed by Larry Page and Sergey Brin in the early days of Google, while it was still located in Stanford.[2] Files are divided into chunks of 64 megabytes, which are only extremely rarely overwritten, or shrunk; files are usually appended to or read. It is also designed and optimized to run on Google's computing clusters, the nodes of which consist of cheap, "commodity" computers, which means precautions must be taken against the high failure rate of individual nodes and the subsequent data loss. Other design decisions select for high data throughputs, even when it comes at the cost of latency.
    The nodes are divided into two types: one Master node and a large number of Chunkservers. Chunkservers store the data files, with each individual file broken up into fixed size chunks (hence the name) of about 64 megabytes,[3] similar to clusters or sectors in regular file systems. Each chunk is assigned a unique 64-bit label, and logical mappings of files to constituent chunks are maintained. Each chunk is replicated several times throughout the network, with the minimum being three, but even more for files that have high demand or need more redundancy.
    The Master server doesn't usually store the actual chunks, but rather all the metadata associated with the chunks, such as the tables mapping the 64-bit labels to chunk locations and the files they make up, the locations of the copies of the chunks, what processes are reading or writing to a particular chunk, or taking a "snapshot" of the chunk pursuant to replicating it (usually at the instigation of the Master server, when, due to node failures, the number of copies of a chunk has fallen beneath the set number). All this metadata is kept current by the Master server periodically receiving updates from each chunk server ("Heart-beat messages").
    Permissions for modifications are handled by a system of time-limited, expiring "leases", where the Master server grants permission to a process for a finite period of time during which no other process will be granted permission by the Master server to modify the chunk. The modified chunkserver, which is always the primary chunk holder, then propagates the changes to the chunkservers with the backup copies. The changes are not saved until all chunkservers acknowledge, thus guaranteeing the completion and atomicity of the operation.
    Programs access the chunks by first querying the Master server for the locations of the desired chunks; if the chunks are not being operated on (if there are no outstanding leases), the Master replies with the locations, and the program then contacts and receives the data from the chunkserver directly (similar toKazaa and its supernodes).
    http://en.wikipedia.org/wiki/BigTable
    BigTable is a compressed, high performance, and proprietary database system built on Google File System (GFS), Chubby Lock Service, and a few otherGoogle programs; it is currently not distributed or used outside of Google, although Google offers access to it as part of their Google App Engine. It began in 2004[1] and is now used by a number of Google applications, such as MapReduce, which is often used for generating and modifying data stored in BigTable[2], Google Reader,[3] Google Maps,[4] Google Book Search, "My Search History", Google Earth, Blogger.com, Google Code hosting, Orkut[4], andYouTube[5]. Google's reasons for developing its own database include scalability, and better control of performance characteristics.[6]
    BigTable is a fast and extremely large-scale DBMS. However, it departs from the typical convention of a fixed number of columns, instead described by the authors as "a sparse, distributed multi-dimensional sorted map", sharing characteristics of both row-oriented and column-oriented databases. BigTable is designed to scale into the petabyte range across "hundreds or thousands of machines, and to make it easy to add more machines [to] the system and automatically start taking advantage of those resources without any reconfiguration".[7]
    Each table has multiple dimensions (one of which is a field for time, allowing versioning). Tables are optimized for GFS by being split into multiple tablets - segments of the table as split along a row chosen such that the tablet will be ~200 megabytes in size. When sizes threaten to grow beyond a specified limit, the tablets are compressed using the secret algorithms BMDiff[8] and Zippy[8], which are described as less space-optimal than LZW but more efficient in terms of computing time. The locations in the GFS of tablets are recorded as database entries in multiple special tablets, which are called "META1" tablets. META1 tablets are found by querying the single "META0" tablet, which typically has a machine to itself since it is often queried by clients as to the location of the "META1" tablet which itself has the answer to the question of where the actual data is located. Like GFS' master server, the META0 is not generally abottleneck since the processor time and bandwidth necessary to discover and transmit META1 locations is minimal and clients aggressively cache locations to minimize queries.
  • http://research.microsoft.com/en-us/um/people/lamport/pubs/chandy.pdf
    Le théorème CAP ou CDP, aussi connu sous le nom de théorème de Brewer dit qu'il est impossible sur un système informatique de calcul distribué de garantir en même temps les trois contraintes suivantes1,2 :
    Cohérence : tous les nœuds du système voient exactement les mêmes données au même moment ;
    Disponibilité (Availability en anglais) : la perte de nœuds n'empêche pas les survivants de continuer à fonctionner correctement ;
    Résistance au morcellement (Partition Tolerance en anglais) : aucune panne moins importante qu'une coupure totale du réseau ne doit empêcher le système de répondre correctement (ou encore : en cas de morcellement en sous-réseaux, chacun doit pouvoir fonctionner de manière autonome).
    D'après ce théorème, un système de calcul distribué ne peut garantir à un instant T que deux de ces contraintes mais pas les trois3.
  • http://www.chevance.com/pdf/cnam/transactionnel.pdf
    Tuxedo:
    Développé par ATéT sous unix, repris par USL(Unix System Labs) puis Novel et maintenant BEA
    Début de commercialisation en 1989 – plusieurs milliers de systèmes installés
    Conforme  au modèle X/Open DTP (Support des transactions distribués)
    Architecture client/serveur
    Support (client) au niveau des langages ex: VB, Java, Cobol, …
    Online transaction processing, or OLTP, refers to a class of systems that facilitate and manage transaction-oriented applications, typically for data entry and retrieval transaction processing. The term is somewhat ambiguous; some understand a "transaction" in the context of computer or database transactions, while others (such as the Transaction Processing Performance Council) define it in terms of business or commercial transactions.[1] OLTP has also been used to refer to processing in which the system responds immediately to user requests. An automatic teller machine (ATM) for a bank is an example of a commercial transaction processing application.
    The technology is used in a number of industries, including banking, airlines, mailorder, supermarkets, and manufacturing. Applications include electronic banking, order processing, employee time clock systems, e-commerce, and eTrading. The most widely used OLTP system is probably IBM's CICS.
    CICS (Customer Information Control System) is a transaction server that runs primarily on IBM mainframe systems under z/OS and z/VSE.
    CICS is a transaction manager designed for rapid, high-volume online processing. This processing is mostly interactive (screen-oriented), but background transactions are possible.
  • http://www.informatica.com/FR/solutions/integration/mdm/mdm_informatica_fr.pdf
    Attention
    Référentiel (service) != Référentiel
    MDM Alliance: http://www.mdmalliancegroup.com/
  • penser objet, penser méta et penser générique.
    « Penser objet » est un raccourci pour caractériser une approche mise en avant par la programmation à 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 (cf. section précédente). L’encapsulation propre à l’approche objet signifie qu’un objet n’est pas défini à partir de ses données internes (qui sont cachées, et qu’il vaut mieux penser comme incomplètes, ce qui permet ensuite de les faire évoluer) mais par sa position ontologique et par ses interfaces (les services qu’il peut rendre). L’expérience montre que la hiérarchie ontologique est stable lorsque le métier évolue, et que l’ensemble des services/méthodes évolue le plus souvent de façon croissante, par ajout. L’approche objet permet également d’introduire la réification des rôles que nous avons introduite dans la section 2.2.1.
     
    « Penser méta » signifie qu’il faut construire et formaliser le méta-modèle de données. Le méta-modèle est le modèle qui décrit les objets utilisés pour construire des différents modèles de données (les objets métiers, mais aussi les processus et les systèmes). L’intérêt d’un méta-modèle est, d’une part, de mieux comprendre le modèle métier et de faciliter son partage et sa diffusion, mais surtout, de permettre de comparer des modèles différents et de simplifier les transferts d’un modèle vers l’autre. Le méta-modèle est une caractérisation précise de ce qui peut être perçu comme « un assemblage de boites et de flèches » (c’est le cas lorsque le modèle métier est construit avec un assemblage ad hoc de « PowerPoint », un peu moins le cas lorsqu’il est décrit en UML et encore moins le cas si le modèle est le résultat d’une démarche méthodologique). Cette caractérisation est essentielle pour produire une cartographie de qualité, dont nous avons vu qu’elle est un des éléments clés d’une démarche d’urbanisation. Il existe de nombreux formalismes en cours de normalisation (Web Sémantique, RDF, meta-object factory de l’approche MDA,…) pour construire une méta-description d’un modèle de données, sur lesquels nous allons revenir dans le prochain chapitre. On peut résumer les avantages de ce travail de méta-modélisation en trois points :
    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.
    Un exemple très intéressant est mentionné dans le livre de F. Cummins : il ne faut pas confondre l’état d’un objet (les données qu’il contient), les demandes de modifications (qui ont été faites sur ces données) et l’état des demandes de modification (lié aux processus de mise-à-jour). La définition du méta-modèle conduit naturellement à se poser ce type de question.
     
    « 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. La façon la plus simple est de s’inspirer des modèles « génériques » liés à des frameworks (cf. 2.2.3), mais il est également possible de valider/critiquer son propre modèle à partir de « jeux de rôles ». 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).
    En particulier, il est très intéressant de se poser le plus tôt possible des questions liées à l’exposition de services (cf. 2.3.2). De la même façon qu’un logiciel spécifique et un progiciel ne sont pas structurés pareillement, le fait de pouvoir fournir à une société externe un service que l’on sait faire en interne suppose bien entendu des interfaces claires (ce à quoi tout le monde pense) mais aussi un certain niveau de paramétrisation du modèle de données (ce à quoi on ne pense pas toujours, ou alors trop tard). Ce type d’approche va bien sûr au delà du simple modèle de donnée puisqu’il permet d’analyser l’ensemble : modèle de donnée + cartographie fonctionnelle + processus. Ce type de raisonnement par scénarios doit également inclure, comme nous l’avions noté dans le chapitre précédent, les scénarios de purge et de nettoyage applicatif.
    Cette remarque dépasse le cadre de la modélisation pour les systèmes d’information. Par exemple, on peut penser à l’importance d’une constitution (et d’un ensemble de lois organiques) qui fournit le méta-modèle pour les lois ordinaires et décrets.
    Cf. p.186 dans le chapitre 7, « Process State versus Subject Matter State ».
  • Réification des liens. Toute modélisation consiste à définir des concepts reliés par des liens. C’est précisément la définition de ce qu’est un modèle entité-relation, mais c’est une partie sous-jacente de toute modélisation orientée-objet ou UML. Les liens se traduisent le plus souvent dans un modèle objet par la notion d’attribut. C’est une approche simple qui est indiquée pour la plupart des cas mais qui fige le modèle dans son évolutivité. 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. Par exemple, si l’on réifie l’attribut « propriétaire » d’un objet « téléphone mobile », qui passe d’une « personne » à un objet qui représente le lien et pointe sur cette personne, cet objet va permettre de représenter de nombreuses modalités sur le lien de propriété entre le client et son mobile.
    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. Cette approche permet de surmonter les situations confuses où un concept semble appartenir à des classifications multiples. Par exemple, un téléphone multimédia est un objet physique, c’est un moyen de communication, c’est un terminal multimédia, etc. La définition de sous objets : le téléphone en tant qu’objet physique, en tant que moyen de communication, etc. permet de simplifier le travail de classification.
    Réification des rôles. C’est l’application du principe de réification des liens au cas particulier des rôles. Par exemple, chaque client a de nombreux rôles dans le système d’information. La liste des rôles n’est pas exhaustive, il faut donc pouvoir ajouter de nouveaux rôles, par exemple liés à de nouveaux usages. De plus, la sémantique de chaque rôle peut évoluer : le rôle de « payeur » sur un compte peut évoluer en fonction des nouveaux moyens de paiement électroniques ou d’un nouveau programme de fidélisation adressé au payeur (par opposition à l’utilisateur, ce qui est le plus courant). 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. L’expérience est que ce type de modification a un fort impact sur les systèmes informatiques car il remet en cause le modèle de données. Ce type d’inconvénient peut être évité au niveau du modèle d’entreprise si l’on prend soin d’introduire des patterns « groupe/individus » dans la définition des principaux rôles.
    La modélisation entité-relation est une des méthodes les plus classiques et les plus efficaces pour représenter des données. Pour un survol voir la troisième partie de « Design Methods for Reactive Systems » de R.J. Wieringa, ou pour un très bon livre d’application pratique, voir « CASE*Method : Entity Relationship Modeling » de Richard Baker. On peut également consulter les actes du colloque francophone LMO (Langage et Modèles à Objet), qui est en grande partie consacré chaque année à ce sujet.
    Puisqu’il s’agit de l’ordre induit sur le produit cartésien de l’ensemble des classes. On parle également de sous-typage paramétrique, puisque les sous-objets sont des paramètres des classes. L’intérêt du sous-typage paramétrique est d’éviter la prolifération dans les hiérarchies de classes, ce qui est précisément ce qu’on obtient avec des hiérarchies utilisant l’héritage multiple puisqu’on crée une classe différente pour toutes les combinaisons de types de paramètres.
  • http://www.qualite-info.net/SISQUAL2005/Planches/4E4_MOISAND.pdf
    http://www.sfdama.org/Presentations/Sarbanes_Oxley_Compliance_Data_Mgmt.ppt
    IT IS THE ABOUT DATA!
    Sarbanes-Oxley requires more data management than ever before.
    RECORD RETENTION IS MORE STRINGENT
    Sarbanes-Oxley requires auditors to retain for a seven-year period all relevant documents (work-papers, memos, correspondence and records [electronic and / or paper]) that contain conclusions, opinions, analyses or financial data created, sent or received in connection with the audit of a public company.
    ENSURE TRANSPARENCY & RELIABLE PROCESS
    Aimed at improving trust and investor confidence
  •  
    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. Dans un SI urbanisé avec un flux inter-applicatif important, la validation de la cohérence des données qui sont injectées dans l’infrastructure d’intégration est fondamentale (cf. un livre connu)
    La conception des échanges doit garantir la cohérence à tous les niveaux. Au niveau sémantique, s’assurer que les changements de modèles ne déforment pas l’information qui est associée à la donnée.  Au niveau du format, il faut s’assurer que les transformations XML sont correctes et correctement interprétées.
    Liste des taches:
    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. La responsabilité de faire des audits de contrôle de qualité des données incombe à la MOE (patrimoniale) de chaque ST, mais c’est l’équipe « Architecture de données » qui doit assurer la cohérence d’ensemble, le rôle de mémoire collective et le partage de l’information et des bonnes pratiques.
  • Cours chapitre7 2012

    1. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 12. Deuxième partie Introduction et Formalisation  Synchronisation et Resynchronisation  Pilotage des processus  Copyright © Yves Caseau – 2012 - Cours Polytechnique (VII) 12/28
    13. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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

    ×