Les architectures n-tiers visent à surmonter les limitations des architectures 3-tiers en répartissant la logique applicative sur plusieurs services, permettant ainsi une meilleure gestion des charges. Cette architecture se compose de plusieurs couches, dont la présentation, l'application, les objets métier et l'accès aux données, afin de faciliter le développement et la maintenance des applications. Des serveurs d'objets métier sont nécessaires pour gérer ces objets, assurant des services essentiels tels que la gestion des transactions et la sécurité.

1. Les architectures n-tiers

2. Synthèse
2
 Avantages
 Déploiement immédiat
 Evolutions transparentes pour l'utilisateur
 Caractéristiques du poste client libres
 Limites
 Le serveur d’application réalise la majorité des
traitements
 Problème de gestion de la montée en charge
rappelant l'époque des mainframes
 le client est soulagé, mais le serveur est fortement sollicité
L’équilibrage de la charge entre client et serveur semble
atteint avec la génération suivante :
Les architectures n-tiers

3. Présentation
3
 Objectif : pallier aux limitations de
l’architecture 3-tiers et concevoir des
applications puissantes et simples à
maintenir.
 Solution : distribuer la logique applicative
pour une meilleure répartition de la charge
entre tous les niveaux.

4. Présentation
4

5. Présentation
5
 Toujours 3 niveaux d’abstraction : n-tiers ne
signifie pas un nombre indéterminé de niveaux
de service
 L'architecture n-tiers qualifie la distribution de la
logique applicative entre de multiples services
 La distribution est facilitée par l'utilisation de
composants
 Un composant rend un service, si possible,
générique et clairement identifié.
 Les composants sont capables de communiquer
entre eux et peuvent donc coopérer en étant
implantés sur des machines distinctes.

6. Les couches de l’arch. n-tiers
6
 Une architecture n-tiers comprend généralement une
couche de présentation, une couche applicative, une
couche objets métier et une couche d'accès aux
données

7. Les couches de l’arch. n-tiers
7
 La couche de présentation contient les différents types de
clients léger (JSP, ASP…) et lourd (Swing, WinForm…)
 La couche applicative contient les traitements représentant
les règles métier (créer un compte, rechercher un client,
calculer une facture, ...)
 La couche d'objets métier est représentée par les objets
du domaine, c'est à dire l'ensemble des entités
persistantes de l'application (Facture, Bon de Commande,
Client, ...)
 La couche d'accès aux données contient les usines
d'objets métier, c'est à dire les classes chargées de créer
et manipuler des objets métier de manière totalement
transparente, indépendamment de leur mode de stockage
(SGBDR, ERP, Fichiers XML, ...)

8. Objet métier : qu’est ce que
c’est ?
 Un objet métier est un concept ou une abstraction
ayant un sens pour des acteurs (partie prenante
interne) d’une organisation (entreprise)
 L’objet métier permet de décrire les entités
manipulées par les acteurs dans le cadre de la
description du métier.
 Exemple
 Mon métier consiste à gérer les comptes bancaires de mes
clients
 Les objets métier sont le compte bancaire, le client.
 Les objets métiers sont représentés par l'ensemble
des objets persistants du domaine de l'application.
 Une facture, un bon de commande ou tout autre objet
nécessitant d'être stocké en base.

9. La couche d'objets métiers
9
 Il existe deux méthodes pour accéder aux
données:
 La première consiste à accéder directement aux
sources de données.
 La deuxième méthode consiste à s'appuyer sur
des objets métier (client, fournisseur, facture ...)
afin de masquer la complexité d'accès aux
données.
 La couche objet métier assure l'indépendance
totale entre le client et le type de stockage
utilisé (SGBDR, SGBDO, fichiers XML, ...).

10. La couche d'objets métiers
 Exemple:
 Un objet AssuréSocial possédera par exemple
une méthode débit() et une méthode crédit() qui
à chaque appel iront modifier les données dans
 une ERP (Entreprise Resource Planning),
 un système de CRM (Customer Relation Ship
Managment),
 des fichiers XML
 ou une base de données.

11. Serveur d’objets métier
11
 Pour gérer ces objets métier, un
environnement d'exploitation est nécessaire :
le serveur d'objets
 Fournit les services essentiels suivants:
 Gestion du cycle de vie des objets :
 fonctionnalités de base permettant la création, la
recherche, la manipulation, et la destruction des objets
 Gestion de la persistance :
 synchronisation de l’état des objets sur un support de
