Cours 2 les architectures reparties

APPLICATIONS RÉPARTIES
CHAPITRE 2 : LES ARCHITECTURES
APPLICATIVES
Mariem ZAOUALI

Les principes de base
TP 1: Design Patterns appliqués
aux systèmes distribués
01
Architectures réparties: du
client/serveur au Cloud
Computing
02
Objets répartis :
RMI/CORBA
TP 2: RMI
03
Intergiciels orientés
messages : JMS
TP 3: JMS
04
05
06
Plan du module
2
07
Frameworks Labs :
Spring et ASP
TP 4 : Architecture micro-
services
Architecture micro-
services : Spring et ASP
(Exposés)
Architecture
microservices: Spring
et ASP (Exposés)

Plan du cours
Motivation01
Les architectures
centralisées02
Les architectures
distribuées
03
Le cloud computing
04
3
05
Protocole de transport
java tcp, udp, multicastIP

MOTIVATION
Your Date Here Your Footer Here
1
4

Motivation
Your Date Here Your Footer Here 5
Pourquoi penser à des architectures distribuées ?
• Echange d’information entre des programmes/applications/entités logicielles sur
plusieurs machines reliées par un réseau
• à large échelle (Internet)
• en local (Intranet)
• Séparation des rôles inhérente à la plupart des systèmes informatiques

Motivation
Architecture répartie
Architecture centralisée Architecture distribuée
Client/serveur
2 tiers 3 tiers

LES ARCHITECTURES
CENTRALISÉES
2
7

Architecture client-serveur
Définition
•Le client-serveur est un type
d’architecture qui effectue
une distinction stricte entre
les rôles de client d’une part et
de serveur d’autre part.

Définition
•Mode de fonctionnement
général :
• Point de vue client: un client
effectue une requête pour un
service précis sur un serveur
donné et reçoit une réponse.
• Point de vue serveur: un
serveur reçoit une demande de
service, la traite, et renvoie la
réponse au client.

Caractéristiques générales
• Protocoles asymétriques : un serveur
répond aux requêtes de plusieurs
clients. Les clients initient le dialogue.
• Encapsulation des services : le serveur
détermine lui-même comment traiter la
demande. Les serveurs peuvent être mis
à jours sans que les clients s’en
aperçoivent.
• Intégrité : le code et les données d’un
serveur sont maintenues de manière
centralisée, ce qui résulte en des coûts
de maintenance réduits et une garantie
d’intégrité des données.

Caractéristiques générales – côté client
•Il est actif (ou maître).
• Il envoie des requêtes au(x) serveur(s).
• Il attend (pas forcement) et reçoit les réponses
du/des serveur(s).

Caractéristiques générales – côté serveur
•Il est passif (ou esclave).
• Il est à l'écoute, prêt à répondre aux requêtes
envoyées par plusieurs clients.
• Dès qu'une requête lui parvient, il la traite et envoie
une réponse.
• Il accepte normalement un nombre important de
connections de la part des clients.

Protocole client-serveur
• Plusieurs paradigmes de communication sont possibles
du client-serveur par exemple :
• Passage de messages synchrone.
• Passage de messages asynchrone.
• Appel de procédures à distance (RPC).
• Invocation de méthodes à distance.
• Interaction événementielle.
• Interaction par messagerie.
• On parle ici de protocoles applicatifs de haut niveau,
indépendamment de leurs implémentations dans la
couche transport inférieure (tcp, udp, ...)

Invocation des méthodes à distance
•Généralisation des RPC au monde objet: on appel
une méthode sur un objet distant (ex. de
technologie: Java/RMI)
•Les invocations de méthodes à distance
permettent:
• De référencer des objets distants (il faut
précédemment avoir obtenu l’adresse distante de
l’objet).
• De transférer des objets locaux “non-répartis”:

Interaction évènementielle
• Basé sur la notion de publication d'événements :
1.Le client s’abonne à un ou plusieurs événements auprès du serveur.
2.Le serveur enregistre les abonnements, puis à chaque événement
correspondant il envoie un message aux abonnés.
• Notion de Push/Pull :
• Push : envoyer l’information à ceux qui en ont besoin.
• Pull : récupérer l’information quand on en a besoin.
• Avantages : évite de surcharger le serveur de messages inutiles
• Inconvénients : le serveur doit conserver la liste des clients en
mémoire persistance ( cause des pannes).

Interaction par message
•Consiste à utiliser une “boite à lettres” pour y
déposer des messages.
•Mécanisme de communication asynchrone
• Exemple : “Message Oriented Middleware” ou
MOM.
•Attention: ne pas confondre avec l’envoi de
messages sur une socket. On parle ici de
protocoles applicatifs de haut niveau et non pas
de protocoles de transport.

