Architecture J2EE gfgfgfggf Khin Chhoung LAO, Cnam.

Présentation au sujet: "Architecture J2EE gfgfgfggf Khin Chhoung LAO, Cnam."— Transcription de la présentation:

1 Architecture J2EE gfgfgfggf Khin Chhoung LAO, Cnam.

2 Introduction Java a permis la création de nouveaux modèles et technologies de programmation concernant des aspects aussi variés que des équipements. En parallèle, Java a joué le rôle de catalyseur en renforçant ou en définissant plus précisément certains domaines technologies, comme la plate-forme Java 2 Édition Entreprise (J2EE).

3 Les besoins des entreprises
Capacité de réaction L ’économie actuelle qui se nourrit d ’information à un rythme de plus en plus vertigineux exige des réactions rapides aux nouvelles orientations afin de prendre et de garder l ’ascendant sur les concurrents. Productivité élevée en programmation Il faut savoir utiliser pleinement les nouvelles technologies et les combiner harmonieusement avec d ’autres technologies. Il faut avoir la capacité à développer, puis déployer des applications de manière efficace et rapide.

4 Les besoins des entreprises (suite)
Fiabilité et disponibilité Dans le monde de l ’économie électronique actuel, les temps d ’immobilisation peuvent causer la perte d ’une entreprise. Il est indispensable que vos opérations basées sur le web fonctionnent en permanence. Vous devez être capable de garantir la fiabilité de vos transactions commerciales. Sécurité Internet a non seulement permis d ’accroître de façon exponentielle le nombre des utilisateurs potentiels, mais il a aussi multiplié la valeur des informations détenues par les sociétés, d ’où l ’importance d ’assurer leur confidentialité.

5 Les besoins des entreprises (suite)
Évolutivité Il est important qu ’une application puisse se développer pour faire face aux exigences. Pour s ’adapter de façon efficace, l ’application doit pouvoir gérer une montée en charge du nombre des utilisateurs et utiliser de manière optimale les ressources du système. Intégration Les applications doivent être en mesure d ’intégrer les systèmes d ’informations existants. C ’est dans la capacité d ’une entreprise à combiner les anciennes et les nouvelles technologies que réside la clé de son succès.

6 Architecture système Les systèmes client-serveur classiques s ’appuient sur une architecture à deux niveaux permettant de séparer nettement les données et la logique de présentation/ logique métier. Ces systèmes appuient généralement sur l ’utilisation des données. L ’application réside entièrement sur le poste client et la base de données est hébergée sur un serveur situé quelque part dans l ’entreprise. Même si une telle approche nous permet de partager les données au sein d ’une entreprise, elle présente de nombreux inconvénients.

7 Architecture à deux niveaux
Dans une application classique à deux niveaux, la charge de traitement est attribuée au poste client tandis que le serveur se contente de contrôler le trafic entre l ’application et la base de données. Par conséquence, les performances de l ’application baissent du fait des ressources limitées du PC. L ’approche à deux niveaux pose un problème de la maintenance. En effet, la moindre modification apportée à l ’application peut avoir des répercussions sur la totalité de la base utilisateur.

8 Architecture à deux niveaux
Appliation DB

9 Architecture à trois niveaux
Pour éliminer les inconvénients d ’architecture à deux niveaux, on a crée la notion d ’architecture à 3 niveaux. Ainsi, une application est divisée en trois niveaux logiques distincts, chacun d ’entre eux étant pourvu d ’un ensemble d ’interface bien défini. 1: Niveau présentation 2: Niveau métier 3: Niveau données.

10 Architecture à trois niveaux (suite)
Interface utilisateur Logique applicative DB DB DB Doc XML

11 Architecture à trois niveaux (suite)
Niveau présentation : Il est généralement constitué d ’une interface utilisateur graphique. Il reçoit les données et les formate en vue de leur affichage. Cette séparation de la logique applicative de l ’interface accentue considérablement la souplesse de conception de l ’application.

12 Architecture à trois niveaux (suite)
Niveau métier (logique applicative) : Il recouvre la logique métier et logique applicative.

13 Architecture à trois niveaux (suite)
Niveau données : Ce niveau abrite les données nécessaires à l ’application. Il peut s ’agit sur n’importe quelle source d ’information : Oracle, Sybase, Jeu de document XML etc..

14 Architecture multiniveaux
Il n ’existe pas de solution toute faite pour définir les niveaux applicatifs d ’un système multiniveaux. En réalité, un système multiniveaux peut supporter différentes configurations. Au sein d ’une architecture multiniveaux, la logique applicative se décompose selon les fonctions.

15 Architecture multiniveaux (suite)
Cette architecture se subdivise donc de la façon suivante : Interface utilisateur Logique de présentation logique métier services d ’infrastructure Niveau données.

16 Architecture multiniveaux (suite)
Interface utilisateur chargée de gérer les interactions entre l ’utilisateur et l ’application. Service d ’infrastructure Qui fournissent des fonctionnalités supplémentaires nécessaires aux composants de l ’application, tels qu ’un service de messagerie, de support transactionnel, etc..

17 Architecture d ’entreprise
Pour transformer un système multiniveaux en un système d ’entreprise, il suffit d ’étendre le niveau intermédiaire de sorte qu ’il accueille plusieurs objets applicatifs plutôt qu ’une application unique. Ces objets applicatifs doivent être pourvus d ’une interface leur permettre de coopérer les uns avec les autres.

