APPLICATIONREPARTIE S

AU: 2023/2024
La majorité des applications informatiques sont maintenant réparties, c’est-à-
dire mettent en jeu un ensemble d’ordinateurs ou d’organes divers reliés par un
réseau de communication
Objectif du cours
 Rappels de l’architecture des réseaux et Introduire les notions de base des

applications et des systèmes réparties

 Connaitre les technologies majeures pour le développement des applications

réparties.
 Comprendre les solutions
-Sockets Java et RPC

-Objets réparties en Java (RMI, CORBA)

2
Plan Matière
-Introduction
-Évolution des systèmes d’information
-Évolution des architectures distribuées
-L'architecture 1-tiers
-L'architecture 2-tiers
-L'architecture 3-tiers
-L'architecture N-tiers
-BD distribuées et fédérées
-Architecture JEE
-Systèmes transactionnels
-Architectures Distribuées
ARCHITECTURES
CLIENT/SERVEUR
Introduction
Evolution des systèmes d’information (1/4)
4

 Un système d’information est constitué d’un

ensemble d’outils destinés à gérer, stocker et
traiter des flux d’information.
 Un « Post-it » laissé par une secrétaire sur le
bureau de son directeur pour lui transmettre
un message est considéré comme un
système d’information.
 L’informatique n’est qu’un outil mis à
disposition des organisations afin de
compléter d’améliorer le système
d’information déjà en place.
Evolution des systèmes d’information (2/4)
5

 L’informatique tend au fur et à mesure des années à

devenir le principal outil incontournable d’un système
d’information.
 Les applications et programmes informatiques
évoluent désormais dans plusieurs domaines
d’activité : comptabilité, administration, chaine de
montage, etc...
 Progressivement, les applications mises en
place se regroupent au sein d’applications
de plus en plus importantes.
 L’objectif étant à terme d’obtenir une seule et même
application qui gère l’ensemble du système
d’informations dans l’ensemble des secteurs
d’activité d’une entreprise ou organisation.
 Evolution des systèmes d’information (3/4)
6

 Avec l’évolution des technologies, les applications

ont progressivement évolué, les attentes des
utilisateurs et des clients également.
 Autrefois, les entreprises privilégiaient le fonctionnel à
l’esthétique, la popularité du système monolithique
(Mainframe) AS/400 en est un très bel exemple.
 Cet outil à la fois simple et extrêmement complet d’un point de
vue fonctionnel ne doit pas sa renommée à son interface
graphique (texte blanc sur fond noir avec des menus
uniquement textuels).
 Il serait aujourd’hui impensable de mettre en place un outil
semblable à l’AS/400 au cœur d’un système d’information.
 Evolution des systèmes d’information (4/4)
7

 Les applications composées d’un exécutable à lancer

ont progressivement laissé la place à des applications
accessibles à partir d’un réseau par l’intermédiaire
d’un navigateur Web.
 Cette évolution est due en partie aux évolutions
technologiques mais aussi grâce à la simplicité de de
mise à jour de l’application :
 Il est plus simple de mettre à jour un serveur unique avec une
interface Web que de compiler un programme et de le
déployer sur l’ensemble des postes du réseau.
 Chaque utilisateur peut accéder à l’application à partir de
n’importe quel PC connecté au réseau doté d’un navigateur
Web alors qu’il aurait été nécessaire autrefois d’avoir un poste
de travail configuré avec l’application préalablement installée.
 Systèmes monolithiques
8

 Le système monolithique centralise la gestion des

données et des tâches sur une seule machine
(ordinateur central, généralement puissant (Mainframe))
 Il gère également un réseau où sont connectés des
terminaux passifs de requêtes (machines sans unité
central)
 Le système central se charge également de la partie
interface utilisateur
 La centralisation des données et des traitements présente
plusieurs inconvénients:
 rend le système fragile à la panne de l’ordinateur central (non
robuste)
 provoque la congestion des communications entre les
terminaux et l’ordinateur central (arrivé de plusieurs
requêtes simultanément)
 surcharge l’ordinateur central
 Systèmes répartis
9

 Dans un système reparti, l'application est

divisée en plusieurs morceaux où chacun
effectue un traitement donnée.
 Possibilité de dupliquer un morceau pour
offrir une meilleure robustesse (fiabilité) du
système
 Chaque morceau de l'application repartie peut
être développé dans un langage de
programmation différent et être exécuté
depuis un système d'exploitation différent.
Evolution des architectures distribuées
 Introduction
11

 Il est de plus en plus fréquent dans le monde

de l'information, qu’on définisse les
applications comme étant distribuées (ou
réparties).
 Les applications distribuées doivent interagir
avec plusieurs ordinateurs en
communiquant à travers un réseau (local ou
distant).
 Quelles sont les différentes
architectures des applications
distribuées ?
 Trois niveaux d’abstraction
12

 Une application informatique peut être découpée

en trois niveaux d'abstraction distincts :

 Présentation Présentation

Locaux
 Logiqueapplicative Traitements Globaux

 Données
Données
 Présentation
13

 la couche de présentation, encore appelée

IHM (Interface Homme Machine), permet
l'interaction de l'application avec
l'utilisateur
 Gère les saisies au clavier et à la souris et

la présentation des informations à l'écran.

 Doit être conviviale et ergonomique.
 Logique applicative
14

 la logique applicative décrit les traitements à

réaliser par l'application.
 Ensemble de traitements nécessaires pour
répondre aux besoins des utilisateurs
 Les traitement peuvent être découpés en deux
familles :
 les traitements locaux: regroupant les contrôles
effectués au niveau du dialogue avec l'IHM, visant
essentiellement le contrôle et l'aide à la saisie
(formulaires, champs, boutons radio…)
 les traitements globaux: constituant l'application elle-
même.
Cette couche, appelée Business Logic ou couche
métier, contient les règles de l’application.
 Les données
15

 Les données, ou plus exactement l'accès aux

données, regroupent l'ensemble des
mécanismes permettant la gestion des
informations stockées par l'application.
 Fonctions classiques d’un SGBD :
 Définition de données
 Manipulation de données
 Sécurité de données
 Gestion de transactions
 etc. ..
 Différentes architectures
16

 Le découpage et la répartition des 3 niveaux

d’abstraction permettent de distinguer les
architectures suivantes
 l'architecture 1-tier,
 l'architecture 2-tiers,
 l'architecture 3-tiers,
 les architectures n-tiers.
17 Architecture 1-tier
 Présentation
