SlideShare une entreprise Scribd logo
1  sur  36
Télécharger pour lire hors ligne
APPLICATIONS RÉPARTIES
CHAPITRE 1 : LES PRINCIPES DE BASE
Mariem ZAOUALI
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
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)
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
MOTIVATION
Your Date Here Your Footer Here
1
5
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
DÉFINITION ET
CARACTÉRISTIQUE DU SYSTÈME
RÉPARTI
Your Date Here Your Footer Here
2
7
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
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
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
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
ARCHITECTURE APPLICATIVE :
RPC ET MULTI-NIVEAUX
Your Date Here Your Footer Here
3
12
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
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
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
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?
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
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
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
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
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
Architectures applicatives
22
SCHÉMA DE CONCEPTION (DESIGN
PATTERN)
Your Date Here Your Footer Here
4
23
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
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
Le pattern proxy : exemple
26
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
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()
Le pattern proxy : exemple
29
Le pattern proxy : exemple
30
Initialisation effectuée une seule
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
Le pattern Factory : exemple
32
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
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).
Exemple : Le pattern Intercepteur
(Interceptor)
35
Pré-traitement de la requête
(pattern intercepteur)
THANK YOU!
Do you have any questions?
36

Contenu connexe

Tendances

Tendances (20)

Le Réseau et Java
Le Réseau et JavaLe Réseau et Java
Le Réseau et Java
 
Chap1 clientsrvr
Chap1 clientsrvrChap1 clientsrvr
Chap1 clientsrvr
 
Rapport application chat
Rapport application chatRapport application chat
Rapport application chat
 
Chap7 java net
Chap7 java netChap7 java net
Chap7 java net
 
Rapport Sockets en Java
Rapport Sockets en JavaRapport Sockets en Java
Rapport Sockets en Java
 
Création des sites web pour débutant
Création des sites web pour débutantCréation des sites web pour débutant
Création des sites web pour débutant
 
Reseau
ReseauReseau
Reseau
 
Programmation réseau en JAVA
Programmation réseau en JAVAProgrammation réseau en JAVA
Programmation réseau en JAVA
 
Java RMI
Java RMIJava RMI
Java RMI
 
Formation1 sockets
Formation1 socketsFormation1 sockets
Formation1 sockets
 
Cours apd
Cours apdCours apd
Cours apd
 
Java Database Connectivity
Java Database ConnectivityJava Database Connectivity
Java Database Connectivity
 
Introduction aux-sockets
Introduction aux-socketsIntroduction aux-sockets
Introduction aux-sockets
 
Les socket ing1_issat
Les socket ing1_issatLes socket ing1_issat
Les socket ing1_issat
 
Dhcp sous fedora 11
Dhcp sous fedora 11Dhcp sous fedora 11
Dhcp sous fedora 11
 
Ccnp formation-ccnp
Ccnp formation-ccnpCcnp formation-ccnp
Ccnp formation-ccnp
 
Cours services web_fabrice_mourlin
Cours services web_fabrice_mourlinCours services web_fabrice_mourlin
Cours services web_fabrice_mourlin
 
Général réseau typologie et architecture
Général réseau typologie et architecture Général réseau typologie et architecture
Général réseau typologie et architecture
 
Alphorm.com Formation CCNP ENCOR 350-401 (1of8) : Commutation
Alphorm.com Formation CCNP ENCOR 350-401 (1of8) : CommutationAlphorm.com Formation CCNP ENCOR 350-401 (1of8) : Commutation
Alphorm.com Formation CCNP ENCOR 350-401 (1of8) : Commutation
 
Cours SNMP
Cours SNMPCours SNMP
Cours SNMP
 

Similaire à Cours 1 les principes de base

applications-reparties
applications-repartiesapplications-reparties
applications-repartiesmourad50
 
AOP.pptx
AOP.pptxAOP.pptx
AOP.pptxManalAg
 
