INFAL23 Architecture N Tiers Support

CESI – INFAL23
Architecture n-tiers
casteranregis@gmail.com 20/07/2020 - 1
Objectifs
 Découvrir le fonctionnement des différentes

architectures.
 Comprendre comment les mettre en œuvre.
 Acquérir les connaissances de base des
architectures informatiques dont le n-tiers.
Architecture n-tiers 20/07/2020 - 2

Sommaire
 Définitions
 Vues du système d’information
 Vue « Système d’information »
 Vue « Système informatique »
 Framework de Zachman
 Architecture applicative
 Architecture en couche
 Responsabilité des composants
 Modèle du Gartner Group
 Client léger, riche et lourd
 Serveur d’application vs Serveur WEB
 Middleware
 Architecture orientée Service
 Architecture orientée WEB
 Echange de données
 Sécurité
 Architecture physique
 Déploiement d’applications / de services
 Enterprise Service Bus
 Architecture Cloud Computing

Définitions
 Système d’information
 Ensemble organisé de ressources qui permettent de collecter, stocker, traiter
et distribuer de l’information.
 Plateforme applicative
 Solution logicielle intégrant un serveur d’applications logicielles et un serveur
de données.
 Accessible via un portail applicatif
 Serveur d’application
 Solution logicielle permettant l’exécution d’applications logicielles
 Serveur WEB
 Solution logicielle permettant l’exécution de sites WEB (requêtes et réponses
HTTP)
 Infrastructure informatique
 Ensemble de ressources logicielles et matérielles permettant d’héberger des
plateformes applicatives, comprenant les éléments de connexion (câbles),
les éléments de commutation (routeurs, commutateurs réseau) et les
éléments d’exécution (serveurs, PCs, smartphones, tablettes…)

Définitions
 Processus Client / Client process
 Processus demandant l’exécution d’une opération (requête) et récupérant le
résultat de cette opération (réponse)
 Processus Serveur / Server process
 Processus accomplissant l’exécution d’une opération demandée (requête) et
retournant le résultat de cette opération (réponse)
 Application logicielle / Software application
 Ensemble de processus client – serveur offrant un service à l’utilisateur
 Intergiciel / Middleware
 Processus créant un échange d’informations entre un client et un serveur
 Requête / Request
 Message transmis par un client à un serveur et demandant l’exécution d’une
opération
 Réponse / Response
 Message transmis par un serveur à un client suite à l’exécution d’une
opération, et contenant le résultat de cette opération

Vues du système d’information
 Une architecture d’un système d’information
d’une entreprise se décrit à l’aide de deux vues
principales:
 La vue « Système d’information »: traduit
l’organisation de l’entreprise (les rôles), les différents
processus et les différentes données manipulées par
ces activités
 La vue « Système informatique »: traduit
l’organisation de l’infrastructure informatique en
termes de composants logiciels (les services, les
applications, les bases de données) et de
composants physiques (serveurs d’application et
serveurs de bases de données)

Vues du système d’information
Fonction

Vue « Système d’information » :
La vue « Métier »
 La vue « Système d’information » se

décompose en deux sous-vues:
 La vue « Métier » permet de définir l’architecture
métier du SI
Vue Métier Vue Système informatique
Architecture métier

La vue « Métier »

 La vue « Métier » permet de définir l’architecture
métier du SI

La vue « Fonctionnelle »

 La vue « Fonctionnelle » permet de définir
l’architecture fonctionnelle du SI
 L’architecture fonctionnelle du SI découle de l’analyse
fonctionnelle du SI : chaque activité nécessite au
moins une fonction du système d’information
 Les fonctions sont reliées entre elles par les données
d’entrées / de sorties qu’elles manipulent
 La vue « Fonctionnelle » permet de définir la
cartographie fonctionnelle du SI en regroupant
les fonctions du SI par domaine fonctionnel
La vue « Fonctionnelle »

 La vue « Fonctionnelle » permet de définir
l’architecture fonctionnelle du SI
https://fr.slideshare.net/OCTOTechnology
/2012-pdj-banque-du-futur-2020

Vue « Système informatique » :
La vue « Application »
 La vue « Système informatique » se

 La vue « Application » permet de définir
l’architecture applicative du SI
 L’architecture applicative du SI découle de l’allocation
des fonctions du SI aux composants logiciels du SI.
 Les composants logiciels sont interconnectés entre
eux par les services qu’ils exposent / appellent.

La vue « Application »

 La vue « Application » permet de définir
l’architecture applicative du SI
https://www.togaf-modeling.org/models/application-
architecture/application-communication-diagrams.html

