Ce document présente les principes de base des applications réparties, y compris les modèles de programmation et l'architecture des systèmes distribués. Il aborde également les défis liés à la communication asynchrone et aux défaillances, ainsi que divers design patterns comme le pattern proxy et le pattern factory. Des langages et frameworks comme Java, C# et Spring sont mentionnés pour illustrer l'implémentation de ces concepts.

1. APPLICATIONS RÉPARTIES
CHAPITRE 1 : LES PRINCIPES DE BASE
Mariem ZAOUALI

2. Objectifs
du cours
• Au termes de ce cours, vous seriez capable de
• Savoir les fondements de programmation
d'applications reparties à savoir (Modèles de
programmation, architecture logicielle des
applications et du middleware)
• Maîtriser les concepts clefs des systèmes distribués
via l’implémentation des Design Patterns employés
ainsi qu’une application web se basant sur une
architecture micro services avec des techniques de
Messaging
• Langage utilisé : Java, C#
• Framework utilisé : Spring, ASP
2

3. 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
3
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)

4. Plan du cours
Motivation01
Définition et
caractéristique du système
réparti
02
Architecture applicative :
RPC et multi-niveaux
03
Schéma de conception04
4

5. MOTIVATION
Your Date Here Your Footer Here
1
5

6. Motivation : Les applications réparties,
pourquoi?
Your Date Here Your Footer Here 6
Les applications réparties nous permet de répondre à des besoins tels que :
• Intégration des applications déjà existantes dans les siennes pour un besoin
spécifique
• Intégration des ressources : Grilles de calcul, gestion des données
• Intégration des objets connectés (Ubiquitous computing)
En termes de faisabilité :
• Allouer un espace de calcul sur AWS par exemple me coûte moins cher que
d’acheter une nouvelle machine performante (Gain en coût et performance)
• Interconnexion généralisée

7. DÉFINITION ET
CARACTÉRISTIQUE DU SYSTÈME
RÉPARTI
Your Date Here Your Footer Here
2
7

8. Définition d’un système réparti
Your Date Here Your Footer Here 8
C’est l’ensemble composé d’éléments reliés par un système de
communication. Ces éléments ont des fonctions de traitement (processeurs),
de stockage (mémoire), de relation avec le monde extérieur (capteurs,
actionneurs)
Définition d’une application répartie
C’est l’application qui, suivant les principes de l’architecture client-serveur,
peut tourner de façon transparente sur plusieurs ordinateurs reliés à travers
un réseau informatique, indépendamment du système utilisé. Elle peut être
appelée : Application n-tiers, applications distribuées

9. Caractéristiques d’un système réparti
Your Date Here Your Footer Here 9
• Les différents éléments du système ne fonctionnent pas indépendamment
mais collaborent pour réaliser une ou plusieurs tâches communes
• Une partie au moins de l’état global du système est partagée entre
plusieurs éléments (sinon un fonctionnement indépendant)
• Le système doit pouvoir fonctionner (au moins de façon dégradée) en cas
de défaillance de certains de ses éléments
• Le système doit pouvoir résister à des perturbation du système de
communication (déconnexion temporaire, performance dégradée)
• Le système doit résister à des attaques cybernétiques

10. Caractéristiques d’un système réparti
Your Date Here Your Footer Here 10
Défis à relever !
• Le système réparti repose sur une technique de communication
asynchrone : On ne sait pas quand recevoir un message
• Difficulté pour détecter les défaillances
• Le système réparti est dynamique : sa composition change en permanence
• Difficulté pour administrer le système et définir l’état global

11. Que répartir?
Your Date Here Your Footer Here 11
• Les données : base de données distribuées
• Les traitements
• Fonctions exécutées à distance
• Objets distants
• Des tâches en parallèle sur un par homogène ou hétérogène de
machines
• On parle de cluster, grid et cloud computing

12. ARCHITECTURE APPLICATIVE :
RPC ET MULTI-NIVEAUX
Your Date Here Your Footer Here
3
12

13. Problématique liée à l’appel distant
Your Date Here Your Footer Here 13
• Accès à des ressources de calcul distantes
• Une partie du programme est mise sur une autre machine
• Les deux parties doivent pouvoir communiquer
Programme
principal
Objet/méthode
distant(e)
appelle
Communication réseau

14. Solutions
Your Date Here Your Footer Here 14
• Solution 1 : implémentation à la main
• Pour chaque situation, on programme tout à l’aide des sockets
• Solution fastidieuse à long terme
• Solution 2 : mettre en place ou utiliser une solution générique
• Solution qui doit fonctionner pour n’importe quel type d’objet
• L’objectif est de s’affranchir de la programmation bas niveau des
sockets

15. Opter pour la solution générique
Your Date Here Your Footer Here 15
• Côté programme principal
• Il faut disposer d’une description de l’objet distant
• Connaître l’endroit ou il est localisé
• Appeler les fonctions de cet objet
• Côté objet distant
• Il faut fonctionner comme un serveur
• Réceptionner et interpréter les requêtes
• Effectuer les traitements demandés
• Retourner le résultat des traitements
Programme
principal
Objet/méthode
distant(e)
appelle
Communication réseau

16. Problèmes de la solution générique
Your Date Here Your Footer Here 16
• Description générique d’un objet
• Affectation des ressources au matériel (localisation)
• Comment encoder/décoder les informations de manière générique:
• A ce que l’objet distant sache
• La méthode à lancer
• Les paramètres à lui passer
• De manière à ce que le programme principal
• Interprète le résultat fourni
• Ou détecte un problème dans la transmission
• Quel protocole de communication mettre en place?