Architecture 2 tiers
• C’est le type d’architecture client-serveur le plus basique :
• La couche présentation est située sur le client
• La couche donnée est située sur le serveur (par ex. une base de
données relationnelles SQL, Oracle,...)
• La couche traitement peut être située sur le client (au sein même
de l’IHM) ou sur le serveur (par ex. des procédures stockées sur la
base de données), ou partagée entre les deux rôles.
• Il y a une relation directe entre les clients et les serveurs de
données.
• (+) simple à mettre en œuvre
• (-) peu flexible et supporte difficilement la montée en charge
• (-) souvent des solutions propriétaires, économiquement très
couteux

Architecture 3 tiers
• L’architecture 3-tiers est une extension du modèle client-serveur
qui introduit
• un rôle spécifique pour la couche de traitements métiers.
• Il y donc décomposition d’un même service sur 2 types de serveurs
(Un type de serveur dédié à la gestion des traitements métiers.
• Un type de serveur dédié à la gestion des données persistantes.
• (+) plus évolutif que le 2-tiers
• (+) meilleure répartition des charges de travail coté serveur
• (+) économiquement moins cher, surtout lors de la montée en
charge
• (-) administration et mise en œuvre plus compliquée que le 2-tiers

APPLICATION : LES
PROTOCOLES DE TRANSPORT
3
19

Protocoles de transport
•Les protocoles de transport à aborder sont les
suivants:
•TCP: permet l’utilisation de flux bi-directionnels
de communication
• UDP: permet l’envoi asynchrone de messages
•Multicast-IP: permet l’envoi de message à un
groupe de destinataires

• L’utilisation de ce niveau primitif de communication permet la
communication dans les architectures simples de type client-
serveur 2-tiers.
• En effet il est nécessaire de :
• 1.Définir le format des messages réseau.
• 2.Localiser le serveur.
• 3.Emballer (“marshall”) les informations émises par le client pour le
réseau.
• 4.Déballer (“unmarshall”) les informatiions émises par le réseau
pour le serveur.
• 5.Gérer la requête.
• 6.Emballer/déballer la/les valeur(s) de retour pour le client.

•Pour chacun de ces protocoles, on dispose de
deux primitives de communication :
• send : envoi d’un message dans un buffer (zone
tampon) distant
• receive : lecture d’un message à partir d’un
buffer local

• De plus, on distingue deux modes de fonctionnement pour ces
primitives :
• synchrone : les primitives sont bloquantes
• asynchrone : les primitives sont non-bloquantes
• Par exemple :
un send synchrone va rester bloqué jusqu’à l’envoi complet du
message, de même un receive synchrone va rester bloqué jusqu’à
ce qu’il y ait un message à lire.
• L’utilisation de primitives asynchrones est plus souple que celui
de primitives synchrones.
• Mais aussi, un programme avec des primitives synchrones vous
épargne de la gestion de la concurrence.

TCP : fonctionnement
• 1.Le serveur crée une socket et
attend une demande de
connexion
• 2.Le client envoie une demande
de connexion
• 3.Le serveur accepte la connexion
• 4.Etablissement du dialogue entre
client et serveur en mode flux
• 5.Fermeture de connexion à
l'initiative du client ou du serveur

•1.Le serveur crée une
socket et attend une
demande de connexion

•2.Le client envoie une
demande de connexion

•3.Le serveur accepte la
connexion

•4.Etablissement du dialogue entre client et serveur en mode flux
Le client
Le serveur

•5.Fermeture de connexion à l'initiative du client ou du
serveur
Initiative du client
pour fermer la
connexion en tapant
« exit »

TCP: Live demo
•Fork your repo from my github!
•https://github.com/MariemZaouali/Test_tcp_serv
eur
•https://github.com/MariemZaouali/Test_tcp_clie
nt

UDP : fonctionnement
•1.Le serveur crée une socket UDP.
•2.Le serveur attend la réception d’un message.
•3.Le client envoie un message.

•Le serveur va recevoir le paquet
Durée d’attente
Méthode de traitement

UDP : Live demo
•https://github.com/MariemZaouali/Test_udp_ser
ver
•https://github.com/MariemZaouali/Test_udp_clie
nt

Remarque
•Pourquoi utiliser les buffers (input/output)?
Il s'agit d'une région d'une mémoire physique utilisée
pour stocker temporairement des données pendant
qu'elles sont déplacées d'un endroit à un autre.
Ce stockage de mémoire physique serait RAM
(mémoire à accès aléatoire) dans la plupart des cas

Multicast IP : fonctionnement
•1.Le serveur (et client) crée une socket MulticastIP.
•2.Le client rejoint le groupe de diffusion.
•3.Le serveur envoie un message.
Your Date Here Your Footer Here 38Your Footer Here 38
Serveur Client

•La multidiffusion est un type de socket de
datagramme. Contrairement aux datagrammes
classiques, la multidiffusion ne gère pas chaque client
individuellement, mais l'envoie à une adresse IP et
tous les clients abonnés recevront le message.
Your Date Here Your Footer Here 39Your Footer Here 39
Serveur Client

• Exécuter le client d'abord: le client doit s'abonner à l'IP
avant de pouvoir commencer à recevoir des paquets. Si
vous démarrez le serveur et appelez la méthode send() ,
puis créez un client (& appelez printMessage() ). Rien ne se
passera car le client est connecté après l'envoi du
message
Serveur Client

• Le multicast IP sert à diffuser des messages vers un groupe de
destinataires :
• Les messages sont émis vers une adresse de classe D (224.0.0.1
à 239.255.255.255) indépendante de la localisation physique des
émetteurs et récepteurs.
• Les messages sont alors reçus par tous les récepteurs “écoutant”
sur cette adresse.
• Plusieurs émetteurs/récepteurs possibles vers/sur la même
adresse.
• Les récepteurs peuvent quitter(leaveGroup) ou rejoindre un
groupe(joinGroup) à tout instant.
• Il dispose des mêmes propriétés que UDP.

Multicast : live demo
•https://github.com/MariemZaouali/Test_multicas
t_client
•https://github.com/MariemZaouali/Test_multicas
t_serveur

LES ARCHITECTURES
DISTRIBUÉES
4
43

Architecture distribuée
Architecture répartie
Architecture centralisée Architecture distribuée
Peer to Peer

•Dans le cadre des architectures réparties, on
distingue :
• Les architectures centralisées (type client-serveur)
• Les architectures distribuées où les problématiques
sont différentes de part l’absence d’un décideur.

•La différence fondamentale entre ces deux types
d’architecture se situe dans
•la distribution des rôles entre les nœuds du
réseau :
• Les nœuds sont simultanément clients et serveurs et
disposent de tout ou partie de l’information
répartie.

• Les caractéristique habituelles de ces architectures
sont les suivantes :
• Pas de connaissance globale du réseau.
• Pas de coordination globale des nœuds.
•Chaque nœud ne connaît que les nœuds constituant
son voisinage.
•Toutes les données sont accessibles à partir de
n’importe quel noeud.
•Les nœuds sont très volatiles (ils peuvent disparaître
ou apparaître à tout moment).

•Les technologies Peer-to-Peer (P2P, ou Pair-à-
Pair) constituent le pendant technologique des
architectures distribuées.

Avantages :
•Tous les pairs fournissent des ressources (bande
passante, stockage, puissance de calcul,...).
•supportent beaucoup mieux la montée en charge
(“scalability”) que les architectures centralisées.
• La distribution augmente la robustesse du
réseau dans le cas d’une panne

•Inconvénients :
•Mauvaise réputation du “P2P”, invariablement
associé au téléchargement musical → faible
adoption par l’industrie.
•concurrence entre les pairs, fragmentation des
données
•Pas de contrôle avancé des échanges
d’information entre les pairs (inconvénient ou
avantage ?).

LE CLOUD COMPUTING
5
51

Cloud Computing
Définition
•Le cloud computing est l’accès via le réseau, à la
demande et en libre-service à des ressources
informatiques virtualisées et mutualisées (mise
en commun)

Usage des technologies Cloud dans une
entreprise
•On peut avoir:
• Private cloud: est un
groupe de ressources
informatiques
configurables à la
demande dans un
environnement de
cloud public, qui fournit
un certain niveau
d'isolement entre les
différentes
organisations qui
utilisent ces ressources

entreprise
•On peut avoir:
• SaaS: Le logiciel en tant
que service, ou
software as a service
(SaaS), est un modèle
d'exploitation
commerciale des
logiciels dans lequel
ceux-ci sont installés
sur des serveurs
distants plutôt que sur
la machine de
l'utilisateur

entreprise
•On peut avoir:
• PaaS : des outils
hardware et logiciels
en tant que service
via internet,
permettant à
l'utilisateur de
développer des
applications

Modèle de déploiement de Cloud
Computing

Fournisseurs de Cloud Public

THANK YOU!
Do you have any questions?
58

Cours 2 les architectures reparties

Recommandé

Recommandé

Contenu connexe

Tendances

Tendances (20)

Similaire à Cours 2 les architectures reparties

Similaire à Cours 2 les architectures reparties (20)

Plus de Mariem ZAOUALI

Plus de Mariem ZAOUALI (17)

Dernier

Dernier (7)

Cours 2 les architectures reparties