La vue « Technique »

 La vue « Technique » permet de définir
l’architecture physique du SI
 L’architecture physique du SI découle de l’allocation
des composants logiciels du SI aux composants
physiques du SI
 Les composants physiques sont interconnectés entre
eux par l’infrastructure réseau

La vue « Technique »

 La vue « Technique » permet de définir
l’architecture physique du SI
https://www.togaf-modeling.org/models/technology-
architecture/network-computing-hardware-
diagrams.html

Vues du système d’information :
Framework de Zachman
Vue « Métier »
Vue
« Fonctionnelle » +
Vue « Applicative »
Vue « Technique »

Exercice
 Architecture fonctionnelle

Architecture applicative :
Architecture en couche
Utilisateur
Couche de Présentation / Presentation Layer

• Interface utilisateur pour interagir avec l’application incluant la
logique de présentation de l’application
Serveur d’application
Couche de Traitement / Business Layer

• Ensemble des services intégrant la logique métier de l’application
Couche de Données / Data Layer

• Persistance et manipulation des données de l’application
données
Serveur
Données
de

Architecture en couche – C#
Utilisateur
WPF (Windows Presentation Foundation)
WCF (Windows Communication

Framework)
ADO .NET (ActiveX Data Object)
Données

Architecture en couche – Java
Utilisateur
OpenJFX (Open Java FX: https://openjfx.io/)
EJB (Enterprise Java Bean)
JPA (Java Persistence API)

JDBC (Java DataBase Connectivity)
Données

Architecture en couche – Responsabilité
 Découpage plus fin de l’architecture en couche pour

répartir les responsabilités entre les composants
logiciels d’une architecture applicative :
Présentation Traitement Données

[P] [T] [R]
Logique Accès aux

Visualisation
applicative ressources
[VP]
[AT] [AR]
Logique de Stockage des

Logique
présentation ressources
métier [MT]
[LP] [SR]

Architecture en couche – Présentation [P]
[VP] [VP] [VP]
[LP] [LP] [LP] [LP]
[LP] [LP]
MVC MVP MVVM
User input is processed by the User input is processed by the View first User input is processed by the View first
Controller first
One controller, multiple views One presenter, one view One view model, multiple views
View is not aware of the Controller View is aware of its Presenter View is not aware of its ViewModel
View is aware of the model View is not aware of the model View is not aware of the model

Modèle du Gartner Group
https://docplayer.fr/740447-Architecture-applicative-et-
cartographie.html
 Basé sur le modèle Client-Serveur

 Processus serveur offre un service à des processus client
 Processus client utilise un service fourni par le processus
serveur
 Processus client et processus serveur communique à
travers un protocole applicatif

Modèle du Gartner Group 2-tiers
[P] [VP]
Processus [T] [AT]

client
[AR]
[LP]
[MT]
Processus [SR] [R]

serveur

Modèle du Gartner Group 3-tiers
[P]
Processus
[AT]
client
[R]
Processus [T] [AT] [MT]

intergiciel /
middleware [R]
Le middleware est un client pour le serveur, et un serveur

pour le client
Processus [MT]
serveur
[R] [R]

Modèle du Gartner Group n-tiers
 Distribution des responsabilités sur plus de 3

tiers:
cartographie.html

Client léger, riche et lourd
 Client léger
 Le processus client est responsable du rendu graphique des
vues de la couche de présentation
 Le processus serveur est responsable d’agencer les vues entre
elles
 Classe 5 d’une architecture 2-tiers ou architecture n-tiers
cartographie.html

 Client riche
 Le processus client est responsable du rendu graphique
et de l’agencement des vues de la couche de
présentation
 Classe 4 d’une architecture 2-tiers ou architecture n-tiers

 Client lourd
 Client riche qui prend en charge tout ou partie des traitements
(logique applicative et/ou logique métier) jusqu’à l’accès aux
données
 Classe 1, 2 et 3 d’une architecture 2-tiers
 Exemple de classe 3 :

Client léger, riche et lourd – C#
Client Internet léger Client Internet riche

(Application Web) le client contrôle les vues via
le serveur contrôle les vues via le browser
le browser
ASP MVC ASP WebForms Silverlight WPF UWA XNA
Client Internet lourd

le client contrôle les vues via une application
XNA Game studio

(https://msdn.microsoft.com/e
n-us/library/bb203894.aspx)
.NET for Windows App

(https://msdn.microsoft.com/en-
us/library/windows/apps/br230232.aspx)

Client léger, riche et lourd – Java
Client Internet léger Client Internet riche

(Application Web) le client contrôle les vues via
le serveur contrôle les vues via le browser
le browser
JSF OpenJFX OpenJFX

JSP JSF OpenJFX
Java applet Java 2D Java 3D
Client Internet lourd

le client contrôle les vues via une application

Serveur d’application vs Serveur Web
Serveur WEB
 La fonction principale d’un serveur WEB est

délivrer une réponse statique à une requête.
 Il recherche dans des pages statiques
préalablement construites.
 Il peut s’appuyer sur des données externes pour
compléter ces pages statiques.

Serveur WEB
Navigateur WEB
Application métier
 La fonction principale d’un serveur d’application est d’offrir un contexte d’exécution pour des
composants logiciels afin de construire une réponse dynamique
 Cas 1: Le serveur WEB réceptionne la requête HTTP, et la passe au serveur d’applications s’il ne trouve
pas de pages statiques.
 Le serveur d’application construit dynamiquement la page et la retourne au serveur WEB
 Le serveur WEB renvoie la réponse au client
 Cas 2 : Le serveur d’application réceptionne une requête HTTP d’une application métier
 Le serveur d’application construit dynamiquement la réponse et la retourne à l’application métier

Critère Serveur Web Serveur d’application
Déploiement d’applications Oui Oui
Web / de service Web
Déploiement d’applications Non Oui
d’entreprise / de service
d’entreprise
Pool de connexion Non Oui
Gestion des files de Non Oui
messages
Gestion des transactions Non Oui
Gestion de cluster Non Oui
Gestion de la charge Non Oui
réseau

 Technologies pour un Serveur d’application :
 EJB (Enterprise Java Beans)
 COM+/DCOM (Microsoft)
 DCE (Distributed Computing Environment – Open Group)
 Technologies pour un Serveur Web :

Middleware
 Un middleware est un ensemble de composants
logiciels auquel les composants logiciels d’un
processus client se connectent via une interface pour
communiquer avec les composants d’un processus
serveur.
 Fonctions principales d’un middleware :
 Gestion des accès concurrents
 Monitoring de la charge réseau
 Connexion (ouverture / fermeture)
 Exécution des requêtes
 Envoi des réponses
 Sécurité
 Intégrité

Middleware et OSI
 Modèle Open Systems Interconnection [OSI]
Couches logicielles
Middleware
Couches matérielles

Middleware – Types
 Fonction de la technique d’échange d’informations

 Echange de messages : Message Oriented Middleware
 Exemple : JMS
 Appel de procédures : Procedural Middleware
 Exemple : RPC, SOAP
 Manipulation d’objets : Object Middleware
 Exemple : Distributed Component Object Model (DCOM –
Microsoft), Distributed Computing Environment (DCE – Open
Group)
 Réalisation de transactions : Transactional Middleware
 Exemple : Information Management System (IMS – IBM), MSDTC
(Microsoft Distributed Transaction Coordinator)

Middleware – Echanges de messages
 Asynchronisme
Processus client  Indépendance du
ACK ACK
format de données
Message
consumption reception
 Routage de
messages
File de
message  Persistance des
messages
Message
Processus serveur

Middleware – Appel de procédures
http://lig-membres.imag.fr/krakowia/Files/MW-Book/
 Synchronisme
 Sérialisation (Marshalling)
 « Binding » à l’aide d’un contrat de service (données et opérations)
identifié par l’adresse du serveur et son port

Middleware – Manipulation d’objets
 Synchrone : Remote Object Call
http://lig-
membres.imag.fr/krakowia/
Files/MW-Book/
 Asynchrone : Asynchronous Remote Method Invocation
http://web.itu.edu.tr/nerdogan/akin-
erdogan-europecomm2009.pdf

Middleware – Réalisation de transaction
 Une transaction est une
séquence d’opérations
élémentaires.
 Elle respecte les propriétés
ACID
 Le “transaction manager”
(TM) associe des identifiants
uniques aux transactions,
http://pubs.opengroup.org/onlinepubs/009680699/toc.pdf surveille leur exécution, et
assure leur terminaison.
 Une transaction est valide si
toutes les opérations sont
valides
 Chaque ressource est gérée
par un « ressource
manager » dédié
https://docs.particular.net/nservicebus/azure/understanding-
transactionality-in-azure

Middleware – Synthèse
Message Procedural Object Transactional
Oriented Oriented
Communication Asynchrone Synchrone Synchrone ou Synchrone ou
Asynchrone Asynchrone
Performance + - - -
Fiabilité / - - + +
Reliability
Flexibilité / - - - -
Scalability
Hétérogénéité / - + + -
Heterogeneity
Cas d’utilisation Réseau Réseau local Réseau Accès à des
étendu d’entreprise bases de
données
réparties

Architecture orientée service
Middleware
Middleware

 Service Oriented
Architecture (SOA)
 Architecture de
flux de données
entre différents
éléments distribués
appelés « service »
 Peut comporter
jusqu’à 13 classes
de service selon le
standard « SOA
Reference
https://publications.opengroup.org/c119 Architecture » de
l’Open Group
 Un service est un ensemble de composants logiciels
accessibles via une interface
 Un service a les caractéristiques suivantes :
 Large granularité / Coarse-grained
 Un service comporte plusieurs opérations sur un périmètre de
données larges
 Basé sur un contrat / Contract-based
 Un service comporte un point d’entrée décrivant l’accès à ces
opérations
 Localisable / Discoverable
 Un service est déployé de manière unique et doit pouvoir être
trouvé dans une infrastructure
 Couplage faible / Loosely-coupled
 Un service a une dépendance faible aux formats de données et à
l’infrastructure

 Un micro service est un service conçu pour une seule
fonction dans une application logiciel
 La caractéristique « Coarse-grained » est donc à
remplacer par « Fine-grained »
 Caractéristiques additionnelles
 Elastique / Elastic : il doit pouvoir gérer une augmentation de
charge / diminution de charge sans impacter les autres fonctions
de l’application logiciel
 Robuste / Resilient : sa défaillance ne doit pas avoir d’impact sur
le reste des fonctions de l’application logiciel
 Modulable / Composable : son contrat doit pouvoir être agrégé /
composé avec d’autres contrats de services de plus haut niveau
 Cohérent / Minimal : il doit avoir qu’une seule responsabilité vis-
à-vis de l’application logiciel (l’application logiciel ne doit pas
l’utiliser de deux façons différentes)

Architecture orientée WEB
 Web oriented architecture (WOA)

 Architecture orientée service pour le Web
 Basée sur les standards W3C
https://www.w3.org/TR/
ws-arch/#relwwwrest
Architecture orientée WEB
 Service Web est un service basé sur les standards W3C.
 Service Web de type RESTful :
 Representational state transfer (REST) : pas de sauvegarde de
l’état de session côté serveur
 Create Read Update Delete (CRUD) URIs
 HTTP pour le protocole de communication
 Service Web de type WS-* :
 eXtended Markup Language (XML) pour la description des
données
 Web Service Description Langage (WSDL) pour la définition de
son contrat
 Single Object Access Protocol (SOAP) pour l’accès aux
données et aux opérations
 HTTP pour le protocole de communication

Echange de données
 Un échange de données est représenté par un

flux ou un arc orienté de l’émetteur vers le
destinataire
 Différents types de flux au sein d’un système
d’information, en fonction de :
 La fréquence d’émission :
 En temps réel :
 Transmis dès que disponible
 Bonne pratique : temps de transmission <= 1 seconde (cas
critique)
 En temps différé :
 Transmis à des moments prédéterminés (événements unitaires
ou périodiques)
 Bonne pratique : temps de transmission > 1 seconde (cas
critique)

Echange de données

 Du mode d’abonnement :
 En pull
 Le processus client envoie une requête
 Le processus serveur répond par une réponse
 En push
 Le processus client écoute
 Le processus serveur pousse l’information
 En publish-subscribe :
 Le processus client s’inscrit pour obtenir certains types
d’information
 Le processus serveur publie les types d’information

Echange de données

 Du mode de connexion :
 Mode connecté
 Le processus serveur garde la connexion tant qu’un signal de
vie est reçu ou que la connexion n’est pas fermée par le
client ou que la connexion est toujours valable au niveau
réseau (même route, même adressage logique)
 Mode déconnecté
 Le processus client doit recréer la connexion pour chaque
séquence d’échange fonctionnel cohérent (ou transaction)
Réseaux informatiques 20/07/2020 - 52

Echange de données

 La présence ou non d’un acquittement applicatif
 La sauvegarde ou non d’informations liées au
contexte de l’échange de données (mécanisme
de session)

Sécurité
 L’architecture applicative doit prendre en

compte les principes Zero Trust:
 Assurer un accès sécurisé à toutes les ressources
 Adopter le principe du moindre privilège
 Contrôler et consigner l’intégralité du trafic
 Exemple d’architecture applicative Zero Trust
du NIST [Zero Trust Architecture]:

Sécurité
 L’architecture applicative doit isoler les

services exposés à d’autres systèmes
d’information, qu’ils soient dans l’entreprise
ou en dehors de l’entreprise
 Extension de la recommandation R11 du guide
ANSSI [Recommandations relatives à
l’interconnexion d’un système d’information à
Internet]

Sécurité

ressources critiques du système
d’information des ressources non critiques
 La criticité peut être déterminée par rapport au
métier, à l’organisation, à l’accès (interne ou
externe), à la règlementation et/ou à la
géographie.
l’administration sécurisée des systèmes
d’information]

