Nous avons donc pensé à bâtir notre système sur des architectures utilisant un serveur d’application afin de respecter les exigences que nous avons défini dans la section 4.1.
L’architecture que nous avons adoptée est celle de la figure 4.7.
Réalisé par Mischaël Dichoso GANSE 47 Figure 4.7 : Architecture du système (vue de déploiement)
Elle comprend le SGBD, le serveur d’application, les différents types de clients que nous prendrons en compte ainsi que les frameworks qui leur permettront de communiquer avec le serveur d’application.
4.3.1 Système de Gestion de Base de Données
Le SGBD est un système de gestion de base de données relationnel parce qu’au niveau performance, il n’y a pas mieux que les bases de données relationnelles. De même, quand la quantité d’informations manipulées est très importante, les bases de données relationnelles sont les plus performantes. Nous avons porté notre choix sur MySQL car
- il est rapide et facile à utiliser ; - il est un SGBD open source ;
- il est supporté par la plupart des hébergeurs [15] ;
- la migration de MySQL vers Oracle est simple étant donné que ces deux SGBD appartiennent à la même société [35] ;
- ses fonctionnalités sont de plus en plus riches et variées ; ses bonnes performances, son ouverture à tous les principaux langages
Réalisé par Mischaël Dichoso GANSE 48
du marché, son fonctionnement sur les systèmes les plus courants et sa facilité d’utilisation pour des applications web [42].
4.3.2 Serveur d’application
Notre système doit être déployé dans un serveur d’application. Nous avons opté pour un serveur d’application Java EE (JEE) car la plate-forme Java est typique de l’informatique des grandes entreprises. JEE simplifie le développement d’applications et permet au programmeur le développement normalisé de composants modulaires réutilisables [30].
Avec JEE, nous avons des serveurs comme JBOSS, Websphere, GlassFish, Tomcat. Nous avons choisi d’utiliser GlassFish parce que : - il est libre et gratuit [12] ;
- il est facile à utiliser et s’intègre simplement aux environnements de développement tels que Netbeans, Eclipse [23].
Présentation des couches du serveur d’application
Le serveur d’application comprend la couche d’accès ordonnée, la
couche métier, la couche service et la couche web.
Couche métier : C’est la partie la plus importante de l’application. Il s’agit du moteur de l’application qui va s’occuper de faire les traitements. Elle correspond à la partie fonctionnelle de l’application. Son développement a été fait suivant l’approche orientée objet. Ici, il faut choisir un framework pour prendre en charge la gestion du cycle de vie de notre application. Le framework aura à créer les objets, il décidera de quand les objets seront créés. Une fois qu’il crée une instance, il sait quand la détruire, la sérialiser, la dé sérialiser ou la gérer d’une manière générale. Dans l’architecture JEE, nous avons le choix entre deux technologies : EJB (Enterprise Java Beans) et Spring. EJB est un conteneur lourd tandis que Spring est un conteneur léger.
Couche DAO (Data Access Object) : ou couche d’accès ordonnée permet de résoudre le premier problème technique. Elle fait la correspondance entre les données qui sont stockées dans la base de données relationnelle avec l’application orientée objet : Mapping Objet relationnel. Pour le Mapping Objet Relationnel nous avons opté pour
Réalisé par Mischaël Dichoso GANSE 49
Hibernate qui permet de faire la correspondance entre une base de données relationnelle et une application orientée objet. Il existe différents frameworks de Mapping Objet Relationnel.
frameworks pour gérer la couche web de l’application comme Struts, JSF, Spring MVC. Nous avons opté pour Spring MVC car il est multiplateforme, évolutif et l’implémentation est facilement maintenable.
Couche service : c’est la couche qui va permettre à l’application de communiquer avec d’autres applications distantes. C’est là qu’interviennent les MiddleWares (RMI, CORBA, EJB, SOAP,…) ou les web services. Par exemple, si une application java desktop a besoin de communiquer avec la couche métier, elle pourra utiliser les middlewares comme RMI, JMS, CORBA, SOAP. Cela veut dire que lorsque l’application java envoie une requête, la couche service se charge de faire appel à la couche métier pour les traitements. Si c’est un smartphone, on va utiliser les web services (SOAP ou REST).
Conclusion partielle : Le moteur de notre application, c’est la couche métier. Il fait les traitements. Ces traitements peuvent être déclenchés via le web (HTTP) ou via une application java desktop, ou via un smartphone… On devrait donc pouvoir consulter l’application via différentes interfaces, différents types de clients.
4.3.3 Présentation et mode de fonctionnement des middleware
Un middleware aide pour la gestion de la complexité inhérente à un système distribué. Il permet également de connecter des parties d’une application distribuée avec ‘des tuyaux de données’ à travers lesquels il fait passer des données [13]. Par exemple :
RMI (Remote Method Invocation) est une technologie développée et fournie par Sun à partir de JDK 1.1 pour permettre de mettre en œuvre facilement des objets distribués
Réalisé par Mischaël Dichoso GANSE 50
JMS (Java Message Service) est une technologie qui permet l’utilisation de système de messages pour l’échange de données entre applications CORBA (Common Object Request Broker Architecture) est une architecture logicielle pour le développement de composants qui assemblés permettent de construire des applications complètes
SOAP (Simple Object Access Protocol) est un protocole qui permet la transmission de messages entre objets distants, ce qui veut dire qu'il autorise un objet à invoquer des méthodes d'objets physiquement situés sur un autre serveur.