Michaël Mrissa - michael.mrissa@iut.univ-lyon1.fr. Architectures n-tierintroduction

Transcription

1 Architectures n-tier Introduction

2 Architecture: Définition Définition...la structure des composants d un programme/système, leurs interrelations et les principes et lignes directrices gouvernant leur conception et leur évolution au fil du temps. [Garlan,1995] Synthétise un système complexe Plusieurs composants, règles de communication, contraintes globales, niveaux de complexité Lien entre le modèle abstrait et la mise en œuvre Facilite l évolution et l ajout de composants

3 Architectures distribuées Applications réparties sur le réseau Fonctionnalités réparties sur le réseau Point de vue physique: client(s)/serveur(s)? Plusieurs niveaux Découpage physique (tiers) 2, 3 tiers + réplication ou serveurs dédiés Découpage logique (tier) N tier, pas forcément lié à la répartition physique Un support: le Web Évolution du Web Pages Web statiques (HTML, CSS,... ) Web dynamique, scripts (ASP, PHP, Javascript,... ) Web orienté Services (Javabeans, services Web,... )

4 Évolution des architectures - Niveau Physique 2 tiers: client/serveur Très classique, le même composant serveur fait tout Côté client pauvre, maintenance + évolution difficile 3 tiers: client/application/ressource Client: présentation, interactions utilisateur Application: traitement des données (validation requêtes, traitement des processus métiers, etc...) Ressource: stockage et accès aux données (SGBD) Déploiement lié à la charge (réplication), à la sécurité (serveur dédié, pare-feu), etc...

5 Évolution des architectures - Niveau logique Côté client Navigateur Web avec plugins (applets (JVM), javascript, flash) Client service Web ou client adhoc Côté serveur: plusieurs composants Liés aux différents processus métiers Présentation Traitement (mise à jour, gestion sécurité & co) Accès aux données Si plusieurs sources de données, peut en soi former une architecture distribuée reposant sur le Web Client lourd/léger (avantages inconvénients?) Déploiement des composants côté serveur? côté client? modèle de Gartner

6 Architecture n-tier Exemple Java Figure: Architecture Web J2EE Source :

7 Challenges des architectures n-tier Performance temps de réponse moyen Fiabilité, disponibilité résistance à la charge, maintien de la qualité de service Facilité d utilisation, interopérabilité compatibilité applications extérieures Sécurité authentification, intégrité, confidentialité, non-répudiation Évolutivité facilité de maintenance, d ajout de fonctionnalités

8 Côté serveur - Tier Présentation Gestion des requêtes Interception, validation et transformation des données Redirection vers les autres composants Envoi de message, génération code HTML et messages HTTP Gestion des sessions utilisateur Adaptation à différents clients Technologies utilisées Anciennement CGI, FastCGI PHP, ASP, JSP (Java Server Pages), Python, Perl, Ruby,... Java servlets, même javascript (côté serveur) Java fournit de nombreuses APIs Plateformes J2EE,.NET, etc...

9 Côté serveur - Tier application Fonctionnalités à fournir Gestion des composants, tolérance aux fautes, disponibilité, balance de charge Fonctions d administration, transactions, sécurité Plusieurs types de serveurs Serveurs Web Information Pas de transactions, sans états, accès au tiers ressource Exemples: ASP, PHP, Python, CGI Serveurs à base de composants Transactions gérées, sans états, accès au tiers ressource Présents dans les serveurs d application Serveurs d applications Environnements complets de développement Gère les transactions, avec états, accès données Supporte la business logic à l aide de composants.net Entreprise servers, J2EE (Websphere, Weblogic, Jboss...)

10 Côté serveur Tier ressource Accès aux ressources Plusieurs types de ressources hétérogènes Bases de données JDO, SQL/J, JDBC, ADO.NET Legacy systems (systèmes propriétaires) J2EE connector, protocoles propriétaires ERP (Entreprise Resource Planning) J2EE connector, protocoles propriétaires EAI (Entreprise Application Integration) J2EE connector, protocoles propriétaires Services Web Java JAX/RPC, WSDL4J, juddi

11 Challenges technologiques Communications entre composants distribués & hétérogènes Notion de middleware (intergiciel) La glue entre les différents composants Répartition logique/physique (et C/S) Compréhension des nouvelles technologies Coût (financier, temps) Installation du serveur d application Modélisation des objets et processus métiers Écriture et maintenance d un code évolutif et réutilisable Maintenance du serveur d application

12 Design Patterns & Frameworks Motivation/Avantages Gain en temps, modularité, extensibilité, performance... Ecriture des programmes + simple & réutilisation des fonctionnalités transversales (transaction, sécurité, session, etc...) Un but commun: promouvoir la réutilisation Définition: Design Patterns Méthodes de résolution abstraite des problèmes Définition: Frameworks Squelettes architecturaux de développement des composants

13 Design patterns Objectif Résoudre des problèmes de programmation bien connus Les clés de la réussite sont dans les démarches de résolution de problèmes Méthode de résolution de problème Comme pour les échecs Apprendre les règles Apprendre les principes/méthodes Apprendre les coups spéciaux (patterns) Design pattern = transmission générique des démarches de résolution Ensuite, adaptation aux domaines d applications Il existe des centaines de patterns Différents types: architectural, analysis,creational, structural, behavioral patterns Observer, factory, prototype, singleton, etc... Design Patterns: Elements of Reusable Object-Oriented Software [GoF]

14 Patterns dans J2EE Tier présentation Intercepting filter, front controller, view helper, composite view, service to worker, dispatcher view Tier applicatif Business delegate, value object, session facade, composite entity, value object assembler, value liste handler, service locator Tier ressource Data access object, service activator

15 Frameworks Applications semi-complètes (squelettes) Proposent des composants pré-paramétrés Proposent une organisation du code Instanciés lors du développement Peuvent suivre des design patterns particuliers (MVC) Fonctionnalités spécifiques Support de différents OS, middleware, accès aux données, etc Proposent l inversion de contrôle IoC: attente passive de la réalisation d un évènement pour appeler le code Prise en charge de certains aspects par le framework Quelque difficultés liées à l IoC...(contrôle des suites d actions) Implémentation pour tous les langages/plateformes

16 à suivre... Aspects développement Modèle de développement: design pattern MVC Frameworks de développement Favorise la séparation des préoccupations MVC: modèle/vue/contrôlleur Design patterns (best practices) IoC: inversion of control DI: dependency injection Notion de middleware EJB, J2EE,.NET, Web services, CORBA, RMI, etc