Sécurité

services de production des services
d’administration
l’administration sécurisée des systèmes
d’information]

Exercice
 Architecture applicative

Déploiement d’applications / de services :
Container et cluster
 Déploiement d’applications / de services sur

un serveur dédié
 Exemple J2EE:

 Déploiement d’applications / de services sur

un ensemble de serveurs sur un même
réseau
 Création d’un cluster nécessitant des services
d’orchestration et de répartition de charges

https://docs.microsoft.com/fr-fr/dotnet/standard/microservices-architecture/architect-microservice-container-applications/scalable-available-multi-container-
microservice-applications

https://azure.microsoft.com/fr-fr/services/kubernetes-service

Container orchestration vs virtualization
https://newtglobal.com/containerisation-benefits-differs-virtualisation/

Enterprise Service Bus
 Middleware permettant l’échange de données

entre différents services implémentant
différentes technologies.

Everything as a Service

Everything as a Service :
Responsabilités

Architecture Cloud Computing
National Institute of Standards and Technology [NIST]

Special Publication 500-292 : NIST Cloud Computing Reference Architecture

Exercice
 Architecture physique

INFAL23 Architecture N Tiers Support

Transféré par

Informations du document

Titre original

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

INFAL23 Architecture N Tiers Support

Transféré par

Droits d'auteur :

