Fitouhi Naoufel

Cycle de formation des ingénieurs en Télécommunications
Option :
Réseaux et Services Mobiles
Rapport de Projet de fin d’études
Thème :
Développement d’une plateforme de

supervision et contrôle distants par SMS et
MMS
Réalisé par :
Fitouhi Naoufel
Encadrants :
M. Mourad Lahmedi
Mme. Benletaifa Asma
Travail proposé et réalisé en collaboration avec ALCATEL Tunisie
Année universitaire : 2005/2006

A ma famille,
A mes amis,
A tous ceux qui me sont chers.
Résumé
Les services à valeur ajoutée ne cessent pas de prendre une valeur et importance pour
les opérateurs des télécommunications ainsi que pour les entreprises travaillantes dans le
même domaine. Cette importance a poussé l’innovation afin de créer des nouveaux services
visant un grand nombre de clients et ayant de l’intérêt pour eux.
Ce projet présente une initiative pour la création d’un service à valeur ajouté à caractère
professionnel, ceci en développant une plateforme qui assure le bon fonctionnement de ce
service et la connexion entre les différents acteurs impliqués. Le service permettra la
supervision et le contrôle distants d’un ensemble de réseaux et équipements hétérogènes en
utilisant d’une part les services du réseau mobile le SMS e le MMS pour assurer la mobilité
des client et d’autre part les services Web comme solution pour la liaison des différents
réseaux avec notre plateforme.
Mots clés: Service à valeur ajoutée, SMS, MMS, Service Web, supervision, contrôle.
Avant Propos
Le travail présenté dans ce rapport a été réalisé dans le cadre de notre projet de fin
d'études du cycle d'Ingénieur en Télécommunications à l'Ecole Supérieure des
Communications de Tunis (SUP'COM). Ce projet a été réalisé dans le locale d’ALCATEL
Tunisie.
Au terme de ce travail, je tiens à remercier pour m'avoir encadrer dans ce stage d’ingénieur,
M. Mourad Lahmedi et Mme. Asma Benletaifa pour leurs soutiens tant sur le point
scientifique que personnel, leurs dévouements à m’installer parmi leurs occupations et leurs
contributions à me fournir les informations nécessaires à ce projet.
J’adresse ma plus vive reconnaissance à tous mes enseignants de SUP’COM pour la

formation d'ingénieur qu’ils m’ont donnée.
Je remercie tous ceux qui n'ont épargné aucun effort, de près ou de loin, pour me permettre
d'accomplir mon projet et j'espère que ça sera le bon départ pour ma carrière d'Ingénieur.
TABLE DES MATIERES
INTRODUCTION GENERALE ............................................................................................ 1

CHAPITRE 1 : CONCEPTS DE BASE................................................................................. 3
1. Services Mobiles ....................................................................................................... 4
1.1. Short Message Service (SMS).............................................................................. 4
1.1.1. Définition................................................................................................... 4
1.1.2. Architecture du service............................................................................ 5
1.1.3. Les services SMS à valeur ajoutée .......................................................... 7
1.2. Multimedia Messaging Service (MMS) .............................................................. 7
1.2.1. Architecture MMS ................................................................................... 7
1.2.2. Entités MMS ............................................................................................. 8
1.2.3. Interfaces MMS ........................................................................................ 9
1.2.4. Fonctionnement du service MMS : Description du scénario d’envoi
d’un message multimédia ...................................................................................... 11
2. Les services Web..................................................................................................... 13
2.1. Définition............................................................................................................. 13
2.2. Principe fondamental du service Web.............................................................. 14
2.3. A quoi ressemble un service Web ..................................................................... 15
2.4. La couche de technologie dans un service Web ............................................... 15
2.4.1. Découverte............................................................................................... 16
2.4.2. UDDI (Universal Description, Discovery et Integration) ................... 16
2.4.3. Description .............................................................................................. 17
2.4.4. WSDL (Web Services Description Language)..................................... 17
2.4.5. Empaquetage .......................................................................................... 17
2.4.6. SOAP (Simple Object Access Protocol) ............................................... 18
2.4.7. Transport ................................................................................................ 18
2.4.8. Réseau...................................................................................................... 18
2.4.9. Application.............................................................................................. 19
2.5. Architecture des services Web .......................................................................... 19
CHAPITRE 2 : ETUDE DE L’EXISTANT ET SPECIFICATION ................................. 21
1. Etude de l’existant.................................................................................................. 22
1.1. Historique de ALMAP FM................................................................................ 22
1.2. Fonctionnalités de ALMAP FM........................................................................ 22
1.3. Architecture de ALMAP FM ............................................................................ 22
1.4. Critique de l’existant......................................................................................... 24
2. Spécification des besoins........................................................................................ 24
2.1. Les besoins fonctionnels..................................................................................... 24
3. Les Acteurs.............................................................................................................. 26
4. Diagramme des cas d’utilisation ........................................................................... 26
4.1. Diagramme des cas d’utilisation général ......................................................... 26
4.2. Description du cas d’utilisation Gérer Profil................................................... 28
4.3. Description du cas d’utilisation Administrer utilisateurs .............................. 30
4.4. Description du cas d’utilisation Administrer CLI .......................................... 31
i
4.5. Description du cas d’utilisation Gérer SMS-MMS-Mail................................ 32
CHAPITRE 3 : CONCEPTION DE L’APPLICATION.................................................... 36
1. Décomposition en Packages................................................................................... 37
2. Conception de la base de données......................................................................... 38
3. Conception détaillée ............................................................................................... 39
3.1. Package « Web Module »................................................................................... 39
3.2. Package « Server Interface »............................................................................. 40
3.3. Package « Server Process » ............................................................................... 41
3.4. Package « Notification Manager ».................................................................... 42
3.5. Package « NSS-API » ......................................................................................... 43
3.5.1. Sous Package « Client Interface »......................................................... 43
3.5.2. Sous Package « Client Services » .......................................................... 44
CHAPITRE 4: REALISATION ........................................................................................... 46
1. Description de l’environnement de travail........................................................... 47
1.1. Environnement technique.................................................................................. 47
1.2. Environnement Logiciel..................................................................................... 48
1.2.1. Les langages de développement ............................................................ 49
1.2.2. L’environnement de développement .................................................... 49
1.2.3. Système de Gestion de Base de Donnée MySQL ................................. 50
1.2.4. Serveur Web Apache Tomcat ............................................................... 50
1.2.5. Protocole de communication client/serveur......................................... 50
2. Description du travail réalisé ................................................................................ 51
2.1. Principales Pages d’administration .................................................................. 52
2.2. Principales Pages d’utilisation .......................................................................... 54
2.3. Exemple de diagnostique en utilisant les MMS ............................................... 58
3. Chronogramme d’avancement du travail............................................................ 59
CONCLUSION GENERALE ............................................................................................... 62
BIBLIOGRAPHIE ................................................................................................................. 63
ii
LISTE DES FIGURES
Figure 1: Architecture du service SMS ...................................................................................... 6

Figure 2: Environnement MMS ................................................................................................. 8
Figure 3: Architecture du service MMS..................................................................................... 8
Figure 4: Interfaces MMS ........................................................................................................ 10
Figure 5: Envoi d’un message multimédia : Flux d’information ............................................. 12
Figure 6: Un Service Web permet l'accès au code de l'application en utilisant les standards de
la technologie Internet ...................................................................................................... 14
Figure 7: : Le service Web offre un couche d'abstraction entre l'application client et le code de
l'application ...................................................................................................................... 14
Figure 8: : Un service web est constitué de plusieurs composants clés ................................... 15
Figure 9: Pile de technologies dans les services Web.............................................................. 16
Figure 10: Structure des données UDDI .................................................................................. 16
Figure 11: Structure de WSDL................................................................................................. 17
Figure 12: Structure d'un message SOAP ................................................................................ 18
Figure 13: Rôles et opérations des services Web..................................................................... 19
Figure 14: Architecture de FM................................................................................................. 23
Figure 15: Diagramme des cas d'utilisation générale............................................................... 27
Figure 16: Diagramme relatif au cas d'utilisation Gérer Profil ................................................ 28
Figure 17! Diagramme de séquence relatif au cas d'utilisation "Gérer Profil" ........................ 29
Figure 18: Diagramme relatif au cas d'utilisation administrer utilisateurs .............................. 30
Figure 19: Diagramme de séquence relatif au cas d'utilisation administrer utilisateurs .......... 31
Figure 20: Diagramme relatif au cas d'utilisation administrer CLI......................................... 31
Figure 21: Diagramme de séquence relatif au cas d'utilisation administrer CLI ..................... 32
Figure 22: Diagramme relatif au cas d'utilisation Gérer SMS-MMS-Mail.............................. 32
Figure 23: Diagramme de séquence pour le scénario d’envoi de notification par SMS.......... 33
Figure 24: Diagramme de séquence pour le scénario de réception de SMS ........................... 34
Figure 25: Diagramme de séquence pour le scénario d’envoi MMS ...................................... 34
Figure 26: Diagramme des Packages ...................................................................................... 37
Figure 27: Modèle conceptuel de la base de données .............................................................. 38
Figure 28: Diagramme des classes pour le package "web Module" ........................................ 39
Figure 29: Diagramme des classes pour le package"Server Intrface"...................................... 40
Figure 30: Diagramme des classes pour le package"Server Process"...................................... 41
Figure 31: Diagramme des classes pour le package"Notification Manager"........................... 42
Figure 32: Diagramme des sous packages pour le package"NSS-API".................................. 43
Figure 33: Diagramme des classes pour le sous package"Client Interface" ............................ 44
Figure 34: Diagramme des classes pour le sous package " Client Services" ........................... 44
Figure 35: Intérêt de la Plate-forme Nextenso ........................................................................ 47
Figure 36: Composition logicielle de la Plate-forme ............................................................... 48
Figure 37: Page Home............................................................................................................. 52
Figure 38: Page admin home.................................................................................................... 53
Figure 39: Page user inscription............................................................................................... 53
Figure 40: Page user inscription............................................................................................... 54
Figure 41: Page user home ....................................................................................................... 55
Figure 42: network management.............................................................................................. 55
Figure 43: Page Filter Management ......................................................................................... 56
iii
Figure 44: Page filter description ............................................................................................. 56
Figure 45: Page schedule management .................................................................................... 57
Figure 46: Page Add command................................................................................................ 57
Figure 47: Le Map sur le terminale.......................................................................................... 58
Figure 48: Le Map en Grande taille ......................................................................................... 58
Figure 49: Autre Example de Map........................................................................................... 59
Figure 50: Taille plus Grande................................................................................................... 59
Figure 51: chronogramme d'avancement du travail ................................................................. 60
LISTE DES TABLES
Tableau 1: Equipements du réseau SMS.................................................................................... 6
iv
LISTE DES ABBREVIATIONS
3G Third Generation
3GPP Third Generation Partnership Project
API Application Programming Interface
ASCII American Standard Code for Information Interchange
BSC Base Station Controller
BSS Base Station Subsystem
BTS Base Transceiver Station
CLI Command Line Interface
EDGE Enhanced Data Rate for Global Evolution
ETSI European Telecommuncations Standard Institute
GGSN Gateway GPRS Support Node
GPRS General Packet Radio Service
GSM Global System for Mobile communication
HLR Home Location Register
HTML HyperText Markup Language
HTTP HyperText Transfer Protocol
IP Internet Protocol
LAN Local Area Network
MMS Multimedia Messaging Service
MMSC MMS Center
MMSE MMS Environment
OSA Open Service Architecture
OTA Over The Air
SMIL Synchronized Multimedia Integration Language
SMS Short Message Service
SMSC SMS Center
GMSC Gateway MSC
IWMSC InterWorking MSC
SOAP Simple Object Access Protocol
v
SS7 Signaling System Number 7
TCP Transmission Control Protocol
UDDI Universal Description, Discovery and Intergration
UML Unified Modelling Language
UMTS Universal Mobile Telecommunications System
VAS Value-Added Service
VASP VAS Provider
VLR Visitor Location Register
W3C World Wide Web Consortium
WAP Wireless Application Protocol
WSDL Web Service Description Langage
XML eXtensible Markup Language
vi
vii
Introduction Générale
INTRODUCTION GENERALE
Dans un monde télécom caractérisé par la concurrence et en même temps par la ressemblance
des technologies utilisées et des services de bases offerts il s’avère nécessaire pour les
opérateurs de trouver un moyen pour se distinguer sur le marché et par suite de garder ses
clients et de conquérir d’autre marchés. Les principaux moyens pour assurer ces objectifs
sont les services à valeur ajoutée qui désignent les services qui dépassent l’accomplissement
du service pour considérer son assurance.
Ce raisonnement a été la principale motivation pour la société ALCATEL Tunisie pour
investir dans le développement des services à valeur ajoutée en créant un espace partenariat
dans lequel on a mis en disposition les outils nécessaires pour le développement des services
dont on cite une Plateforme de développement et de gestion des applications SMS/MMS les
serveurs et les modems GSM.
Dans ce cadre ALCATEL Tunisie nous a proposé pour notre projet de fin d’études la
réalisation d’une plateforme qui assure les services à valeur ajoutée suivants :
Supervision distante par SMS
Contrôle distant par SMS
Diagnostique distante par MMS
En effet, la plupart des applications de supervision présentes sur le marché ont été conçues et
développées selon le modèle interaction homme machine, et donc nécessitent la présence
continue de l’administrateur devant sa machine pour réagir efficacement en cas d’anomalie
remontée du réseau. Cette contrainte est difficile à gérer puisque les réseaux supervisés et
spécialement les réseaux de télécommunication fonctionnent en continu. De plus les
notifications remontées peuvent être causés par des problèmes critiques qui nécessitent une
intervention rapide et si possible à distance.
Pour résoudre un tel problème, il fallait penser à une solution qui permet de notifier
l’administrateur en cas d’alerte pertinente mais aussi de lui donner la possibilité d’agir sur le
réseau à distance. L’idée est d’exploiter des technologies existantes, pas chers et simple à
utiliser à savoir:
1 2005/2006
Introduction Générale
Le service de messagerie Short Message Service (SMS) via le réseau GSM.

Le service de messagerie multimédia Multimédia Messaging Service (MMS) via le
réseau GSM ou le réseau GPRS.
Le service de messagerie électronique E-Mail via le réseau publique Internet.
Mais l’implémentation d’une telle application par une entreprise, pour une utilisation dédiée
et unique par l’administrateur, n’est pas profitable puisqu’elle nécessite beaucoup
d’investissements. Pour cela, les gens pensent aujourd’hui aux services de masse dont l’intérêt
est d’offrir la possibilité aux entreprises de s’inscrire à des services de ce genre auprès d’une
société de service qui s’engage de tout investissement antérieur. De plus, elle leur garantit la
qualité de service et la sécurité optimale.
Notre projet, effectué au sein de l’Espace Partenariat d’Alcatel Tunisie (EPA), s’inscrit dans
ce courant thème puisque son objectif est de concevoir et d’implémenter une plateforme
permettant aux administrateurs réseaux de les superviser à distance via le réseau mobile : par
SMS ou MMS. Cette plateforme doit être susceptible de gérer différents types de réseaux
avec des équipements hétérogènes et supporter différents protocoles de gestion des réseaux.
Elle doit être alors la plus générique possible.
Dans ce rapport, nous commençons dans un premier chapitre par présenter une étude
théorique aux grands concepts rencontrés lors de la réalisation du projet à savoir les services
de messageries (SMS, MMS) et les services web. Le deuxième chapitre est consacré à une
étude de l’existant et une spécification des besoins. Le troisième chapitre traite la conception
détaillée du projet. Enfin, le chapitre réalisation va illustrer par des captures d'écran le travail
réalisé ainsi qu’une description de l’environnement du travail. Tout au long de ce travail nous
allons adopter la méthodologie orientée objet et le formalisme UML (Unified Modeling
Langage).
2 2005/2006
Chapitre 1 : Concepts De Base
Introduction
Dans un monde qui se veut sans frontières où la communication est un besoin vital, il est
important de mettre en place les bons outils et techniques pour garantir la fiabilité et la qualité
des moyens de communication. De tels outils se résument dans un bon dispositif de
supervision et d’administration. Pour mettre en place une application de supervision
innovante permettant l’intervention et la résolution des problèmes en un minimum de temps il
faut bien choisir les technologies adéquates qui subviennent à ces besoins. Une plateforme
exploitant les services de messageries via le réseau mobile ou le réseau Internet s’avère la
meilleure solution pour assurer une supervision continue et efficace. Alors, il est nécessaire de
faire une étude complète sur les services de messageries SMS (Short Message Service) et
MMS (Multimedia Messaging Service) et sur les concepts des services web.
3 2005/2006
1. Services Mobiles
Les services offerts par le réseau mobile sont multiples mais dans la suite nous nous
contenterons d’étudier les services utilisés dans le projet.
1.1. Short Message Service (SMS)
De nos jours la plus part des utilisateurs bénéficie de la technologie des messages courts SMS.
Elle permet de recevoir sur le téléphone mobile toute sorte d'informations et d'envoyer des
SMS pour effectuer des opérations ou pour demander des informations. Dans cette partie,
nous allons définir le service SMS, nous présentons une brève description de son
fonctionnement, de son architecture physique et de quelques services.
1.1.1. Définition
Le service Short Message Service (SMS) [1] permet d'envoyer ou de recevoir des courts
messages texte, comprenant jusqu'à 160 caractères à un téléphone GSM adapté dont la carte
SIM ait été autorisée par l'opérateur du réseau. Dans le standard GSM sont précisés deux
types différents de SMS : SMS Point to Point (SMS/PP) qui permet d'envoyer un message
texte à partir d'un téléphone GSM vers un autre SMS Cell Broadcast (SMS/CB) qui permet
d'envoyer simultanément un ou plusieurs messages (broadcast) à tous les téléphones situés à
l'intérieurs d'une zone déterminée couverte par une ou plusieurs cellules radio. L'envoi d'un
SMS PP, de la part d'un téléphone GSM à un autre, doit être considéré comme l'enchaînement
de deux opérations : l'acheminement du message à partir d'un téléphone mobile vers une
entité particulière du réseau, appelé SMSC (Short Message Service Center), et ensuite à partir
du SMSC jusqu'au téléphone récepteur. La première opération est appelée SMS-MO (SMS
Mobile Originated), tandis que la deuxième est appeler SMS-MT (SMS Mobile Terminated) :
SMS MO : permet à l'abonné d'envoyer des messages texte ( 160 caractères au maximum) à
un autre terminal GSM, à un fax ou à une adresse de courrier électronique sur internet.
Seulement quelques téléphones sont adaptés pour l'envoi de messages brefs.
SMS MT : permet à l'utilisateur de recevoir des messages texte jusqu'à 160 caractères sur
l'écran de son téléphone GSM.Presque tous les téléphones sont réglés pour profiter de ce type
de service de réseau, excepté les vieux téléphones.
4 2005/2006
1.1.2. Architecture du service
Le service des messages courts offert par le réseau GSM (SMS, pour Short Messages Service)
permet à un utilisateur de composer un message textuel d'aux plus 160 caractères (codés à
l'aide d'Ascii 7 bits sur 140 octets) à partir de son terminal mobile et de l'envoyer à un
destinataire possédant également un téléphone radio mobile GSM. Les messages SMS émis et
reçus, sont véhiculés par le réseau de signalisation sémaphore n°7 (SS7). Ils sont soit transmis
directement au terminal destinataire du message (si celui-ci est allumé), soit stockés dans le
serveur des messages courts (SMSC, pour SMS Center) par lequel ils transitent. Les messages
courts ne circulent pas dans les mêmes canaux logiques que la voix ou les donnés, il est ainsi
possible à un utilisateur en communication téléphonique (avec un autre correspondant) de
recevoir simultanément des messages courts. Le service SMS nécessite la mise en place d'un
ou plusieurs serveurs spécifiques dans le réseau. Le serveur de messages courts (SMSC)
assure le stockage des messages SMS (dans la bases de données), la distribution des messages
SMS aux terminaux mobiles destinataires et le traitement des dates de validité des messages.
Dés que le terminal mobile se manifeste, le réseau avertit le SMSC qu'il peut délivrer le
message à son destinataire avec succès. Le SMSC est repéré par un numéro de téléphone
appartenant au PLMN (Public Land Mobile Network).Le dialogue entre le SMSC et le
terminal mobile se fait à travers le MSC (Mobile services Switching Center). Pour
l'acheminement d'un message vers un terminal mobile, une passerelle est nécessaire : la
GMSC. Celle-ci route les messages SMS vers le MSC visité (VMSC pour Visited MSC) en
interrogeant le HLR (Home Location Register). Un message SMS issu d'un terminal mobile
est routé vers le SMSC du MSC associé au terminal mobile vers le MSC associé au SMSC
(appelé ici SMS-IW-MSC pour SMS-InterWorking-MSC car il est responsable de l'inter
fonctionnement entre PLMN et SMSC) (figure 1).
5 2005/2006
Figure 1: Architecture du service SMS
Le tableau suivant décrit rapidement les équipements de l'architecture du réseau SMS.
Nom Signification Fonction

