Soutenance mémoire
Télécharger le fichier pdf d’un mémoire de fin d’études
Architecture système
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, dont des terminaux aux faibles capacités permettent juste l’affichage des résultats demandés. Le client/serveur est une évolution du Mainframe et permet par l’utilisationde nouvelles méthodes et techniques de passer outre les limites de l’environnement Mainframe et les systèmes propriétaires. Cette innovation permet ainsi d’améliorer l’interopérabilité, la xibilitéfle des systèmes.
Dix ans après son apparition, le client/serveur est devenu l’architecture 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 est désormais offerte aux utilisateurs finaux.
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, ses entreprises forment aujourd’hui le nouvel établissement de l’informatique.
Même si cela peut surprendre, une modification silencieuse est en marche au sein même de la révolution client/serveur. La figure 1.02 montre eneffet 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 que l’évolution initiale des aplications 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.
Modèle générale d’architecture système
Toutes les architectures informatiques client/serveur présentent des caractéristiques communes :
• Elles intègrent une interface utilisateur souvent graphique (GUI)
• Elles fonctionnent grâce à des applications
• Les applications qui les animent manipulent des données.
C’est la répartition de ces trois composants entrele client et/ou les serveurs qui caractérisent les différentes architectures.
Espace serveur
Voici quelques exemples de serveurs :
• Serveur objet
Le serveur objet exécute la logique applicative auquel le client se connecte par l’intermédiaire d’un protocole d’objets distribuésLes. objets qu’héberge ce serveur peuvent éventuellement être conditionnés sous la forme deomposantc.
• Moniteur transactionnel
Son but est de coordonner l’exécution de transactions distribuées sur plusieurs machines. Par exemple : si l’utilisateur veut à la fois réserver un avion et un hôtel, à l’aide d’une même application, alors l’application devra s’assurer que la transaction a lieu intégralement ou pas du tout. Le moniteur transactionnel sera alors très utile pour coordonner ces deux réservations simultanées et s’assurer de l’atomicité (ACID) de’opérationl composée.
• Serveur web
Le serveur web selon le cas a un rôle de serveur de fichiers ou celui de middleware
• Serveur de sécurité
Le serveur de sécurité qui gère l’authentificationdes utilisateurs et le chiffrement des flux de communication. La norme LDAP (Lightweight Directory Access Protocol) mise en œuvre par Netscape à la fin des années 90, s’impose aujourd’hui comme le standard de serveur d’annuaire distribué. LDAP est ainsi au centre de oust les systèmes de sécurité à base de cryptage à clé public (PKI : Public Key Interface).
Espace client
Le logiciel client n’est pas lié à la machine qui le fait tourner, il doit être portable et mobile. Dece fait, l’espace client est souvent unique pour un utilisateur donné et sa localisation physique est en principe indéterminée.
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 intermédiaires. Ils servent à simplifier le travail du développeur en se chargeant d’un point particulier. Ils sont de plusieurs types, les principaux étant :
• Les middlewares 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 (Object 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 plusieurs machines
· Les Messages Oriented Middleware (MOM) :
Il s’agit de serveurs intermédiaires dans la communication entre application.
Typologie technique
Pour comparer les architectures entre elles, le paragraphe qui suit s’attache à déterminer quelles sont les caractéristiques significatives d’une architecture client/serveur.
Type de données véhiculées (TDV)
La figure 1.04 représente le TDV
De quelle nature est l’information qui circule entre le client et le serveur ?
• S’agit-il d’une information de présentation (interface HTML) auquel cas le client s’apparente à un terminal passif (il doit juste afficher ce qu’on lui envoie) ?
• Ou bien s’agit-il uniquement de données extraites d’une base SQL, auquel cas le client a pour responsabilités de déterminer 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 sont-elles des objets sérialisées, c’est à dire transformées en une série d’octets propre à être transmise au travers d’un réseau ?
Type de dialogue client/serveur
La figure 1.05 représente le type de dialogue client/serveur
Figure 1.05: Dialogue 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 avec un tel protocole ?
Par exemple : comment faire 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 avait acheté lors des pages précédentes. A l’inverse, lesprotocoles tel que CORBA – IIOP – RMI – DCOM, ou plus simplement le protocole TCP sont dits connectés. A la manière d’une communication téléphonique, la ligne reliant les interlocuteurs est dédiée : le dialogue est interrompu explicitement soit par le client, soit par le serveur.
Structure et localisation des applicatifs
La figure 1.06 représente la structure et localisation des applicatifs
Figure 1.06: Localisation des applicatifs
La centralisation des applicatifs est d’un attrait certain, car elle facilite la maintenance, le déploiement, la gestion des accès concurrent aux données, des transactions, etc. L’intégrisme centralisateur doit céder le pas à une réflexion plus rationnelle sur l’organisation du système d’information. Par exemple : certains métiers imposent la mobilité et l’autonomie : on doit travailler sans être connecté au serveur. Comment yparvenir s’il n’y a pas de code sur le poste client ?
Architectures client/serveur
Client/serveur à client passif (1/3)
Le terme client/serveur appliqué à ce type d’architecture présente des clients passifs qui n’exécutent rien. Le client ici se présente sous forme de terminal ou l’émulation de terminal. C’est le serveur qui héberge les applications.
Dans ce type d’architecture, la logique applicative (métier) et les données sont concentrées en un seul point : « le site central ». Le client (c’est à dire le terminal) ne sert qu’à la visualisation e t à l’insertion des données.
Figure 1.07: Architecture 1/3
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égré. 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 tableau de caractères ou maps 3270 par exemple.
Figure 1.08: Eléments constituants de l’architecture 1/3
Client/serveur de données (2/3)
Ce type d’architecture est apparu 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 mainframe n’est pas mort pour autant car il contenait déjà toute la logique applicative et toutes les données de l’entreprise. Opére une migration intégrale vers les PC n’était pas envisageable. Ainsi un nouveau type d’architecture s’est développé autour du PC : « le client/serveurde données ».
Le PC étant capable d’exécuter des traitements, pourquoi ne pas en profiter ? 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 SGBDR et des outils L4G (SQLWindows. PowerBuilder) qui permettent rapidement de développer des applications pour un PC avec accès aux données du serveur.
Le client concentre ainsi l’ensemble de la logique applicative et communique au serveur à l’aide d’un langage de requête standardisé : « SQL ». Grâce au PC, les interfaces peuvent alors devenir beaucoup plus graphiques accroissant la qualité d’information disponible dans un même écran et améliorant les possibilités de manipulation de données. Les GUI peuvent augmenter notablement la productivité des utilisateurs.
A peine dix ans plus tard le bilan est sans appel : le coût de maintenance de ce type d’architecture, démontré par la figure ci-dessus, est prohibitif. Par ailleurs, les déploiements à grande échelle sont complexes (en cas de mise à jour, il faut réinstaller l’application sur les postes clients). Ainsi le mainframe est resté indispensable et il a survécu àla vague des PC.
Bref, la nature des éléments constituant cette architecture est résumée par la figure 1.10 suivant:
Figure 1.10: Eléments constituants de l’architecture 2/3
Client/serveur distribués (3/3)
Les débuts industriels de ce type d’architecture marquent le début des années 90. On commence à comprendre que la décentralisation intégrale des traitements vers les PC n’est pas forcément une bonne chose. Quelques portions de programme sous la forme de « procédures stockées » seront transférées progressivement sur le serveur.
Mais le problème de déploiement et de la maintenanc des applications reste presque inchangé. Certains éditeurs d’outils L4G prennent la mesure du problème et proposent la solution basée sur des serveurs d’applications : N AT STAR, PowerBuilder, Forte, … Ces serveurs hébergent des traitements appelés par des protocoles RPC propriétaires.
Figure 1.11: Architecture 3/3
Le principe de cette architecture est simple, il ne s’agit plus de disposer le code à exécuter sur le client, mais plutôt sur un serveur tiers (appelé « serveur d’application », car il offre la possibilité d’exécuter des portions d’application). Ainsi, il ste au faveur du client de demander aux serveurs d’exécuter telle ou telle procédure. Le serveur effectue l’opération demandée puis retourne le résultat au client. Ainsi le client se trouve-t-il déchargé d’une bonne part des traitements. Par ailleurs, les données ne circulent presque plus qu’entre le serveur d’application et la base de données ce qui économise la bande passante réseau.
|
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