Formats disponibles

CESI – INFAL23

 Découvrir le fonctionnement des différentes

Architecture n-tiers 20/07/2020 - 2

Architecture n-tiers 20/07/2020 - 3

Architecture n-tiers 20/07/2020 - 4

Architecture n-tiers 20/07/2020 - 5

Architecture n-tiers 20/07/2020 - 6

Architecture n-tiers 20/07/2020 - 7

 La vue « Système d’information » se

Architecture n-tiers 20/07/2020 - 8

 La vue « Système d’information » se

Architecture n-tiers 20/07/2020 - 9

 La vue « Système d’information » se

 La vue « Système d’information » se

Architecture n-tiers 20/07/2020 - 11

 La vue « Système informatique » se

Architecture n-tiers 20/07/2020 - 12

 La vue « Système informatique » se

Architecture n-tiers 20/07/2020 - 13

 La vue « Système informatique » se

Architecture n-tiers 20/07/2020 - 14

 La vue « Système informatique » se

Architecture n-tiers 20/07/2020 - 15

Architecture n-tiers 20/07/2020 - 16

Architecture n-tiers 20/07/2020 - 17

Couche de Présentation / Presentation Layer

Couche de Traitement / Business Layer

Couche de Données / Data Layer

Architecture n-tiers 20/07/2020 - 18