resume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfresume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfFootballLovers9
 
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhvSOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhvamine17157
 
Design applicatif avec symfony - Zoom sur la clean architecture - Symfony Live
Design applicatif avec symfony - Zoom sur la clean architecture - Symfony LiveDesign applicatif avec symfony - Zoom sur la clean architecture - Symfony Live
Design applicatif avec symfony - Zoom sur la clean architecture - Symfony LiveRomainKuzniak
 
Codedarmor 2012 - 03/04 - Android, What else?
Codedarmor 2012 - 03/04 - Android, What else?Codedarmor 2012 - 03/04 - Android, What else?
Codedarmor 2012 - 03/04 - Android, What else?codedarmor
 
Déploiement d’applications
Déploiement d’applicationsDéploiement d’applications
Déploiement d’applicationsMohammed Jaafar
 
Fondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application FlexFondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application Flexdavid deraedt
 
Fondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application FlexFondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application Flexdavid deraedt
 
Architecture réparties et les services web
Architecture réparties et les services webArchitecture réparties et les services web
Architecture réparties et les services webCHOUAIB EL HACHIMI
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2Christophe Rochefolle
 
Université de la performance - Devoxx France
Université de la performance - Devoxx FranceUniversité de la performance - Devoxx France
Université de la performance - Devoxx FranceMarc Bojoly
 
srep_cours_01.pdf
srep_cours_01.pdfsrep_cours_01.pdf
srep_cours_01.pdfSamirAwad14
 
Inf4420 final a05-solutions
Inf4420 final a05-solutionsInf4420 final a05-solutions
Inf4420 final a05-solutionsmouad11
 
SPA avec Angular et SignalR (FR)
SPA avec Angular et SignalR (FR)SPA avec Angular et SignalR (FR)
SPA avec Angular et SignalR (FR)Rui Carvalho
 
Introduction aux architectures des SI
Introduction aux architectures des SI Introduction aux architectures des SI
Introduction aux architectures des SI Heithem Abbes
 

Similaire à Cours 1 les principes de base (20)

applications-reparties
applications-repartiesapplications-reparties
applications-reparties
 
Remote method invocation
Remote method invocationRemote method invocation
Remote method invocation
 
AOP.pptx
AOP.pptxAOP.pptx
AOP.pptx
 
resume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdfresume-theorique-m107-2203-6246f60d6b994.pdf
resume-theorique-m107-2203-6246f60d6b994.pdf
 
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhvSOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
SOA-Partie 2.pdf hvjhvhjvkhvhjvhvhvjhvkhv
 
Les sockets.pptx
Les sockets.pptxLes sockets.pptx
Les sockets.pptx
 
Design applicatif avec symfony - Zoom sur la clean architecture - Symfony Live
Design applicatif avec symfony - Zoom sur la clean architecture - Symfony LiveDesign applicatif avec symfony - Zoom sur la clean architecture - Symfony Live
Design applicatif avec symfony - Zoom sur la clean architecture - Symfony Live
 
Codedarmor 2012 - 03/04 - Android, What else?
Codedarmor 2012 - 03/04 - Android, What else?Codedarmor 2012 - 03/04 - Android, What else?
Codedarmor 2012 - 03/04 - Android, What else?
 
Déploiement d’applications
Déploiement d’applicationsDéploiement d’applications
Déploiement d’applications
 
Fondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application FlexFondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application Flex
 
Fondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application FlexFondamentaux d'architecture d'une application Flex
Fondamentaux d'architecture d'une application Flex
 
Architecture réparties et les services web
Architecture réparties et les services webArchitecture réparties et les services web
Architecture réparties et les services web
 
Perf university
Perf universityPerf university
Perf university
 
Cloud migration
Cloud migrationCloud migration
Cloud migration
 
Automatisation des tests - objectifs et concepts - partie 2
Automatisation des tests  - objectifs et concepts - partie 2Automatisation des tests  - objectifs et concepts - partie 2
Automatisation des tests - objectifs et concepts - partie 2
 
