CESI: Architecture N Tiers

This commit is contained in:
wpetit 2018-01-13 15:28:05 +01:00 committed by Benjamin Bohard
parent 3e85ca32a0
commit 34833d8186
7 changed files with 193 additions and 0 deletions

Binary file not shown.

After

Width:  |  Height:  |  Size: 22 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 20 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 35 KiB

Binary file not shown.

After

Width:  |  Height:  |  Size: 21 KiB

View File

@ -0,0 +1,171 @@
<style>
pre { font-size: 0.5em !important; }
table { font-size: 0.6em !important; }
</style>
# Architectures N Tiers
## William Petit - S.C.O.P. Cadoles
---
## Les architectures distribuées (1)
### Qu'est ce qu'une application distribuée ?
![center 75%](./img/application_distribue.png)
> Une application distribuée est une application informatique constituée de **composants indépendants** (i.e. processus distincts et sans partage de mémoire) **communiquant via des messages**.
---
## Les architectures distribuées (2)
### Exemples d'applications distribuées
- Sites/applications Web
- Jeux en ligne multijoueurs
- Gestionnaire de version de code source (SVN, Git, etc...)
- Serveurs de courriel
---
<!-- page_number: true -->
## Les différents modèles d'architectures distribuées
### Modèle 2 tiers (ou client/serveur)
### Modèle 3 tiers
### Modèle N tiers
### Modèle Pair à pair
---
## Le modèle 2 tiers (ou "client/serveur")
### Définitions
### Les différentes topologies
### Communication client/serveur
### Répartition des traitements
### Exercice : Implémentation d'une calculatrice par TCP/IP
### La couche intergiciel
### Exercice : Utilisation d'un couche JSON-RPC2 pour la calculatrice TCP/IP
---
## Définitions
- **Client** Processus demandant lexécution dune opération à
un autre processus par envoi de message contenant le
descriptif de lopération à exécuter et attendant la réponse de
cette opération par un message en retour.
- **Serveur** processus accomplissant une opération sur
demande dun client, et lui transmettant le résultat.
- **Requête** message transmis par un client à un serveur
décrivant lopération à exécuter pour le compte du client.
- **Réponse** message transmis par un serveur à un client suite
à lexécution dune opération, contenant le résultat de
lopération.
---
## Les différentes topologies
![center 100%](./img/clientserveur.png)
---
## Communication client/serveur (3)
### Protocole de communication
Une application distribuée étant fondamentalement un environnement hétérogène (composants indépendants). Il est donc nécessaire de définir un "langage commun" (ou "protocole") pour que les composants puissent communiquer entre eux.
La spécification de régles de **sérialisation** et **désérialisation** des structures de données échangées (messages) est souvent à la base de la définition des protocoles d'échange.
[Exemples de formats de sérialisation sur Wikipédia](https://en.wikipedia.org/wiki/Comparison_of_data_serialization_formats)
---
## Communication client/serveur (2)
### Modes de communication
![center](./img/communication_client_serveur.png?3)
---
## Communication client/serveur (3)
### Différences entre les deux modes
#### Synchrone
- Les messages sont émis aussitôt
- Bloquant
- Pas de file d'attente de traitement
### Asynchrone
- Nécessite une file d'attente de traitement
- Non bloquant
- Favorise le multitâche/la montée en charge
---
## Répartition des traitements (1)
### Couches de traitement
La conception d'une application distribuée nécessite d'établir une répartition de la responsabilité des traitements sur les différents composants. On peut catégoriser ces traitements par "couche":
- **Couche de présentation** rendu des interfaces textuelle ou graphique destinée à l'utilisateur de l'application, gestion des interactions, validation des entrées...
- **Couche métier/logique** traitement appliqués sur les modèles de données de l'application, validation des données...
- **Couche de données** Persistance et accès aux données de l'application
---
## Répartition des traitements (2)
### Classification des architectures 2 tiers (Gartner Group)
![center](./img/modle_gartner_2_tiers.png)
---
## Exercice (1)
Implémenter en NodeJS une application distribuée permettant d'effectuer les opérations arithmétiques simples (addition, soustraction, multiplication et division). Cette application devra répondre aux contraintes suivantes:
- Elle devra être suivre une architecture 2 tiers de classe 4.
- Le client devra utiliser le transport TCP/IP pour communiquer avec le serveur.
- Elle n'aura pas à supporter de multiples clients.
- Toutes les implémentations de la classe devront être compatibles, i.e. vous devez vous mettre d'accord sur un protocole de sérialisation/désérialisation des messages commun.
---
## Exercice (2)
---
## L'architecture 3 tiers
### Principes
### Modèle transactionnel
### Sécurité
### Exercice : Implémentation de couche de présentation (HTML/CSS et ligne de commande) multiple pour une même couche logique et de données
---
## Les architectures n-tiers
### Principes
### Approche objet et notion de responsabilité
### Communication inter-composants
### Exercice : Présentation de l'architecture orientée « micro-services » et implémentation d'une application basée sur ce patron de conception.
---
# Licence
## CC BY-NC-SA 3.0 FR
[Creative Commons - Attribution - Pas dUtilisation Commerciale - Partage dans les Mêmes Conditions 3.0 France](https://creativecommons.org/licenses/by-nc-sa/3.0/fr/)

View File

@ -0,0 +1,22 @@
msc {
wordwraparcs=true, hscale=2;
Client,Serveur;
--- [ label = "Mode synchrone (bloquant)" ];
Client->Serveur [ label = "Requête" ];
Serveur->Serveur [ label = "Traitement de la requête" ];
Serveur->Client [ label = "Réponse" ];
--- [ label = "Mode asynchrone (non bloquant)" ];
Client->Serveur [ label = "Requête" ];
Serveur->Serveur [ label = "Création de la tâche #N" ];
Serveur->Client [ label = "Réponse <Tâche #N créée>" ];
... [ label = "" ];
Serveur->Serveur [ label = "Exécution de la tâche #N" ];
Serveur->Client [ label = "Résultat <Tâche #N terminée>" ];
}