persistance afin d’assurer la sauvegarde durable de
l’état des objets

12. Serveur d’objets métier
 Gestion des transactions :
 permet d’assurer l’intégrité des données et de gérer la
concurrence d’accès (basé sur les propriétés ACID)
 Gestion de la montée en charge :
 mécanismes (pools d’objets, cache transactionnel, etc.…)
pour améliorer les performances des applications accédant
de manière concurrente aux objets
 Gestion de la sécurité :
 mécanismes d’authentification et de contrôle d’accès aux
objets
 définition de permissions sur les opérations de lecture, de
mise à jour, et sur les appels aux traitements métier permet
de définir des restrictions d’accès basées sur la définition de
groupes d’utilisateurs et de rôles

13. Serveur d’objets métier
14
 Les principaux serveurs d'objets:
 Corba de OMG
 Microsoft DCOM de .NET
 EJB (Enterprise Java Beans) de JEE

14. Programmation orientée objet - Limites
« programming in the small »
 tout est la la charge du programmeur
 construction des différents modules
 définition des instances
 interconnexions des modules
 structure de l’application peu visible
 ensemble des fichiers de codes nécessaire
 évolution/modification difficile
 changement du mode de communication
 évolution, ajout, suppression de fonctionnalités
 modification du placement
 développement, génération des exécutables,
déploiement
 pas ou peu d’outils pour les applications réparties

15. Objets et encapsulation
 Granularité trop fine
 Mal adaptée à la programmation à grande échelle
 Couplage fort
 Rend difficile la réutilisation
 Accroît la complexité des systèmes orientés objets

16. Composants logiciels
 Analogie avec les composants électroniques,
legos, puzzles
 Plus de structuration

17. Programmation orientée composant
« Programming in the large »
 Motivation : réutilisation de logiciel
 intégration de modules logiciels existants
 construction d'applications réparties par assemblage
de modules logiciels existants
 programmation à gros grain ("programming in the
large")
 Approche : description de l'architecture de
l'application à l'aide d'un langage déclaratif
 séparation de l’interface/implémentation
 modèle de construction des composants
 Composants: interfaces, attributs, implémentation
 description des interactions entre composants
(connecteurs)

18. Composants : définition
 Définition
 module logiciel autonome
 unité de déploiement (installation sur différentes plates-formes)
 unité de composition (combinaison avec d’autres composants)
 Propriétés
 spécifie explicitement la ou les interface(s) fournie(s) (attributs,
méthodes)
 spécifie explicitement la ou les interface(s) requise(s) pour son
exécution
 peut être configuré
 capable de s’auto-décrire (Introspection)
 Intérêt
 permettre la construction d’applications par composition de
briques de base configurables
 séparer les fonctions des fournisseur et d’assembleur (conditions
pour le développement d’une industrie des composants)

19. Exemple: application de e-
commerce
Interface Utilisateurs Logique Application et
Transaction
Logique Données
Serveur de
Paiement
Navigateur
Client
Caddie
Applet
Java
Serveur
d’Application
Composant
Paiement
Composant
Catalogue
Composant
Commande
Serveur de données
Validation Commande

20. Composant : modèle génerique
Interfaces
requises
Interfaces
fournies
Contraintes techniques
Propriétés configurables
placement, sécurité
accès transactionnel, Persistance
interfaces fournies par le système (bibliothèques,
etc.)
fournies par
d'autres composants
Méthodes, attributs
interfaces spéciales avec accès restreint

21. Composants : utilisation
 Composition hiérarchique et encapsulation
 composants construits, sous-composants
 Interconnexion de composants
 connecteurs, ou objets de communication

22. Composants : utilisation
24

23. Support logiciel pour
composants
 Pour assurer leurs fonctions, les composants ont
besoin d’un support logiciel: conteneurs et structures
d’accueil
 Conteneur
 encapsulation d’un composant
 prise en charge des services du système
 nommage, sécurité, transactions, persistance, etc.
 prise en charge partielle des relations entre composants
(connecteurs)
 invocations, événements
 techniques utilisées : interposition, délégation
 Les appels des composants transitent par le conteneur qui y répond
lorsqu’il en a la charge ou les transmet au destinataire.
 Structure d’accueil
 espace d’exécution des conteneurs et composants
 médiateur entre conteneurs et services du système

24. Support logiciel pour
composants