Université de la performance - Devoxx France
Université de la performance - Devoxx FranceUniversité de la performance - Devoxx France
Université de la performance - Devoxx France
 
srep_cours_01.pdf
srep_cours_01.pdfsrep_cours_01.pdf
srep_cours_01.pdf
 
Inf4420 final a05-solutions
Inf4420 final a05-solutionsInf4420 final a05-solutions
Inf4420 final a05-solutions
 
SPA avec Angular et SignalR (FR)
SPA avec Angular et SignalR (FR)SPA avec Angular et SignalR (FR)
SPA avec Angular et SignalR (FR)
 
Introduction aux architectures des SI
Introduction aux architectures des SI Introduction aux architectures des SI
Introduction aux architectures des SI
 

Plus de Mariem ZAOUALI

Chap5 La manipulation des iterables en python
Chap5 La manipulation des iterables en pythonChap5 La manipulation des iterables en python
Chap5 La manipulation des iterables en pythonMariem ZAOUALI
 
Chap6 Manipulation des fichiers
Chap6 Manipulation des fichiers Chap6 Manipulation des fichiers
Chap6 Manipulation des fichiers Mariem ZAOUALI
 
Chap7 simulation numérique
Chap7 simulation numériqueChap7 simulation numérique
Chap7 simulation numériqueMariem ZAOUALI
 
Chap4 Récursivité en python
Chap4 Récursivité en pythonChap4 Récursivité en python
Chap4 Récursivité en pythonMariem ZAOUALI
 
Chap3 programmation modulaire en python
Chap3 programmation modulaire en pythonChap3 programmation modulaire en python
Chap3 programmation modulaire en pythonMariem ZAOUALI
 
Chap2 Les conteneurs en python
Chap2 Les conteneurs en pythonChap2 Les conteneurs en python
Chap2 Les conteneurs en pythonMariem ZAOUALI
 
Chap1 Introduction à python
Chap1 Introduction à pythonChap1 Introduction à python
Chap1 Introduction à pythonMariem ZAOUALI
 
Tp1 design patternappliques
Tp1 design patternappliquesTp1 design patternappliques
Tp1 design patternappliquesMariem ZAOUALI
 
TP1 Traitement d'images Génie Logiciel avec Matlab
TP1 Traitement d'images Génie Logiciel avec MatlabTP1 Traitement d'images Génie Logiciel avec Matlab
TP1 Traitement d'images Génie Logiciel avec MatlabMariem ZAOUALI
 
Comment retrouver la forme récursive
Comment retrouver la forme récursiveComment retrouver la forme récursive
Comment retrouver la forme récursiveMariem ZAOUALI
 
Correction TP4 Atelier C++ /GL2 INSAT / Tunisie
Correction TP4 Atelier C++ /GL2 INSAT / TunisieCorrection TP4 Atelier C++ /GL2 INSAT / Tunisie
Correction TP4 Atelier C++ /GL2 INSAT / TunisieMariem ZAOUALI
 
TP4 Atelier C++ /GL2 INSAT / Tunisie
TP4 Atelier C++ /GL2 INSAT / TunisieTP4 Atelier C++ /GL2 INSAT / Tunisie
TP4 Atelier C++ /GL2 INSAT / TunisieMariem ZAOUALI
 
TP3 Atelier C++/ GL2 INSAT / Tunisie
TP3 Atelier C++/ GL2 INSAT / TunisieTP3 Atelier C++/ GL2 INSAT / Tunisie
TP3 Atelier C++/ GL2 INSAT / TunisieMariem ZAOUALI
 
TP2 Atelier C++/ GL2 INSAT / Tunisie
TP2 Atelier C++/ GL2 INSAT / TunisieTP2 Atelier C++/ GL2 INSAT / Tunisie
TP2 Atelier C++/ GL2 INSAT / TunisieMariem ZAOUALI
 