18

 les trois niveaux (présentation, traitement,

données) sont fortement liés et s'exécutent
sur la même machine.
 Dans un contexte multiutilisateurs, on
distingue deux types d'architectures mettant
en œuvre des applications 1-tiers :
 Les applications sur site central (Mainframe)
 Les applications applications 1-tier déployées
sur des machines indépendantes (Micro-
Ordinateurs)
 Lesapplications sur site central (Mainframe)
19

 Les applications sur site central étaient les

premières à proposer un accès
multiutilisateurs.
 Les utilisateurs se connectent aux applications
exécutées par le serveur central (le mainframe) à
l'aide de terminaux passifs
 le serveur central prend en charge l'intégralité des
traitements, y compris l'affichage qui est
simplement transmis sur des terminaux passifs.
 Lesapplications sur site central (Mainframe)
20

 Architecture d'une application sur site central

 Mainframe
21

 IBM, AS/400, RS6000, HDS, SUN Microsystems et Hewlett-Packard

RS6000
22
 Les applications 1-tier déployées (1/2)
23

 Avec l'arrivée des premiers PC en réseau, il est

devenu possible de déployer une application 1-
tier sur plusieurs ordinateurs indépendants.
 Ce type de programme est simple à
concevoir et à mettre en œuvre.
 Il existe de nombreux environnements de
développement (dBase, Ms Access, Lotus
Approach, Paradox... ) qui sont souvent
intégrés aux principales suites bureautiques.
 L'ergonomie des applications mises en œuvre,
basée sur celle des outils bureautiques, est très
riche.
 Lesapplications 1-tier déployées (2/2)
24

 Ce type d'application peut être très satisfaisant

pour répondre aux besoins d'un utilisateur isolé
 Sa mise en œuvre dans un
environnement multiutilisateurs est
envisageable:
 plusieurs utilisateurs se partagent des fichiers de
données stockés sur un serveur commun.
 Le moteur de base de données est
exécuté indépendamment sur chaque
poste client.
 La gestion des conflits d'accès aux données doit être
prise en charge par chaque programme de façon
indépendante, ce qui n'est pas toujours évident.
 Limitations de l’arch. 1-tier
26

 Les applications sur site central souffrent d'une

interface utilisateur en mode caractères
jugée « obsolète »
 la cohabitation d'applications sur PC exploitant des
données communes n'est pas fiable au delà d'un
certain nombre d'utilisateurs.
 Solution
27

 Trouver une solution regroupant:

 la fiabilité de l’application sur site central, qui gèrent
les données de façon centralisée,
 l'interface utilisateur moderne des applications sur
micro-ordinateurs (applications 1-tier déployées).
 Il est nécessaire de scinder l’application en plusieurs
parties distinctes et coopérantes :
 gestion centralisée des données
 gestion locale de l'interface utilisateur

Naissance du concept du client/serveur.

28 Concept du Client-Serveur
 Définition
29

C’est une architecture de systèmes

informatiques dans laquelle un ensemble de
machines interconnectées partagent des
ressources.
 Structure
30

Un système client/serveur est :

 Animé par trois types d’acteurs :
 Serveur(s)
 Clients
 Middleware(s)

 Constitué de trois composantes :

 Présentation
 Logique applicative
 Gestion des données
 Lestrois types d’acteurs
31

 Serveur Machine qui dispose de ressources qui les

gère et accepte de lespartager:
 Ressources informationnelles
 Client
 Ressources physiques

 Middleware
 Lestrois types d’acteurs
32

 Serveur

 Client Machine demandant l’utilisation de

ressources d’un serveur.

 Middleware
 Lestrois types d’acteurs
33

 Serveur

 Client

Ensemble de mécanismes assurant la

 Middleware communication entre client et serveur
 Le schéma du Gartner Group
34

 Lesdifférents types de client-serveur selon la classification du

Gartner Group

 Le trait horizontal représente le réseau

 les flèches représentent le trafic réseau généré par la
conversation entre client et serveur.
 1. Présentation distribuée
35

 Correspond à l'habillage ``graphique'' de

l'affichage en mode caractères d'applications
fonctionnant sur site central.
 Cette solution est aussi appelée revamping.
 La classification « client-serveur » du
revamping est souvent jugéeabusive:
 L'intégralité des traitements originaux est
conservée
 Le poste client conserve une position d'esclave
par rapport au serveur.
 2. Présentation distante
36

 Encore appelée client-serveur de

présentation.
 L'ensemble des traitements est exécuté par
le serveur, le client ne prend en charge que
l'affichage.
 Inconvénients:
 Génère un fort trafic réseau
 Aucune répartition de la charge entre client
et serveur.
 2. Présentation distante
37

 X Window System ou X11 permet la présentation distance

 interface utilisateur graphique qui gère l'interaction homme-
machine par l'écran, la souris et le clavier des ordinateursdistants
 3. Gestion distante des données
38

 Correspond au client-serveur de données

 Représente le type de client-serveur le plus
répandu
 Principe:
 L'application fonctionne dans sa totalité sur le
client
 La gestion des données et le contrôle de leur
intégrité sont assurés par un SGBD centralisé.
 Inconvénients :
 Génère toutefois un trafic réseau important
 Ne soulage pas énormément le poste client, qui
réalise la grande majorité des traitements.
 4. Traitement distribué
39

 Correspond au client-serveur de traitements

 Principe : les traitements sont distribués entre le
client et le serveur
 Utilise le mécanisme d'appel de procédure distante

 Avantage: Cette architecture permet d'optimiser

la répartition de la charge de traitement entre
machines et limite le trafic réseau.
 Inconvénient: il n'offre pas la même souplesse que
le client-serveur de données puisque les traitements
doivent être connus du serveur à l'avance.
 5. Bases de données distribuées
40

 Il s'agit d'une variante du client-serveur de

données
 Principe: une partie de données est prise en
charge par le client.
 Ce modèle est intéressant:
 Si l'application doit gérer de gros volumes de
données
 Disposer de temps d'accès très rapides sur certaines
données
 Garantir une grande confidentialité.
 Inconvénients:
 Complexe à mettre en œuvre
 Le client réalise la majorité des traitements
 6. Données et traitements distribués
41

 Principe: répartir la charge des données

et des traitements entre le client et le
serveur
 Ce modèle est très puissant et tire partie
de la notion de composants réutilisables et
distribuables pour répartir au mieux la
charge entre client et serveur
 C'est l'architecture la plus complexe à
mettre en œuvre
 Remarques
