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.
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
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
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
Les contraintes semblent inversées par rapport à celles rencontrées avec les architectures deux tiers : le client
est soulagé, mais le serveur est fortement sollicité. Le phénoméne fait penser à un retour de balancier.
et il est difficile de répartir la charge entre client et serveur
C ambigu
La distribution des services applicatifs facilite aussi l'intégration de l’existant (EAI : Entreprise Application Integration) dans les nouvelles applications.
Une facture, un bon de commande ou tout autre objet nécessitant d'être stocké en base.. Cette couche assure l'indépendance totale entre le client et le type de stockage utilisé (SGBDR, SGBDO, fichiers XML, ...). Le client doit posséder uniquement une vue sur un objet avec l'ensemble de ces attributs et non un éventuel curseur (ResultSet et RecordSet) pointant vers une ligne d'une quelconque base. Cette couche est en étroite collaboration avec la couche de persistance qui assure la création des objets métier de manière totalement transparente.
ERP: Progiciel (Produit + logiciel) (produit sur mesure)Progiciel de gestion intégré (PGI) (en anglais Enterprise Resource Planning ou ERP) est, selon le grand dictionnaire terminologique, un « logiciel qui permet de gérer l'ensemble des processus opérationnels d'une entreprise, en intégrant l'ensemble des fonctions de cette dernière comme la gestion des ressources humaines, la gestion comptable,financière, mais aussi la vente, la distribution, l'approvisionnement, le commerce électronique. »
CRM :
De cette façon, la durée de vie des objets n’est pas limitée à la durée de vie d’une session applicative.
synchronisation de l’état des objets sur un support de persistance (base de données), afin d’assurer la sauvegarde durable de l’état des objets.
non seulement de mieux gérer la montée en charge en autorisant la répartition des requêtes des applications clientes sur plusieurs machines, mais également
Il faut commencer la partie JEE avec une bonne introduction sur la programmation par composant
Animer cette figure
Structure et architecture de l’application peu visibles
Interactions entre objets enfouies dans le code
Évolution / modification difficile
Recherche des bouts de code impliqués source d’erreur
Gestion de la consistance d’un changement délicate
J’aurais besoin de parler de composants qui sont jusqu’à mnt non définis ??? Je pense qu’il faut précéder ce diapo par une explication de qu’est ce qu’un composant !
description de variables d'environnement (placement, regroupement, sécurité, etc.)
l’introspection: fonctions pour découvrir les fonctions et les connecteurs des composants (structure)
Peut etre qu’il faut enrichir cette partie qui parle sur l’introspection et la reflexion (reflexivité en donnnant des exemples)
Animer la figure
Structures d’accueil :
Elles servent de médiateur entre les conteneurs et les services systèmes (sandbox).
Certaines peuvent prendre en charge le téléchargement de code additionnel (navigateur web…).
La Java Virtual Machine est la structure d’accueil d’une application J2EE.
- Il faut bien comprendre : Intropection, Serialisation, EJB 3 vs EJB2…
Un conteneur doit être généré automatiquement !!!
Tu peux enrichir cette partie en mettant d’autres concepts sur les composants (cycle de vie, structure d’un conteneur, controleur…)