Architecture J2EE gfgfgfggf Khin Chhoung LAO, Cnam.

Slides:



Advertisements
Présentations similaires
Lundi 21 mars 2011 Un réseau social pour Entreprise Jean-Luc Walter Patrick de Dieuleveult.
Advertisements

Global Total Microcode Support (TMS ou GTMS) Microcode Management proactif pour System i, System p, System x et SAN.
Internet et le client- serveur Licence Pro IE Cours Internet / Intranet Le Web HTML Protocoles Le client universel Contenus dynamiques.
Cours 5 : XML et les architectures N-tier Janvier Version 1.0 -
Nouveautés pour les développeurs Office System Scott Burmester Responsable des programmes PSPS.
Xavier Blanc Web Services Xavier Blanc
Introduction aux environnements répartis
Première expérience d’utilisation des Web Services dans SmartTools Didier Parigot Projet OASIS INRIA Sophia www-sop.inria.fr/oasis/SmartTools Journée.
Introduction aux réseaux informatiques
Serveur jeu Le serveur fait partie d'un logiciel de jeu en ligne multi joueur en architecture client serveur. Il répond à des demandes.
L’architecture .net et ASP.net
Exposé de Système - Informatique et Réseau
Le développement d’applications sous Lotus Notes
Vue d'ensemble Implémentation de la sécurité IPSec
Cours 6 : XML et les architectures N-tiers – Tier Applicatif
1 Les technologies XML Cours 1 : Les Web Services et Architectures Orientées Services Fé vrier Version 1.0 -
51 Les technologies XML Cours 7 : Utilisations dXML Janvier Version 1.0 -



Stéphane Frenot - Département Télécommunication - SID - II - Comp 312 Avantages de l'approche distribuée Economie Performance.
UV J2EE Module Java Expert
NFE 107 : Urbanisation et architecture des systèmes d'information
Programmer avec Java EE
Introduction aux services WEB
LOG 02 Bases de Données Avancées Rappels sur JSP / Servlet
Control des objectifs des technologies de l’information COBIT
Etude des Technologies du Web services
SECURITE DU SYSTEME D’INFORMATION (SSI)
JAVASERVER FACES Un framework Java pour le développement Web.
Amélioration de la sécurité des données à l'aide de SQL Server 2005
Réalisée par :Samira RAHALI
7 - EAI Les EAI : Enterprise Application Integration Marché
Programmation Approche composants Ing5 SI
Le protocole FTP.
Interopérabilité JOnAS - CORBA
Gestion des bases de données
An Introduction to distributed applications and ecommerce 1 1 Les services Web, XML et les places de marchés.
Document élaboré à Centrale Paris par Pascal Morenton LES TECHNOLOGIES DU WEB 1. LES PHASES D UN DEPLOIEMENT DE RESEAUX 2. LE LANGAGE HTML 3. LE LANGAGE.
Adaptée du cours de Richard Grin
J2EE vs .NET Réaliser par : SEIF ENNACER BADRA && CHETOUI RIM.
Patrons de conceptions de créations
JEE 5 F.Pfister 2 institut eerie JEE – Une plateforme serveur  Développement et exécution d'applications réparties.
L’architecture J2EE
1 - Architecture Internet
4 - Annuaires Les Annuaires d ’Entreprises Offres et solutions
SGBD orientés Objet Standards : OMG et ODMG.
Internet et le client- serveur Licence Pro IE Cours Internet / Intranet Le Web HTML Protocoles Le client universel Contenus dynamiques.
Présentation de CORBA et de IIOP
1 Architecture orientée service SOA Architecture orientée service SOA (Service Oriented Architecture)
Java Enterprise Edition, anciennement J2EE
Contenus riches et logique d'industrialisation Contenus riches et logique d'industrialisation Modélisation, production, génération, gestion Stéphane Crozat.
E-Technology lab Plateformes, Technologies et Architectures pour les systèmes eGouvernement Par: Dr Mamadou Koné Université Laval, Québec, Canada et Houda.
Expose sur « logiciel teamviewer »
Le contenu est basé aux transparents du 7 ème édition de «Software Engineering» de Ian Sommerville«Software Engineering» de Ian Sommerville B.Shishedjiev.
Introduction à la plateforme .NET
Enterprise Java Beans 3.0 Cours INF Bases de Données Hiver 2005, groupe 10 Stefan MARTINESCU.
Le web service
Mastère Professionnel Systèmes de Communication et Réseaux
Séminaire (6-12 Février 2007) Promo. M2 ESCE-Tunis 2006/07
François CARCENAC,Frédéric BONIOL ONERA-DTIM Zoubir MAMMERI IRIT
Présentation du framework JSF (Java Server Faces) dans le modèle événementiel MVCII
Struts.
Les différents modèles d’architecture technique
PaCO++ André Ribes Réunion Hydrogrid Rennes 15/09/03.
21/02/2003DEA DISIC 1 Grid Computing Programming the grid: Distributed Software Components, P2P and Grid Web Services for Scientific Applications Tarak.
Web Services 17/01/2009.
Objectifs du développement Des agendas culturels et services quotidiens de La Libre Belgique et de La Dernière Heure et proposera des services d’informations.
Parquet Geoffrey 3 ARIL EXIA.CESI ARRAS. Présentation du MLD Présentation de la persistance Présentation récapitulatif du projet JSP/SERVLET MVC Cycle.
Applications distribuées Introduction Jean-Jacques LE COZ.
Transcription de la présentation:

Architecture J2EE gfgfgfggf Khin Chhoung LAO, Cnam.

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).

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.

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é.

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.

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.

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.

Architecture à deux niveaux Appliation DB

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.

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

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.

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

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..

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.

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.

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..

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.

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

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.

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

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.

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.

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.

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

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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.

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

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

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