42

 Les différents types du modèle client-serveur

proposés par Gartner Group sont indépendants et
combinables à volonté.
 Les deux premiers types (présentation distribuée
et présentation distance) ne correspondent pas,
vraiment, à des applications client-serveur.
 Les traitements et la gestion des données sont
réalisées par le serveur
 La première solution qui met en œuvre un modèle
client- serveur correspond au client-serveur de
données (troisième niveau du schéma de Gartner).
 Ce modèle client-serveur de données, appelé aussi
client- serveur de première génération, suit une
architecture 2- tiers.
L'architecture 2-tiers
 Présentation de l’arch. 2-tiers (1/2)
44

 Une architecture 2-tiers, encore appelée client-

serveur de première génération ou client-serveur
de données
 Le poste client délègue la gestion des données

à unservice spécialisé (serveur de données).

 Exemple: une application de gestion

fonctionnant sur Windows et exploitant un

SGBD (oracle) centralisé.
 Présentation de l’arch. 2-tiers (2/2)
45

 Ce type d'application permet:

 d’exploiter la puissance des ordinateurs pour fournir à
l’utilisateur uneinterface riche
 de garantir la cohérence des données

 La gestion des données est prise en charge par un

SGBD centralisé, s'exécutant le plus souvent sur un
serveur dédié (serveur de données).
 Leserveur de données est interrogé en utilisant un
langage de requête qui est, le plus souvent, SQL.
 Le dialogue client-serveur (1/2)
46

 Le dialogue entre client et serveur consiste à:

 Envoyer de requêtes (coté client)
 Renvoyer les données correspondant aux requêtes (coté
serveur).
 Dans une conversation client-serveur, on distingue donc
les deux parties suivantes :
 Client: le programme qui provoque (initialise) le dialogue
 Serveur: le programme qui se contente de répondre au client
 Le dialogue client-serveur (2/2)
47

 Le client provoque l'établissement d'une conversation afin de

d'obtenir des données ou un résultat de la part du serveur.

 Cet échange de messages transite à travers le réseau reliant les

deux machines.
 Il utilise des mécanismes relativement complexes qui sont, en
général, pris en charge par un intergiciel (middleware).
 Middleware
48

 Un middleware ou « intergiciel » ou «
élément du milieu » est l'ensemble des
couches réseau et services logiciel qui
permettent le dialogue entre les différents
composants d'une application répartie.
 Gartner Group définit le middleware comme
une interface de communication
universelle entre processus.
 Représente l’élément le plus important de
toute application client-serveur.
 Middleware
49

 Objectif
 Unifier, pour les applications, l'accès et la manipulation
de l'ensemble des services disponibles sur le réseau, afin
de rendre l'utilisation de cesderniers transparente
 Offre des API (Application Programming Interface)
de haut niveau
 Permettant de masquer la complexité des échanges
inter-applications
 Facilite le développement d'une application client-
serveur
 Middleware
50

 Positionnement du middleware entre client et serveur

 Middleware
51

Services du middleware
 Conversion :
 permet la communication entre machines mettant en
œuvre des formats différents de données prise en
charge par la FAP (Format And Protocol)

 Adressage :
 Permet d'identifier la machine serveur sur laquelle
est localisé le service demandé afin d'en déduire le
chemin d'accès.
 fait, souvent, appel aux services d'un annuaire.
 Middleware
52

 Sécurité :
 permet de garantir la confidentialité et la sécurité des
données à l'aide de mécanismes d'authentification et
de cryptage des informations
 Communication :
 permet la transmission des données entre les deux
systèmes
 Types de middleware
53

 Middleware de base de données

 Moniteurs transactionnels
 Middleware orienté messages (MoM)
 Middleware orienté objets
 Middleware orienté services
 Fonctions du middleware de BD
54

 Rendre le client indépendant de la localisation

géographique des données
 Masquer l’hétérogénéité des serveurs de données
 Masquer l’hétérogénéité entre les clients et le
serveur
 Types de middleware de BD
55

Middleware propriétaire
 Toutes les données sont gérées par un même SGBD
 L’application utilise uneAPI propriétaire au SGBD
 Avantages
 Utilisation de toutes les fonctionnalités du SGBD
 Meilleur temps de réponse
 Inconvénients
 Dépendance totale du SGBD : le changement du SGBD
entraîne la réécriture de la couche traitement
 Exemples:
 SQL*Net d’Oracle
 Open Client de Sybase
 Types de middleware de BD
56

Middleware indépendant
 Indépendant du SGBD.
 Avantages
 Indépendance par rapport au SGBD
 Possibilité de connexions avec différentes BD
 Inconvénients
 Besoin d’un driver pour chaque SGBD
 Utilisation partielle des fonctionnalités des SGBD
 Perte de performance
 Exemples:
 ODBC de Microsoft
 JDBC
 IDAPI de Borland, IBM, Novell et Wordperfect
 Gestion des données
57

 Fonctions de SGBD
 Définition des données
 manipulation des données
 Sécurité et intégrité de données
 Gestion des transactions
 Gestion des accès concurrents
 Gestion des données réparties (BD dedistribuées)
 Définition des données
58

Création, suppression et modification des :

 Objets: Tables, Contraintes d’intégrité,
Séquenceurs, Procédures cataloguées,
Déclencheurs, Vues, Synonymes, etc...

 Structures physiques et chemins d’accès : Index,

Regroupement, localisation de données, etc...
 Manipulation des données
59

 Consultation des données : Sélection, projection,

produit cartésien, jointures, union, intersection,
différence, fonctions (numérique, chaîne de caractères,
date, conversion, autres), regroupement, tri, imbrication
de requêtes

 Mise à jour des données : Insertion, modification et

suppression de données
 Sécurité et intégrité de données
60

 Gestion des utilisateurs

 Notion de groupe d’utilisateurs
 Gestion des droits d’accès
 Contrôle d’utilisation des ressources
 Contrôle de la validité des opérations effectuées
 Protection des donnée
 Gestion des transactions
61

 Une transaction : effectuer une opération cohérente

composée de plusieurs tâches unitaires.
 L'opération est valide lorsque toutes les tâches unitaires
sont effectuées correctement (commit).
 Sinon, l'ensemble des données traitées lors de
l'opération reviennent à leur état initial (rollback).
 Un moniteur transactionnel assure le bon
déroulement des transactions en respectent les
quatre contraintes dites ACID
 Gestion des transactions
62

 les quatre contraintes ACID:

 Atomicité : une transaction doit s'effectuer en tout
