CESI: architectures n tiers

cesi/architecture_n_tiers/presentation/slides.md

@@ -1,9 +1,9 @@
 <style>
 pre { font-size: 0.5em !important; }
-table { font-size: 0.6em !important; } 
+table { font-size: 0.5em !important; } 
 </style>
 
-# Architectures N Tiers
+# Les architectures distribuées
 ## William Petit - S.C.O.P. Cadoles
 
 ---
@@ -34,7 +34,6 @@ table { font-size: 0.6em !important; }
 ### Modèle 2 tiers (ou client/serveur)
 ### Modèle 3 tiers
 ### Modèle N tiers
-### Modèle Pair à pair
 
 ---
 
@@ -135,10 +134,10 @@ Aussi appelé "intergiciel" ou "intersticiel" en français.
 
 ### Rôle
 
-- Ensemble de services logiciels construits au dessus d’un
-protocole de transport afin de permettre l’échange de
-requêtes et des réponses associées entre client et serveur de
-manière transparente.
+- Ensemble de services logiciels construits **au dessus d’un
+protocole de transport** afin de permettre l’échange de
+requêtes et des réponses associées entre client et serveur **de
+manière transparente**.
 - Les services du middleware sont un ensemble de logiciels
 répartis qui existe entre l’application, l’OS et les services
 réseaux sur un nœud du réseau.
@@ -167,8 +166,8 @@ réseaux sur un nœud du réseau.
 ### Différentes techniques
 
 - **Échange de messages**, ou MOM - Message Oriented Middleware. Exemple: AMQP, NATS
-- **Appel de procédures distantes**, ou RPC. Exemple: JSON-RPC2, SOAP.
-- **Manipulation d'objets** Exemple: DCOMM, CORBA, RMI
+- **Appel de procédures distantes**, ou RPC. Exemple: JSON-RPC2, XML-RPC, SOAP.
+- **Manipulation d'objets** Exemple: REST, DCOMM, CORBA, RMI
 
 ---
 
@@ -189,8 +188,8 @@ réseaux sur un nœud du réseau.
 ## L'architecture 3 tiers
 
 ### Généralités
+### Transactions
 ### 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
 
 ---
 
@@ -200,9 +199,9 @@ réseaux sur un nœud du réseau.
 
 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:
 
-- Couche de **présentation**
-- Couche de **traitement/logique/métier**
-- Couche de **persistence/données**
+- Couche **présentation**
+- Couche **logique/métier**
+- Couche **persistence/données**
 
 ---
 
@@ -210,16 +209,164 @@ L'architecture 3 tiers est le modèle d'architecture applicative le plus utilis
 
 ### Exemple: Application LAMP (Linux, Apache, PHP, MySQL)
 
-
 ![center](./img/lamp.png?1)
 
 ---
 
+## Transactions (1)
+
+### Qu'est ce qu'une transaction ?
+
+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_
+- Identification des **niveaux de confiance**
+	Exemple: _Utilisateur anonyme, administrateur_
+
+---
+
+## Sécurité (3)
+
+### Identification des flux de données
+
+![center](./img/Data_flow2.jpg)
+
+---
+
 ## Modèle N tiers
 
+### Architecture orientée services (ou SOA)
+### Architecture orientée microservices
+### Exercice
+
 ---
 
-## Modèle Pair à pair
+## Architecture orientée services (1)
+
+### Notion de "service"
+
+Un service est un composant d'une application distribuée répondant aux caractéristiques suivantes:
+
+- Il a pour responsabilité **un domaine métier identifié** (ex: gestion du paiement par carte).
+- Il est **autonome**.
+- C'est une **"boite noire"** pour ses utilisateurs.
+- Il peut être lui même un **aggrégat de plusieurs autres sous services**.
+
+---
+
+## Architecture orientée services (2)
+
+### Exemple
+
+![center 90%](./img/soa.png)
+
+---
+
+## Architecture orientée services (3)
+
+### Piliers
+
+- 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
 
 ---
 

cesi/architecture_n_tiers/ressources/exercices/ex_2_tiers/README.md

@@ -4,10 +4,10 @@
 
 Implémenter en NodeJS une application distribuée permettant d'effectuer les opérations arithmétiques simples. Cette application devra répondre aux contraintes suivantes:
 
-- Elle devra être suivre une architecture 2 tiers de classe 4.
+- Elle devra 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.
+- Toutes les implémentations de la classe devront être compatibles, i.e. vous devez vous mettre d'accord sur un protocole commun de sérialisation/désérialisation des messages.
 
 Le client/serveur devront gérer les instructions suivantes:
 
@@ -20,6 +20,15 @@ Le client/serveur devront gérer les instructions suivantes:
 
 Vous pouvez vous baser sur les fichiers `client.js` et `server.js` présents dans ce répertoire pour amorcer votre projet.
 
+Si vous débutez avec NodeJS, des liens sont disponibles plus bas dans la section "Ressources".
+
+### Phases de l'exercice
+
+- **Phase 1** Lisez bien les consignes.
+- **Phase 2** Concevez et mettez vous d'accord sur un protocole commun pour la sérialisation/desérialisation des instructions échangées entre le client et le serveur.
+- **Phase 3** Implémentez votre client et serveur en fonction des spécifications que vous aurez établi.
+- **Phase 4** Testez l'interopérabilité de vos implémentations en faisant pointer votre client vers le serveur d'un de vos collègues, et inversement.
+
 ## Exemple de séquence d'échange
 
 ![center](./seq.png)

cesi/architecture_n_tiers/ressources/exercices/ex_microbloggr/README.md

@@ -0,0 +1,26 @@
+# Prototypage d'une application basée sur des microservices
+
+## Consignes
+
+Prototypez une application de micro-blogging (un clone de Twitter) en vous basant sur une architecture orientée microservices.
+
+Votre application devra comprendre les fonctionnalités suivantes:
+
+- Pouvoir créer un compte avec un identifiant unique et un mot de passe.
+- Se connecter avec son couple identifiant/mot de passe.
+- Poster un nouveau "statut" (une fois connecté).
+- Rechercher un utilisateur par son identifiant.
+- "Suivre" un autre utilisateur.
+- Visualisez le flux des statuts de tous les utilisateurs que l'on suit, par ordre chronologique décroissant.
+- Voir le profil d'un utilisateur et ses statuts.
+
+### Exemples de vues
+
+![center](./microblogging.png)
+
+### Phases de l'exercice
+
+- **Phase 1** En fonction des fonctionnalités identifiées, proposer un découpage de l'application en microservices, les canaux de communication entre ceux ci et la responsabilité de chacuns.
+- **Phase 2** Répartissez vous en groupes, un pour chaque microservice pressenti.
+- **Phase 3** Concevez l'API de chacun des microservices ensemble.
+- **Phase 4** Chaque groupe implémente le microservice qui lui est attribué et teste l'intégration de celui ci avec ceux des autres groupes.