TP1 Atelier C++/ GL2 INSAT / Tunisie
TP1 Atelier C++/ GL2 INSAT / TunisieTP1 Atelier C++/ GL2 INSAT / Tunisie
TP1 Atelier C++/ GL2 INSAT / TunisieMariem ZAOUALI
 
Graduation Project Presentation _ INSAT Tunisia
Graduation Project Presentation _ INSAT Tunisia Graduation Project Presentation _ INSAT Tunisia
Graduation Project Presentation _ INSAT Tunisia Mariem ZAOUALI
 

Plus de Mariem ZAOUALI (17)

Chap5 La manipulation des iterables en python
Chap5 La manipulation des iterables en pythonChap5 La manipulation des iterables en python
Chap5 La manipulation des iterables en python
 
Chap6 Manipulation des fichiers
Chap6 Manipulation des fichiers Chap6 Manipulation des fichiers
Chap6 Manipulation des fichiers
 
Chap7 simulation numérique
Chap7 simulation numériqueChap7 simulation numérique
Chap7 simulation numérique
 
Chap4 Récursivité en python
Chap4 Récursivité en pythonChap4 Récursivité en python
Chap4 Récursivité en python
 
Chap3 programmation modulaire en python
Chap3 programmation modulaire en pythonChap3 programmation modulaire en python
Chap3 programmation modulaire en python
 
Chap2 Les conteneurs en python
Chap2 Les conteneurs en pythonChap2 Les conteneurs en python
Chap2 Les conteneurs en python
 
Chap1 Introduction à python
Chap1 Introduction à pythonChap1 Introduction à python
Chap1 Introduction à python
 
Tp1 design patternappliques
Tp1 design patternappliquesTp1 design patternappliques
Tp1 design patternappliques
 
TP2 RMI
TP2 RMITP2 RMI
TP2 RMI
 
TP1 Traitement d'images Génie Logiciel avec Matlab
TP1 Traitement d'images Génie Logiciel avec MatlabTP1 Traitement d'images Génie Logiciel avec Matlab
TP1 Traitement d'images Génie Logiciel avec Matlab
 
Comment retrouver la forme récursive
Comment retrouver la forme récursiveComment retrouver la forme récursive
Comment retrouver la forme récursive
 
Correction TP4 Atelier C++ /GL2 INSAT / Tunisie
Correction TP4 Atelier C++ /GL2 INSAT / TunisieCorrection TP4 Atelier C++ /GL2 INSAT / Tunisie
Correction TP4 Atelier C++ /GL2 INSAT / Tunisie
 
TP4 Atelier C++ /GL2 INSAT / Tunisie
TP4 Atelier C++ /GL2 INSAT / TunisieTP4 Atelier C++ /GL2 INSAT / Tunisie
TP4 Atelier C++ /GL2 INSAT / Tunisie
 
TP3 Atelier C++/ GL2 INSAT / Tunisie
TP3 Atelier C++/ GL2 INSAT / TunisieTP3 Atelier C++/ GL2 INSAT / Tunisie
TP3 Atelier C++/ GL2 INSAT / Tunisie
 
TP2 Atelier C++/ GL2 INSAT / Tunisie
TP2 Atelier C++/ GL2 INSAT / TunisieTP2 Atelier C++/ GL2 INSAT / Tunisie
TP2 Atelier C++/ GL2 INSAT / Tunisie
 
TP1 Atelier C++/ GL2 INSAT / Tunisie
TP1 Atelier C++/ GL2 INSAT / TunisieTP1 Atelier C++/ GL2 INSAT / Tunisie
TP1 Atelier C++/ GL2 INSAT / Tunisie
 
Graduation Project Presentation _ INSAT Tunisia
Graduation Project Presentation _ INSAT Tunisia Graduation Project Presentation _ INSAT Tunisia
Graduation Project Presentation _ INSAT Tunisia
 

Cours 1 les principes de base

  • 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
  • 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