WPF (Windows Presentation Foundation)

WCF (Windows Communication

ADO .NET (ActiveX Data Object)

Architecture n-tiers 20/07/2020 - 19

OpenJFX (Open Java FX: https://openjfx.io/)

EJB (Enterprise Java Bean)

JPA (Java Persistence API)

Architecture n-tiers 20/07/2020 - 20

 Découpage plus fin de l’architecture en couche pour

Présentation Traitement Données

Logique Accès aux

Logique de Stockage des

Architecture n-tiers 20/07/2020 - 21

[VP] [VP] [VP]

[LP] [LP] [LP] [LP]

MVC MVP MVVM

Architecture n-tiers 20/07/2020 - 22

 Basé sur le modèle Client-Serveur

Architecture n-tiers 20/07/2020 - 23

Processus [T] [AT]

Processus [SR] [R]

Architecture n-tiers 20/07/2020 - 24

Processus [T] [AT] [MT]

Le middleware est un client pour le serveur, et un serveur

Architecture n-tiers 20/07/2020 - 25

 Distribution des responsabilités sur plus de 3

Architecture n-tiers 20/07/2020 - 26

Architecture n-tiers 20/07/2020 - 27

Architecture n-tiers 20/07/2020 - 28

Architecture n-tiers 20/07/2020 - 29

Client Internet léger Client Internet riche

ASP MVC ASP WebForms Silverlight WPF UWA XNA

Client Internet lourd

XNA Game studio