ou rien
 Cohérence : la cohérence des données doit être
assurée même dans les cas d'erreur (le système
doit revenir au précédent état cohérent)
 Isolation : une transaction n'est pas affectée par
le résultat des autres transactions
 Durée : les transactions validées sont conservées
même si le système tombe en panne.
 Gestion des accès concurrents
63

 Parallélisme d’exécution de plusieurs transactions

 Verrouillage des ressources
 Mécanisme d’inter-blocage
Les architectures distribuées
Architectures 3-tiers
Architectures N-tiers
 Limites du client-serveur 2-tiers (1/2)
84

 le poste client réalise tous les traitement applicatifs

 Il est coûteux et contraignant de réaliser l'ensemble des traitements
applicatifs et de les maintenir par le poste client.
 Le poste client doit installer une application
assez complexe
Client Lourd ( fat client )

 La conversation entre client et serveur est assez bruyante

et s'adapte mal à des bandes passantes étroites.
 Ce type d'application est souvent réservé au réseau local de
l'entreprise
 Limites du client-serveur 2-tiers (2/2)
85

 Architecture rigide :
 Coûts : mise à jour de l’ensemble des clients
 Le poste client doit être mis à jour
régulièrement pour répondre aux besoins des
utilisateurs
 Maintenance difficile
Architectures 3-tiers

83
 Présentation de l’arch. 3-tiers (1/2)
86

 Leslimites de l'architecture 2-tiers proviennent de la

nature du client utilisé :
 Le frontal est complexe et non standard ( PCavec
Windows, Linux, Mac,…)
 Le middleware entre client et serveur n'est pas
standard ( dépend de la plateforme, du
SGBD)

Solution : utilisation d'un poste client simple

communicant avec le serveur par le biais d'un
protocole standard.
Présentation de l’arch. 3-tiers (2/2)
La solution résiderait dans l’utilisation d’un poste
client simple communicant avec le serveur par le
biais d’un protocole standard.
Avènement de l’architecture 3-tiers (appelée aussi
C/S de 2ème génération ou C/S distribué ) ayant
comme proposition :
oLes données sont toujours gérées de façon centralisée
oLa présentation est toujours prise en charge par le poste client
(souvent appelé client léger)
oLa logique applicative est prise en charge par un serveur
intermédiaire

70
 Répartition des traitements
88

 L'architecture 3-tiers, encore appelée client-serveur de

deuxième génération ou client-serveur distribué, sépare
l'application en trois niveaux de service distincts :
 premier niveau : l'affichage et les traitements locaux (contrôles
de saisie, mise en forme de données... ) sont pris en charge par
le poste client
 deuxième niveau : les traitements applicatifs globaux sont pris
en charge par le service applicatif : Serveur d’application
 troisième niveau : les services de base de données sont pris en
charge par unSGBD:Serveur de données
 Exemple
8
 Fonctionnement app bibliothèque
9
 Fonctionnement (parfait)
10
 Fonctionnement(erreur)
11
 Serveur d’application
12

 Leserveur d'application est l'environnement

d'exécution des applications côté serveur.
 Il prend en charge l'ensemble des fonctionnalités de
l’application
 Le serveur d’application se retrouve dans la position
du poste client d'une application 2-tiers
 La communication avec le SGBD met en œuvre les
mécanismesdes applications client-serveur de
données.
 Serveur d’application

 Assure les fonctions suivantes:

🞑 Gestion de la session utilisateur : conserver des
contextes propres à chaque utilisateur (par exemple,
un panier de commandes).
🞑 Gestion des montées en charge et reprise sur
incident : se déployer sur plusieurs machines et
éventuellement offrir des possibilités de reprise sur
incident
🞑 Accès à des multiples sources de données :
rendre accessible les données des applications
du système d'information. Il doit donc pouvoir
accéder à de nombreuses sources de données.
 Serveur d’application

 Le serveur d’application agit comme middleware entre les

systèmes d’information de l’entreprise et des clients qui
accèdent à ces données.
 Le code métier est stocké sur le serveur d’application, et est
déployé et géré de manière centralisée.
 L’application peut être rendue accessible à un très grand
nombre de clients hétérogènes
🞑clients légers de type navigateur Web,
🞑 clients lourds de type application graphique Windows,
Corba, ou Java, et terminaux mobiles de type téléphone
cellulaire,
Framework de serveur d’application

 Java Platform, Enterprise Edition (JEE ou J2EE)

🞑 Standard développé par Sun

🞑 Ensemble de spécifications que doit vérifier un

serveur d’application
🞑 architecture standardisée, facile à comprendre

pour l’extérieur
🞑 portabilité : peut passer d’un serveur
d’applications J2EE à un autre sans problèmes
Framework de serveur d’application

 Avantages :
🞑Standard
🞑 nombreuses implantation avec différents
coûts et performances dont implantations
libres
🞑 disponible sur différentes plateformes (Windows,
Unix libre ou propriétaire, . . . )
 Inconvénients :
🞑 le code doit être écrit en Java
🞑 la portabilité entre serveurs d’application J2EE
n’est pas totale
Framework de serveur d’application

 Exemples d’implantations
🞑 Apache Tomcat
🞑Sun Java System Application Server,

🞑 GlassFish

🞑 Jboss

🞑IBM WebSphere

🞑JOnAS (Bull, France Télécom, Inria)

🞑 et d’autres. . .
Framework de serveur d’application

 Microsoft .NET
🞑 Environnement de développement complet proposé
par Microsoft
🞑 disponible uniquement sous environnement Windows

🞑 plusieurs langages possibles : C#, Visual Basic, etc.

🞑 [Link] permet de créer des pages Web

dynamiques
Framework de serveur d’application

 Avantages :
🞑 intégration complète avec le système d’exploitation
🞑 unité, cohérence

🞑 plusieurs langages disponibles

 Inconvénients :
🞑 spécifique à une plateforme
🞑 non libre

🞑 implantations libres partielles : Mono, CrossNet

 Client léger
20

 Dans l'architecture 3-tiers, le poste client est, souvent, appelé

client léger ou Thin Client
 Il ne prend en charge que la présentation de l'application
avec, éventuellement, une partie de logique applicative
permettant une vérification immédiate de la saisie et la mise
en forme des données
 Aucune connaissance des traitements applicatifs ou de la
structure des données exploitées
 Les évolutions de l'application ne nécessitent pas la
modification de la partie cliente
 Éviter l'installation des applications sur le poste utilisateur