17. Solutions de la solution générique
Your Date Here Your Footer Here 17
• Utiliser les interfaces pour décrire un objet distant
• Deux implémentations
• Une implémentation locale (la souche – stub)
• Sérialise les requêtes
• Gère la communication avec l’objet distant
• Désérialise les réponses
• Implémentation distante ( le squelette – skeleton)
• Désérialise les requêtes
• Lance les méthodes de l’objet
• Sérialise la réponse
Sérialisation (marshalling) : processus permettant d’encoder un objet en
mémoire sous la forme d’une suite d’octets
Désérialisation (unmarshalling) : processus inverse. A partir d’une suite
d’octets, on reconstitue les données

18. RPC : Remote Procedure call
Your Date Here Your Footer Here 18
• Assurer la sémantique habituelle
de l’appel de la procédure en
mode centralisé sans se
préoccuper de la localisation de la
procédure exécutée
• Avantages
• Formes et effets identiques a local
• Simplicité conceptuelle et mise au point
• Abstraction
• Vis-à-vis protocole de communication
• Distribution masquée

19. SUN RPC
Your Date Here Your Footer Here 19
Application du pattern proxy
Talon client :
1. Reçoit l'appel local
2. Emballe les paramètres
3. Cree un identificateur
4. Exécute l'appel distant
5. Place le client en attente
Talon serveur :
6 Reçoit le message d'appel
7 Déballe les paramètres
8 Fait exécuter la procédure
9 Emballe, transmet résultat
Talon client:
10 Reçoit et déballe résultats
11 Les (( retourne )) au client

20. Raffiner RPC
Your Date Here Your Footer Here 20
• Beaucoup d’appels successifs pour peu de choses chacun
• Temps de communication et charge réseau « inutiles »
• Il faut augmenter le ration calcul/communications
• Découpe de l’application
• Couche présentation
• IHM
• Logique applicative
• Traitements
• Applications métiers
• Gestion des données
• Stockage
• Sauvegarde
• Base de données

21. Architectures applicatives
Your Date Here Your Footer Here 21
• Applications sur un site central
• Modèle utilisé dans le passé
• Distribution des applications
autonomes
• Difficile à mettre à jour
• Client lourd, programme dupliqué • Client léger

22. Architectures applicatives
22

23. SCHÉMA DE CONCEPTION (DESIGN
PATTERN)
Your Date Here Your Footer Here
4
23

24. Définition du Design pattern
24
Les design patterns sont des règles répondant à des besoins dans un
environnement donné. Ils sont élaborés par des experts pour résoudre des
problèmes récurrents

25. Le pattern proxy
25
Contexte
Le client a besoin d’accéder aux services d’un autre composant (ex. objet,
base de données, page html ou image)
L’accès direct est possible du point de vue technique mais sans être la
meilleure solution
Problème
L’accès direct à un composant n’est souvent pas pratique
– des procédures additionnelles de contrôle sont nécessaires (ex.
authentification, localisation)
Le code client doit rester simple et l ’accès aux composants transparent et
efficace
Solution
Le client communique avec le représentant (proxy) plutôt qu’avec le
composant
Le proxy offre l’interface du composant mais exécute des procédures
additionnelles avant (pre) et après (post) l’invocation du composant

26. Le pattern proxy : exemple
26

27. Le pattern proxy : exemple
27
On peut penser à mettre ici
toute la configuration
d’adressage pour retrouver
l’objet réparti puis appeler
new ExpensiveObjectImpl()
Initialisation effectuée une seule

28. Le pattern proxy : exemple
28
On peut penser à mettre ici
toute la configuration
d’adressage pour retrouver
l’objet réparti puis appeler
new ExpensiveObjectImpl()

29. Le pattern proxy : exemple
29

30. Le pattern proxy : exemple
30
Initialisation effectuée une seule

31. Le pattern Factory
31
Contexte
• Dans une application , on a un ensemble d'objets
Problème
• Créer a distance et dynamiquement des instances
d'une classe d'objets
• Propriétés souhaitables :
• Instances paramétrables ;
• évolution facile (rien (( en dur )), pas d’appel
explicite de « new »)
Solution
Abstract factory : interface et organisation génériques
de création d'objets
Création effective déléguée a des fabriques concrètes
dérivées

32. Le pattern Factory : exemple
32

33. Le pattern Intercepteur (Interceptor)
33
Contexte
• Client-serveur, P2P, hiérarchique ; Uni/Bi
directionnel, Synchrone ou non
Problème
Transformer le service
Ajouter de nouvelles fonctions, modifier les existantes
Changer la destination de l'appel
Solution
peuvent rediriger l'appel vers une cible différente
peuvent utiliser des appels en retour (callbacks) sur le
client
Proxy est une forme simplifiée d'Interceptor
Ajouter un Interceptor a un proxy devient un smart
proxy

34. Exemple : Le pattern Intercepteur
(Interceptor)
34
Filter - va executer une tâche
avant ou après l’execution d’un
gestionnaire de requêtes
Filter Chain - gère plusieurs filtres
et les execute suivant un ordre
sur une cible(target).
Target - Target execute les
requêtes
Filter Manager - Filter Manager
gère les filtres et Filter Chain.
Client - Client est l’objet qui
envoie le requête à la
cible(Target).

35. Exemple : Le pattern Intercepteur
(Interceptor)
35
Pré-traitement de la requête
(pattern intercepteur)

36. THANK YOU!
Do you have any questions?
36