> 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
### Exercice: Implémentation d'une calculatrice par TCP/IP
---
## Définitions
- **Client** Processus demandant l’exécution d’une opération à
un autre processus par envoi de message contenant le
descriptif de l’opé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 d’un client, et lui transmettant le résultat.
- **Requête** message transmis par un client à un serveur
décrivant l’opération à exécuter pour le compte du client.
- **Réponse** message transmis par un serveur à un client suite
à l’exécution d’une opération, contenant le résultat de
l’opération.
---
## Les différentes topologies
---
## 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)
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)
L'architecture 3 tiers est le modèle d'architecture applicative le plus utilisé aujourd'hui dans la conception d'application. Il propose de découper l'application en 3 couches aux rôles distincts:
Une transaction est une série d'opérations appliquées sur un corpus de données respectant les caractéristiques suivantes:
- **A**tomicité
- **C**ohérence
- **I**solation
- **D**urable
---
## Transactions (2)
### Atomicité
La série d'opérations est indivisible.
**Exemple**
Soit une transaction comportant 3 opérations arithmétiques sur la variable `ACC`.
|Opération|État |Description|
|:-|:-|:-|
| -- | `ACC = 0` | État initial |
| `ACC = ACC + 1` | `ACC = 1` | Application de l'opération A |
| `ACC = ACC - 5` | `ACC = -4` | Application de l'opération B |
| `ACC = ACC / 0` | `ACC = 0` | Application de l'opération C. La division par 0 provoque une erreur. Retour à l'état initial. |
---
## Transactions (3)
### Cohérence
L'état du corpus de données à la fin de l'exécution de la transaction doit être cohérent (sans pour autant que le résultat de chaque opération pris distinctement soit cohérent).
---
## Transactions (4)
### Isolation
Lorsque deux transactions A et B sont exécutées en même temps, les modifications effectuées par A ne sont ni visibles par B, ni modifiables par B tant que la transaction A n'est pas terminée et validée.
---
## Transactions (5)
### Durable
Une fois validé, l'état du corpus de données doit être permanent, et aucun incident technique (exemple: crash) ne doit pouvoir engendrer une annulation des opérations effectuées durant la transaction.
---
## Sécurité (1)
### Objectifs
- Maintenir l'intégrité des données
- S'assurer du niveaux d'authentification et d'autorisation
- Maintenir la disponibilité des services
- Assurer la traçabilité des échanges
- Éviter la fuite d'informations
---
## Sécurité (2)
### Modélisation de menace
- Identification des **dépendances externes**.
Exemple: _serveur GNU/Linux, base de données_
- Identification des **points d'entrées**
Exemple: _formulaire de contact, port de la base de données_
- Identification des **assets**
Exemple: _Comptes utilisateurs de l'application, données personnelles, droits d'accès_
- La **plus-value métier** prévaut sur la technique.
- L'**interopérabilité** des services doit être considérée comme une des pierres angulaires de la conception.
- La **flexibilité** de l'architecture doit être privilégiée à l'optimisation.
---
## Architecture orientée microservices (1)
### Différence avec le SOA
L'architecture orientée microservices est une variante du modèle plus général de la SOA.
Elle peut se résumer à la philosophie Unix **"Faire une seule chose et le faire bien"**.
---
## Architecture orientée microservices (2)
### Piliers
- Chaque service remplit **une fonction unique**.
- La culture de l'**automatisation du processus de développement** devrait être adoptée au maximum par les équipes (mise en place de tests unitaires et fonctionnels, intégration et déploiement continu).
- L'application devrait **prendre en compte et gérer l'échec** d'un de ses composants.
- Chaque service est **élastique**, **résilient**, **composable**, **minimaliste** et **complet**.
---
## Exercice
### Prototypage d'une application distribuée basée sur les microservices