🞑 Utiliser un simple navigateur web
🞑 Communiquer avec le serveur d’application via une façade web
 Niveau web dans l’arch. 3-tiers
21

 Le poste client prend la forme d'un simple navigateur

Web
 Le service applicatif est assuré par un serveur
d’application contenant une couche Web (appelé
serveur Web)
 Serveur Web
🞑 Transmet au client, lui ayant fait une demande HTTP via
URL , les fichiers statiques présents sur le disque dur
(pages HTML , images, fichiers CSS,...).
 Niveau web dans l’arch. 3-tiers
22
Les technologies web
 Les technologies web : coté client
24

 Javascript
🞑 Langage Interprété
🞑 Orienté Objet

🞑 Code s’insère dans le code HTML

🞑Gère les évènements principaux de la souris

🞑Page envoyé au client, puis interprété

Les technologies web : coté client

 Les Applets
🞑 Langage java
🞑Ensemble de fichiers sources java

🞑Compiler en .class

🞑JVM client exécute le code

🞑 Appel de l’applet dans le code HTML

 <APPLET CODE= … > </APPLET>

Les technologies web : coté serveur

 Les CGI
🞑 Common Gateway Interface
🞑 Technologie la plus ancienne

🞑 Programme sur le serveur

(précompilé)
 Placé dans un répertoire particulier
🞑 Tout langage possible
 Langage Perl le plus utilisé
 C, C++, Fortran, etc...
Les technologies web : coté serveur

 Les servlets
🞑 Classes Java
🞑 Exécuté par un moteur de servlet

🞑 La classe doit générer tout le code html

Les technologies web : coté serveur

 Les JSP
🞑 Technologie Java (Java Server Pages)
🞑 Langage de scripts

🞑 Fichier .jsp remplaçant les fichiers .html

🞑 Combine l’utilisation d’html et de java

Les technologies web : coté serveur

 Les ASP
🞑 ASP (Active Server Pages)
🞑 Technologie Microsoft

🞑 Même principe que JSP

🞑 Combine code html (statique) et traitements

 Les technologies web : coté serveur
31

 PHP
🞑 Langage de scripts
🞑 Orienté Objet

🞑 S’intègre au code HTML

🞑 Permet un accès facile aux bases de données

 Avantages du modèle 3-tiers
32

 Les 3 niveaux sont indépendants

 Peuvent être implantés sur des machines
différentes:
🞑 le poste client ne supporte plus l'ensemble des
traitements, il est moins sollicité et peut être moins
évolué, donc moins coûteux
🞑 la fiabilité et les performances de certains traitements
se trouvent améliorées par leur centralisation (gestion
des données)
🞑 il est relativement simple de faire face à une forte
montée en charge, en renforçant le service applicatif.
Avantages du modèle 3-tiers

 la force des architectures trois tiers par rapport au client-

serveur de première génération:
🞑 Le déploiement est immédiat,
🞑 les évolutions sont transparentes pour l'utilisateur

🞑 et les caractéristiques du poste client sont libres.

 Exemple
🞑 un internaute se connectant à [Link] pour effectuer une
recherche provoque l'exécution de traitements sur le serveur.
🞑 Si ces traitements évoluent, le client continuera à utiliser le service
sans se rendre compte des changements
🞑 Le même internaute peut se connecter au serveur en utilisant tout
type de poste client disposant d'un navigateur compatible HTML
(PC sous Windows, Macintosh, Linux, IPhone… ) .
 Limites du modèle 3-tiers
34

 Le serveur d’application constitue la pierre angulaire

de l'architecture et se trouve souvent fortement
sollicité.
 Problème de gestion de la montée en charge
rappelant l'époque des mainframes.

L’équilibrage de la charge entre client et serveur

semble atteint avec la génération suivante :
Les architectures n-tiers
Architectures n-tiers

83
 Présentation
2

 L'architecture n-tiers a été pensée pour pallier

aux limitations des architectures 3-tiers et
concevoir des applications puissantes et simples à
maintenir.
 Ce type d'architecture permet de distribuer plus
librement la logique applicative, ce qui facilite la
répartition de la charge entre tous les niveaux.
 Présentation
3
 Présentation
4

 L'appellation n-tier ne signifie pas un nombre

indéterminé de niveaux de service, ils sont
toujours 3 (Présentation, Logique applicative et
Données)
 L'architecture n-tier qualifie la distribution
d'application entre de multiples services et
non la multiplication des niveaux de
service.
 La distribution des services applicatifs facilite
aussi l'intégration de traitements existants
dans les nouvelles applications.
Présentation

 La distribution est facilitée par

l'utilisation de composants ou objets
«métier», spécialisés, indépendants et
réutilisables.
 Les composants rendent un service si
possible générique et clairement
identifié.
 Les composants sont capables de
communiquer entre eux et peuvent donc
coopérer en étant implantés sur des
machines distinctes.
 Les couches de l’arch. n-tiers
6

 Une architecture n-tiers comprend généralement une couche de

présentation, une couche applicative, une couche objets métier et
unecouched'accèsauxdonnées.
 Lescouches de l’arch. n-tiers
7

 La couche de présentation contient les différents

types de clients,
 léger (Web, ASP, JSP)
 lourd (Swing, WinForm)
 La couche applicative contient les traitements
représentant les règles métier (créer un compte,
rechercher un client, calculer une facture, ...)
Les couches de l’arch. n-tiers

 La couche d'objets métier est représentée par les

objets du domaine, c'est à dire l'ensemble des
entités persistantes de l'application (Facture, Bon
de Commande, Client, ...)
 La couche d'accès aux données contient les usines
d'objets métier, c'est à dire les classes chargées de
créer des objets métier de manière totalement
transparente, indépendamment de leur mode de
stockage (SGBDR, SGBDO, Fichiers, Legacy, ...)
Limites de la programmation usuelle
« programming in the small »
 tout est la la charge du programmeur
 construction des différents modules
 définition des instances
 interconnexions des modules
 structure de l’application peu visible
 ensemble des fichiers de codes nécessaire
 évolution / modification difficile
 changement du mode de communication
 évolution, ajout, suppression de fonctionnalités
 modification du placement
 développement, génération des exécutables,
déploiement
 pas ou peu d’outils pour les applications réparties
La programmation par composant
 Programmation constructive (ou par composition)
 « programming in the large »
 Motivation : réutilisation de logiciel
 intégration de modules logiciels existants
 construction d'applications réparties par assemblage de
