PLATE-FORME J2EE

Télécharger le fichier pdf d’un mémoire de fin d’études

Briques de l’architecture système

Interface utilisateur

Aujourd’hui, les interfaces utilisateurs sont interactives, multimédia, et de préférence portables, c’est-à-dire des interfaces graphiques pouvant fonctionner sur tous les systèmes d’exploitation et conservent toujours le même aspect.

Applications

Le choix en matière de langage de développement estconsidérable, et souvent de haut niveau, c’est à dire qu’il reste éloigné des préoccupationsau niveau des matérielles, comme la gestion de la mémoire ou la programmation réseau ; Ces détailssont réglés automatiquement. Le développement peut donc se concentrer sur la logique de l’application, sur les langages de scripts (Perl. PHP, TCL, JavaScript, VBScript) et sur les langages objets (Java, C++, VB.Net, C#). Ces langages de scripts sont très simples et permettent de développer rapidement des petites applications. Pour des projets de plus grandes envergures, il est nécessaire d’avoir recours au langage objet de troisième génération. Dans la pratique, les applications d’entreprises mettent souvent en jeu des combinaisons de ces deux types de langage.
Cependant, le problème du développement informatique ne se limite pas au choix d’un langage.
La qualité d’une application informatique s’exprimeselon quatre axes :
• Facilité de développement (FAIRE)
• Facilité de déploiement (INSTALLER)
• Facilité à être maintenu ou maintenabilité (‘METTREA JOUR)
• Facilité de réutilisation (RECYCLER)
Dans les architectures client/serveur, l’optimum de qualité est atteint par le recours à la programmation objet ou à base de composant (ActiveX , DLL….) Ces briques logicielles qui servent à construire l’édifice applicatif sont généralement développées dans des langages compilés de troisième génération comme C++ ou Java. La gestion des interfaces graphiques de type HTML est par contre simplifiée par l’utilisation de langage script côté serveur. Actuellement la multiplication des solutions offrent des combinaisons de scripts et de composants : le langage de scripts joue le rôle d’intermédiaire entre le serveur d’application et les composants qu’il héberge (ASP/ActiveX, JSP/EJB, JavaScript/EJB).

Données

La grande majorité des données de gestion est encor à l’heure actuelle stockée dans des bases de données non relationnelles, dans des « Mainframes ». Jusqu’à une époque très récente, la plupart des éditeurs de sites intranet avaient purement etsimplement oublié ce fait. Les accès se limitaient aux données relationnelles (Sybase, Oracle à travers SQL) souvent exclusivement au travers de l’interface ODBC (Open DataBase Connectivité) de Microsoft. Les Systèmes de Gestion de Base de Données Objet ne percent toujours pas. Leurs qualités sont pourtant indéniables lorsque l’on mène un projet objet :
• La persistance des données objets est gérée presqueautomatiquement
• Il n’est pas nécessaire de constituer une correspondance entre la représentation des données et leur représentation sous forme relationnelle.
• Les performances sont aussi bonnes voire meilleures qu’avec le SGBDR
• L’administration de base de données est souvent plus aisée qu’avec le SGBDR

Middleware

Pour lier efficacement les différentes composantes d’une application client/serveur, il est parfois nécessaire d’avoir recours à des logiciels spécifiques : « les middlewares » Comme leur nom l’indique, ce sont des intermmédiaires. Ils servent à simplifier le travail du développeur en se chargeant d’un point particulieer. Ils sont de plusieurs types, les principaux étant
• Les middlewarees d’accès aux données
Ils mettent en communication les applications avec les différentes sources de données de l’entreprise.
• Les ORB (Objeect Request Broker) :
Leur but premier est de rendre plus transparente la communication avec les applications situées sur des machines distantes grâce à ce qu’on appelle objets distribués (interopérabilités). Citer comme exemple : CORBA, DCOM, RMI.
· Les moniteurs transactionnels :
Leur fonction est de coordonner les transactions distribuées sur plusieeurs machines
· Les Messages Oriiented Middleware (MOM) :
Il s’agit de serveurs intermédiaires dans la communication entre appliccation.

Typologie technique

Pour comparer les architecturres entre elles, le paragraphe qui suit s’attacche à déterminer quelles sont les caractéristiques signiificatives d’une architecture client/serveur.
De quelle nature est l’information qui circule entre le client et le serveur ?
• S’agit-il d’une informattion de présentation (interfac HTML) auquel cas le client s’apparente à un terminal passif (il doit juste afficher ce qu’on lui envooie) ?
• Ou bien s’agit-il uniquem ent de données extraites d’une base SQL,auquel cas le client a pour responsabilités de détermminer comment afficher cesdonnées ?
• Ces données représentent-elles des appels de fonction à distance (avec le protocole CORBA-IIOP par exemple) ?
• Ou enfin, ces données s on-elles des objets sérialisées, c’est à dire transformées en une série d’octets propre à être trannsmise au travers d’un réseau ?

Type de dialogue cliennt/serveur

La figure 1.05 représente le tyype de dalogue client/serveur
Le HTTP est un protocole dééconnecté : on demande une page HTML, le serveur web la renvoie (avec les éventuels fichiers qui s’y rattachent comme les images, ou des applets Java), et la communication est coupée. Comment obtenir un contexte transactionnel avvec un tel protocole ?
Par exemple : comment fairee en sorte qu’un utilisateur puisse acheter des produits en ligne au travers de page HTML, et que chaque nouvelle page qu’il visite se souvienne de ce qu’il avai acheté lors des pages précéédente A l’inverse, les protocoles tel que CORBA – IIOP – RMI – DCOM, ou plus simplemennt le protocole TCP sont dits connectéss. A la manière d’une communication téléphoniquue, la lign reliant les interlocuteurs est déédiée : le dialogueest interrompu explicitement soit par le client, soit par le serveur.

Architectures client/serrveur

Client/serveur à client passif (1/3)

Le terme client/serveur apppliqué à ce type d’architecture présente des clients assifsp qui n’exécutent rien. Le client ici se présente sous forme de terminal ou l’ém ulation de terminal. C’es le serveur qui héberge les appplications
Dans ce type d’architecture, la logique applicative (métier) et les donnéees sont concentrées en u seul point : « le site central ». Le client (c’est à dire le terminal) ne sert qu’à la visualisation e t à l’insertion des données.
Ce type de système d’information a fait ces preuves. Sûr, sécurisé, robuste,, il satisfait parfaitement
à la première loi de l’informatique d’entreprise : « il faut que ça fonctionne ». La programmation est simple puisque l’accès aux données est généralem nt très bien intégé.En effet, l’avantage est de pouvoir travailler dans la mémoire d’un ordinateur puissant, particulièrement stable et qui est spécialement conçu pour le traitement de gestion : « le mainframe ». Le flux réseau entre le client et le serveur ne véhicule que des informations de présentation : de tableaau de caractères ou maps 3270 par exemple.

Client/serveur de donnnées (2/3

Ce type d’architecture est appparu avec la vague de PC du milieu des annéées 80 La loi de Grosh stipule qu’à puissances égales, plusieurs petites machines coûtent moins cher qu’une grosse. Pragmatique, les entreprises ont donc adhéré au PCCependant. le mainfraame n’est pas mort pour autant car il contenait déjà touute la logique applicative et toutes les donnéees de l’entreprise. Opére une migration intégrale vers les PC n’était pas envisageable. Ainsi un nou veau type d’architecture s’est développé autour du PCC : «e client/serveur de données ».
Le PC étant capable d’exécuuter des traitements, pourquoi ne pas en profitter ? Par conséquent, le serveur perd ces prérogatives,et n’est désormais utilisé qu’à la gestion des données
C’est l’avènement des SGBDDR et desoutils L4G (SQL Windows. PowerBuilder) qui permettent rapidement de développer des applications pour un PC avec accès aux donnnées d serveur.
Le client concentre ainsi l’ensemble de la logique applicative et communiique au serveur à l’ aide d’un langage de requête standardisé : « SQL ». Grâce au PC, les interfacees peuvent alors devenir beaucoup plus graphiques acccroissant la qualité d’information disponible dans un même écran e améliorant les possibilités d e manipulation de données. Les GUI peuvent augmenter notablement la productivité des utilisateurs
A peine dix ans plus tard le biilan est sans appel : le coût de maintenance de ce type d’architecture, démontré par la figure cidess-us, est prohibitif. Par ailleurs, les déploiements à grande échell sont complexes (en cas de mise à jour, il faut réinstaller l’application sur les postes clients). Ainsi le mainframe est resté indispenssable et il a survécu àla vague des PC.

Client/serveur distribuués (3/3

Les débuts industriels de ce type d’architecture marquent le début des années 90. O commence à comprendre que la décentraliisation intégrale des traitements vers les PC n’est pas forcément une bonne chose. Quelques portioons de programme sous la forme de « procéédures stockées seront transférées progressivement sur le serveu.
Mais le problème de déploie ment et de la maintenance de applications reste presque inchangé. Certains éditeurs d’outils L4 G prennent la mesure du problème et proposeent la solution basé sur des serveurs d’applications : N AT STAR, PowerBuilder, Forte, … Ces serveurs hébergen des traitements appelés par des prrotocoles RPC propriétaires.
Le principe de cette architectuure est simple, il ne s’agit plus de disposer lee code à exécuter sur le client, mais plutôt sur un serveeur tiers (appelé « serveur d’application », car il offre la possibilité d’exécuter des portions d’appplication)Ainsi, il est au faveur du client de demander aux serveurs d’exécuter telle ou telle procédure. Le serveur effectue l’opération demmandée puis retourne le résultat au client. Ainsi le client se trouve-t-il déchargé d’une bonne part des traitements. Pa ailleurs, les données ne circculent presque plus qu’entre le serveur d’application et la base de données ce qui économise la bande passante résea

Table des matières

INTRODUCTION GENERALE
CHAPITRE 1 GENERALITES SUR LES ARCHITECTURES SYSTEMES
1.1. Le contexte
1.1.1. Applications multitiers distribuées
1.2. Architecture système
1.2.1. Introduction sur le client/serveur
1.2.2. Modèle générale d’architecture système
1.2.2.1. Espace serveur
1.2.2.2. Espace client
1.2.3. Briques de l’architecture système
1.2.3.1. Interface utilisateur
1.2.3.2. Applications
1.2.3.3. Données
1.2.3.4. Middleware
1.2.4. Typologie technique
1.2.4.1. Type de données véhiculées (TDV)
1.2.4.2. Type de dialogue client/serveur (TD)
1.2.4.3. Structure et localisation des applicatifs
1.2.5. Architectures client/serveur
1.2.5.1. Client/serveur à client passif (1/3)
1.2.5.2. Client/serveur de données (2/3)
1.2.5.3. Client/serveur distribués (3/3)
1.2.5.4. Client/serveur à objets distribués (système réparti)
1.2.6. Evolution du client/serveur avec Internet
1.2.6.1. Standardisation des protocoles
1.2.6.2. Influence de la sécurité
1.2.6.3. Problème de bande passante
1.2.7. Architectures clients/serveurs basées sur Internet
1.2.7.1. Architectures C/S HTML/WEB
1.2.7.2. Architectures à code mobile
1.3. Conclusion
CHAPITRE 2 PLATE-FORME J2EE
2.1. Introduction
2.2. Applications multitiers distribuées de J2EE
2.2.1. Composants J2EE
2.2.2. Clients J2EE
2.2.2.1. Client web
2.2.2.2. Applet
2.2.2.3. Applications clientes
2.2.3. Composants web
2.2.4. Composants métiers
2.2.5. Niveau EIS
2.3. Conteneurs J2EE
2.3.1. Services conteneurs
2.3.2. Types de conteneurs
2.3.2.1. Serveur J2EE
2.3.2.2. Conteneur EJB
2.3.2.3. Conteneur web
2.3.2.4. Conteneur d’application cliente
2.3.2.5. Conteneur d’applet
2.4. API de J2EE
2.4.1. Technologie Enterprise JavaBeans
2.4.2. Technologie Java Servlet
2.4.3. Technologie JavaServer Page
2.4.4. API Java Message Service
2.4.5. API JDBC
2.4.6. API Java Transaction
2.4.7. JNDI
2.4.8. API JavaMail
2.5. Serveurs d’applications
2.5.1. Rôles d’un serveur d’application
2.5.2. Intégration dans l’architecture d’entreprise
2.5.3. Architecture externe d’un serveur d’application
2.5.4. Architecture interne d’un serveur d’application
2.6. Communication entre le client et le serveur : le protocole HTTP
2.7. Développement client
2.8. Développement serveur en Java
2.9. Conclusion
CHAPITRE 3 BASES DE DONNEES
3.1. Présentation générale
3.1.1. Introduction aux bases de données
3.1.2. Objectifs et avantages
3.1.2.1. Indépendance physique.
3.1.2.2. Indépendance logique.
3.1.2.3. Manipulable par des non-informaticiens.
3.1.2.4. Accès aux données efficace.
3.1.2.5. Administration centralisée des données.
3.1.2.6. Non redondance des données.
3.1.2.7. Cohérence des données.
3.1.2.8. Partageabilité des données.
3.1.2.9. Sécurité des données.
3.1.3. Différents types de bases de données
3.1.4. Quelques systèmes existants
3.1.5. Modéliser les données
3.2. Algèbre relationnelle
3.2.1. Opérations de base
3.2.2. Expressions de l’algèbre relationnelle
3.2.3. Quelques remarques sur l’algèbre relationnelle
3.3. Langage SQL
3.3.1. L’obtention des données
3.3.1.1. Expression des projections
3.3.1.2. Expression des restrictions
3.3.1.3. Tri et présentation des résultats
3.3.1.4. Expression des jointures
3.3.1.5. Fonctions statistiques
3.3.2. Mise à jour d’informations
3.3.2.1. Insertion.
3.3.2.2. Mise à jour
3.3.2.3. Suppression.
3.3.3. Définition des données : DDL
3.3.3.1. Types de données
3.3.3.2. Création de tables
3.3.3.3. Expression des contraintes d’intégrité
3.4. Connexion aux bases de données
3.4.1. API JDBC
3.4.1.1. Qu’est ce que JDBC?
3.4.1.2. Structure d’une application JDBC
3.4.2. Différents pilotes
3.4.3. Requêtes précompilées
3.4.4. Commit et Rollback
3.4.5. Méta-base
3.5. Conclusion
CHAPITRE 4 SERVLETS ET JSP
4.1. Application web
4.1.1. Cycle de vie des applications web
4.1.2. Modules web
4.2. Servlets
4.2.1. Définition
4.2.2. Cycle de vie d’une servlet
4.2.3. API servlet
4.2.4. Structure de fonctionnement interne d’une servlet
4.2.5. Implémentation d’une servlet
4.2.6. Initialisation et destruction d’une servlet
4.2.6.1. Initialisation
4.2.6.2. En service
4.2.6.3. Destruction
4.2.7. Invocation d’une servlet à partir d’un client léger
4.2.7.1. Invocation de la méthode doGet()
4.2.7.2. Invocation de la méthode doPost()
4.3. JSP
4.3.1. Généralités
4.3.2. Comparaison entre JSP et servlet
4.3.3. Architecture
4.3.4. Tags JSP
4.3.4.1. Déclaration tag (<%! %>)
4.3.4.2. Expression tag (<%= %>)
4.3.4.3. Directive tag (<%@ directive
4.3.4.3.1. Page directive
4.3.4.3.2. Include directive
4.3.4.3.3. Tag Lib directive
4.3.4.4. Scriptlet tag (<% . . . %>)
4.3.4.5. Action tag
4.3.4.6. Javabeans
4.3.4.7. Commentaire
4.3.5. Avantages et inconvénients des JSP
4.4. Conclusion
CHAPITRE 5 MISE EN OEUVRE DE L’APPLICATION
5.1. Etat de l’art
5.2. Choix du Langage Java
5.3. Choix de la base de données
5.4. Outils de développement
5.4.1. MERISE
5.4.2. ECLIPSE et DREAMWEAVER
5.4.2.1. Configuration d’ECLIPSE
5.4.2.2. Configuration de DREAMWEAVER
5.4.3. Win’ Design et EASYPHP
5.4.4. TOMCAT
5.4.4.1. Configuration de Tomcat
5.4.4.2. Modification de contexte
5.5. Mise en oeuvre de l’application
5.5.1. Règles de gestion
5.5.2. Organigramme
5.5.3. Exemples de pages de l’application
5.5.3.1. Inscription
5.5.3.2. Authentification ou login
5.5.3.3. Page représentant la liste des différents services
5.6. Conclusion
CONCLUSION GENERALE
ANNEXES
ANNEXE 1 : ARCHITECTURE DES RESEAUX
ANNEXE 2 : RAPPELS HTML
ANNEXE 3 : CODE D’AUTHENTIFICATION
ANNEXE 4: CODE SOURCE JEUX.JSP
ANNEXE 5 : CODE SOURCE SHOWCADDY.JSP
BIBLIOGRAPHIE
FICHE DE RENSEIGNEMENT
RESUME
ABSTRACT

Télécharger le rapport complet