18 Architecture d ’entreprise (suite)
Tout système capable de présenter des données Formulaire HTML (Navigateur) Appet Java (Navigateur) Interface Composant applicatif Interface Composant applicatif Interface Composant applicatif Middleware de base de données DB Documents XML Système distant DB

19 Architecture d ’entreprise (suite)
Il est important de noter que, lors de la conception d ’un objet et de son interface, il est conseillé d ’opter pour une interface aussi générique que possible afin d ’échapper aux risques de modifications ultérieures.

20 Les différentes solutions
Microsoft : DNA (.net) Sun : J2EE Oracle : Oracle 8i Internet Platform etc..

21 Java Indépendance de la plate-forme :
Dans une entreprise, les informations sont réparties entre différentes plate-formes et applications. Il est important de disposer d ’un langage de programmation capable de fonctionner n ’importe où dans l ’entreprise sans avoir devoir passer par des mécanismes de translation inefficaces et compliqués.

22 Java (suite) Réutilisabilité :
Réutiliser le code représente le but ultime à atteindre pour tout programmeur. Java est un langage orienté objet doté, de mécanismes de réutilisation.

23 Java (suite) Modularité :
Les servelets Java, les JavaServer Pages (JSP) et les Entreprise JavaBeans (EJB) vous permettre de modulariser votre application en la décomposant en niveaux et en tâches.

24 Qu ’est ce que J2EE ? J2EE est essentiellement un environnement serveur d ’applications distribuées.

25 Qu ’est ce que J2EE ? (suite)
C ’est à dire, un environnement Java fournissant les outils suivants: une infrastructure d ’exécution pour héberger des applications . Un ensemble d ’API d ’extension Java pour concevoir des application.

26 La Plate-forme J2EE Cette plate-forme est de fournir un standard simple et unifié, destiné aux applications via un modèle applicatif basé sur des composants.

27 La Plate-forme J2EE (suite)
J2EE spécifie les rôles et les interfaces pour les applications, ainsi que l ’environnement d ’exécution dans lequel les applications pourraient être déployées. Il en résulte une séparation claire entre les applications et l ’infrastructure d ’exécution.

28 La Plate-forme J2EE (suite)
J2EE ne spécifie ni la nature ni la structure de l ’environnement d ’exécution. Il introduit un conteneur et, via les API J2EE, il élabore un contrat entre les conteneurs et les applications.

29 Les API J2EE Les applications distribuées doivent avoir accès aux services distribués. De tels services comprennent le traitement des transactions, l ’accès aux bases de données, la messagerie etc.. L ’architecture J2EE unifie l ’accès à ces services au sein des API de ses services d ’entreprise.

30 Les API J2EE (suite) Toutefois, plutôt que d ’avoir accès à ces services au travers d ’interfaces propriétaires ou non standard, les applications J2EE peuvent accéder à ces API via le conteneur. Une plate-forme commerciale (ou un serveur d ’application) J2EE typique comprend un ou plusieurs conteneurs et a accès aux API d ’entreprise spécifiées par J2EE.

31 Les API J2EE (suite) La plate-forme J2EE doit prendre en charge:
l ’extension JAVA DataBase Connectivity (JDBC) le protocole standard Remote Method Invocation over the Internet Inter-ORB (RMI-IIOP). Il permet aux applications RMI et CORBA de se rejoindre.

32 Les API J2EE (suite) Entreprise Java Beans (EJB) 1.1, il fournit moyen standard pour définir les composants coté serveur. Java Servelets 2.2, il fournit une couche d ’abstraction orientée objet dans le cadre de l ’élaboration d ’applications WEB dynamiques. JavaServer Pages (JSP) 1.1, il permet de valoriser davantage les applications WEB J2EE en permettant le développement d ’applications Web basées sur les modèles.

33 Les API J2EE (suite) Java Message Service (JMS) 1.0, il permet d ’accéder à un service de messages et de publier et souscrire à divers types de services middleware orientés message. Java Naming and Directory Interface (JNDI) 1.2, il normalise l ’accès aux différents services de nommage et d ’annuaire.

34 Les API J2EE (suite) API Java Transaction 1.0, il est chargée de la mise en œuvre d ’applications distribuées transactionnelles. Java Mail 1.1, il conçoit des applications de courrier électronique basées sur Java.

35 Qu ’est ce un Conteneur J2EE ?
C ’est un environnement d’exécution chargé de gérer des composants applicatifs et de donner accès aux API J2EE. En d ’autres termes, des instances des composants applicatifs sont créés et invoquées à l’intérieur de la JVM( Java Virtuel Machine) du conteneur.

36 Architecture de J2EE Conteneur web Conteneur EJB DB EJB
Servlet Java EJB Page JSP Les API : JDBC, JAVA MAIL, RMI etc.. Les API: JDBC, JAVA MAIL, RMI etc.. Serveur d ’applications J2EE Clients applicatifs DB

37 Un Conteneur J2EE Avec J2EE, le totalité des composants applicatifs sont instanciés et initialisé dans la JVM du conteneur.

38 L ’architecture typique d ’une application web :
Conteneur Web Http Entrepôt de données JSP Navigateur Servlet HTML, XML