modules logiciels existants
 programmation à gros grain ("programming in the large")
 Approche : description de l'architecture de l'application à
l'aide d'un langage déclaratif
 séparation de l’interface/implémentation
 modèle de construction des composants
 Composants: interfaces, attributs, implémentation
 description des interactions entre composants (connecteurs)
 Un Composant : Qu’est-ce que c’est ?
11

 Une unité regroupant les fonctionnalités

concernant une même idée
 Un module logiciel autonome pouvant être
installé sur différentes plates-formes
 qui exporte des attributs et des méthodes
 qui peut être configuré (déploiement semi
automatique)
 capable de s’auto-décrire
 Intérêt
 Etre des briques de base configurables pour
permettre la construction d’une application par
composition
Objet métier : qu’est ce que c’est ?
 Un objet métier est un concept ou une abstraction
ayant un sens pour des acteurs (partie prenante
interne) d’une organisation (entreprise)
 L’objet métier permet de décrire les entités
manipulées par les acteurs dans le cadre de la
description du métier.
 Exemple
 Mon métier consiste à gérer les comptes bancaires de mes
clients
 Les objets métier sont le compte bancaire, le client.
 Les objets métiers sont représentés par l'ensemble
des objets persistants du domaine de l'application.
 Une facture, un bon de commande ou tout autre objet
nécessitant d'être stocké en base.
 La couche d'objets métiers
15

 Il existe deux méthodes pour accéder aux données:

 La première consiste à accéder directement aux sources
de données.
 La deuxième méthode consiste à s'appuyer sur des
objets métier (client, fournisseur, facture ...) afin de
masquer la complexité d'accès aux données.
 La couche objet métier assure l'indépendance totale
entre le client et le type de stockage utilisé (SGBDR,
SGBDO,fichiers XML, ...).
La couche d'objets métiers

 Exemple:
 Un objet AssuréSocial possédera par exemple
une méthode débit() et une méthode crédit()
qui à chaque appel iront modifier les données
dans
 une ERP (Entreprise Resource Planning),
 un système de CRM (Customer Relation Ship
Managment),
 des fichiers XML
 ou une base de données.
 Services Serveur d’objets
17

 Pour gérer ces objets métier, un environnement

d'exploitation est nécessaire : le serveur
d'objets
 Fournit les services essentiels suivants:
 la gestion du cycle de vie des objets :
 le serveur d’objets intègre des fonctionnalités de base
permettant la création, la recherche, la manipulation, et la
destruction des objets.
 la gestion de la persistance :
 synchronisation de l’état des objets sur un support de
persistance (base de données), afin d’assurer la sauvegarde
durable de l’état des objets.
Services Serveur d’objets

 la gestion des transactions :

 très liée à la gestion de la persistance, la gestion
transactionnelle des objets permet d’assurer l’intégrité des
données et de gérer la concurrence d’accès.
 le service de gestion transactionnelle assure aux objets le
bénéfice des propriétés transactionnelles de base ACID.
 la gestion de la montée en charge :
 le serveur d’objets inclut différents mécanismes (pools
d’objets, cache transactionnel, etc.…) qui permettent
d’améliorer les performances des applications accédant de
manière concurrente aux objets.
Services du Serveur d’objets

 La gestion de la sécurité :
 Le serveur d’objet inclut une infrastructure de sécurité qui
permet la mise en place d’un mécanisme
d’authentification et de contrôle d’accès aux objets
 La définition de permissions sur les opérations de
lecture, de mise à jour, et sur les appels aux traitements
métier permet de définir des restrictions d’accès très
fines basées sur la définition de groupes d’utilisateurs et
de rôles
Serveur d’objets

 la gestion de la reprise sur pannes et de la

transparence de localisation des objets:
 le serveur d’objet intègre des fonctionnalités de
distribution des objets sur plusieurs machines.
 Ces fonctionnalités permettent la mise en place de
mécanismes de reprise sur panne
 Afin d’assurer la transparence de localisation des objets
distribués, le serveur fournit un service de nommage qui
permet d’accéder à un objet de manière transparente,
indépendamment de sa localisation physique.
 Serveur d’objets
21

 Les principaux serveurs

d'objets:
 Corba
 EJB (Enterprise Java Beans)
 Microsoft DCOM.
 Schéma de récapitulation
22
 Framework globaux
Une application 3/N – tiers intègre un grand nombre de technologies
Présentation : HTML, GUI ...
Applicatif : objets, composants, scripts exécutables, services ...
BDD : fichiers XML, SGBDR, ...
Protocoles de communication : RMI, HTTP
Pour faciliter l'intégration de ces technologies et le développement
d'applications
Editeurs offrent des frameworks globaux
J2EE / Java EE chez Sun
.Net chez Microsoft
Serveur d'application
Serveur permettant d'exécuter les parties applicatives dans le contexte de ces framework

Architecture N-Tiers
 J2EE caractéristique
J2EE / Java EE : Java Entreprise Edition
Norme / standard défini par Sun pour le langage Java
Technologies intégrées
Composants logiciels : EJB
Applications orientées Web : JSP, servlet
Communication à distance : Java RMI, IIOP, JMS (Java Message Service : communication
par message), Web Services
Gestion données distantes : JDBC, JPA (Java Persistance API)
Gestion d'annuaires (type LDAP) : JNDI
Transactions : JTA
...
Existe plusieurs serveurs d'applications J2EE
Versions libres
GlassFish, JBoss, Apache Geronimo, Jonas ...
Versions d'éditeurs
Sun Java System Application Server (basé sur GlassFish), IBM WebSphere, BEA WebLogic,
Oracle Container for Java EE, ...

Architecture N-Tiers
 Microsoft .NET caractéristique
Solution Microsoft similaire à J2EE
Particularité : multi-langage
Permet interopérabilité d'éléments écrits en C, Java, C#, J#, Eiffel, VB, ...
(plus de 20 langages)
Traduction en code intermédiaire (MSIL) qui sera exécuté par la couche
CLR (Common Language Runtime)
Coté Java, c'est le code Java qui était converti en byte code exécuté
par la machine virtuelle Java (JVM)

Technologies intégrées
Composants logiciels : COM+
Applications orientées Web : ASP .Net,
Communication à distance : .Net remoting, MSMQ, Web services
Accès données : ADO .Net, ODBC
...

Architecture N-Tiers
Architecture 3/4 – tiers, contexte J2EE
Client lourd (3-tiers)

Client léger (4-tiers)