BTS Base Transceiver Station Station de base réceptionnant les appels entrants
et sortants du ME.
ME Mobile Equipement Terminal de l'abonné.
SIM Sim Identity Mobile Carte SIM identifiant l'abonné sur le réseau
défini.
BSC Base Station Controller Contrôleur de station de base
SMSC SMS Center Le centre des messages courts.
GMSC Gateway MSC Formé par : OMC, NMC, TMN
OMC Operations and Maintenance Supervision locale des équipements BSC, MSC,
Center VLR.
NMC Network and Management Administration de l'ensemble du réseau par un
Center contrôle centralisé.
TMN Telecommunication Composant qui permet la supervision des
Management Network réseaux.
HLR Home Location Register Base de données sur l'identité et la localisation
des abonnées.
MSC Mobile Switching Center Commutateur du réseau.
VLR Visitor Location Register Base de donnée sur les visiteurs du réseau
Tableau 1: Equipements du réseau SMS
6 2005/2006
1.1.3. Les services SMS à valeur ajoutée
Le principe d'une application SMS à valeur ajoutée est de permettre à tout utilisateur d'un
téléphone mobile d'effectuer deux types d'opérations :
Opération de type Push : demander une information en envoyant un SMS à un
numéro abrégé (envoi d'un SMS pour récupérer une valeur boursière...).
Opération de type Pull : récupérer une informations sans la demander (dans ce cas
l'utilisateur doit s'inscrire au service). En effet, les utilisateurs peuvent être informés
de plusieurs événements qui peuvent se produire tels que la rupture de stock pour un
produit donné, la réception d'un mail...
1.2. Multimedia Messaging Service (MMS)
Le Service de Messagerie Multimédia (MMS, Multimedia Messaging Service) [2] permet la

mise
en place de nouveaux services d’échanges de messages pour les terminaux mobiles. Il est
normalisé par le WAP Forum et le 3GPP. Le MMS constitue une véritable révolution par
rapport au SMS souvent comparée au passage de DOS à Windows. Le MMS s’appuie sur
un MMSC (Multimedia Messaging Service Centre) qui autorise l’échange de messages de
mobile à mobile, de mobile à e-mail fixe ainsi que d’e-mail fixe à mobile. Outre le contenu
textuel déjà familier du SMS, les messages MMS peuvent contenir des images fixes, du
texte, des clips vocaux ou audio, et plus tard aussi des clips vidéo. Le message MMS est
une présentation multimédia : ce n'est donc pas un fichier texte avec des pièces jointes.
1.2.1. Architecture MMS
La figure si dessous décrit l’architecture générale du service MMS. Elle implique différents
réseaux et doit intégrer les systèmes de messagerie déjà existants dans ces réseaux. Le
terminal mobile fonctionne dans l’environnement MMS (MMSE, Multimedia Messaging
Service Environment). Cet environnement comprend des réseaux mobile de 2éme et 3éme
génération et fournit toutes les fonctions requises par le service telles que relais, stockage et
notification.
7 2005/2006
Figure 2: Environnement MMS
1.2.2. Entités MMS
Diverses entités sont impliquées dans l’architecture MMS afin de mener à bien l’envoi et la
réception d’un message multimédia (figure 3). Ces entités sont les suivants :
Figure 3: Architecture du service MMS
8 2005/2006
:
MMSE : L’environnement MMS représente l’ensemble des éléments MMS, sous le
contrôle d’une administration donnée (fournisseur MMS) en charge de fournir le
service à des usagers MMS.
MMS User Agent : Il s’agit de l’application utilisateur présente sur la station mobile
permettant de visualiser, de composer et de traiter les messages multimédia.
User Databases : Il s’agit des bases de données utilisateur contenant l’information
concernant les souscripteurs au service MMS. Cette information comprend les détails
de souscription et les profils d’usager.
MMS Relay/Server : Le MMS Relay route les messages dans l’environnement MMS
ou à l’extérieur de cet environnement. Le MMS Server stocke les messages en attente
de récupération par leur destinataire. Les entités MMS Relay et MMS Server peuvent
être implantées dans des équipements distincts ou intégrées dans le même équipement.
Dans ce dernier cas, l’équipement est appelé MMSC (Multimedia Messaging Service
Centre). Le MMSC s’interface à différents systèmes de messagerie tels que SMSC,
système de messagerie électronique et système de messagerie unifiée.
MMS VAS Applications : Les applications MMS VAS offrent des services à valeur
ajoutée aux utilisateurs du service MMS. L’application VAS interagit avec le MMSC
afin de délivrer des MMSs à des MMS User Agent. Un MMS User Agent peut aussi
soumettre un message à une application VAS à une adresse représentée généralement
par un numéro court.
1.2.3. Interfaces MMS
Les différentes entités de l’environnement MMS communiquent à travers un ensemble

d’interfaces décrites par la figure ci-dessous.
L’interface MM1 permet à l’agent utilisateur MMS (MMS User Agent) d’interagir
avec le MMSC (soumettre un messagerie multimédia, être notifié de l’arrivée d’un
message, télécharger un message).
L’interface MM2 est l’interface entre les entités MMS Relay et MMS Server. Elle
n’est pas normalisée. La plupart des solutions des fournisseurs intègrent les deux
entités dans le même équipement, rendant l’interface propriétaire.
9 2005/2006
Figure 4: Interfaces MMS
L’interface MM3 est présente entre le MMSC et les serveurs externes. Elle permet au
MMSC d’échanger des messages avec d’autres serveurs de messagerie externes (E-
mail server, SMSC, Unified Messaging Server, etc). Les protocoles pouvant être
utilisés sont ceux normalisés par l’Internet tels que SMTP, HTTP, IMAP, POP, et
T30.
L’interface MM4 permet l’échange de MMS entre deux MMSCs appartenant à deux
environnements MMS distincts. Le protocole utilisé est SMTP.
L’interface MM5 permet au MMSC d’interroger le HLR pour identifier la localisation
de l’usager et ainsi pouvoir lui envoyer une notification pour l’informer de l’arrivée
d’un message multimédia. Le protocole utilisé est MAP. Si le MMSC s’appuie sur un
SMSC pour l’envoi d’un SMS, l’interface MM5 n’est pas indispensable.
L’interface MM6 qui n’est pas encore normalisée permet au MMSC d’accéder aux
informations des bases de données des usagers MMS telles que les données de
présence.
L’interface MM7 permet le transfert de messages multimédia d’un MMSC vers des
applications VAS et vice versa. Lorsque l’application envoie un MMS au MMSC, il
10 2005/2006
est délivré à l’ensemble des destinataires à travers l’interface MM1. Parmi les
protocoles utilisés pour la réalisation de cette interface figurent HTTP et SMTP.
L’interface MM8 permet au MMSC d’interagir avec le système de facturation. Elle
n’est pas encore normalisée.
Alors que les messages courts SMS sont émis et reçus sur des canaux de signalisation du
réseau SS7 entre le MSC/SGSN et le SMSC, les messages multimédia sont transmis sur les
canaux de parole GSM ou dans les contextes PDP GPRS.
1.2.4. Fonctionnement du service MMS : Description du scénario d’envoi d’un

message multimédia
Les étapes suivantes montrent le fonctionnement du service MMS:
L’utilisateur active le client MMS (application disponible sur la station mobile

permettant l’envoi / la réception de MMS).
L’utilisateur sélectionne ou introduit l’adresse du destinataire du message multimédia.
L’utilisateur compose / édite le message multimédia à émettre (e.g. avec une image,
du texte et /ou du son).
L’utilisateur émet le message multimédia à son MMSC à travers l’interface MM1.
Le MMSC de l’émetteur relaye le message multimédia au MMSC du destinataire à
travers l’interface MM4, en supposant dans cet exemple que l’émetteur et le récepteur
du message multimédia n’appartiennent pas au même MMSE.
Le MMSC destinataire émet une notification (en s’appuyant par exemple sur les
services d’un SMSC) au client MMS destinataire sur l’interface MM1.
Le client MMS destinataire télécharge le message multimédia stocké sur le MMSC à
travers l’interface MM1.
Le client MMS destinataire notifie l’utilisateur de l’arrivée d’un nouveau message
multimédia.
L’utilisateur visualise le message sur sa station mobile.
11 2005/2006
Voici une description des flux d’information lors de l’envoi d’un message multimédia :
Figure 5: Envoi d’un message multimédia : Flux d’information
Le MMS UA émetteur soumet son message multimédia au MMSC auquel il est associé sur
l’interface MM1 en utilisant la requête MM1_submit.REQ. Le MMSC acquitte la requête par
une réponse MM1-submit.RES. Cette acquittement contient l’état de la requête soumise au
MMSC. La demande peut être acceptée ou refusée (e.g. absence de souscription, service
indisponible, message incorrect, etc). Après acceptation de la requête, Le MMSC émetteur
identifie le(s) MMSC(s) associé(s) au(x) récepteur(s). Plusieurs possibilités existent :
L’émetteur et le destinataire du MMS appartiennent au même MMSE. Dans ce cas, ils
sont associés au même MMSC.
L’émetteur et le destinataire appartiennent à des environnements MMS différents. Le
destinataire est associé à un autre MMSC auquel le MMSC émetteur relaye le message
multimédia sur l’interface M4 en utilisant la requête MM4_forward.REQ.
Le destinataire n’est pas un utilisateur du service MMS. Il s’agit par exemple d’un
destinataire disposant du service SMS ou d’un compte de messagerie électronique. Le MMSC
émetteur relaye alors le message sur l’interface M3 au serveur de messagerie du destinataire
(SMSC, serveur E-mail, serveur de messagerie unifiée). Dans le second cas, le MMSC
destinataire retourne un acquittement MM4_forward.RES indiquant le statut de la demande
(e.g., absence de souscription du destinataire, service indisponible, acceptation de la
demande). Le MMSC destinataire émet une notification (requête MM1_notification.REQ) au
12 2005/2006
destinataire l’informant de l’arrivée d’un MMS, acquittée par ce dernier (réponse

MM1_notification.RES). Le destinataire demande le téléchargement du message (requête
MM1_retrieve.REQ) qui lui est retourné dans la réponse MM1_retrieve.RES. Le destinataire
acquitte alors la réception du message multimédia au MMSC par une requête
MM1_acknowledgement.REQ. Si le MMS UA émetteur indique dans la requête
MM1_submit.REQ la demande d’un rapport de livraison, le MMSC destinataire le génère
(MM4_delivery_report.REQ) et le retourne au MMSC origine. Ce dernier produit alors la
requête MM1_delivery_report.REQ sur l’interface MM1 reçue par le MMS UA émetteur. Si
le MMS UA émetteur indique dans la requête MM1_submit.REQ la demande d’un rapport à
la lecture du message par le destinataire, le MMSC destinataire le génère
(MM4_read_reply_report.REQ) et le retourne au MMSC origine qui l’acquitte
(MM4_read_reply_report.RES). Enfin, le MMSC origine délivre le rapport
(MM1_read_reply_originator.REQ) au MMS UA émetteur sur l’interface MM1.
2. Les services Web

Il existe beaucoup de méthodes, dans la littérature, pour implémenter un dialogue entre deux
applications distantes. La méthode qui nous vient directement à l'esprit c'est les Sockets.
Mais, cette méthode exige une implémentation très coûteuse (en temps). En effet, le débogage
devient de plus en plus difficile chaque fois que la complexité du dialogue augmente.
Ajoutons à cela les problèmes de portabilité du code, etc. Pour nous faciliter la tâche nous
allons implémenter l'architecture distribuée client serveur comme service Web.
Ce paragraphe va introduire la notion de Service Web.
2.1. Définition
Un service Web [5] est un module logiciel effectuant une tâche discrète ou un ensemble de
tâches, qui peut être localisé et appelé au travers d’un réseau, en particulier le World Wide
Web. En effet, une application cliente peut appeler une série de services Web par
l’intermédiaire d’appels de procédures distantes ou d’un service de messagerie pour fournir
une partie de la logique de l’application (figure 6). En d'autres termes, si une application peut
être accessible sur le réseau en utilisant une combinaison de protocoles comme HTTP, XML,
SMTP, ou Jabber, alors c'est un service Web.
13 2005/2006
Figure 6: Un Service Web permet l'accès au code de l'application en utilisant les standards de la
technologie Internet
2.2. Principe fondamental du service Web
Un Service Web est une interface positionnée entre le code de l'application et l'utilisateur de
ce code. Elle agit comme couche d'abstraction, qui sépare les détails spécifiques à un langage
ou plate-forme donnée, de la façon dont le code sera invoqué. Cette couche de standardisation
signifie que n'importe quel langage qui supporte le service Web peut accéder aux
fonctionnalités de l'application (figure 7).
Figure 7: : Le service Web offre un couche d'abstraction entre l'application client et le code de
l'application
Les services Web que nous voyons aujourd'hui sur Internet sont les sites Web HTML. Dans
ces services –les mécanismes de publication, de gestion, de recherche– sont accessible via des
protocoles standard comme HTTP et HTML. Les applications client (navigateur Web) qui
comprennent ces standards peuvent interagir avec ces services.
À cause de cette couche d'abstraction offerte, il n'est plus problème que les applications
clients sont écrites en Java et les clients en C++, ou bien les applications sont déployés sur
14 2005/2006
Unix alors que les clients tournent sur le modeste Windows. Les services Web permettent
l'interopérabilité cross plateforme. L'interopérabilité est un gain important lors de
l'implémentation des services web.
2.3. A quoi ressemble un service Web
Un service Web est un framework de messagerie. Le seul besoin requis dans un service Web
c'est la possibilité d'envoyer et de recevoir des messages en utilisant une sorte de combinaison
de technologies Internet (figure 8).
Figure 8: : Un service Web est constitué de plusieurs composants clés
La forme de service web la plus commune c'est l'appel de procédures distantes, dans lequel le
message encode « Appelez ces routines avec ses arguments » et « voici les résultats d'appel de
routine ». Le code de l'application tient tout le business logic et la logique nécessaires pour
offrir les services. Le Service Listener parle le protocole de transport (HTTP, SOAP, Jabber,
etc.) et reçoit les requêtes entrantes. Le Service Proxy décode ses appels en des appels de
procédure dans le code de l'application. Le Service Proxy peut encoder ensuite la réponse à la
requête du Service Listener. Les composants Service Proxy et Service Listener peuvent être
soit des applications autonomes (un serveur TCP ou demon HTTP) ou bien peuvent tourner
dans le contexte d'une autre application.
2.4. La couche de technologie dans un service Web
L'architecture d'un service Web est implémentée à travers cinq technologies mises en couches
comme le décrit la figure suivante :
15 2005/2006
Figure 9: Pile de technologies dans les services Web.
2.4.1. Découverte
La couche découverte offre aux consommateurs un mécanisme pour dégager les descriptions
des fournisseurs. Un des mécanismes de découverte largement reconnus est Universal
Description, Discovery and Intergration (UDDI).
2.4.2. UDDI (Universal Description, Discovery et Integration)

Il s’agit d’une spécification de registre distribué d’informations sur des services Web [4].
Lorsqu’un service Web a été développé et qu’un document le décrivant a été créé, il doit y
avoir un moyen de mettre les informations à la disposition des utilisateurs désirant utiliser le
service Web décrit. La publication d’un service Web dans un registre UDDI permet aux
utilisateurs de rechercher et d’apprendre l’existence du service Web. Le contenu d’un registre
UDDI est similaire à celui d’un répertoire téléphonique (figure 10):
Dans la section des “pages blanches” du registre, on trouve des informations comme le nom,
l’adresse et le numéro de téléphone du business qui propose un ou plusieurs services Web.
La section des “pages jaunes” identifie le type de business et la classe par industrie.
La section des “pages vertes” fournit des informations sur les services Web proposés par le
business.
Figure 10: Structure des données UDDI
16 2005/2006
2.4.3. Description
Lorsqu'un service Web est implémenté, il doit faire des décisions à chaque niveau inférieur il
va supporter. Une description représente ces décisions d'une manière à permettre au
consommateur de contacter et utiliser le service. Le langage WSDL (Web Service Description
Langage) est en fait le standard qui offre ces descriptions. Il existe aussi d'autres approches
moins connues comme W3C Ressource Description Framework (RDF) et DARPA Agent
Markup Language (DAML).
2.4.4. WSDL (Web Services Description Language)

Un service Web n’est utilisable que si d’autres personnes peuvent découvrir ce qu’il fait et
comment l’appeler. De plus, les développeurs doivent posséder suffisamment d’informations
sur un service Web pour pouvoir écrire un programme client qui l’appelle. WSDL {4] est un
langage basé sur XML qui permet de définir des services Web et de décrire la manière d’y
accéder (figure 11). Il décrit en particulier les contrats de données et de messages d’un service
Web. En examinant le document WSDL d’un service Web, les développeurs connaissent les
méthodes disponibles et savent comment les appeler en utilisant les paramètres adéquats.
Figure 11: Structure de WSDL
2.4.5. Empaquetage
Pour que les données puissent être transportées par la couche réseau, elles doivent être
empaquetées dans un format que toutes les parties peuvent comprendre (le processus s'appelle
« Serialisation » et « Marshalling »). HTML est un format d'empaquetage, mais il peut être
inconvenable pour travailler avec puisque HTML est plus lié à la présentation de l'information
qu'à sa signification. Actuellement, XML est la base de tout format d'empaquetage pour les
services webs, puisque XML peut être utilisé pour représenter la signification des données
transférées, et parce que les parseurs XML sont maintenant omniprésents dans tout
17 2005/2006
framework de développement. SOAP est aussi un format d'empaquetage, basé sur XML,
qu'on va détailler l'usage plus tard dans ce chapitre. Désormais, il existe beaucoup de standard
d'empaquetage dans la littérature, comme XML-RPC, mais pour des raisons qu'on va
expliciter après, on a choisi le standard SOAP [5].
2.4.6. SOAP (Simple Object Access Protocol)

Pour échanger des messages entre un service Web et une application appelante, on utilise les
messages SOAP (figure 12). Ces messages sont des documents XML transportés via le
protocole http. En réalité, il s'agit d'un important composant de base pour développer des
applications distribuées. Les services Web peuvent être écrits dans n’importe quel langage et
exécutés sur n’importe quelle plate-forme. Un client d’un service Web peut également être
écrit dans n’importe quel langage et exécuté sur n’importe quelle plate-forme.
Figure 12: Structure d'un message SOAP
2.4.7. Transport
La couche de transport inclue les différentes technologies qui permettent une communication
application à application. Parmi ces technologies on peut citer TCP, HTTP, SMTP, et Jabber.
Le rôle primaire de la couche transport étant de transporter les données entre deux
emplacements du réseau. Les services Web peuvent être basés sur tout protocole de transport.
Le choix du protocole de transport est basé largement sur les besoins de communication du
service Web implémenté.
2.4.8. Réseau
La couche réseau de la pile de technologies d'un service Web est la même que celle dans la
pile TCP/IP. Elle offre l'adressage, le routage, etc.
18 2005/2006
2.4.9. Application
La couche application est le code qui implémente la fonctionnalité du service web, (c'est à
dire le Business Logic), qui est accessible via les couches inférieurs de la pile.
2.5. Architecture des services Web
L’architecture des services Web a trois rôles distincts :

Le fournisseur crée le service Web et le met à la disposition des clients qui souhaitent
l’utiliser.
Un demandeur est une application cliente qui utilise le service Web. Le service Web
demandé peut également être client d’autres services Web.
L’agent permet au fournisseur et au demandeur d’un service Web de communiquer
ensemble. Il peut être par exemple un registre de service.
Les trois rôles de fournisseur, de demandeur et d’agent interagissent les uns avec les autres
par l’intermédiaire des opérations de publication, de recherche et de liaison. Un fournisseur
informe l’agent de l’existence du service Web en utilisant l’interface de publication de cet
agent pour permettre aux clients d’accéder au service. Les informations publiées décrivent le
service et spécifient son emplacement. Le demandeur consulte l’agent pour localiser un
service Web publié. Grâce aux informations sur le service Web obtenues par l’agent, le
demandeur peut lier ou appeler le service Web. Le diagramme suivant résume la manière dont
le fournisseur, le demandeur et l’agent interagissent les uns avec les autres (figure 13):
Figure 13: Rôles et opérations des services Web
19 2005/2006
Conclusion
Dans ce chapitre, nous avons distingué entre deux grands concepts: les services télécoms
(SMS/MMS) et les services web. En découvrant leurs intérêts ainsi que leurs modes d’emploi
nous avons pu imaginer la possibilité de combiner les deux types de services afin de répondre
aux besoins de notre application. Ainsi le lecteur ne trouvera pas d’ambiguïté pour
comprendre le choix de ces solutions pour répondre à nos besoins décrit dans le chapitre
suivant qui est consacré à une étude de l'existant et la description des besoins fonctionnels et
non fonctionnels de notre application.
.
20 2005/2006
Chapitre 2 : Etude De L’Existant Et Spécification
Introduction
Après avoir donné une idée sur les concepts utiles pour la réalisation de notre projet, et pour
pouvoir proposer une solution compétitive, il faudra explorer les différentes technologies
existantes traitant cette problématique. Le chapitre suivant présentera en premier temps une
étude de l’existant et par la suite une spécification détaillée des besoins fonctionnels et non
fonctionnels de notre application.
21 2005/2006
1. Etude de l’existant
Notre étude de l’existant s’est basée sur les solutions proposées par ALCATEL (département
Research and Development) pour résoudre des problématiques de supervision réseau.
Au terme de cette étude il s’avéré que l’application ALMAP Faut Management (FM) est la
solution qui présente le plus de similitude avec notre sujet. En effet FM est un produit WEB
qui gère les alarmes remontées d’un système de télécommunication.
1.1. Historique de ALMAP FM
ALMAP FM est une évolution de l’application Alarm Surveillance (AS), il s’agit en grande
partie d’un re-design de ALMAP AS pour être compatible WEB tout en restant dépendant de
son ancêtre pour la récupération des alarmes du réseau de télécommunication.
1.2. Fonctionnalités de ALMAP FM
ALMAP FM est un outil de supervision de systèmes de télécommunication. Il permet, à

travers deux interfaces graphiques basées sur l’architecture Java Web Start (JWS), de gérer
des alarmes de type X.733 conformément au standard OSI TMN.
Les principales fonctionnalités de ALMAP FM sont :
la collecte des alarmes.
la présentation des alarmes.
la gestion des alarmes courantes par le biais de différentes actions exemple : clear
alarm, acknowledge alarm …
l’export des alarmes vers des fichiers textes.
l’archivage des alarmes.
la mise à jour de l’alarme au niveau l’agent.
1.3. Architecture de ALMAP FM
ALMAP FM est architecturé pour subvenir essentiellement aux besoins suivants :

offrir des opérations de gestion de réseau à travers des interfaces graphiques web.
ne pas imposer de opérations d’administration sur la machine de l’opérateur.
minimiser toutes opérations d’installation et la limiter a l’installation d’un navigateur
web.
22 2005/2006
permettre la navigation vers d’autres application ALMAP.

FM package est décomposé fonctionnellement en plusieurs sous packages :
FM Current GUI : c’est l’interface graphique de gestion des alarmes courantes.
FM Historical GUI: c’est l’interface graphique de gestion des alarmes archivées.
FM Current Server: est le médiateur entre les Current GUIs et AS Current
IM(Information Manager).
FM Historical Server: est le médiateur entre le Historical GUIs et AS Historical IM
(Information Manager).
La communication au sein de FM est basée sur le protocole IIOP du corba.
FM s’intègre avec différents produits tiers comme ALMAP SEC7.1 pour la Sécurisation,
ALMAP SSO 1.0 pour le Single Sign On, etc.
Le package FM peut être schématisé comme suit
Web Server Host(s)

(one or more)
Tomcat Apache
server http
server
Client Hosts
« JWS « JWS application»
application » Local Session Manager
FM Cur. Gui « JWS (LSM)
application »
FM Hist. Gui
Firewall IIOP IIOP

(optional)
«Corba»
“Java application” Naming
LBM Service
« C++ application » « C++ application »

fmcurusmserver fmhistusmserver « Java application »
Session and
Authentication Server
Server Host(s) (SAS)
(one or more)
« C++ application » « java application »
NSP UDM
(Corba Naming
Service )
« C++ application » « C++ application »

ASCURIM ASHISTIM
SEC7 LDAP
server server
GUI client application Server application Optional application
Figure 14: Architecture de FM
23 2005/2006
1.4. Critique de l’existant
ALMAP FM ne permet de gérer que les alarmes standard X.733.

Il a une architecture complexe (demande un effort d’intégration et d’installation).
FM est basé sur une architecture CORBA ce qui rend la configuration assez complexe.
En effet dans un monde WEB les pares feu (firewall) et DNS (Domain Name System)
sont fréquemment utilisés et présente un obstacle devant les requêtes CORBA d’ou le
besoin d’une configuration fine.
FM est compliqué a utiliser et nécessite des utilisateurs expérimenté.
FM n’offre pas la possibilité de supervision ni par SMS et MMS ni par Mail.
2. Spécification des besoins
La finalité de ce projet est de réaliser une plateforme, nommée Network Supervision Services
(NSS), dont l’objectif est de permettre aux utilisateur la supervision et le contrôle à distance
via les services de messagerie : le SMS le MMS ou le Mail.
L’application NSS doit offrir principalement trois services :
Service de notification à distance : L’utilisateur doit recevoir une notification par
SMS ou par Mail en cas de problème remonté.
Service de contrôle à distance : L’utilisateur doit pouvoir corriger un problème
notifié par l’envoi d’un SMS ou Mail.
Service de diagnostique : l’application doit offrir aussi la possibilité à L’utilisateur de
recevoir un MMS résumant l’état du réseau ou des équipements supervisés tout en
envoyant une commande SMS.
2.1. Les besoins fonctionnels
Pour aboutir à la réalisation de ces services, l’application NSS doit répondre à un ensemble
des besoins fonctionnels tels que :
La gestion des SMS-MMS-Mail : C’est la fonction principale de l’application qui

permet la notification et la commande via le SMS ou le Mail et le diagnostique par
MMS.
La généricité : L’application permettra de superviser plusieurs types de réseaux
gérés chacun par un administrateur réseau.
24 2005/2006
L’authentification : L’utilisateur doit s’authentification avant d’utiliser les services

fournis par l’application.
L’administration des utilisateurs : L’application doit permettre d’administrer des
utilisateurs :
o Créer un utilisateur.
o Supprimer un utilisateur.
o Modifier un utilisateur.
o Attacher un réseau à un utilisateur.
La gestion de profil : Chaque utilisateur a la possibilité de gérer son profil. Il doit
pouvoir :
o Créer ses propres filtres.
o Gérer son schedule : pour ordonnancer la réception des notifications selon
des intervalles de temps choisis.
o Choisir le type de notification qui le convient : SMS, Mail ou SMS et Mail.
o Activer/Désactiver ses filtres.
La gestion des Commandes Lignes (CLI) : Pour pouvoir interagir avec le réseau via
le SMS, l’utilisateur a besoin d’envoyer des scripts qui vont être exécutés coté réseau.
La plupart de ces scripts sont de taille grande par rapport à celle d’un SMS. Pour
réduire la taille de ces scripts, l’utilisateur a besoin d’associer pour chaque script une
ligne de commande de taille compatible avec celle d’un SMS. Pour cela, l’application
doit offrir à l’utilisateur de :
o Créer ses propres CLI
o Supprimer ses CLI
o Modifier ses CLI
Le traçage des événements : L’application permet d’enregistrer des fichiers pour
tracer les événements d’envoi et de réception des SMS/MMS
L’interaction avec les réseaux : L’application doit interagir avec les réseaux
supervisés pour échanger des données.
Les Besoins non fonctionnels :
Application générique : elle doit être utilisée indépendamment de la nature du

réseau.
Usage simple : l’utilisateur doit fournir le moindre effort pour comprendre le mode
d’utilisation de l’application.
25 2005/2006
Messages envoyés adaptés à la nature du terminal : on doit envoyer des messages

courts dans le cas ou le terminal sera un téléphone mobile.
Utilisation de la plate-forme Nextenso : elle permet l’envoi et la réception des SMS,
MMS et Mail. Elle joue le rôle d’un SMSC, MMSC et serveur SMTP.
3. Les Acteurs
Acteurs Principaux : On a deux acteurs principaux qui vont interagir avec notre
application :
o L’utilisateur qui a le droit d’utiliser l’application pour qu’il puisse
superviser son réseau à distance.
o L’agent réseau (proxy) qui est responsable sur l’envoie des alarmes réseaux
à notre application
Acteur Secondaire : C’est l’administrateur application qui est responsable de la
gestion, de la maintenance et de la configuration de notre application.
4. Diagramme des cas d’utilisation
4.1. Diagramme des cas d’utilisation général
Le diagramme principal des cas d’utilisations permet de traduire les spécifications

fonctionnelles d’utilisation du système. C'est-à-dire les différentes possibilités d’utilisation de
l’application vis-à-vis les utilisateurs. Ce diagramme est représenté par la figure suivante :
26 2005/2006
User and application administrator

must authenticate before using
application.
authenticate
Manage Profil
User
Manage CLI
Webmaster
Edit Map
Manage SMS-MMS-Mail
Network Agent
Administrate
Users/Networks
View log file
Figure 15: Diagramme des cas d'utilisation générale
Authenticate : L’utilisateur et l’administrateur application n’ont le droit d’utiliser les

services offerts par l’application qu’après authentification.
Manage Profil : L’utilisateur a le droit de gérer son profil : il peut le modifier,
l’activer ou le désactiver.
Manage CLI : Afin de pouvoir se notifier et agir par SMS, l’utilisateur doit associer à
chaque script utilisable une syntaxe courte pour les rendre compatible avec la taille
des shorts messages (SMS).
Edit Map : L’utilisateur peut recevoir un MMS décrivant l’état de son réseau.
L’image continue dans le MMS peut être éditée selon le choix de l’utilisateur.
Manage Users/Networs : L’administrateur application doit gérer l’inscription des
utilisateurs qui ont le droit d’utiliser le service de notification à distance sur un réseau
27 2005/2006
bien spécifique. Un utilisateur qui n’est pas inscrit par l’administrateur il ne peut en
aucun cas utiliser l’application.
View log file : Seul l’administrateur application peut consulter les fichiers log qui
servira pour le traçage des événements parcourus par l’application.
Manage SMS-MMS-Mail : L’application gère d’une part l’envoi des SMS/Mail
vers l’utilisateur suite à la réception d’une alerte envoyée par l’agent réseau et d’autre
part l’envoi des MMS vers l’utilisateur pour lui informer sur l’état de son réseau.
4.2. Description du cas d’utilisation Gérer Profil
Dans ce cas d’utilisation, l’utilisateur va configurer ses besoins en terme de règles

de filtrage, de manière de notification (SMS/MMS/Mail) et du planning suivant lequel il veut
recevoir des notifs.
Manage way of notification
<<extend>> <<extend>>
<<extend>>
Notify by SMS Notify by Mail

Notify by SMS and Mail
Manage Filter
User
<<include>>
<<include>>
<<include>> <<include>>
Add Filter
Activate/Desactivate Filter
D elete Filter Edit Filter
Manage schedule
Figure 16: Diagramme relatif au cas d'utilisation Gérer Profil
28 2005/2006
Manage way of notification : l’utilisateur a le choix d’être notifié par SMS, par Mail
ou par SMS et Mail.
Manage Filter : l’utilisateur gère ses filtres selon ses besoins en terme d’équipements
réseaux et type d’alarme.
Manage schedule : l’utilisateur peut ordonnancer le planning de ses filtres en utilisant
le schedule.
Diagramme de séquence
Un diagramme de séquence montre chronologiquement (de haut en bas) les interactions entre
un ensemble d'objets pour un cas d’utilisation spécifique. Chaque objet dispose d'une ligne de
vie
(ligne verticale). Sur ces lignes de vie, des périodes d'activité sont indiquées par de rectangles
fins. La figure suivante décrit le diagramme de séquence pour le cas d’utilisation « Gérer
Profil ».
W e b M o d u le D ataB as e
Us er
M a n a g m e n t P ro fil R e q u e s t ( )
D is p la y M a n a g m e n t P ro fil P a g e
C re a t e F ilt e r( )
M a n a g e N o tific a t io n M a n n e r( )
M a n a g e S c h e d u le( )
V a lid a t e ( )
S a ve ( )
Figure 17! Diagramme de séquence relatif au cas d'utilisation "Gérer Profil"
29 2005/2006
4.3. Description du cas d’utilisation Administrer utilisateurs
Dans ce cas de figure, l’administrateur application va inscrire la liste des utilisateurs qui ont le
droit d’utiliser le service de supervision à distance. Pour cela, il peut :
Add user /Network : la création d’un utilisateur est accompagné par l’inscription du
réseau à superviser.
Edit user /Network : modifier ses coordonnées, modifier son login/password,
modifier les informations sur le réseau supervisé.
Delete user /Network : on doit offrir aussi la possibilité de supprimer un utilisateur
dans le cas ou il n’a plus besoin d’être servis.
Add User/Network
Delete User/Network
Application Administrator
Edit User/Network
Figure 18: Diagramme relatif au cas d'utilisation administrer utilisateurs
L’interaction entre les instances d’objets dans le cas d’utilisation « Administrer utilisateurs »
est représentée par le diagramme suivant :
30 2005/2006
W e b M o d u le D a ta B a s e
W e b m a s te r
M a n a g m e n t U s e r s R e q u e s t( )
D i s p l a y M a n a g m e n t U s e rs P a g e
M a n a g e U s e rs ( )
V a lid a t e
S a ve ( )
Figure 19: Diagramme de séquence relatif au cas d'utilisation administrer utilisateurs
4.4. Description du cas d’utilisation Administrer CLI
Ce cas d’utilisation est représenté par la figure suivante :
Add command CLI
Edit command CLI

User
Delete command CLI
Figure 20: Diagramme relatif au cas d'utilisation administrer CLI
Les CLI nécessaires pour la supervision d’un réseau à distance doivent être crées par
l’administrateur réseau .Dans certaines situations, il doit pouvoir supprimer des commandes
31 2005/2006
CLI ou bien d’entrer des modifications sur quelques commandes CLI afin d’exprimer au
mieux ses besoins.
De même pour le cas d’utilisation « Administrer CLI » l’interaction se entre trois objets :
l’utilisateur, le module Web et la base de donnée.
W e b M o d u le D a ta B a s e
User
M a n a g m e n t C L I R e q u s t( )
D ip la y M a n a g m e n t C L I P a g e
M a n a g e C L I( )
V a l i d a te
S a ve ( )
Figure 21: Diagramme de séquence relatif au cas d'utilisation administrer CLI
4.5. Description du cas d’utilisation Gérer SMS-MMS-Mail
Le présent cas d’utilisation décrit la fonctionnalité principale de l’application. Il est

décomposé en quatre sous cas d’utilisations représentés dans la figure ci dessous :
n o tify b y S M S /M a i l
s e n d MMS
User
re c e ive S M S
Figure 22: Diagramme relatif au cas d'utilisation Gérer SMS-MMS-Mail
32 2005/2006
Notify by SMS/Mail : Les alarmes réseaux reçues par l’application seront filtrées
ensuite converties en SMS ou Mail. Les utilisateurs concernés sont ceux qui seront
notifiés par ces alarmes.
Send MMS : L’application peut envoyer un MMS à l’utilisateur si celui ci demande
des informations sur l’état de son réseau.
Receive SMS : l’application peut aussi recevoir des SMS de la part des utilisateurs
afin d’agir sur le réseau ou de récupérer des données sur son l’état.
Dans ce cas d’utilisation on a trois scénarios possibles : « notification par SMS »,
« notification par Mail », « envoie de MMS » et « réception de SMS ».
Les deux premiers scénarios sont presque identiques. On choisit de présenter le diagramme de
séquence relatif au scénario « notification par SMS »
A p p lic a t io n
N e t w o rk A g e n t Us er
N o t ify A la rm ( )
A p p lic a t e F ilt e rs ( )
S end S MS ( )
Figure 23: Diagramme de séquence pour le scénario d’envoi de notification par SMS
Ce scénario décrit l’interaction dans le temps entre l’agent réseau, l’application et l’utilisateur
pour de mener une notification.
Le scénario inverse est celui de « réception SMS ».Il est décrit par le diagramme suivant :
33 2005/2006
A p p lic a t io n
U s er N e t w o rk A g en t
Se nd S M S( ) ve rify p h o n e n u m b e r,
C LI s ent and U s er
In s c ri p t i o n
c h e c k In fo ( )
c o n ve rt C L I ( )
T ra n s m i t C o m m a n d( )
ex ec ute C om m and( )
C o firm O p é ra t i o n ( )
S e n d C o n fi rm m e s s a g e ( )
Figure 24: Diagramme de séquence pour le scénario de réception de SMS
Le scénario d’envoi de MMS décrit l’interaction entre l’utilisateur, l’application et la base de

donnée :
A pplic ation DataB as e

: Us er
send S M S ( )
Cons ult DataB as e ( )
c ons truc t M ap ( )
send M M S ( )
Figure 25: Diagramme de séquence pour le scénario d’envoi MMS
34 2005/2006
Conclusion
Dans ce chapitre, nous avons présenté en premier lieu une étude de l'existant qui a décrit
le produit Alcatel ALMAP FM conçu pour la supervision des réseaux. Dans un second lieu
nous avons déterminé les besoins fonctionnels et non fonctionnels de notre application. En
dernier lieu nous avons dégagé les cas d'utilisations et les diagrammes des séquences
correspondants. Le chapitre suivant présente les différentes phases de notre conception
(conception générale et détaillée).
35 2005/2006
Chapitre 3 : Conception De L’Application
Introduction
La conception est une étape primordiale dans le cycle de vie d'un logiciel. Elle permet de
décrire les solutions adoptées pour résoudre des problématiques d’une application ou d'un
système. Dans ce chapitre, nous présentons tout d'abord une conception générale de notre
application qui vise à décomposer le système en modules, ensuite nous entamons la
conception détaillée dans la quelle nous présentons pour chaque module (package) le
diagramme de classe correspondant.
36 2005/2006
1. Décomposition en Packages
L’architecture de notre application ainsi que les diagrammes des cas d’utilisations nous a
permis de décomposer notre système en cinq modules :
Notification Manager : ce premier module assure l’envoi et la réception des

notifications de genre SMS/MMS et Mail.
Server Process: il englobe tout traitement interne concernant les fonctionnalités de
l’application.
Web Module : Ce module gère l’interaction entre l’application et les utilisateurs à
travers des interfaces graphiques.
Server Interface : c’est un module qui permet de créer une interface de
communication avec les réseaux clients.
NSS-API (Network Supervision Services- Application Programming Interface) : Le
dernier package est une API qui sera implémenté coté client. Il permet de créer une
interface de communication avec le serveur de l’application.
Les liens entre ces packages sont représentés par la figure suivante :
W eb Module NSS-API
u ses
Notification instantiate Server Process us es Server Interface

Manage r
Figure 26: Diagramme des Packages
Description des liens
Lors de la réception d’une alerte envoyée par le réseau client (via le NSS-API) le module
« Server Interface » utilise le module « Server Process » pour faire le traitement nécessaire
(identification du réseau, opération de filtrage, ect…) avant d’instancier le module
« Notification Manager » pour envoyer l’alerte à l’utilisateur concerné.
37 2005/2006
De plus, le module « Server Process » sera utilisé par le module web afin de répondre à tout
traitement demandé par l’utilisateur via nos interfaces web.
2. Conception de la base de données
Dans cette partie nous présentons une conception de la base de donnée à travers le modèle
conceptuel de donnée (MCD) qui permet de représenter la structure logique globale d'une
base de données, indépendamment du logiciel ou de la structure de stockage des données. Un
modèle conceptuel contient toujours des données qui ne sont pas encore mises en oeuvre dans
la base de données physique. Il constitue une représentation formelle des données (voir figure
27).
décrit possède
Users
CLIcommands login
commandname firstname Filters
userlogin 0,n 0,n name filtername
0,n 1,1
attributes password userlogin
action phonenumber description
description mail state
network sms
networkaddress mail
startdate
1,1 enddate
gère
Objects
1,1 networkaddress
Network objectaddress Status
networkaddress objectname
userlogin network
type
name objectaddress
parent
agentstate status
child
description 0,n 1,1 state1
description 1,1 0,n
connectionId state2
appartient à actions possède state3
optattributes
Figure 27: Modèle conceptuel de la base de données
Users : cette table contient la liste des utilisateurs inscrits par l’administrateur application.
Chaque utilisateur est identifié par son login.
Network : dans cette table on inscrit tous réseaux supervisés par l’application. Chaque réseau
est identifié en plus de son adresse par le login de son administrateur unique.
Objects : au niveau de cette table on stocke tous les objets appartenant aux réseaux inscrits.
Un objet est identifié par l’adresse réseau et par son adresse lui même pour bien le spécifier.
38 2005/2006
Status : les états actuels des objets sont regroupés dans la table status. Chaque objet est lié à
son état par le couple d’identifiant adresse du réseau et adresse d’objet lui même.
3. Conception détaillée
3.1. Package « Web Module »
Ce package est composé par une combinaison des pages HTML et des pages JSP. Son
diagramme de classe est le suivant :
Home
doPost()
CommandsManagment
name : String
webmaster user UserMain description : String
attribute : String
login : String login : String login : String
action : String
password : String password : String password : String
add()
delete()
edit()
AuthenticateAdmin AuthenticateUser
AdminMain EditMap
login : String login : String NetworkManagment FiltersManagment
login : String name : String
password : String password : String name : String
password : String agentAddress : String
description : String add()
doPost() doPost() state : String
update() delete()
schedule : String modify()
sms : String
mail : String
add()
LogFile delete()
CustomersManamment
edit()
message : String firstname : String
name : String
login : String
password : String
phonenumber : String
mail : String
networkname : String
agentaddress : String
state : String
add()
delete()
edit()
Figure 28: Diagramme des classes pour le package "web Module"
39 2005/2006
Le module web est décomposé en deux groupes d’interfaces : les interfaces utilisateur (user)
et les interfaces administrateur (webmaster).
L’administrateur doit s’authentifier via l’interface « AuthenticateAdmin » pour pouvoir gérer
son application. Si l’opération d’authentification est menée à juste l’administrateur accède
directement à la page « AdminMain » et choisit entre l’accès à la page de gestion des
utilisateurs ou bien à la page de traçage des événements d’envoi et de réception des
notifications.
De même, l’utilisateur doit s’authentifier pour accéder à la page « UserMain ». Celui ci, peut
alors accéder aux différentes interfaces pour gérer ses filtres, ses commandes, pour modifier
sa Mappe ou bien pour récupérer des informations sur l’architecture et les détails de son
réseau.
3.2. Package « Server Interface »

Ce package contient sept classes permettant l’interaction avec le réseau client :
N e tw o rk
n a m e : S trin g
a d d re s s : S trin g
d e s crip tio n : S trin g
o b je ctL is t : Ma n a g e d Ob je c t[ ]
s ta tu s : s ta te [ ]
cu rre n tSta t e : S trin g
N e tw o rk()
g e t()
s e t() D e c la re Im p l
in c lu d e D e cl a re I m p l()
a u th e n tica te ()
Ma n a g e d O b je ct
ca ll
n a m e : S trin g
S ta te a d d re s s : S trin g
s ta tu s : St ri ng E ve n tIm p l
n a m e : S trin g
in s ta n cia te d e s crip ti o n : S trin g
cu rre n tva lu e : S trin g
p a re n t : S trin g us es E ve n tIm p l ()
va lu e L is t : S trin g [ ]
ch i ld : S trin g n o tify()
a ct io n L is t : Actio n [ ] a d d()
S ta te ()
o p tAtt rib u t e s : Attrib u te [ ] u p d a te()
s e t()
d e le te()
g e t()
M a n a ge d O b je ct()
s e t()
g e t()
in s ta n cia te in s ta n c ia te
Ac tio n Attrib u te
n a m e : S trin g n a m e : S trin g
p a ra m e te rs : S trin g [] va lu e : S trin g
Actio n () Attrib u te ()
s e t() g e t()
g e t() s e t()
Figure 29: Diagramme des classes pour le package"Server Intrface"
40 2005/2006
Les deux classes « DeclareImpl » et « EventImpl » implémentent les méthodes qui vont être
invoquées coté client.Les autres classes sont utiles pour la récupération de toute information
sur l’ensemble des objets appartenant à un réseau supervisé par l’application. Ces classes vont
être implémentées aussi bien chez le serveur application que chez le client.
3.3. Package « Server Process »
C’est le package principal de l’application. Il implémente toutes les classes qui regroupent des
méthodes de traitement des taches fournies par l’application.
ProcessNotif CommandExcecuter
ObjName : String
ObjState : String CommandExcecuter()
value : String parseCommand()
connectionId : String exécute()
ProcessNotif() MapConstructor
process()
MapConstructor()
construct()
inst ant iate

uses
ObjManager
LogEvents Co nsultDataBa se
login : String d ata Base nam e : String
message : String cal l
logGateway : String d ata Base Use r : String
ObjManager() a dminLo gin
DeleteObj()
LogEvents() use s u serL ogi n : String
updateObj()
save()
manageObj() verifyInd B()
call
uses
use s
Log
UpdateDataBase
doPost() Cl ientManage r
use rname
login
use rLogin
password
adminLogin
connectionId
filte rna me
comma ndname
ClientManager()
dataBasename : String uses getConnectionId()
dataBaseUser : String
randomPassword()
dataBasePass : String
initiate()
extend
DeleteFromDataBase ModifyDataBase AddToDataBase
deleteUser() modifyUser() add Use r()

deleteFilter() modifyFilter() add Filter()
deleteCommand() modifyCommand() add Command()
deleteObj() modifyschedule() add Obj()
activateFilter()
desactivateFilter()
changeNotifManner()
updateObj()
Figure 30: Diagramme des classes pour le package"Server Process"
41 2005/2006
La classe « Process Notif » est concernée par le traitement nécessaire lors de la

réception d’une alarme.
Les classes «Log Events» et «Log» s’occupent de l’opération de sauvegarde des
évènements issus par l’application dans des fichiers log.
La classe « CommandExécuter » est celle qui fait le parsing d’une commande envoyée
par SMS.
Les classes « ObjManager », « ClientManager », «ConsultDataBase »,
« UpdateDataBase », « DeleteFromDataBase », « ModifyDataBase » et
« AddToDataBase » permettent l’interaction de l’application avec la base de données.
La classe « MapConstructor » s’occupe de la construction de l’image à envoyer en
fonction des données disponibles dans la base de données. Une fois l’image est prête
elle sera transmis au module « Notilfication Manager »
3.4. Package « Notification Manager »
Ce package contient cinq classes : «NotifyManner», «SMSsender », «MMSsender»,

« Mailsender » et « SMS receiver ».
SMS receiver
SMS : String
phone number : String
SMSreceiver()
receiveSMS()
send
proxyAddress : String
send()
SMSsender MMSsender MailSender

message : String image : Byte mailaddress : String
SMSGateway : String text : String message : String
phonenumber : String phonenumber
MailSender()
SMSsender() MMSsender() sendMail()
sendSMS() sendMMS()
Figure 31: Diagramme des classes pour le package"Notification Manager"
42 2005/2006
La classe « send » est la classe chargé de l’envoie du SMS, Mail ou Mail.

La classe« SMS receiver » reçoit les SMS envoyés par les utilisateurs et les transmet au
package «Server Process ».
3.5. Package « NSS-API »
Ce package est décomposé en deux sous packages:
C l ie n t S e rvic es C lie n t In te rfa ce

us es
Figure 32: Diagramme des sous packages pour le package"NSS-API"
Client Interface: ce premier sous package joue le rôle d’interface avec le serveur
application. Il contient un ensemble des classes fournies par l’administrateur
application à l’utilisateur pour les utiliser afin de pouvoir se bénéficier du service
fournit par notre application.
Client Services : le second sous package regroupe des méthodes fonctionnelles coté
client.
3.5.1. Sous Package « Client Interface »
Ce sous Package contient sept classes. Les classes « Network », « ManagedObject »,

« State », « Action » et « Attribute » sont déjà définies dans le package « Server Interface »
puisqu’ils sont communes entre le serveur et le client.
Les classes « DeclareManager » et « EventManager » implémentent des méthodes nécessaires
pour transmettre des données au serveur.
43 2005/2006
DeclareManager
Network
connectionId : String
name : String
address : String
DeclareManager()
description : String
inst antiat e authenticate()
objectList : ManagedObject[ ]
init()
status : state[]
ping()
currentState : String
sendNotif()
Delete()
Network()
update()
get()
add()
set()
include
instantiate
ManagedObject
Name : String
address : St ring EventManager
State description : String
name : St ring parent : St ring EventManager()
currentvalue : String instantiate child : Boolean noti fyAlarm()
valueList : String[] actions : action[] addObj()
status : state[] delet eObj()
State() optAttributes : attribute[] updateObj()
set()
get() ManagedObject()
get()
set()
instantiate instantiate
Action At tribute
name : St ring name : String
paramet ers : String[] value : St ring
Action() Attribute()
set() set()
get() get()
Figure 33: Diagramme des classes pour le sous package"Client Interface"
3.5.2. Sous Package « Client Services »
Ce sous Package contient une seule classe « Receive Command » qui est responsable de la
réception d’une commande envoyée par l’utilisateur via le serveur application et de son
exécution.
Rec eiveCom m and
Rec eiveCom m and ()

ex ec ut eComm and( )
Figure 34: Diagramme des classes pour le sous package " Client Services"
44 2005/2006
Conclusion
Après avoir terminer la phase de conception, il sera facile d’entamer la phase

d’implémentation surtout qu’on a définit toutes les classes avec leurs méthodes et les relations
entre elles.
Le chapitre suivant, sera consacré alors pour la mise en pratique des résultats de la partie
conception.
45 2005/2006
Chapitre 4 : Réalisation
Chapitre 4: Réalisation
Introduction
Une des étapes de la vie d’un projet, aussi importante que la conception, est l’implémentation.
Cette étape constitue la phase d’achèvement et d’aboutissement du projet. Pour accomplir
cette tache avec succès il faut savoir utiliser les outils adéquats et nécessaires. Ce choix
d’outils peut influencer sur la qualité du produit obtenu et donc nécessite une attention
particulière et doit se baser sur les besoins du projet et le résultat escomptée.
Ce chapitre présent alors l’environnement technique du travail ainsi que le choix pris en
matière d’environnement logiciel. Par la suite, nous présentons un démo du travail réalisé et
enfin, nous illustrons un chronogramme qui décrit les différentes étapes par lesquelles nous
sommes passés.
46 2005/2006
1. Description de l’environnement de travail
Dans cette partie nous s’intéressons à l’étude de l’environnement technique disponible pour la
réalisation de notre projet ensuite nous justifions les choix pris en matière d’environnement
logiciel pour mener à terme la partie applicative.
1.1. Environnement technique
Pour la réalisation et la concrétisation de tel projet, l’Espace Partenariat d’Alcatel ( EPA)

offre une plate-forme de développement et de gestion des services à valeurs ajoutés (le SMS,
le MMS, le Mailing, le WAP,ect.). Cette plate-forme appelée Nextenso Proxy Plate-forme
nous a permis essentiellement la mise en place de la communication entre les clients du
réseau mobile et le serveur de notre application. L’utilisation de Nextenso Proxy met en
pratique le concept de communication client /serveur comme l’indique la figure suivante :
Figure 35: Intérêt de la Plate-forme Nextenso
Avec Nextenso Proxy Plate-forme on peut assurer une panoplie de fonctionnalités :
Elle permet d’effectuer les traitements nécessaires sur les SMS échangés entre les
clients mobiles et le serveur entre autres la conversion SMS/http.
Elle permet d’intercepter les MMS échangés entre le mobile et le serveur pour lui
appliquer des traitements spécifiques. Par exemple, elle permet l’adressage, le routage,
l’adaptation de format, le codage et décodage.
47 2005/2006
Elle permet la conversion WAP/http pour réussir l’interaction clients mobiles et

serveurs WML.
Elle offre aussi la possibilité de notification par mail en utilisant le serveur SMTP.
Le noyau logiciel de cette Plate-forme comprend une organisation en couches distinguées par
la figure suivante :
Figure 36: Composition logicielle de la Plate-forme
Protocol Layer : c’est la couche protocole gérant les protocoles de bas niveaux et
fournissant des objets décodés à la couche Proxylet.
Proxylet Layer : c’est la couche motrice des proxylets rattachés à la couche protocole.
Elle permet d’appeler les proxylets en fonction du flot d’entrée.
Protocol Mapping Layer : c’est la couche qui se charge de la conversion d’un
protocole à un autre. Elle contient en particulier les mappers WAP/http et SMS/http.
1.2. Environnement Logiciel
Les choix pris en matière d’environnement logiciel concernent les langages de

développement, l’environnement de développement, le SGBD gérant la base des données
interne à l’application, le serveur web déployant l’application et le protocole de
communication client /serveur à utiliser.
48 2005/2006
1.2.1. Les langages de développement
Java : Java est à la fois un langage de programmation et une plateforme d'exécution. Le

langage Java a la particularité principale d'être portable sur plusieurs systèmes d’exploitation.
Il permet aussi de développer des applications autonomes et surtout, des applications client-
serveur. Côté client, les applets sont à l'origine de la notoriété du langage. C'est surtout côté
serveur que Java s'est imposé dans le milieu de l'entreprise grâce aux servlets, le pendant
serveur des applets, et plus récemment les JSP (Java Server Pages) qui peuvent se substituer à
PHP et ASP.
Pour toutes ces raisons et pour les besoins de notre application, le choix du java c’est avéré le
plus judicieux et le mieux approprié pour développer notre application.
Hyper Text Markup Langage (HTML) : Le HTML est un langage dit de « marquage » (de
« structuration » ou de « balisage ») dont le rôle est de formaliser l'écriture d'un document
avec des balises de formatage. Les balises permettent d'indiquer la façon dont doit être
présenté le document et les liens qu'il établit avec d'autres documents.
Le langage HTML permet notamment la lecture de documents sur Internet à partir de
machines différentes, grâce au protocole HTTP, permettant d'accéder via le réseau à des
documents repérés par une adresse unique, appelée URL.
Java Script (JS) : Il s’agit d’un langage de script créé pour le web. Il permet d’exécuter des
commandes du côté utilisateur, donc au niveau du navigateur et non au niveau du serveur.
Ce langage nous fournit la possibilité de générer par exemple des messages d’erreurs ou
d’alertes en cas de fausse manipulation par l’utilisateur.
Java Server Pages (JSP) : Java Server Pages est une technologie standard permettant de
développer des applications Web interactives dont le contenu est dynamique. C'est-à-dire
qu'une page web JSP aura un contenu pouvant être différent selon certains paramètres (des
informations stockées dans une base de données, les préférences de l'utilisateur, ect. ) tandis
qu’une page Web classique (page html) affichera continuellement la même information. La
plupart des pages dans notre module Web seront des pages JSP.
1.2.2. L’environnement de développement
Notre application de notification à distance Network Supervision Services (NSS) est destinée
à s’exécuter sous une plate-forme Windows donc il est judicieux de choisir un environnement
49 2005/2006
de développement java sous Windows pour tirer au maximum de profit de la plate-forme de

travail. Par conséquent, JBuilderX 2005 Entreprise Edition a été choisi.
JBuilderX est un environnement complet permettant la génération, à l’aide du langage java,
des solutions manipulant des bases de données et le développement des services Web par
différents langages : html, JS,JSP,ect..
1.2.3. Système de Gestion de Base de Donnée MySQL
MySQL est une base de données open source la plus populaire dans le monde. Elle se
caractérise par sa performance, sa haute fiabilité et sa simplicité d'utilisation. Elle est utilisée
par des grandes entreprises transnationales tel que Alcatel. MySQL fonctionne sur plus de
vingt plates-formes, notamment Linux, Windows, OS/X, HP-UX, AIX ou Netware, une
polyvalence qui nous permet de déployer notre application sur plusieurs plates-formes.
1.2.4. Serveur Web Apache Tomcat
Etant donnée que NSS est une application web, nous aurons besoin d’un serveur web sur
lequel nous déployons notre application. Le serveur web utilisée est Apache Tomcat (voir
Annexe A).
1.2.5. Protocole de communication client/serveur
Vue que notre application nécessite un transfert important de données confidentielles avec des
clients dispersés géographiquement, il est important de bien choisir le protocole de
communication adéquat. Deux choix techniques de protocole se présentent:
SOAP (voir chapitre1)
CORBA ou Common Object Request Broker Architecture est une norme qui permet
de faire communiquer un ensemble d’applications en environnement hétérogène
(plusieurs systèmes et plusieurs langages).
Pour pouvoir choisir la solution la plus adéquate nous avons mené une étude comparative
entre ces deux protocoles :
50 2005/2006
Corba exige de compiler et distribuer des stubs client (un ensemble des classes qui se
trouvent du coté client et qui permettent l’interaction avec le serveur d’un service
distant) pour chaque type de clients. Ce n'est pas toujours pratique, particulièrement
quand on a un grand nombre de combinaisons de plates-formes et de langages ou
quand on veut offrir des services à des clients anonymes à travers Internet.
IIOP (le protocole de transfert de Corba) n'est pas facile à utiliser sur le réseau
Internet. En effet, dans un monde Internet la sécurité est une nécessité vitale et impose
l’utilisation entre autre des firewall , ces derniers présentent un obstacle devant les
requêtes CORBA et doivent être bien configurés pour laisser passer les messages
CORBA entre le client et le serveur. Par contre, avec SOAP on ne trouvera pas de tels
obstacles car le transport est réalisé grâce au HTTP associé au port 80 à travers lequel
passe le trafic Internet.
SOAP est conçu aussi pour le développement des services Web (voir chap1) alors que
CORBA est conçu uniquement pour le développement d’applications fonctionnant
dans un réseau Intranet.
Pour tous ces raisons, nous avons eu recours au choix de la spécification SOAP afin d’assurer
la communication entre les agents réseaux (nos clients) et le serveur de notre application.
Pour pouvoir exploiter le protocole SOAP nous avons eu recours à Apache Axis :
Apache Axis est une nouvelle implémentation de la spécification SOAP (Simple Object
Access Protocol) développé par la fondation Apache (The Apache Software Foundation), qui
succède à Apache SOAP. Axis est à la fois un environnement d'hébergement de services Web
(voir Annex A), et un toolkit complet de développement pour la création de services et l'accès
à des services tiers.
2. Description du travail réalisé
Notre application NSS est décomposée en trois grands modules : le serveur, le NSS-API et le
module web. Dans cette partie on présente le module web par une hiérarchie des principales
pages regroupées selon la nature de l’utilisateur :
- Administrateur application
- Utilisateur application.
La page d’accueil de notre application est la suivante :
51 2005/2006
Figure 37: Page Home
Cette page contient des informations sur les services offerts par l’application et sur la
manière d’inscription à ces services. De plus, elle offre le lien aux pages d’authentification
administrateur et utilisateur.
2.1. Principales Pages d’administration
L’administrateur est chargé de gérer les utilisateurs application et de consulter le fichier des
événements exécutés par l’application :
52 2005/2006
Figure 38: Page admin home
Pour ajouter un utilisateur, l’administrateur doit remplir le formulaire suivant :
Figure 39: Page user inscription
53 2005/2006
L’administrateur peut consulter le fichier log pour chaque réseau en cliquant sur le nom de
l’utilisateur correspondant :
Figure 40: Page user inscription
2.2. Principales Pages d’utilisation
L’application NSS offre à l’utilisateur la possibilité :

de récupérer une description détaillée sur l’état et l’architecture de son réseau.
de gérer ses filtres.
de gérer ses commandes.
De créer une map qui sert de base pour la notification par MMS.
Toutes ces fonctionnalités sont accessibles à partir de la page suivante :
54 2005/2006
Figure 41: Page user home

L’utilisateur a la possibilité de visualiser l’architecture du réseau supervisé ainsi qu d’ample
information par élément sélectionné. Ces informations sont offertes par la page « Network
Management »
Figure 42: network management
55 2005/2006
La gestion des filtres, s’opère à partir de la page « Filter Management ». Cette page contient
la liste des filtres existants, leurs descriptions et leurs états.
Figure 43: Page Filter Management

A partir de la page précédente nous pouvons accéder à la description d’un filtre qui décrit un
ensemble de règles de filtrage :
Figure 44: Page filter description
56 2005/2006
Cette page permet de modifier la description d’un filtre, son état (activé/désactivé) et de lui
attacher une manière de notification. On peut aussi appliquer à ce filtre un schedule.
La gestion des schedules se fait à partir de la page suivante :
Figure 45: Page schedule management

Un utilisateur a aussi la possibilité d’agir à distance sur le réseau supervisé par des
commandes prédéfinies par la page suivante :
Figure 46: Page Add command
57 2005/2006
2.3. Exemple de diagnostique en utilisant les MMS
Après que l’utilisateur envoi un SMS pour demander le diagnostique une mappe sera crée en
fonction de l’états des équipements supervisés cette mappe sera envoyée par MMS ver le
terminale de l’utilisateur des exemple de mappe apparaissent dans les figures suivantes :
Figure 47: Le Map sur le terminale
Figure 48: Le Map en Grande taille
58 2005/2006
Figure 49: Autre Example de Map
Figure 50: Taille plus Grande
3. Chronogramme d’avancement du travail
Le chronogramme illustré par la figure 39 décrit les différentes phases par lesquelles nous
sommes passés afin de mener à terme ce travail. Nous avons commencé par la phase de
documentation et l'étude de l'existant, qui nous a aidé à préparer l'étape de spécification et
entamer la rédaction du notre rapport. Une fois nous avons achevé notre spécification, nous
avons passé à une phase d'apprentissage technique. Dans cette phase, nous avons commencé
par implémenter un prototype web qui permet l’envoi d’un SMS à un terminal mobile via un
modem GSM. Cet exemple nous a permis de manipuler les langages java, JSP, JS… Par la
suite, nous avons suivi toutes les étapes du déploiement d’un service web à base SOAP :
implémentation du service web
59 2005/2006
intégration de Axis avec le serveur web Tomcat

déploiement du service web,
test du service.
Nous avons ensuite entamé la phase de conception en utilisant le formalisme UML. Une fois
la conception est bien avancée nous avons commencé la phase de codage tout en rectifiant
notre conception.
La rédaction du rapport est restée comme une tâche de fond pendant toute la période du projet
à part le mois de juin où elle est devenue la tâche principale.
Figure 51: chronogramme d'avancement du travail
60 2005/2006
Conclusion
Dans ce chapitre nous avons présenté l’environnement technique et logiciel utilisé lors du
projet ainsi que la description du travail réalisé à l’aide des imprimes écrans. Enfin, nous
avons illustré le déroulement des étapes de réalisation du projet par un chronogramme
d’avancement.
61 2005/2006
Conclusion Générale
CONCLUSION GENERALE
Ce projet avait pour objectif la réalisation d’une plateforme offrant les services de notification
et de contrôle distants par SMS et MMS. Nous avons choisis les services mobiles SMS et
MMS et les services Web comme solution technique pour assurer la connexion entre les
différents agents intervenant dans le service. La plateforme Nextenso d’Alcatel et la
plateforme J2SEE représentaient notre environnement de développement.
On tient à préciser que ce projet nous a été bénéfique puisqu’il nous a permis de découvrir un
champ d’application pratique, vaste et riche en procédures, il nous a donné aussi l’occasion de
bien tester nos connaissances théoriques.
De plus, ce projet nous a permis de :
Etudier en détails les services de messageries via le réseau mobile le SMS et le MMS.
Etudier la norme SOAP dont l’importance est vitale pour assurer la communication entre un
service Web et application appelante
Maîtriser les langages de développement Java, JS, Servlet/JSP et HTML
Maîtriser l’utilisation du système de gestion de base de données MySQL.
Se familiariser avec plusieurs environnements techniques: JBuilderX, Eclipse, Axis,
JakartaTomcat, AMC*Designor et Rational Rose.
La réalisation de notre produit ne signifie pas qu’il n’est pas susceptible à être amélioré. En
effet, la notion du sécurité et l’évolution des réseaux mobiles ver la troisième génération
nous inspire pour ajouter d’autre qualités a ce services et d’améliorer celles qui existent.
62 2005/2006
Bibliographie
BIBLIOGRAPHIE
[1] Arnaud Henry-Labordère, Vincent Jonack, SMS and MMS Interworking in

Mobile Networks, Artech House, 2005.
[2] G. Le Bodic ; Multimedia Messaging Service - An Engineering Approach to MMS;
John Wiley and Sons, 2002.
[3] G. Le Bodic - Mobile Messaging Technologies and Services SMS EMS and MMS;
John Wiley and Sons, 2ed.Mar.2005.
[4] David Chappell, Tyler Jewell, Java Web Services, O'Reilly, First Edition March 2002
[5] Sanjiva Weerawarana, Francisco Curbera, Frank Leymann, Tony Storey,
Donald F. Ferguson, Web Services Platform Architecture: SOAP, WSDL, WS-Policy, WS-
Addressing, WS-BPEL, WS-Reliable Messaging, and More, Prentice Hall PTR, March 22,
2005
63 2005/2006

Fitouhi Naoufel

Uploaded by

Document Information

Original Title

Copyright

Available Formats

Share this document

Share or Embed Document

Sharing Options

Did you find this document useful?

Is this content inappropriate?

Copyright:

Available Formats

Fitouhi Naoufel

Uploaded by

Copyright:

Available Formats

Cycle de formation des ingénieurs en Télécommunications

Réseaux et Services Mobiles

Rapport de Projet de fin d’études

Développement d’une plateforme de

Travail proposé et réalisé en collaboration avec ALCATEL Tunisie

Année universitaire : 2005/2006

J’adresse ma plus vive reconnaissance à tous mes enseignants de SUP’COM pour la

INTRODUCTION GENERALE ............................................................................................ 1

Figure 1: Architecture du service SMS ...................................................................................... 6

LISTE DES TABLES

Tableau 1: Equipements du réseau SMS.................................................................................... 6

Le service de messagerie Short Message Service (SMS) via le réseau GSM.

Chapitre 1 : Concepts De Base

1.1. Short Message Service (SMS)

1.1.2. Architecture du service

Figure 1: Architecture du service SMS

Le tableau suivant décrit rapidement les équipements de l'architecture du réseau SMS.

Nom Signification Fonction

Tableau 1: Equipements du réseau SMS

1.1.3. Les services SMS à valeur ajoutée

1.2. Multimedia Messaging Service (MMS)

Le Service de Messagerie Multimédia (MMS, Multimedia Messaging Service) [2] permet la

1.2.1. Architecture MMS

Figure 2: Environnement MMS

1.2.2. Entités MMS

Figure 3: Architecture du service MMS

1.2.3. Interfaces MMS

Les différentes entités de l’environnement MMS communiquent à travers un ensemble

Figure 4: Interfaces MMS

1.2.4. Fonctionnement du service MMS : Description du scénario d’envoi d’un

Les étapes suivantes montrent le fonctionnement du service MMS:

L’utilisateur active le client MMS (application disponible sur la station mobile

Figure 5: Envoi d’un message multimédia : Flux d’information

destinataire l’informant de l’arrivée d’un MMS, acquittée par ce dernier (réponse

2. Les services Web

2.2. Principe fondamental du service Web

2.3. A quoi ressemble un service Web

Figure 8: : Un service Web est constitué de plusieurs composants clés

2.4. La couche de technologie dans un service Web

Figure 9: Pile de technologies dans les services Web.

2.4.2. UDDI (Universal Description, Discovery et Integration)

Figure 10: Structure des données UDDI

2.4.4. WSDL (Web Services Description Language)

Figure 11: Structure de WSDL

2.4.6. SOAP (Simple Object Access Protocol)

Figure 12: Structure d'un message SOAP

2.5. Architecture des services Web

L’architecture des services Web a trois rôles distincts :

Figure 13: Rôles et opérations des services Web

Chapitre 2 : Etude De L’Existant Et Spécification

1.1. Historique de ALMAP FM

1.2. Fonctionnalités de ALMAP FM

ALMAP FM est un outil de supervision de systèmes de télécommunication. Il permet, à

1.3. Architecture de ALMAP FM

ALMAP FM est architecturé pour subvenir essentiellement aux besoins suivants :

permettre la navigation vers d’autres application ALMAP.

Web Server Host(s)

Firewall IIOP IIOP

« C++ application » « C++ application »

« C++ application » « C++ application »

GUI client application Server application Optional application

Figure 14: Architecture de FM

1.4. Critique de l’existant