Le document présente un cours sur les architectures applicatives, abordant les architectures client-serveur, les architectures distribuées, ainsi que des protocoles de transport comme TCP, UDP et Multicast IP. Il explique les modèles de communication, les caractéristiques des architectures 2 et 3 tiers, et introduit le cloud computing avec ses différents modèles de service. Des exemples de mises en œuvre et des TP sont également mentionnés pour illustrer les concepts abordés.

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

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

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

4. MOTIVATION
Your Date Here Your Footer Here
1
4

5. 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

6. Motivation
Your Date Here Your Footer Here 6
Architecture répartie
Architecture centralisée Architecture distribuée
Client/serveur
2 tiers 3 tiers

7. LES ARCHITECTURES
CENTRALISÉES
Your Date Here Your Footer Here
2
7

8. 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.
Your Date Here Your Footer Here 8

9. Architecture client-serveur
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.
Your Date Here Your Footer Here 9

10. Architecture client-serveur
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.
Your Date Here Your Footer Here 10

11. Architecture client-serveur
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).
Your Date Here Your Footer Here 11

12. Architecture client-serveur
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.
Your Date Here Your Footer Here 12

13. Architecture client-serveur
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, ...)
Your Date Here Your Footer Here 13

14. Architecture client-serveur
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”:
Your Date Here Your Footer Here 14

15. Architecture client-serveur
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).
Your Date Here Your Footer Here 15

16. Architecture client-serveur
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.
Your Date Here Your Footer Here 16

17. Architecture client-serveur
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
Your Date Here Your Footer Here 17

18. Architecture client-serveur
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
Your Date Here Your Footer Here 18

19. APPLICATION : LES
PROTOCOLES DE TRANSPORT
Your Date Here Your Footer Here
3
19

20. 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
Your Date Here Your Footer Here 20

21. Protocoles de transport
• 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.
Your Date Here Your Footer Here 21

22. Protocoles de transport
•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
Your Date Here Your Footer Here 22

23. Protocoles de transport
• 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.
Your Date Here Your Footer Here 23

24. 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
Your Date Here Your Footer Here 24

25. TCP : fonctionnement
•1.Le serveur crée une
socket et attend une
demande de connexion
Your Date Here Your Footer Here 25

26. TCP : fonctionnement
•2.Le client envoie une
demande de connexion
Your Date Here Your Footer Here 26

27. TCP : fonctionnement
•3.Le serveur accepte la
connexion
Your Date Here Your Footer Here 27

28. TCP : fonctionnement
•4.Etablissement du dialogue entre client et serveur en mode flux
Your Date Here Your Footer Here 28
Le client
Le serveur

29. TCP : fonctionnement
•5.Fermeture de connexion à l'initiative du client ou du
serveur
Your Date Here Your Footer Here 29
Initiative du client
pour fermer la
connexion en tapant
« exit »

30. 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
Your Date Here Your Footer Here 30

31. 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.
Your Date Here Your Footer Here 31

32. UDP : fonctionnement
•1.Le serveur crée une socket UDP.
•2.Le serveur attend la réception d’un message.
Your Date Here Your Footer Here 32

33. UDP : fonctionnement
•3.Le client envoie un message.
Your Date Here Your Footer Here 33

34. 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.
Your Date Here Your Footer Here 34

35. UDP : fonctionnement
•Le serveur va recevoir le paquet
Your Date Here Your Footer Here 35
Durée d’attente
Méthode de traitement

36. UDP : Live demo
•Fork your repo from my github!
•https://github.com/MariemZaouali/Test_udp_ser
ver
•https://github.com/MariemZaouali/Test_udp_clie
nt
Your Date Here Your Footer Here 36

37. Remarque
•Pourquoi utiliser les buffers (input/output)?
Your Date Here Your Footer Here 37
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

38. 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

39. Multicast IP : fonctionnement
•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

40. Multicast IP : fonctionnement
Your Date Here Your Footer Here 40
• 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

41. Multicast IP : fonctionnement
Your Date Here Your Footer Here 41
• 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.

42. Multicast : live demo
•Fork your repo from my github!
•https://github.com/MariemZaouali/Test_multicas
t_client
•https://github.com/MariemZaouali/Test_multicas
t_serveur
Your Date Here Your Footer Here 42

43. LES ARCHITECTURES
DISTRIBUÉES
Your Date Here Your Footer Here
4
43

44. Architecture distribuée
Your Date Here Your Footer Here 44
Architecture répartie
Architecture centralisée Architecture distribuée
Peer to Peer

45. Architecture distribuée
•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.
Your Date Here Your Footer Here 45

46. Architecture distribuée
•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.
Your Date Here Your Footer Here 46

47. Architecture distribuée
• 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).
Your Date Here Your Footer Here 47

48. Architecture distribuée
•Les technologies Peer-to-Peer (P2P, ou Pair-à-
Pair) constituent le pendant technologique des
architectures distribuées.
Your Date Here Your Footer Here 48

49. Architecture distribuée
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
Your Date Here Your Footer Here 49

50. Architecture distribuée
•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 ?).
Your Date Here Your Footer Here 50

51. LE CLOUD COMPUTING
Your Date Here Your Footer Here
5
51

52. 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)
Your Date Here Your Footer Here 52

53. 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
Your Date Here Your Footer Here 53

54. Usage des technologies Cloud dans une
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
Your Date Here Your Footer Here 54

55. Usage des technologies Cloud dans une
entreprise
•On peut avoir:
• PaaS : des outils
hardware et logiciels
en tant que service
via internet,
permettant à
l'utilisateur de
développer des
applications
Your Date Here Your Footer Here 55

56. Modèle de déploiement de Cloud
Computing
Your Date Here Your Footer Here 56

57. Fournisseurs de Cloud Public
Your Date Here Your Footer Here 57

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