Architecture N-Tiers
NOTION DES
APPLICATIONS REPARTIS
 Définition des systèmes répartis
2

Ensemble composé d’éléments reliés par un système

de communication ; les éléments ont des fonctions de
traitement (processeurs), de stockage (mémoire), de
relation avec le monde extérieur (capteurs, actionneurs)

Les différents éléments du système ne fonctionnent pas

indépendamment mais collaborent à une ou plusieurs
tâches communes.

Conséquence : une partie au moins de l’état global du

système est partagée entre plusieurs éléments (sinon,
on aurait un fonctionnement indépendant)
 Pourquoi les Systèmes Repartis ?

• Aspects économiques (rapport prix/performance)

• Adaptation de la structure d’un système à celle des
applications (géographique ou fonctionnelle)
• Besoin d’intégration (applications existantes)
• Besoin de communication et de partage d’information
• Réalisation de systèmes à haute disponibilité
• Partage de ressources (programmes, données, services)
• Réalisation de systèmes à grande capacité d’évolution
 Exemple : Agence de voyage

• Un produit « voyage » est la combinaison de plusieurs

produits
• Gestion de réservation de billets de transport
• Gestion de réservation des hôtels
• Gestion de réservation de voitures de location
• …
• Le résultat des informations récupérées auprès de
différents fournisseurs
• Compagnies aériennes
• Chaînes hôtelières
• Agences de location de voitures
• …
Programmation “classique” vs.
Informatique Répartie. Objectifs

• Programmation “classique”
• En programmation classique lorsque qu’un programme a besoin d’un service,
il appelle une fonction d’une librairie, une méthode d’un objet, etc.

• Informatique Répartie
• Proposer des méthodes et outils pour simplifier le développement
d’applications réseau Client-Serveur, en essayant de s’abstraire de l’aspect
“distant” : proposer une programmation “naturelle”
• Pour les applications “lourdes” :
• Décomposer les applications en ensembles de services
• Rationaliser la répartition des services pour limiter les échanges d’informations
 Programmation “classique” vs.
Informatique Répartie
128

• Programmation “classique”
• Une seule machine
• Même OS
• Même espace mémoire
• Pas de problème de transport
• Disponibilité du service assuré (tant que l’on a accès à la librairie)
• Informatique Répartie
• Deux machines (sans compter celles “traversées”)
• OS différents
• Représentations différentes des types de bases
• Espace mémoire : “passer un pointeur/référence comme argument” ? Problème de
transport : firewall, réseau HS, etc.
• Retrouver le service ? Où se trouve-t-il ? Qui le propose ?
 Programmation “classique” vs. Informatique Répartie.
Interopérabilité des langages
129

• Un même langage
• Même paradigme de programmation
• Même représentation des types de base
• Même représentation de l’information composite
• Deux langages
• Représentation des types de base et de l’information composite pouvant être
différente
• Association des paramètres effectifs aux paramètres formels ? comment
gérer les différents types de passage de paramètre ? Paradigmes de
programmation différents : qu’est-ce que c’est un objet pour un langage
procédural ? Comment gérer les erreurs ?
 Programmation “classique” vs.
Informatique Répartie. Solutions
130

• Séparer la spécification/conception de l'implémentation java

• Utilisation d’un langage propre à la spécification/conception
• Utilisation de “traducteurs” vers le langage cible en distinguant le client
du serveur
• Utiliser un langage de représentation de l’information

• Langage de représentation indépendant du langage de programmation

• Pour chaque langage de programmation, définir un ensemble d’opérations
pour “sérialiser” ces types (prédéfinis ou utilisateur)
 Programmation “classique” vs.
Informatique Répartie. Solutions
131

• Utiliser un protocole de transport

• Comment spécifier le service demandé
• Comment associer les paramètres effectifs aux paramètres formels
• Comment transmettre les erreurs
• Définir la gestion du service
• Utiliser un mécanisme permettant d’identifier la librairie (au sens large) qui
fournit le service
• Utiliser un mécanisme qui permet d’activer le service si besoin
 Introduction aux systèmes distribués
64

Système distribué en opposition à un système centralisé

Système centralisé
Tout est localisé sur la même machine et accessible par le programme
Système logiciel s'exécutant sur une seule machine
Les applications accèdent localement aux ressources
nécessaires (données, code, périphériques, mémoire ...)
Système distribué
Ensemble d’ordinateurs indépendants connectés en
réseau et communiquent via ce réseau
Cet ensemble apparaît du point de vue de l'utilisateur comme une seule
entité
 Intérêts des systèmes distribués
64

Utiliser et partager des ressources distantes

Un même service peut être utilisé par plusieurs acteurs,
situés à des endroits différents
Système de fichiers : utiliser ses fichiers à partir de n'importe quelle machine
Imprimante : partagée entre toutes les machines

Optimiser l'utilisation des ressources disponibles

Calculs scientifiques distribués sur un ensemble de machines

Système plus robuste

Duplication pour fiabilité : deux serveurs de fichiers
dupliqués, avec sauvegarde
Plusieurs éléments identiques pour résister à la montée e9n
charge ...
 Inconvénients des systèmes distribués
64

Si problème au niveau du réseau : le système marche mal ou plus du tout

Bien souvent, un élément est central au fonctionnement du système : serveur

Si serveur plante : plus rien ne fonctionne

 Les propriétés des systèmes distribués

64

 Hétérogénéité
Des machines utilisées (puissance, architecture matérielle...)
Des systèmes d'exploitation tournant sur ces machines
Des langages de programmation des éléments logiciels formant le système
Des réseaux utilisés : impact sur performances, débit,
disponibilité ...
Réseau local rapide
Internet

Réseaux sans fil

 Les propriétés des systèmes distribués

64

 Fiabilité des systèmes distribués

Nombreux points de pannes ou de problèmes potentiels:
-Réseau
Une partie du réseau peut-être inaccessible
Les temps de communication peuvent considérablement selon la charge du réseau
Le réseau peut perdre des données transmises
-Machine
Une ou plusieurs machines peut planter, engendrant une paralysie
partielle ou totale du système

 Peutaugmenter la fiabilité par redondance, duplication 14

de certains
éléments
Mais rend plus complexe la gestion du système
 Les propriétés des systèmes distribués

64

 Tolérance aux fautes

