Architectures n-tiers

3 080 vues

Publié le

Présentation des architectures n-tiers en mettant l'accent sur la notion de composant

Publié dans : Formation
0 commentaire
3 j’aime
Statistiques
Remarques
  • Soyez le premier à commenter

Aucun téléchargement
Vues
Nombre de vues
3 080
Sur SlideShare
0
Issues des intégrations
0
Intégrations
5
Actions
Partages
0
Téléchargements
0
Commentaires
0
J’aime
3
Intégrations 0
Aucune incorporation

Aucune remarque pour cette diapositive
  • 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…)
  • Architectures n-tiers

    1. 1. Les architectures n-tiers
    2. 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. 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. 4. Présentation 4
    5. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 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. 16. Composants logiciels  Analogie avec les composants électroniques, legos, puzzles  Plus de structuration
    17. 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. 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. 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. 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. 21. Composants : utilisation  Composition hiérarchique et encapsulation  composants construits, sous-composants  Interconnexion de composants  connecteurs, ou objets de communication
    22. 22. Composants : utilisation 24
    23. 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. 24. Support logiciel pour composants

    ×