IV.2.2.1.3. MySQL
Le Système de Gestion de Bases de Données
utilisé pour la gestion et le stockage des données dans le cadre
de la mise en oeuvre du prototype final est MySQL dans sa version 5.1. Le
logiciel MySQL est un serveur de base de données SQL très rapide,
multi-thread, multi utilisateurs et robuste. Il est destiné aux missions
stratégiques, aux systèmes de production à forte charge,
et à l'intégration dans des logiciels déployés
à grande échelle. MySQL est une marque déposée de
MySQL AB.
Les principaux concurrents de MySQL sont : PostgreSQL,
Microsoft SQL Server, et Oracle. Ainsi, le choix de ce Serveur de
Bases de Données a été particulièrement
orienté par un certain nombre d'avantages qu'il offre aux
développeurs. En effet, par rapport aux autres SGBD cités, MySQL
est un logiciel intégrant un haut degré de portabilité, de
sécurité et constitue un système de sauvegarde assez
évolué avec utilisation optimale de ressources.
IV.2.2.2. Les outils de développement
La mise en oeuvre du serveur d'applications USSD a
nécessité un certain nombre de plateformes. Ces derniers
garantissent au serveur un haut niveau de sécurité, une couche
d'accès au données, une bonne qualité des services et
rendent ce module maintenable et réutilisable. Ces plateformes sont les
suivantes :
Mémoire de Fin d'Etudes d'Ingénieur de Conception
en Informatique : ENSP, JUIN 2008 DONFACK Cédric Pérez Page
46
IV.2.2.2.1. J2EE.
J2EE (Java Platform Enterprise Edition) est une plateforme
fortement orientée serveur pour le développement et
l'exécution d'applications distribuées. Elle est composée
de deux parties essentielles :
? un ensemble de spécifications pour une infrastructure
dans laquelle s'exécutent les
composants écrits en java : un tel environnement se nomme
serveur d'application.
? un ensemble d'API qui peuvent être obtenues et
utilisées séparément. Pour être utilisées,
certaines nécessitent une implémentation de la part
d'un fournisseur tiers.
J2EE permet une grande flexibilité dans le choix de
l'architecture de l'application en combinant les différents composants.
Ce choix dépend des besoins auxquels doit répondre l'application
mais aussi des compétences dans les différentes API de J2EE.
L'architecture d'une application se découpe idéalement en au
moins trois tiers :
? la partie cliente : c'est la partie qui permet le dialogue avec
l'utilisateur. Elle peut être composée d'une application
standalone, d'une application web ou d'applets.
? La partie métier : c'est la partie qui encapsule les
traitements (dans des EJB ou des JavaBeans).L
? a partie donnée : c'est la partie qui stocke les
données.
IV.2.2.2.2. J2ME
Historiquement, Sun a proposé plusieurs plateformes
pour le développement d'applications sur des machines possédant
des ressources réduites, typiquement celles ne pouvant exécuter
une JVM (Java Virtual Machine) répondant aux spécifications
complètes de la plateforme J2SE (Java Platform Standard Edition).
? JavaCard : pour le développement sur des cartes à
puces
? EmbeddedJava :
? PersonnalJava : pour le développement sur des machines
possédant au moins 2mo de mémoire
Mémoire de Fin d'Etudes d'Ingénieur de Conception
en Informatique : ENSP, JUIN 2008 DONFACK Cédric Pérez Page
47
J2ME (Java Platform Micro Edition) est utilisé
essentiellement dans le cadre de notre travail pour réaliser les
tests.
IV.2.2.3. Analyse du serveur d'applications
? Les acteurs du système o La
passerelle :
Elle est responsable du déclenchement des processus.
Elle envoie la requête sous forme de fichier XML (eXtended Markup
Language.) au serveur d'applications et attend une réponse .
o Le SGBD
C'est le gestionnaire des données de notre serveur.
? Les fonctionnalités du
système.
o ReceptionRequete.
o TraitementRequete.
Mémoire de Fin d'Etudes d'Ingénieur de Conception
en Informatique : ENSP, JUIN 2008 DONFACK Cédric Pérez Page
48
o EnvoieResultat.
? Le diagramme des cas d'utilisation
Figure 21: Diagramme des cas d'utilisations Serveur
d'applications
IV.2.2.4. Conception du serveur
d'applications
? Description des classes. o
ReceptionCode
Cette classe, responsable de la réception de la
requête sous forme de message XML, récupère l'information
nécessaire et l'envoie pour traitement
Mémoire de Fin d'Etudes d'Ingénieur de Conception
en Informatique : ENSP, JUIN 2008 DONFACK Cédric Pérez Page
49
o LesServicesOfferts
Cette classe ne peut pas être instanciée (IL
n'existe pas d'objets qui lui est directement lié.). Aussi, elle
contient les informations liées à tous les services notamment le
codeServices ; ainsi que les méthodes.
o EnvoieCode
Cette classe, responsable de l'envoie du résultat,
converti d'abord en MessageXML. o ServicesA
Cette classe représente un service bien défini dans
le système. Elle contient toutes les informations relatives à ce
service donné.
? Le diagramme de classes.
Figure 22: Diagramme des classes du serveur
d'applications
Mémoire de Fin d'Etudes d'Ingénieur de Conception
en Informatique : ENSP, JUIN 2008 DONFACK Cédric Pérez Page
50
? Les diagrammes de séquences.
o
ReceptionRequete
Figure 23: Diagramme de séquence
RéceptionRequete.
o TraitementRequete
Figure 24: Diagramme de sequence
TraitementRequete
o EnvoieResultat.
Figure 25: Diagramme de sequence
EnvoieResultat.
Mémoire de Fin d'Etudes d'Ingénieur de Conception
en Informatique : ENSP, JUIN 2008 DONFACK Cédric Pérez Page
52
IV.2.2.5. Test du serveur d'applications
USSD.
Ce travail n'a pas pu être testé dans sa
totalité à cause de certains manquements notamment la carte
d'extension. Qu'à cela ne tienne, un projet de déploiement de
notre travail est prévu pour le mois d'Août. Cela garantit
l'existence du matériel nécessaire. Toutefois, ce projet a eu
deux grands points d'énormes difficultés à savoir le
déploiement d'OpenSS7 et la mise en oeuvre du server USSD. La plateforme
ayant été installée correctement, notre prototype
consistera à montrer que notre serveur d'applications USSD fonctionne
normalement.
| 