-Une partie du réseau peut-être inaccessible
-Capacité d'un système à gérer et résister à un ensemble de problèmes
-Le système doit pouvoir fonctionner (au moins de façon
dégradée) même en cas de défaillance de certains de ses éléments
-Le système doit pouvoir résister à des perturbations du système de
communication (perte de massage, déconnexion temporaire, performances
dégradées)
-Le système doit pouvoir facilement s’adapter pour réagir à des
changements d’environnement ou de conditions
d’utilisation
 Les propriétés des systèmes distribués

64

 Sécurité
Nature d'un système distribué fait qu'il est beaucoup plus sujet à des attaques
Communications à travers le réseau peuvent être interceptées car On ne connaît pas
toujours bien un élément distant avec qui on communique

Le système doit pouvoir résister à des attaques contre sa sécurité (violation de

la confidentialité, de l’intégrité, usage indu de ressources, déni de service)

Solutions
Connexion sécurisée par authentification avec les éléments distants
Cryptage des messages circulant sur le réseau
 Les propriétés des systèmes distribués

64

 Transparence
un élément peut être invisible ou caché à l'utilisateur ou un autre élément formant le
système distribué
Devrait plutôt parler d'opacité dans certains cas ...
But: cacher l’architecture, le fonctionnement de l’application ou du système
distribué pour apparaitre à l’utilisateur comme une application unique cohérente
L'ISO définit plusieurs normes de transparences (norme RM-ODP): accès,
localisation, concurrence, réplication, mobilité, panne
performance,,,,
 Les propriétés des systèmes distribués

64

 Transparence d'accès : accès à des ressources distantes aussi

facilement que localement et accès aux données indépendamment de leur
format de représentation
 Transparence de localisation : accès aux éléments/ressources
indépendamment de leur localisation
 Transparence de concurrence : exécution possible de plusieurs
processus en parallèle avec utilisation de ressources partagées
 Transparence de réplication : possibilité de dupliquer certains
éléments/ressources pour augmenter la fiabilité
 Les propriétés des systèmes distribués

64

 Transparence de mobilité : possibilité de déplacer

des éléments/ressources
 Transparence de panne : doit supporter qu'un ou
plusieurs éléments tombe en panne
 Transparence de performance : possibilité de
reconfigurer le système pour en augmenter les performances
 Distinction entre “système” et “application”

Système Réparti Application répartie

est un ensemble de systèmes est un ensemble de processus

calculatoires autonomes ( exp: qui tournent sur un système
ordinateur, serveur, terminal, réparti afin de fournir ou
etc.) sans mémoire physique utiliser un service déterminé
commune qui communiquent à
travers un réseau quelconque
 Applications réparties
Application répartie = traitements coopérants sur des
données réparties
 Exemples d’applications réparties
-Navigation web, transfert de fichiers;
-Guichets de banque (GAB (Guichet Automatique de Banque),
DAB (DistributeurAutomatique de Banque);

-Commerce électronique;
-Jeux en réseaux;
-Télévision interactive
 Terminologie

• Interlogiciel ou middleware : un logiciel qui s’insère entre deux

applications pour permettre la communication des machines entre
elles, indépendamment de la nature du processus, du système
d’exploitation, du langage.
• Répartition vs parallélisme :
• Le parallélisme implique des tâches nombreuses mais répétitives. Le
problème est de paralléliser les tâches ou le données. Les architectures
parallèles exploitent des régularités de traitement ou de données (ceci limite
le champ d’application)
• Une architecture répartie implique des données et des tâches différentes sur
les machines. Les applications réparties ne partagent pas de mémoire. Le
problème est la transmission des données entre tâches et la synchronisation
entre celles-ci
144
 Terminologie

• Communication entre applications : Deux grande familles

• Les technologies d’appel à procédure à distance (RPC, remote procedure
call), regroupant des standards tels que CORBA, RMI, SOAP …
Le principe réside sur l’invocation d’un service (une procédure ou une
méthode d’un objet) situé sur une machine distance indépendamment de a
localisation et de son implémentation.
Le concept est le même que l’appel de sous-procédure, avec un déroutement
du contexte d’appel et une attente bloquant des résultats
• Les technologies d’échange de messages : échange véhiculé par
l’infrastructure MOM (message oriented middleware) Exemple, JMS

145
Communication dans un système distribué

 Sockets

 Appel de procédure à distance: RPC

 Objets réparties: Java RMI, CORBA

 Web services

 EJB
Approche de la BD
dans le système réparti
 Types de BD
64

 Base de données centralisée:

WAN
 Types de BD
65

 Base de données répartie :

WAN
 Répartition de données
66

Objectifs
 Gérer les données d’une organisation répartie
sur différents sites
 Rapprocher les données des utilisateurs
(performance, coût)
 Assurer une autonomie des sites
 Assurer une indépendance par rapport à
localisation des données
 Approches de répartition de données
69

 Approche « Base de données répartie »

 Approche « Multibase »
 Approche « Réplication de données »
 Approches de répartition de données
70

 Approche BD répartie
 Schéma global (méta dictionnaire
de données)
 Ensemble de bases de
données locales
 Accès à travers le schéma global

 Mieux adaptée à la mise

en place de nouvelles BD
 Approches de répartition de données
71

 Approche multibase de données

 Interopérabilité d’un ensemble de
bases de donnéesindépendantes
 Ne nécessite pas de schéma global
 Mieux adaptée à l’intégration de BD
existantes
 Réplication de données
72

Problématique
La mise en place d’une base de données répartie sans
réplication (ou duplication) des données entraîne :

• Des coûts de communicationimportants

• Des performances dégradées
• La disponibilité des données n’est pas garantie
 Réplication de données
73

Principe : dupliquer une partie des

données d’une base locale sur une ou
plusieurs bases distantes.
Réplication

Avantages
 Amélioration des performances
 Augmentation de la disponibilité des données
 Réduction des coûts de communication
 Réplication de données
74

 Problématique
 Comment assurer la cohérence entre les données
sources et les copies ?
 Solution
 Effectuer des rafraîchissements (mises à jour)

 Modes de rafraîchissement
 Synchrone

 Asynchrone
 Réplication de données
75

 Rafraîchissement synchrone
Propagation immédiate des modifications des données
sources vers lescopies.
 Réplication de données
76

 Rafraîchissement asynchrone
 Regroupement des modifications des données sources et
propagation vers les copies à desintervalles prédéfinis.
 Types de réplication
77

 Réplication par diffusion

 Réplication par centralisation
 Réplication symétrique
 Réplication en cascade
 Réplication par diffusion
78
 Réplication par centralisation
79
 Réplication symétrique
80
 Réplication en cascade
81