Théorie et Pratique du Système d’Information
Septième Chapitre: Distribution de l’information
Janvier-Mars 2009 Ecole Polytechnique
Yves Caseau
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
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) P re m iè re P a rti e : D is tri b u tio n e t Q u a lit é d es d o n n é e s
composant A
même client
Données locales
Données partagées
composant B
composant C
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
P re m iè re P a rti e : D is tri b u tio n e t Q u a lit é d es d o n n é e s
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)
P re m iè re P a rti e : D is tri b u tio n e t Q u a lit é d es d o n n é e s
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.
P re m iè re P a rti e : D is tri b u tio n e t Q u a lit é d es d o n n é e s
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
P re m iè re P a rti e : D is tri b u tio n e t Q u a lit é d es d o n n é e s
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
P re m iè re P a rti e : D is tri b u tio n e t Q u a lit é d es d o n n é e s
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
P re m iè re P a rti e : D is tri b u tio n e t Q u a lit é d es d o n n é e s
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
P re m iè re P a rti e : D is tri b u tio n e t Q u a lit é d es d o n n é e s
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
P re m iè re P a rti e : D is tri b u tio n e t Q u a lit é d es d o n n é e s
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
P re m iè re P a rti e : D is tri b u tio n e t Q u a lit é d es d o n n é e s
Deuxième partie
• Introduction et Formalisation
• Synchronisation et Resynchronisation
• Pilotage des processus
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 » D e u x iè m e P a rti e : ( re ) S yn ch ro n is a tio n
Serveurs applicatifs Serveurs données
Cluster HP SAN
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
D e u x iè m e P a rti e : ( re ) S yn ch ro n is a tio n
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
D e u x iè m e P a rti e : ( re ) S yn ch ro n is a tio n
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
D e u x iè m e P a rti e : ( re ) S yn ch ro n is a tio n
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)
D e u x iè m e P a rti e : ( re ) S yn ch ro n is a tio n
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
D e u x iè m e P a rti e : ( re ) S yn ch ro n is a tio n
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èle paresseux Insouciant entrelacé
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
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
D e u x iè m e P a rti e : ( re ) S yn ch ro n is a tio n
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 processus Fin 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
D e u x iè m e P a rti e : ( re ) S yn ch ro n is a tio n
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)
D e u x iè m e P a rti e : ( re ) S yn ch ro n is a tio n
Synchronisation et Processus: la cible (entrelacée)
broker CCS Re-sync Annuaire
Référentiel 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
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)
D e u x iè m e P a rti e : ( re ) S yn ch ro n is a tio n
Troisième Partie
• Introduction et Formalisation
• Synchronisation et Re-synchronisation
• Architecture de Données
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
T ro is iè m e P ar tie : A rc h ite c tu re d e d o n n ée s
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
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 »
T ro is iè m e P ar tie : A rc h ite c tu re d e d o n n ée s
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
ertemps : modéliser le métier / les cycles de vie
o
2
èmetemps: créer un modèle logique de donnée
urbanisation des donnée (ex: repérer les couplages)
o
3
èmetemps: 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: http://www.orchestranetworks.com/product/index.cfm
T ro is iè m e P ar tie : A rc h ite c tu re d e d o n n ée s
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).
T ro is iè m e P ar tie : A rc h ite c tu re d e d o n n ée s
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.
T ro is iè m e P ar tie : A rc h ite c tu re d e d o n n ée s
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 ☺
T ro is iè m e P ar tie : A rc h ite c tu re d e d o n n ée s
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 Destruction Purge
Ecriture
T ro is iè m e P ar tie : A rc h ite c tu re d e d o n n ée s
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
T ro is iè m e P ar tie : A rc h ite c tu re d e d o n n ée s
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.
T ro is iè m e P ar tie : A rc h ite c tu re d e d o n n ée s
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 Synchronisation Nettoyage
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
