Soutenance mémoire
Applications multitiers distribuées
La plate-forme J2EE se base sur le modèle d’application multitiers distribué en général, et sert d’atelier logiciel pour la production d’applications d’entreprises et d’application Web. Une application multitiers est composée du traitement et de la présentation ; le traitement contient les données et la logique applicative (ou processus métier ou logique métier). La logique applicative est divisée en deux composants selon ses fonctions (orientées web ou entreprise). Les différents composants d’applications que comporte une application J2EE sont installés sur différentes machines selon leur niveau dans l’environnement multitiers J2EE. Pour illustrer ceux-ci, la figure I.1 montre deux exemples types d’application multitiers basée sur la plate-forme J2EE. La représentation ici est hiérarchisée en niveau et comprend les composants suivants :
• Composant « niveau client » : s’exécute sur la machine cliente
• Composant « niveau web » : s’exécute sur un serveur web J2EE (Applet, image, HTML)
• Composant « niveau métier » : s’exécute sur un serveur J2EE (Servlet, JSP, EJB)
• « Niveau système d’information de l’entreprise » (niveau EIS)
Introduction sur le client/serveur
Auparavant les Mainframes étaient les architectures dominantes dans les entreprises. Les applications et les données étaient centralisées sur un gros ordinateur, qu’on entoure de terminaux aux faibles capacités permettant juste l’affichage des résultats demandés. Le client/serveur est une évolution du Mainframe et permet par l’utilisation de nouvelles méthodes et techniques de passer outre les limites que l’on connaissait avec l’environnement Mainframe et les systèmes propriétaires, et ainsi d’améliorer l’interopérabilité, la flexibilité des systèmes. Dix ans après son apparition, le client/serveur est devenu l’architecture d’applications la plus prisée. En fait, il applique un gigantesque découpage aux applications monolithiques des sites centraux pour répartir les charges de traitement entre clients et serveurs. La manière dont étaient conçues et bâties les applications jusqu’ici en a été révolutionnée, et la facilité d’utilisation désormais offerte aux utilisateurs finaux s’est nettement améliorer. Le client/serveur a entraîné, dans son sillage, la création d’une énorme industrie logicielle dominée par des géants comme Baan, Informix, Lotus, Microsoft, Novell, Oracle, PeopleSoft, SAP, Sun et Sybase. Superstars de la première époque du client/serveur, ces entreprises forment aujourd’hui le nouvel établissement de l’informatique. Même si cela peut surprendre, une révolution silencieuse est en marche au sein même de la révolution client/serveur. La figure 1.2 montre en effet que la technologie client/serveur est en train de passer d’une structure originelle à 2 niveaux à une architecture à 3 niveaux. L’impact du changement du client/serveur à deux niveaux vers le client/serveur à trois niveaux sera plus important encore que l’évolution initiale des applications monolithiques (Mainframe) vers le client/serveur. Ce courant vers le modèle à 3 niveaux a été initié par la nécessité d’utiliser la technologie client/serveur pour les grandes applications des entreprises. L’Internet, les intranets, les objets distribués et les composants propulsent aujourd’hui la structure à 3 niveaux au cœur du client/serveur. Le client/serveur est donc devenu la forme dominante de l’informatique et le modèle à 3 niveaux la forme dominante du client/serveur.
Influence de la sécurité
Avant l’ouverture des réseaux sur le monde extérieur, la sécurité est devenue une caractéristique obligatoire des architectures client/serveur. Elle a en réalité des composantes distinctes.
• La protection des réseaux contre les intrusions, c’est à dire l’interdiction de l’accès à des services autres que ceux qui sont officiellement permis
• L’authentification des utilisateurs.
Les contraintes très fortes de sécurité sur Internet imposent des limitations aux architectures clients/serveurs dans l’entreprise. En particulier la présence de firewall peut empêcher ou limiter l’utilisation de certains protocoles de haut niveau.
Les composants web
Les composants web sont soit des servlets, soit des Java Server Page (JSP). Les Servlets sont des classes Java qui, dynamiquement, traitent les requêtes et construisent les réponses. Les JSP s’exécutent de la même manière qu’une servlet, mais permet une approche beaucoup plus naturelle pour la création du contenu statique. Les pages HTML et les applets sont liés au composant web durant l’assemblage de l’application mais ne sont pas considérés comme des composants web selon la spécification J2EE. Les autres scripts côtés serveur sont aussi liés aux composants web, mais comme les pages HTML, ils ne sont pas considérés comme des composants web. Comme illustrés sur la figure ci-dessous, le niveau web, comme le niveau client, peut inclure des composants JavaBeans, qui sont des classes java spéciales, pour gérer les entrées utilisateurs et envoyer ces entrées vers l’ « enterprise beans » qui tournent sur le niveau métier.
Introduction aux bases de données
Une base de données est un ensemble structuré de données enregistrées avec le minimum de redondance pour satisfaire simultanément plusieurs utilisateurs de façon sélective en même temps opportun. Dans cette approche la partie de structuration et de description des données sont unifiées et séparées des programmes d’application. Il semble plus facile de définir l’outil principal de gestion d’une base de données : le système de gestion de bases de données (SGBD).
• C’est un outil permettant d’insérer, de modifier et de rechercher efficacement des données spécifiques dans une grande masse d’informations.
• C’est une interface entre les utilisateurs et la mémoire secondaire facilitant le travail des utilisateurs en leur donnant l’illusion que toute l’information est comme ils le souhaitent. Chacun doit avoir l’impression qu’il est seul à utiliser l’information. Le SGBD est composé de trois couches successives :
• Le système de gestion de fichiers. Il gère le stockage physique de l’information. Il est dépendant du matériel utilisé (type de support, facteur de blocage, etc …).
• Le SGBD interne. Il s’occupe du placement et de l’assemblage des données, gestion des liens et gestion de l’accès rapide.
• Le SGBD externe. Il s’occupe de la présentation et de la manipulation des données aux concepteurs et utilisateurs. Il s’occupe de la gestion de langages de requêtes élaborés et des outils de présentation (états, formes, etc…).
|
Table des matières
INTRODUCTION
CHAPITRE I. GENERALITES
I.1. Contexte
I.1.1. Applications multitiers distribuées
I.2. Architecture système
I.2.1. Introduction sur le client/serveur
I.2.2. Modèle générale d’architecture système
I.2.2.1. Espace serveur
I.2.2.2. Espace client
I.2.3. Les briques de l’architecture système
I.2.3.1. Interface utilisateur
I.2.3.2. Les applications
I.2.3.3. Les données
I.2.3.4. Le Middleware
I.2.4. Typologie technique
I.2.4.1. Type de données véhiculées
I.2.4.2. Type de dialogue client/serveur
I.2.4.3. Structure et localisation des applicatifs
I.2.5. Les architectures client/serveur
I.2.5.1. Client/serveur à client passif (1/3)
I.2.5.2. Client/serveur de données (2/3)
I.2.5.3. Client/serveur distribués (3/3)
I.2.5.4. Client/serveur à objets distribués (système réparti)
I.2.6. Evolution du client/serveur avec Internet
I.2.6.1. Standardisation des protocoles
I.2.6.2. Influence de la sécurité
I.2.6.3. Le problème de bande passante
I.2.7. Les architectures clients/serveurs basés sur Internet
I.2.7.1. Les architectures C/S HTML/WEB
I.2.7.2. Les architectures à codes mobiles
CHAPITRE II. LA PLATE-FORME J2EE
II.1. Introduction
II.2. Les applications multitiers distribuées de J2EE
II.2.1. Les composants J2EE
II.2.2. Les clients J2EE
II.2.2.1. Client web
II.2.2.2. Applet
II.2.2.3. Les applications clientes
II.2.3. Les composants web
II.2.3.1. L’architecture du composant JavaBeans
II.2.4. Les composants métiers
II.2.5. Le niveau EIS
II.3. Les conteneurs J2EE
II.3.1. Les services conteneurs
II.3.2. Les types de conteneurs
II.3.2.1. Le serveur J2EE
II.3.2.2. Le conteneur EJB
II.3.2.3. Conteneur web
II.3.2.4. Le conteneur d’application cliente
II.3.2.5. Le conteneur d’applet
II.4. Les API de J2EE
II.4.1. La technologie Enterprise JavaBeans
II.4.2. La technologie Java Servlet
II.4.3. La technologie JavaServer Page
II.4.4. L’API Java Message Service
II.4.5. L’API Java Transaction
II.4.6. L’API JavaMail
II.4.7. JNDI
II.4.8. L’API JDBC
CHAPITRE III. LES BASES DE DONNEES
III.1. Présentation générale
III.1.1. Introduction aux bases de données
III.1.2. Objectifs et avantages
III.1.2.1. Indépendance physique
III.1.2.2. Indépendance logique
III.1.2.3. Manipulable par des non-informaticiens
III.1.2.4. Accès aux données efficace
III.1.2.5. Administration centralisée des données
III.1.2.6. Non redondance des données
III.1.2.7. Cohérence des données
III.1.2.8. Partageabilité des données
III.1.2.9. Sécurité des données
III.1.3. Différents types de bases de données
III.1.4. Quelques systèmes existants
III.1.5. Modéliser les données
III.2. L’algèbre relationnelle
III.2.1. Les opérations de base
III.2.2. Expressions de l’algèbre relationnelle
III.2.3. Quelques remarques sur l’algèbre relationnelle
III.3. Le langage SQL
III.3.1. L’obtention des données
III.3.1.1. Expression des projections
III.3.1.2. Expression des restrictions
III.3.1.3. Tri et présentation des résultats
III.3.1.4. Expression des jointures
III.3.1.5. Les fonctions statistiques
III.3.2. La mise à jour d’informations
III.3.2.1. Insertion
III.3.2.2. Mise à jour
III.3.2.3. Suppression
III.3.3. La définition des données : Le DDL
III.3.3.1. Les types de données
III.3.3.2. La création de tables
III.3.3.3. Expression des contraintes d’intégrité
III.4. Connexion aux bases de données
III.4.1. L’API JDBC
III.4.2. Obtenir une connexion
III.4.3. Exécuter des requêtes SQL
CHAPITRE IV. LES SERVLETS ET LES JSP
IV.1. Application web
IV.1.1. Cycle de vie des applications web
IV.1.2. Modules web
IV.2. Les Servlets
IV.2.1. Définition
IV.2.2. Cycle de vie d’une servlet
IV.2.3. L’API servlet
IV.2.4. Structure de fonctionnement interne d’une servlet
IV.2.5. Implémentation d’une servlet
IV.2.5.1. La classe HttpServlet
IV.2.6. Initialisation et destruction d’une servlet ; l’interface servlet
IV.2.6.1. Initialisation
IV.2.6.2. En service
IV.2.6.3. Destruction
IV.2.7. Invocation d’une servlet à partir d’un client léger
IV.2.7.1. Invocation de la méthode doGet()
IV.2.7.2. Invocation de la méthode doPost()
IV.3. Les JSP
IV.3.1. Généralités
IV.3.2. Comparaison entre JSP et servlet
IV.3.3. Architecture
IV.3.4. Les tags JSP
IV.3.4.1. Declaration tag (<%! %>)
IV.3.4.2. Expression tag (<%= %>)
IV.3.4.3. Directive tag (<%@ directive … %>)
IV.3.4.4. Scriptlet tag (<% … %>)
IV.3.4.5. Action tag
IV.3.4.6. Commentaire
IV.3.5. Avantages et inconvénients des JSP
CHAPITRE V. APPLICATION : MISE EN PLACE DU SYSTÈME D’INFORMATION POUR LA GESTION DE LA SCOLARITE
V.1. Démarche méthodologique de construction d’une application
V.1.1. Les différentes étapes
V.1.1.1. Expression des besoins
V.1.1.2. Analyse
V.1.1.3. Conception
V.1.1.4. Implémentation
V.1.1.5. Les tests de vérification
V.1.1.6. Validation
V.1.1.7. Maintenance et évolution
V.1.2. Les différents cycles de vie
V.1.2.1. Le cycle de vie en cascade
V.1.3. La méthode Merise
V.1.4. Récapitulation
V.2. Description générale
V.2.1. Architecture matérielle
V.2.2. Les objectifs du programme d’informatisation du Service de la Scolarité
V.2.3. Description du système
V.3. REALISATION
V.3.1. Diagramme des flux
V.3.2. Règles de gestion
V.3.3. Recueil des données
V.3.4. Entités
V.3.5. Création du MCD
V.3.6. Mise en place de la base de données
V.3.7. Description de l’application
CONCLUSION
ANNEXE
ANNEXE 1 : Les fondements du reseau
ANNEXE 2 : HTML
BIBLIOGRAPHIE
Télécharger le rapport complet
