diff --git a/cesi/architecture_n_tiers/presentation/img/Data_flow2.jpg b/cesi/architecture_n_tiers/presentation/img/Data_flow2.jpg new file mode 100644 index 0000000..1f6fd63 Binary files /dev/null and b/cesi/architecture_n_tiers/presentation/img/Data_flow2.jpg differ diff --git a/cesi/architecture_n_tiers/presentation/img/clientserveur.png b/cesi/architecture_n_tiers/presentation/img/clientserveur.png index 9d89285..ba7121c 100644 Binary files a/cesi/architecture_n_tiers/presentation/img/clientserveur.png and b/cesi/architecture_n_tiers/presentation/img/clientserveur.png differ diff --git a/cesi/architecture_n_tiers/presentation/img/lamp.png b/cesi/architecture_n_tiers/presentation/img/lamp.png index 9a58494..4be51d7 100644 Binary files a/cesi/architecture_n_tiers/presentation/img/lamp.png and b/cesi/architecture_n_tiers/presentation/img/lamp.png differ diff --git a/cesi/architecture_n_tiers/presentation/img/soa.png b/cesi/architecture_n_tiers/presentation/img/soa.png new file mode 100644 index 0000000..876c974 Binary files /dev/null and b/cesi/architecture_n_tiers/presentation/img/soa.png differ diff --git a/cesi/architecture_n_tiers/presentation/slides.md b/cesi/architecture_n_tiers/presentation/slides.md index e87013b..15d6c1b 100644 --- a/cesi/architecture_n_tiers/presentation/slides.md +++ b/cesi/architecture_n_tiers/presentation/slides.md @@ -1,9 +1,9 @@ -# 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 --- diff --git a/cesi/architecture_n_tiers/ressources/exercices/ex_2_tiers/README.md b/cesi/architecture_n_tiers/ressources/exercices/ex_2_tiers/README.md index a386bfb..09e94b7 100644 --- a/cesi/architecture_n_tiers/ressources/exercices/ex_2_tiers/README.md +++ b/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) diff --git a/cesi/architecture_n_tiers/ressources/exercices/ex_microbloggr/README.md b/cesi/architecture_n_tiers/ressources/exercices/ex_microbloggr/README.md new file mode 100644 index 0000000..a1de919 --- /dev/null +++ b/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. diff --git a/cesi/architecture_n_tiers/ressources/exercices/ex_microbloggr/microblogging.png b/cesi/architecture_n_tiers/ressources/exercices/ex_microbloggr/microblogging.png new file mode 100644 index 0000000..755cb65 Binary files /dev/null and b/cesi/architecture_n_tiers/ressources/exercices/ex_microbloggr/microblogging.png differ diff --git a/cesi/architecture_n_tiers/ressources/exercices/ex_microbloggr_solution/servicemicrobloggr.png b/cesi/architecture_n_tiers/ressources/exercices/ex_microbloggr_solution/servicemicrobloggr.png new file mode 100644 index 0000000..7672225 Binary files /dev/null and b/cesi/architecture_n_tiers/ressources/exercices/ex_microbloggr_solution/servicemicrobloggr.png differ diff --git a/cesi/architecture_n_tiers/ressources/schemas_slides.epgz b/cesi/architecture_n_tiers/ressources/schemas_slides.epgz index b224ce3..5439b7d 100644 Binary files a/cesi/architecture_n_tiers/ressources/schemas_slides.epgz and b/cesi/architecture_n_tiers/ressources/schemas_slides.epgz differ