Architecture proposée
L’architecture est adaptée sur une structure de microfinance composée d’un siège et des agences implantées un peu partout dans un pays.
L’architecture réseau est le modèle étoilé centrée sur le siège De ce point de vue, le système de transfert aura une approche dans laquelle, l’application à réaliser pour la gestion du transfert, le serveur de base de données(ou les serveurs de bases de données, dans le futur avec la montée en charge), le serveur d’application, seront tous sur des machines virtuelles différentes, centralisées sur une machine physique (hôte) faisant office de serveur du système de transfert et installé sur le réseau interne au niveau du siège de la microfinance.
Au niveau des agences, les postes de travail (ordinateur) susceptibles d’exploiter le système de transfert seront munis d’une application cliente (Navigateur) configurée convenablement pour pouvoir accéder au système de transfert. Cela suppose que l’infrastructure est déjà disponible.
Les différents composants nécessaires
Pour mener bien notre projet, nous avons besoin en autre d’un serveur d’applications, d’un serveur de base de données, le langage et l’IDE utilisés pour développer l’application et le système d’exploitation qui va héberger notre application.
Le serveur d’applications : Glassfish Server : GlassFish est un projet de serveur d’applications Java créé par Sun Microsystems qui permet à plusieurs développeurs de mettre en place des applications qui sont pratiques et évolutive, ainsi que des services supplémentaires qui peuvent être installés en fonction des besoins. Il est un logiciel libre, sous une double licence en vertu de la licence publique générale GNU (GPL) et le Common Development and Distribution License (CDDL). GlassFish a été acquis par Oracle en 2010. L’implémentation de Java EE est GlassFish, afin qu’il soutienne JMS, Java Server Pages, Enterprise JavaBeans, RMI et de servlets. En raison de sa nature, les développeurs peuvent créer des applications évolutives et portables qui s’intègrent facilement avec les systèmes et les technologies existantes.
Le système de gestion de base de données (SGBD) : Le système de gestion de base de données retenu pour gérer les données du système est un système NoSQL. C’est un moteur de base de données éprouvé assez efficace, robuste et rapide.
JEE : Java est un langage de programmation et de plate-forme informatique d’abord été publié par Sun Microsystems en 1995. Java est rapide, sécurisée et fiable. Des ordinateurs portables aux centres de données, les consoles de jeux aux superordinateurs scientifiques, des téléphones cellulaires à l’Internet, Java est partout!
Le choix de JEE peut en autre se justifier par le fait que c’est un langage avec lequel on se sente à l’aise, de plus il est muni d’outils qui aident à générer rapidement des codes.
L’IDE : NetBeans : NetBeans est un environnement de développement intégré, un outil pour les programmeurs pour écrire, compiler, déboguer et déployer des programmes. Il est écrit en Java – mais peut supporter n’importe quel langage de programmation. Il y a également un grand nombre de modules pour étendre l’IDE NetBeans, ainsi que des outils pour le contrôle de version et la collaboration de développeur. NetBeans est un produit gratuit, sans aucune restriction quant à son usage.
Le système d’exploitation : La mise en œuvre du système de transferts nécessite l’installation d’un environnement d’exploitation sur lequel le serveur de base de données (NoSQL) et l’application seront installés et exploités en temps réel pour la production du système. Nous avons opté pour le système Linux, de part : sa robustesse ; le faible coût d’acquisition; sa bonne mise en œuvre des techniques de tolérance aux pannes du fait qu’il est très rare qu’il soit l’objet d’attaque.
Présentation du NoSQL
Une base de données NoSQL permet de stocker des valeurs, du XML, des fichiers, etc. Elle est peut être distribuée sur une multitude de serveurs sur un réseau pour fournir un maximum de performance et de disponibilité. Les éléments stockés sont accessibles par une clé unique. Dépendamment du besoin, certaines solutions sauvegardent les informations de façon persistante sur disque (informations importantes à conserver) et d’autres les conservent en mémoire (informations de session, cache, etc…). NoSQL englobe une grande variété de technologies de bases de données différentes qui ont été développés en réponse à une augmentation du volume des données des objets, la fréquence à laquelle ces données sont accessible, et de la performance et de l’adaptation des besoins. Bases de données relationnelles, d’autre part, ne sont pas conçues pour faire face aux défis d’évolutivité et de souplesse qui font face à des applications modernes, ils ne se sont construits pour profiter des puissances de traitement disponible aujourd’hui.
Les applications web typiques sont construites avec une architecture trois tiers. Pour supporter la charge, plus de serveurs Web sont simplement ajoutés derrière un load balancer (partage de charge) pour supporter plus d’utilisateurs. La capacité à monter en charge est un principe fondamental dans le monde du cloud computing, de plus en plus important, dans lesquels des instances de machines virtuelles peuvent être facilement ajoutées ou enlevées pour répondre à la demande.
Différence entre le SQL et le NoSQL
Evolutivité – Elasticité : La scalabilité (évolutivité) est aussi synonyme de réduction des coûts lorsque l’on monte en charge. « En NoSQL, il suffit de mettre en parallèle de nombreux serveurs standards possédant leur propre stockage, sur lesquels la base de données est répartie ». Alors qu’avec SQL, il faut mettre en œuvre de grosses baies et un SAN coûteux. Autre avantages du NoSQL: il automatise la réplication de données entre sites, laissant plus de liberté dans la modélisation des données et se révèle mieux adapté aux données non structurées.
Flexibilité : Une des raisons principales pour passer à un système de base de données NoSQL est le modèle de données plus flexible que l’on retrouve dans la plupart des bases de données NoSQL. Le modèle de données relationnel est basé sur des relations définies entre les tables, qui sont définis par une structure de colonne déterminée, qui sont tous explicitement organisés dans un schéma de base de données ; tous très stricte et uniforme. Problèmes commencent à surgir avec le modèle relationnel autour de l’évolutivité et les performances lorsque vous essayez de gérer les grands volumes de données qui deviennent une réalité de la vie moderne dans un environnement informatique et d’affaires. Un modèle de données NoSQL souvent désigné comme schéma moins, peut supporter beaucoup de ces cas d’utilisation et d’autres qui ne cadrent pas bien dans un SGBDR. Une base de données NoSQL est en mesure d’accepter tous les types de données structurées, semi-structurées, et non structurées, beaucoup plus facilement qu’une base de données relationnelle qui reposent sur un schéma prédéfini. Cette caractéristique d’une base de données relationnelle peut être un obstacle sur la flexibilité, car un schéma prédéfini détermine de façon rigide comment les données de base de données sont organisées. Beaucoup d’applications d’entreprise d’aujourd’hui ont réellement la capacité de faire appliquer les règles sur l’utilisation des données elles-mêmes ; faire une plate-forme de base de données du schéma moins reste une option viable.
Enfin, les facteurs de performance entrent en jeu avec le modèle de données d’un SGBDR, surtout lorsque plusieurs tables sont impliquées et mettent à jour, les actions sont nombreuses, ce qui peut avoir des conséquences réelles sur la performance. Cependant, un modèle de données NoSQL gère facilement de telles situations et offre des performances très rapides en lecture et en écriture.
Table des matières
INTRODUCTION
CHAPITRE I : PRESENTATION DU CONTEXTE
I-1 Problématique
I-2 Objectif du projet
I-3 Architecture proposée
I-4 Les différents composants nécessaires
I-4-1 Le serveur d’applications : Glassfish Server
I-4-2 Le système de gestion de base de données (SGBD)
I-4-3 JEE
I-4-4 L’IDE : NetBeans
I-4-5 Le système d’exploitation
CHAPITRE II : TRANSITION DU SQL VERS LE NOSQL
II-1 Présentation du NoSQL
II-2 Différence entre le SQL et le NoSQL
II-2-1 Evolutivité – Elasticité
II-2-2 Flexibilité
II-2-3 La haute disponibilité
II-2-4 Architecture
II-2-5 Big data
II-2-6 Business Analytique et Business Intelligence
II-2-7 Economique
II-2-8 Les types de bases de données NoSQL
II-3 Mongodb
II-3-1 Présentation de Mongodb
II-3-2 Les modèles de données
II-3-3 Fonctionnalité avec Mongodb
CHAPITRE III : LES TECHNOLOGIES UTILISÉES
III-1 Fonctionnalités de l’application
III-2 JPA
III-2-1 Présentation de JPA
III-2-2 L’ architecture JPA
III-2-3 Les Composants ORM
III-3 EJB
III-4 JSF
III-5 PRIMEFACES
III-6 SMSLib
III-7 JasperReport
CHAPITRE IV LA VIRTUALISATION
IV-1 Les aspects de la virtualisation
IV-1-1 Virtualisation de l’ordinateur
IV-1-2 Virtualisation de l’infrastructure
IV-1-3 L’informatique cloud
IV-1-4 Consolidation de serveurs
IV-1-5 Continuité d’activité
IV-1-6 Composants et fonctions VMware vSphere
CHAPITRE V : IMPLEMENTATION
V-1 ARCHITECTURE DE L’APPLICATION
V-2 ANALYSE ET CONCEPTION
V-3 REALISATION
V-3-1 Installation et configuration de la Base de données MongoDB
V-3-2 Développement de l’application
V-4 SÉCURISATION
v-4-1 Sécurisation De L’infrastructure
v-4-2 Sécurisation De La Base De Données
V-4-3 Sécurisation De L’application
V-5 Tests
V-5-1 Test unitaire
V-5-2 Évaluation technique
V-6 DEPLOIMENT
CONCLUSION
Webographie
