Ben Khemis Amine

Introduction gnrale
Cycle de formation des ingnieurs en Tlcommunications

Option :
Rseaux et Services Mobiles (RSM)
Rapport de Projet de fin dtudes
Thme :
Conception et ralisation du service MMS To Postcard

Ralis par :
Mohamed Amine BEN KHEMIS

Encadrants :
M. Abdennacer CHIKHI M. Zied CHOUKAIR

Travail propos et ralis en collaboration avec
Anne universitaire : 2005/2006
Ddicaces
A mes parents, A mon frre, A mes surs, A la mmoire de mon cousin Hatem, A toute ma famille, Je ddie ce modeste travail.
-i-
Remerciement
Le travail prsent dans ce mmoire a t effectu dans le cadre de la prparation du diplme d'ingnieur en tlcommunications, option Rseaux et Services Mobiles (RSM) l'Ecole Suprieure des Communications de Tunis (SUP'COM). Au terme de ce projet, je tiens exprimer ma profonde gratitude et mon immense respect Monsieur Zied CHOUKAIR, Matre de confrences l'cole suprieure des Communications de Tunis, et Madame Asma BEN LTAIFA, pour leur disponibilit, leur persvrance et leur dynamisme. J'aimerais tmoigner du plaisir qu'tait pour moi de travailler sous leurs directives. Mes vifs remerciements s'adressent galement Monsieur Abdennaceur CHIKHI, ingnieur Ericsson pour ses conseils et son soutien affectif. Avec beaucoup d'gard, je ne manquerai pas d'exprimer ma grande reconnaissance tous les enseignants et administrateurs de l'cole suprieure des communications de Tunis et tous les membres du jury pour avoir accept de juger ce modeste travail.
ii
Avant- Propos
Dans le cadre da ma formation dingnieur en tlcommunication lcole Suprieur des communications de Tunis, jai effectu un projet de fin dtudes au sein de lentreprise Ericsson. Le sujet porte sur la conception et limplmentation du service MMS To Postcard sur la plateforme du rseau dessai dEricsson. Ericsson est lun des plus grands quipementiers des systmes mobiles dans le monde et soutient toutes les normes principales pour la communication sans fil. Les dix plus grands oprateurs mobiles du monde sont parmi ses clients et quelques 40% de tous les appels mobiles sont faits par les systmes d'Ericsson. La socit Ericsson fournit des solutions totales, des systmes et des applications aux services. Elle a t en activit dans le monde entier depuis 1876 et elle est aujourd'hui prsente dans plus de 140 pays. Ses siges sociaux sont situs Stockholm au Sude [8].
iii
Table des matires
Avant- Propos............................................................................................................................ iii Table des matires..................................................................................................................... iv Liste des figures......................................................................................................................... vi Liste des abrviations .............................................................................................................. vii Introduction gnrale ................................................................................................................ 1 Chapitre I : Service MMS to Postcard : tat de lart ............................................................ 3 I-1 Prsentation du protocole WAP ..................................................................................... 3 I-1-1 Dfinition .................................................................................................................... 3 I-1-2 Gnralits .................................................................................................................. 3 I-2 Prsentation du service MMS ......................................................................................... 6 I-2-1 Dfinition .................................................................................................................... 6 I-2-2 Architecture................................................................................................................. 6 I-2-3 Linterface MM7......................................................................................................... 8 I-3 Conclusion......................................................................................................................... 9 Dans ce premier chapitre nous avons tudi les diffrentes normes et protocoles qui vont tre utiliss pour implmenter le service MMS To Postcard . Cette tude nous sera utile pour spcifier les besoins de lapplication finale et envisager une solution possible.......... 9 Chapitre II : tude de faisabilit et spcification des besoins ............................................. 10 II-1 tude de faisabilit ....................................................................................................... 10 II-1-1 tude et critique de lexistant .................................................................................. 10 II-1-2 tude des solutions possibles .................................................................................. 11 II-1-3 Bilan de lanalyse et choix de la solution ................................................................ 13 II-2 Spcification des besoins .............................................................................................. 15 II-2-1 Spcification gnrale des besoins .......................................................................... 15 II-2-2 Modle de cas dutilisations .................................................................................... 17 II-3 Conclusion ..................................................................................................................... 21 Dans ce deuxime chapitre, nous avons utilis une mthodologie UML pour spcifier les cas dutilisations de la solution adopte. Cette spcification va nous servir comme base pour concevoir le service. .................................................................................................. 21 Chapitre III : Conception du service MMS To Postcard ............................................... 22 III-1 tude conceptuelle ...................................................................................................... 22 III-2 Organigramme ............................................................................................................ 26 III-3 Conception dtaille.................................................................................................... 27 III-3-1 Diagramme de paquetages ..................................................................................... 27 III-3-2 Diagrammes de classes........................................................................................... 28 III-4 Diagrammes de squences.......................................................................................... 34 III-4-1 Envoi dun seul message ........................................................................................ 34 III-4-2 Ajout dun nouveau contact ................................................................................... 35 III-4-3 Envoi multiple ........................................................................................................ 35 III-4-4 Transmission des messages vers le MMSC ........................................................... 37 iv
III-5 Conclusion ................................................................................................................... 37 Chapitre IV : Choix technique et Ralisation ....................................................................... 38 IV-1 Environnement logiciel ............................................................................................... 38 IV-2 Outils logiciels.............................................................................................................. 39 IV-2-1 Les outils web ........................................................................................................ 39 IV-2-2 Les API .................................................................................................................. 41 IV-2-3 Les serveurs............................................................................................................ 43 IV-2-4 Le systme de gestion des bases de donns ........................................................... 43 IV-3 Implmentation ........................................................................................................... 43 IV-3-1 Description Fonctionnel......................................................................................... 44 IV-3-2 Prsentation de linterface utilisateur..................................................................... 45 IV-4 Problme daffichage sur les mobiles et solution propose ..................................... 47 IV-5 Conclusion.................................................................................................................... 48 Conclusion et perspectives ...................................................................................................... 49 Annexes ....................................................................................................................................... 1 Bibliographie .............................................................................................................................. 0
Liste des figures

Figure 1 : Architecture du protocole WAP .................................................................................. 5 Figure 2 : Architecture du service MMS ..................................................................................... 7 Figure 3 : Architecture finale du service MMS To Postcard ..................................................... 14 Figure 4 : Diagramme de cas d'utilisation ................................................................................. 19 Figure 5 : Sparation entre le module de tarification et l'application ........................................ 23 Figure 6 : Ajout dune base de donns pour connecter le serveur dapplication au module de tarification .................................................................................................................................. 24 Figure 7 : Extension du service MMS To Postcard ................................................................... 25 Figure 8 : Organigramme du service MMS To Postcard ........................................................... 26 Figure 9 : Diagramme de paquetages......................................................................................... 27 Figure 10 : Diagramme de classes du paquetage "UserInterface" ............................................. 28 Figure 11 : Diagramme de classes du paquetage "UploadParam"............................................. 29 Figure 12 : Diagramme de classes du paquetage "DBConnection"........................................... 31 Figure 13 : Diagramme de classes du paquetage "CCNInterface" ............................................ 32 Figure 14 : Diagramme de classes du paquetage "Printing"...................................................... 32 Figure 15 : Diagramme de squences pour un envoi simple ..................................................... 34 Figure 16 : Diagramme de squences en cas d'ajout d'un contact ............................................. 35 Figure 17 : Diagramme de squences pour un envoi multiple................................................... 36 Figure 18 : Diagramme de squences du service lorsque les messages passe par l' MMSC..... 37 Figure 19 : Architecture de la plateforme Java .......................................................................... 39 Figure 20 : Utilisation de l'api "Ericsson MM7 API" ................................................................ 42 Figure 21 : Utilisation de l'api "Diameter Charging API" ......................................................... 42 Figure 22 : Schma fonctionnel du produit final ....................................................................... 45 Figure 23 : Les premires pages de l'interface........................................................................... 45 Figure 24 : Formulaire denvoi dun seul message et interface des options pour lenvoi multiple .................................................................................................................................................... 46 Figure 25 : Interface d'envoi multiple........................................................................................ 46 Figure 26 : Mise jour et consultation de la liste des contacts.................................................. 47 Figure 27 : Pile de protocoles du WAP1 ..................................................................................... 1 Figure 28 : Conversion des protocoles pour WAP1 .................................................................... 2 Figure 29 : Conversion des protocoles pour WAP2 .................................................................... 3 Figure 30 : Exemple d'un message SOAP ................................................................................... 6 Figure 31 : Communication entre le fournisseur de services et le systme de tarification.......... 9
vi
Liste des abrviations
AAA API CCN CCF JDBC GSM GPRS HLR HTML HTTP IP JSP J2ME MIDP MMS MMSC MSISDN PPP SCAP SGBD SGML SLIP
Authentication Autorization Accounting Application Programming Interface Charging Control Node Charging Control Function Java Data Base Connectivity Interface Global System for Mobile communications General Packet Radio Service Home Location Registry HyperText Markup Language HyperText Transfer Protocol Internet Protocol Java Server Pages Java 2 MicroEdition Mobile Information Device Profile Mobile Messaging Service Mobile Messaging Service Center Mobile Station International ISDN Number Point to Point Protocol Service Charging Application Protocol Systme de Gestion des Base de Donns Standard Generalized Markup Language Serial Line Internet Protocol
vii
SMTP SMS SOAP SQL SSL TCP TSP URL UML UMTS VASP VPN WAE WAP WDP WML WSP WTP WTLS W3C XHTML XML XSL
Simple Mail Transfer Protocol Short Message Service Simple Object Access Protocol Structured Query Language Secure Socket Layer Transmission Control Protocol Telecommunication Server Platform Uniform Ressources Locator Unified Modeling Language Universal Mobile Telecommunication System Value Added Service Provider Virtual Private Network Wireless Application Environment Wireless Application Protocol Wireless Datagram Protocol Wireless Markup Language Wireless Session Protocol Wireless Transaction Protocol Wireless Transport Layer Security World Wide Web Consortium eXtensible HyperText Markup Language eXtensible Markup Language eXtensible Stylesheet Language
viii
Introduction gnrale
Introduction gnrale
Les rseaux mobiles ne sont plus utiliss que pour transporter la voix. Avec lapparition du GPRS et de l UMTS, la bande passante a connu une amlioration considrable, ce qui a permis limplmentation de nouveaux services multimdias. Ainsi, louverture des rseaux radios mobiles de nouveaux services valeur ajoute constitue lun des segments les plus porteurs du march des tlcommunications dans les prochaines annes. En effet, cette nouvelle vision permet, et pas seulement aux oprateurs de gnrer plus de trafic sur leurs rseaux, dobtenir plus de gains, et permettre des fournisseurs de service de profiter de linfrastructure des rseaux pour proposer de nouveaux services aux abonns. Lun des services les plus connus est le MMS. Il reprsente le successeur du clbre SMS, et il offre la possibilit aux abonns de transmettre des messages multimdias. Le problme avec ce service est quil ne connat pas lnorme succs que le SMS a connu, ce qui a pouss les oprateurs permettre lutilisation de ce service comme base pour dautres services valeurs ajoutes. Cest dans ce cadre que ce projet sinscrit. Il sagit de concevoir, implmenter et intgrer le service MMS To Postcard sur la plateforme du rseau radio mobile dEricsson. La plupart des terminaux mobiles de nouvelle gnration sont compatibles avec le protocole WAP dans sa deuxime version. On pourra ainsi les utiliser pour transmettre et recevoir des donns via le rseau radio mobile. De plus, la majorit de ces terminaux sont quips dappareil photo. Lide de ce projet part du faite quon peut exploiter ces deux caractristiques des nouveaux terminaux mobiles pour offrir aux abonns dun oprateur la possibilit denvoyer des cartes postales personnalises. En plus du gain quil pourra gnrer pour loprateur et pour le fournisseur, ce service peut rendre lusage des cartes postales dlaisses aprs lapparition des services de messageries lectroniques. Ainsi, la poste pourra gnrer des gains supplmentaires grce ce service. La diffrence entre ce service et lenvoi de cartes postales traditionnelles cest que labonn pourra dfinir lui-mme limage quil va envoyer son destinataire. Cet avantage est particulirement intressant puisquil permet dautres usages de ce service que lon verra plus loin dans ce rapport.
Med Amine BEN KHEMIS
-1-
Introduction gnrale Limplmentation de ce service require le dveloppement de deux parties principales savoir linterface utilisateur et la partie serveur. Il sagit aussi de dvelopper une interface qui permettra cette application de communiquer avec le systme de tarification. Dans ce rapport de fin dtude, nous commencerons, dans un premier chapitre par une recherche bibliographique. Nous prsenterons travers cette partie linfrastructure sur laquelle nous nous sommes bass pour implmenter ce service, Nous sommes passs, dans un deuxime chapitre, une tude comparative entre les diffrentes solutions possibles. A partir de cette tude, nous avons choisi la solution qui va tre implmente, et nous avons spcifi les besoins de cette solution en prcisant les diffrents cas dutilisations du systme final. Dans le troisime chapitre, nous nous sommes bass sur le formalisme UML pour concevoir la solution choisi. Dans le quatrime chapitre, nous prsentons les diffrents outils utiliss et linterface daccs au service.
Chapitre I : Service MMS to Postcard : tat de lart
Chapitre I
Service MMS to Postcard : tat de lart
Le service MMS To Postcard est un service qui marie les services offerts par les nouvelles technologies des communications au traditionnel service postal. Il permet aux usagers dapporter leur touche personnelle aux cartes postales quils envoient leurs correspondants. Pour implmenter ce service, une tude de quelques protocoles et entits des rseaux radio mobiles simposent. Dans cette partie du rapport, nous prsentons les diffrents protocoles et entits du rseau que nous avons utilis pour mettre en place le service MMS To Postcard .
I-1 Prsentation du protocole WAP I-1-1 Dfinition

Le WAP, standardis par le WAP Forum, est un protocole de communication dont le but est de permettre aux abonns dun oprateur mobile daccder Internet laide de terminaux mobiles. En plus de la connectivit Internet, ce protocole a t conu pour offrir la possibilit aux oprateurs dintgrer de nouveaux services multimdias sur leurs infrastructures [9].
I-1-2 Gnralits
Le protocole WAP comprend deux versions. Pour la premire version, on essayait de profiter du service de transmission de donns bas sur la commutation de circuit comme pour le cas du GSM. Mais lorsquon est pass la commutation de paquets dans les rseaux
-3-
Chapitre I : Service MMS to Postcard : tat de lart mobiles, en vue doptimiser les ressources et damliorer la bande passante, le protocole WAP a aussi volu pour sadapter cette nouvelle infrastructure. aLe WAP 1 Les premiers terminaux mobiles avaient des optionalits trs limites, ils ne permettaient pas dafficher du contenu multimdia. Pour offrir des services bass sur la transmission de donns, le WAP, dans sa premire version, a spcifi des protocoles (voir Annexe A) qui avaient pour rle doptimiser le contenu des serveurs et de ladapter ces terminaux, offrant ainsi dautres services aux abonns que la tlphonie et le SMS. Cependant, cette version du WAP na pas connu un grand succs et a t trs vite dlaisse cause de son manque dinteractivit. bvolution vers le WAP 2 Avec lvolution des rseaux mobiles et lamlioration considrable de la bande passante. On tait contraint de faire voluer le protocole WAP pour mieux utiliser ces ressources, surtout avec la nouvelle gnration des terminaux mobiles qui supportent les protocoles de transports classiques dInternet. Cette nouvelle version du protocole WAP introduit de nouvelles fonctionnalits multimdias, telles que le Streaming ou le tlchargement de contenu multimdia volumineux. Pour cela, la pile protocolaire de ce standard a t redfini (voir annexe A). En plus de la migration vers le TCP/IP comme protocole de transport. Ainsi, les utilisateurs quips de terminaux compatibles WAP 2 auront laccs des applications plus riches, avec des graphiques en couleur et des possibilits textuelles accrues. Cette modification de la pile de protocole sur la quelle se base le WAP rend plus facile le dveloppement et lintgration de nouveaux services puisquon pourra profiter de lexpertise acquise du monde informatique et plus prcisment du domaine du dveloppement web pour implmenter des services multimdias.
Chapitre I : Service MMS to Postcard : tat de lart cLa passerelle WAP Afin de permettre aux terminaux mobiles daccder Internet, le protocole WAP dfinit une architecture spcifique. Il sagit de connecter le rseau mobile de loprateur une passerelle, connue encore sous le nom de passerelle WAP ou WAP Gateway , cette passerelle joue le rle dinterface entre le mobile et le serveur et permet ainsi dadapter les messages transmis au protocole de communication correspondant. Cette entit du rseau encode les documents WML ou XHTML (voir Annexe B), selon la version du protocole utilise, avant leur envoi au mobile, et dans lautre sens, elle cre des requtes HTTP partir des requtes WAP. Elle est galement utilise par les fournisseurs de services pour rcuprer certains paramtres de lutilisateur, comme l MSISDN, pour contrler laccs leurs services. Pour conclure voici un schma rcapitulatif de larchitecture du rseau sur laquelle se base le protocole WAP.
Figure 1 : Architecture du protocole WAP
I-2 Prsentation du service MMS I-2-1 Dfinition

LMMS, est un service qui permet aux abonns dun oprateur mobile denvoyer et de recevoir des messages multimdias partir de terminaux compatibles. Considr comme le successeur du clbre SMS, ce service ne sest pas limit quaux messages textuels mais il a permis en plus le transfert des images et des sons. Dans sa version la plus rcente, il offre la possibilit de transmettre des squences vido.
I-2-2 Architecture
aLMMSC Le MMSC, est lentit qui reoit les messages multimdias des expditeurs et les transmet leurs destinataires respectifs, elle permet aussi de rcuprer des informations concernant les abonns du HLR et les envoie au systme de tarification pour dcrmenter son compte suite lutilisation du service. Dans certaines configurations on peut trouver que le MMSC est dcompos en MMS Server et MMS Relay. bLes diffrentes interfaces du MMSC Pour permettre au centre de messagerie multimdia de communiquer avec les diffrentes entits du rseau il a fallut dfinir des interfaces. On entend par interface, la spcification des communications entre deux entits. Ces interfaces sparent les spcifications en huit normes nommes MM1, MM2, jusqu' MM8. En ralit il existe 10 interfaces, mais les deux interfaces MM9 et lMM10 sont en cours de dveloppement [1] [4].
La figure suivante met en vidence les diffrentes interfaces du MMSC.
Figure 2 : Architecture du service MMS
Linterface MM1 Cest linterface entre labonn et le MMSC. Linterface MM2 Cest linterface entre MMS Server et MMS Relay. Puisque ces deux entits peuvent tre combines sous forme de MMSC, linterface MM2 est propritaire.
Linterface MM3 Cette interface relie l MMSC aux diffrents serveurs externes comme les serveurs Mail et les centres SMS, dans cette interface on utilise le protocole SMTP pour transfrer les messages entre les entits du rseau.
Linterface MM4 Il sagit de linterface reliant les MMSC moyennant des connecteurs SMTP. Linterface MM5 Cest linterface par laquelle l MMSC est connect au HLR. Cette interface nest pas encore complte.
Chapitre I : Service MMS to Postcard : tat de lart Linterface MM6 Cette interface permet au MMSC daccder des bases de donns externes. Elle nest pas encore normalise. Linterface MM7 (ou linterface VASP). Cest une interface standard qui permet un fournisseur de service de connecter son serveur dapplication l MMSC pour offrir un service valeur ajoute bas sur lMMS. Cette interface joue un rle important dans lintgration de nouveaux services. Linterface MM8 Cette interface est rserve aux changes entre le MMSC et les systmes de facturation.
I-2-3 Linterface MM7

Linterface qui nous intresse le plus est linterface MM7 car cest travers cette interface quon peut ventuellement intgrer de nouveaux services valeur ajoute. LMM7 spcifie les diffrents protocoles quil faut respecter pour pouvoir mettre en place une application qui sera en mesure de communiquer avec L MMSC. Il sagit des protocoles SOAP et HTTP. aLe protocole SOAP SOAP pour Simple Object Access Protocol est un protocole de transmission de messages, il dfinit un ensemble de rgles pour structurer les messages transmettre, il est particulirement utile pour excuter des dialogues requte-rponse. Il nest pas li une plateforme donn ce qui le rend intressant pour dvelopper des applications distribues. Il nest pas non plus li un systme dexploitation particulier, ce qui donne la possibilit aux applications tournants sur des systmes diffrents de dialoguer ensemble du moment quils puissent formuler et comprendre les messages SOAP [5] [6]. Le protocole SOAP est compos de deux parties :
Une enveloppe, contenant des informations sur le message lui-mme afin de permettre son acheminement et son traitement. Un modle de donns, dfinissant le format du message, c'est--dire les informations transmettre. Dans le cas de linterface MM7, on utilise les messages SOAP pour transmettre les
diffrents paramtres de lutilisateur du service et une dclaration pour chaque fichier attach au message. Dans cette dclaration, on spcifie le type du message, le codage utilis, et plusieurs autres paramtres qui ont pour rle dinformer le rcepteur des caractristiques des messages envoys (voir Annexe C). Ces messages sont ensuite encapsuls par le protocole HTTP. bLe protocole HTTP Le protocole HTTP est le protocole le plus utilis sur Internet depuis 1990. A partir de la version 1.0 du protocole, on peut transfrer des messages avec des en-ttes dcrivant le contenu du message. Le but du protocole HTTP est de permettre un transfert de fichiers, la base essentiellement des fichiers HTML, mais tout autre type de fichier est possible. Les fichiers sont localiss grce une chane de caractres appele URL.
I-3 Conclusion
Dans ce premier chapitre nous avons tudi les diffrentes normes et protocoles qui vont tre utiliss pour implmenter le service MMS To Postcard . Cette tude nous sera utile pour spcifier les besoins de lapplication finale et envisager une solution possible.
Chapitre II : tude de faisabilit et spcification des besoins
Chapitre II
tude de faisabilit et spcification des besoins
II-1 tude de faisabilit II-1-1 tude et critique de lexistant

Dans cette section, nous prsentons les diffrentes implmentations dj faites du service MMS To Postcard . a- Solution implmente par Orange Il sagit dutiliser linterface standard de composition des messages MMS quont trouve sur tous les terminaux compatibles. Le problme avec cette interface est de comment indiquer au serveur ladresse du destinataire parce que cette interface ne nous permet lenvoi de MMS que vers un autre mobile ou vers une adresse E-mail. La solution propose par Orange est dutiliser le champ texte pour indiquer ladresse du destinataire, le nom de lexpditeur et le contenu du message. Ils indiquent aux abonns dsirant utiliser ce service quils doivent se conformer un format prcis du texte envoyer avec limage, il sagit de sparer les diffrents champs par # . La partie serveur se chargera ensuite de dcomposer les diffrents champs. Lavantage de cette mthode est quon peut profiter de linfrastructure du service MMS. Son inconvnient rside dans la complexit dutilisation.
- 10 -
b- Solution implmente par VODAFONE Ce service a dj tait implment par VODAPHONE , leur solution consiste en la configuration des mobiles qui seront en mesure daccder ce service. Ils ont install directement linterface utilisateur sur les terminaux. Cette solution a t adopte par plusieurs fournisseurs de service cest pourquoi dans certains terminaux mobiles on peut trouver loption denvoi de carte postale. Linconvnient de cette solution est que linterface utilisateur doit tre install sur le mobile. Cette mise jour ne peut pas se faire automatiquement via linterface radio parce que laccs au mobile et la modification de ses paramtres via cette interface et trs limit vu les problmes de scurit, ce qui implique que le fournisseur du service est oblig de configurer les mobiles des utilisateurs manuellement et individuellement ce qui est pratiquement irralisable, ou de configurer certaines marques de mobiles, mais dans ce cas lutilisateur dsirant bnficier de ce service doit acheter un mobile de ces marques ce qui est un facteur dcourageant pour sy abonner. Les solutions proposes dans ce PFE doivent permettent daccder ce service sans configuration pralable du terminal.
II-1-2 tude des solutions possibles

Dans cette section nous avons tudi les diffrentes solutions possibles en prsentant les avantages et les inconvnients de chaque solution. a- Interface utilisateur Linterface utilisateur doit tre comprhensible et simple manipuler par tous les abonns, il y a beaucoup de solutions possibles pour implmenter cette partie.
11
i- Intgrer linterface dans une MIDlet Cette interface peut tre intgre dans une MIDlet (voir Annexe D), il sagit dune archive contenant des classes Java. Aprs le tlchargement de la MIDlet, la machine virtuelle Java qui se trouve sur le mobile se charge de lexcution des classes java ouvrant ainsi une interface utilisateur. Cette interface a pour rle la composition du message et sa transmission au serveur. Lavantage de cette mthode est que lutilisateur tlcharge une seule fois linterface lui permettant de communiquer avec le serveur, et peut sen servir chaque fois quil veut utiliser ce service. Linconvnient est que certains mobiles ne contiennent pas de machine virtuelle Java pour excuter ce programme, de plus ce programme accde aux rpertoires du mobile donc cela reprsente un problme de scurit pour les abonns. ii- Linterface utilisateur est un formulaire HTML Lide est inspire des formulaires HTML quon peut trouver sur certains sites web. Pour accder au service, lutilisateur devra chaque fois tlcharger une page HTML contenant un formulaire, ce formulaire prcise chaque champ du message envoyer. On peut par exemple dfinir un champ pour ladresse du destinataire, un deuxime pour le nom de lexpditeur, un troisime champ pour le message textuel et un dernier avec lequel on peut attacher limage transmettre. Cette mthode prsente beaucoup davantages : Profiter des technologies du dveloppement web pour implmenter cette interface. Avec cette mthode on na pas un problme de compatibilit car touts les terminaux compatibles WAP peuvent afficher cette interface. Avec cette mthode, on pourra utiliser ce service en se connectant dun poste de bureau.
12
Cette mthode prsente aussi quelques inconvnients : Labonn doit imprativement passer par un service de connexion Internet pour bnficier de ce service. Comme il y a une grande varit de navigateurs installs sur les terminaux mobiles, et que la taille de lcran diffre dun mobile lautre, alors il y a un problme daffichage de cette interface, c'est--dire que cette page ne sera pas affiche de la mme faon pour touts les terminaux. b- Partie serveur Cette partie reoit les messages multimdias, les enregistrent sur le serveur, les met sous un format de carte postale et les imprime. On aura le choix pour cette partie entre connecter ce module au centre de messagerie MMS, ou linstaller sur un serveur totalement indpendant de larchitecture du service MMS mais qui utilise le protocole WAP pour communiquer avec le client. Le choix qui sera fait dpend troitement du choix de la solution implmenter pour linterface utilisateur. Ce module doit tre en mesure de communiquer avec le systme de tarification, il faudra donc dvelopper une interface le reliant ce systme.
II-1-3 Bilan de lanalyse et choix de la solution

a- Bilan Selon ce qui a dj t avanc, on remarque que chaque solution a ses avantages et ses inconvnients, le but de ce projet est de trouver un compromis entre ces diffrentes solutions pour que ce service soit accessible et facile utiliser par tout le monde, pour cela, la solution intgrant linterface utilisateur dans une MIDLet est carter, non seulement parce quelle ne permet pas aux terminaux qui ne sont pas quips dune machine virtuelle Java daccder ce service mais aussi cause des paramtres de scurit des mobiles qui supportent ces
13
Chapitre II : tude de faisabilit et spcification des besoins programmes . Lapproche qui a t dvelopp par VODAFONE ne peut pas, aussi, tre considr cause de son ct limitatif pour laccs au service. b- Choix de la solution implmenter La solution qui sera retenu pour limplmentation de ce service est celle qui permettra un accs facile pour les utilisateurs. Pour cela jai opt pour la solution web, il sagit de dvelopper une interface web pour les abonns, cette interface contiendra un formulaire HTML pour la composition des messages et se chargera de les envoyer au serveur en utilisant le protocole WAP. Non seulement, cette approche offre la possibilit de jouer sur la prsentation mais elle est trs maniable et extensible, par exemple on pourra ajouter loption denvoi multiple vers un groupe de destinataires dfini pralablement par lutilisateur. Seulement, le problme avec cette solution est quelle oblige les utilisateurs passer par une connexion Internet. Pour contourner ce problme, nous avons utilis lide de Orange pour dvelopp une autre approche complmentaire la premire, il sagit dutiliser linterface classique denvoi des messages multimdias en dfinissant un format spcifique du texte envoyer avec limage, cela implique que les messages vont transiter par le centre de messagerie multimdia, donc il y a deux contraintes dont nous devons tenir compte, la premire est quil faut connecter lapplication qui se chargera de la rception des messages lMMSC et la deuxime est quil faut configurer le centre de messagerie pour quil puisse router ces messages vers cette application. Pour rcapituler, voici un schma explicatif (figure 3) de larchitecture finale sur laquelle ce service va tre bas :
Figure 3 : Architecture finale du service MMS To Postcard
14
II-2 Spcification des besoins

La spcification des besoins du systme final dpend troitement de la solution retenue. Dans cette partie, nous avons spcifi les diffrents besoins fonctionnels et non fonctionnels requis pour limplmentation de la solution voque prcdemment et les cas dutilisations possibles du systme final. Nous sommes ensuite passs la conception de cette solution.
II-2-1 Spcification gnrale des besoins

Mme si les deux solutions adoptes sont complmentaires, ils prsentent, toutefois, quelques besoins diffrents. Le travail demand consiste : Pour la premire approche, implmenter une interface utilisateur et une application ct serveur qui aura pour rle de recevoir les messages, les formater et les imprimer, ainsi quune solution pour la tarification du service. Pour la deuxime approche, concevoir et implmenter une application qui utilisera linterface standard MM7 pour recevoir les messages directement du MMSC, les formater et les imprimer. Donc ces applications doivent obir aux besoins suivants : a- Besoins fonctionnels Certains besoins fonctionnels sont communs aux deux approches alors que dautres sont spcifiques chaque une. Besoins fonctionnels pour la premire approche Linterface utilisateur est une interface web qui permettra de contrler laccs ce service et de vrifier le compte de lutilisateur en cas denvoi multiple.
15
Chapitre II : tude de faisabilit et spcification des besoins La solution propose pour la tarification doit tre indpendante de la tarification dans le service MMS puisque les messages ne passeront pas par l MMSC, elle doit tre intgre dans lapplication dvelopper et doit pouvoir communiquer avec le systme de tarification. Labonn doit se connecter au serveur et remplir un formulaire qui se chargera de transmettre le message, donc pour accder ce service, il doit tre abonn un service de connexion Internet. Besoins fonctionnels pour la deuxime approche Le serveur dapplication doit tre connect au MMSC via linterface MM7, donc lapplication doit tre en mesure de comprendre le format des messages dfinis par le protocole SOAP (voir Annexe C). Lutilisateur doit connatre la structure du texte quil va envoyer avec limage car cest dans ce texte que doivent tre spcifis le nom de lexpditeur, ladresse du destinataire et le message envoyer avec limage. Besoins fonctionnels communs Lapplication qui se chargera du formatage des messages et de leur impression est commune aux deux solutions, donc, elle doit tre indpendante de la mthode utiliser pour recevoir les messages. De plus, cette application doit lancer un processus qui fonctionne continuellement et qui accde priodiquement au serveur o sont stocks les messages pour en imprimer les nouveaux. b- Besoins non fonctionnels Ces besoins rsultent des contraintes lies au produit final et son dveloppement. Contraintes lies au produit final Ce service doit tre accessible par touts les terminaux mobiles compatibles avec le rseau de loprateur (GPRS, UMTS,).
16
Chapitre II : tude de faisabilit et spcification des besoins Les interfaces utilisateurs doivent tre comprhensibles, et lutilisation de ce service ne doit pas exiger des connaissances techniques en informatique ou en tlcommunication. Contraintes lies au dveloppement Concernant la premire solution, pour linterface utilisateur, il est commode quelle soit gnre partir dun script qui sexcute sur le serveur, cela nous permettra davoir une interface dynamique avec laquelle on pourra contrler laccs au service. Linterface qui communiquera avec le systme de tarification doit tre en mesure de comprendre le protocole de communication avec ce systme savoir le protocole SCAP qui est bas sur le protocole Diameter (voir Annexe E) [3].
II-2-2 Modle de cas dutilisations

Le modle de cas dutilisations est un modle conceptuel bas sur le formalisme UML [7]. Le but de la conceptualisation est de comprendre et structurer les besoins du client. Aprs quils soient identifis et structurs, ces besoins prcisent le but attendu du systme implmenter. Ce modle est dcri par le diagramme de cas dutilisations. Il sagit de diagramme qui reprsente les cas d'utilisation, les acteurs et les relations entre les deux, il dcrit le comportement d'un systme du point de vue d'un utilisateur et permet de dfinir ses limites et ses relations avec l'environnement. Les acteurs se reprsentent sous la forme de petits personnages. Un acteur reprsente le rle jou par une personne ou une chose qui interagit avec un systme. Les acteurs se dterminent en observant les utilisateurs directs du systme, ceux qui sont responsables de son exploitation ou de sa maintenance, ainsi que les autres systmes qui interagissent avec le systme en question. Un cas d'utilisation est une manire spcifique d'utiliser un systme. Il reprsente une fonctionnalit du systme, dclenche suite la stimulation d'un acteur externe.
17
a- Identification des diffrents acteurs agissant sur le systme
Un cas dutilisation reprsente une suite dinteractions entre un acteur et le systme, donc afin de dterminer tout les cas dutilisation du systme, il faut dfinir les diffrents acteurs qui interagissent avec ce systme. Lexpditeur : Cest un abonn de loprateur qui utilise ce service. Le serveur CCN (voir Annexe E): Ce serveur reprsente linterface dintgration des services au niveau du systme de tarification. Le serveur dapplication : Cest le serveur qui va traiter les messages. LMMSC : Cet acteur nintervient que pour la deuxime approche.
b- Diagramme de cas dutilisations Dans ce qui suit , une explication textuelle accompagne le diagramme de cas dutilisations (figure 4), elle comprend un ensemble de pr conditions ncessaires la ralisation du cas dutilisation, une description commentant le cas dutilisation et un ensemble de post-conditions issu de la ralisation du cas dutilisation considr.
18
Figure 4 : Diagramme de cas d'utilisation
Cas dutilisation EnvoyerMMS
Ce cas dutilisation reprsente deux scnarios possibles. Ces scnarios dpendent troitement de la solution qui va tre utilise. Pr condition : a) Si lutilisateur va utiliser linterface web pour accder ce service, son terminal doit tre configur pour le WAP 2. b) Si lutilisateur va utiliser linterface classique denvoi des MMS, alors son mobile doit tre configur pour le service MMS.
19
Chapitre II : tude de faisabilit et spcification des besoins Bien sur, nous supposons que les utilisateurs qui vont accder ce service sont quips de terminaux compatibles WAP 2. Description : Lutilisateur compose un message multimdia, c'est--dire quil va choisir limage, crire le texte, et spcifier ladresse du destinataire puis envoie le touts au serveur. Post condition : Les messages envoys vont tre reus et traits par le serveur dapplication. Cas dutilisation GrerLesRequtes
Pr condition : Le serveur dapplication doit tre accessible aux utilisateurs dsirant bnficier du service. Description : Le serveur dapplication reoit les requtes des utilisateurs, leur envoie la page web contenant linterface utilisateur et rcupre les messages envoys. Post condition Les messages sont enregistrs sur le serveur dapplication. Cas dutilisation TransfrerMessage
Pr condition : Le MMSC doit tre configur pour router les MMS vers le serveur dapplication Description : Les MMS des utilisateurs utilisant ce service sont routs vers le serveur sapplication. Post condition : LMMSC encapsule les MMS dans le protocole dfinit par linterface MM7 qui le relit au serveur dapplication.
20
Cas dutilisation TraiterMessage
Pr condition : Le message est enregistr sur le serveur dapplication. Description : Ce cas dutilisation englobe les diffrents traitements des messages pour gnrer finalement une carte postale. Ces traitements sont le formatage des messages, c'est-dire leur mise sous forme de carte postale standard, et leur impression. Post condition : Cration dune carte postale partir du message multimdia envoy par lutilisateur.
II-3 Conclusion
Dans ce deuxime chapitre, nous avons utilis une mthodologie UML pour spcifier les cas dutilisations de la solution adopte. Cette spcification va nous servir comme base pour concevoir le service.
21
Chapitre III : Conception du service MMS To Postcard
Chapitre III
Conception du service MMS To Postcard
Aprs la dtermination des besoins fonctionnels et non fonctionnels et la spcification des besoins de lapplication, nous sommes passs, dans ce troisime chapitre la conception du projet. Notre tude se base sur le formalisme UML, dans un premier temps, nous prsentons une tude conceptuelle comportant les difficults conceptuelles rencontres et les solutions proposes pour les surmonter, ensuite , nous passons une conception dtaille du projet puis les diagrammes de classe relatifs lapplication.
III-1 tude conceptuelle

Le service qui va tre implment peut tre dploy par un fournisseur de service indpendant de loprateur, donc ce fournisseur ne doit pas avoir accs au systme de tarification, or daprs la spcification des besoins, il faut prvoir un module qui sera en mesure de communiquer avec ce systme, et ce module appartient lapplication elle-mme, donc il sera install sur le serveur dapplication. Le problme est que le fournisseur pourra, par malveillance, se servir de ce module pour dcrmenter les comptes des abonns alors quils nont pas accd au service. La solution que nous avons propose consiste installer la partie tarification sur un serveur nomm serveur de transfre (voir figure 5) indpendant de celui du fournisseur de service, ce serveur appartiendra loprateur. Le fournisseur de service naura, donc, aucun accs au systme de tarification et soccupera seulement du traitement des messages envoys.
- 22 -
Ce serveur aura pour rles le transfre des messages au fournisseur du service et la communication avec le systme de tarification. Cette solution est reprsente dans le schma suivant.
Figure 5 : Sparation entre le module de tarification et l'application
La deuxime difficult rside dans le faite quil faut que, chaque arriv dun nouveau message, le serveur dapplication puisse le rcuprer pour limprimer. Cette condition implique quil doit pouvoir faire la diffrence entre les nouveaux messages arrivs et les anciens messages pour ne pas imprimer deux fois ou plus le mme message. La solution qui vient directement lesprit est deffacer chaque foie le message aprs son impression, or, daprs les exigences de lentreprise, il faudra garder une trace de touts les messages envoys. La solution que nous avons proposes pour contourner ce problme consiste garder les messages sur le serveur de transfre, dfinit prcdemment, et enregistrer le chemin daccs de chaque message envoy dans une base de donn.
23
Chapitre III : Conception du service MMS To Postcard Ainsi, le serveur dapplication, c'est--dire celui du fournisseur de service, devra consulter priodiquement cette base, retirer les chemins daccs des nouveaux messages envoys, rcuprer ces messages pour les imprimer et finalement, effacer ces chemins daccs de la base de donn. La solution finale qui sera implmente est modlise par le schma suivant.
Figure 6 : Ajout dune base de donns pour connecter le serveur dapplication au module de tarification
24
Chapitre III : Conception du service MMS To Postcard Pour permettre plus de flexibilit dans lutilisation de ce service nous avons ajout loption denvoi multiple avec la possibilit de dfinir des groupes de contacts. Cette option permet aux utilisateurs denvoyer la mme carte postale plusieurs correspondants sans quils soient obligs de rpter la mme action plusieurs fois. Pour assurer cette fonctionnalit nous avons ajout une base de donns pour enregistrer les groupes damis des utilisateurs. Cette modification ajoute une nouvelle contrainte respecter dans le systme final. Il faut accder la balance de lutilisateur, chaque fois quil utilise cette option, pour dterminer le nombre maximum de personnes qui il peut envoyer une carte postale en mme temps.
Figure 7 : Extension du service MMS To Postcard
25
III-2 Organigramme
Dans lorganigramme suivant nous dcrivons les diffrentes tapes qui reprsentent le systme final.
Figure 8 : Organigramme du service MMS To Postcard
26
III-3 Conception dtaille

Les diagrammes de classe modlisent les interactions et les hirarchies entre les classes les plus importantes conues pour la ralisation de ce service. Pour modliser les diffrentes classes du systme final nous avons regroup les principales classes en des paquetages selon leurs rles. Dans ce qui suit nous reprsentons le Diagramme de paquetages suivi des diagrammes de classes constituants chaque paquetage. Nous nous sommes appuys sur le formalisme UML [7] pour reprsenter ces diffrents diagrammes.
III-3-1 Diagramme de paquetages
Figure 9 : Diagramme de paquetages
Dans ce diagramme, nous avons modlis les diffrentes relations entre les paquetages du systme. Ces relations dpendent troitement de la spcification des besoins. Med Amine BEN KHEMIS 27
III-3-2 Diagrammes de classes

Dans ce qui suit une description dtaill de chaque paquetage. a- Paquetage UserInterface
Figure 10 : Diagramme de classes du paquetage "UserInterface"
i.
La classe UserAccess Description Cette classe permet de contrler laccs au service et dafficher linterface utilisateur. Mthodes La mthode getMSISDN () permet de rcuprer l MSISDN de lutilisateur pour pouvoir accder son compte. La mthode showUserInterface () permet denvoyer linterface utilisateur labonn.
ii.
La classe VerifyAccount Description Cette classe permet de calculer, daprs la balance de lutilisateur, le nombre de destinataires qui il pourra envoyer des cartes postales en utilisant loption denvoi multiple.
28
iii.
La classe FriendGrp Description Cette classe gre les groupes de contacts des utilisateurs. Mthodes Les mthodes getGrpList() et getFriendList() permettent de rcuprer, respectivement, la liste des groupes de contacts et la liste damis pour chaque groupe, ces listes sont ensuite affiches sur linterface utilisateur.
b- Paquetage UploadParam Le rle principal de ce paquetage est la rception des messages multimdias, il est aussi utilis pour recevoir dautres donns des utilisateurs.
Figure 11 : Diagramme de classes du paquetage "UploadParam"
29
i.
La classe Upload Description Cette classe reprsente la classe mre de ce paquetage. Attribut Lattribut MSISDN contient l MSISDN de lutilisateur Mthodes On utilise la mthode getMSISDN () pour rcuprer l MSISDN de labonn. La mthode getParamFromUser () rcupre les paramtres utiliss pour dfinir les groupes damis
ii.
La classe UploadGrpParam Description Cette classe hrite de la classe Upload et elle est utilise pour dfinir les groupes damis.
iii.
La classe UploadFromHMLForm Description Cette classe hrite de la classe UploadMessage , son rle est de recevoir les messages multimdias partir de linterface web et de les enregistrer sur le serveur. Mthode La mthode filterMsg () filtre les messages envoys pour ne laisser passer que les textes et les images. La classe UploadFromMMSC Description Le systme utilise cette classe pour rcuprer les messages envoys du MMSC travers linterface MM7. Mthodes Les mthodes de cette classe sont utilises pour extraire les MMS des messages SOAP.
30
c- Paquetage DBConnection Ce paquetage joue le rle dinterface entre les autres paquetages et les diffrentes bases de donns du systme, ses classes sont donc utilises pour se connecter aux bases de donns et y effectuer les diffrents traitements.
Figure 12 : Diagramme de classes du paquetage "DBConnection"
i.
La classe ConnectionDB Description Cette classe est utilise pour se connecter ou se dconnecter des bases de donns. Attribut Lattribut success indique si la connexion une base de donn sest effectue avec succs ou si elle a choue. Mthodes Les mthodes de cette classe, comme leur nom lindique, sont utilises pour crer ou fermer une connexion vers une base de donns.
31
d- Package CCNInterface Ce paquetage reprsente linterface qui permet daccder au systme de tarification.
Figure 13 : Diagramme de classes du paquetage "CCNInterface"
i.
La classe DecUserBalance Description Cette classe est utilise pour dcrmenter les comptes des utilisateurs.
ii.
La classe DecUserBalance Description Le rle de cette classe est de consulter la balance des utilisateurs.
e- Package Printing Ce paquetage effectue les derniers traitements aux messages multimdias pour, finalement, gnrer la carte postale.
Figure 14 : Diagramme de classes du paquetage "Printing"
32
i.
La classe GetMsg Description Cette classe rcupre le chemin daccs de chaque message enregistr sur le serveur. Mthodes Les mthodes getTextPath() et getImgPath() sont utilises pour rcuprer, respectivement, le chemin daccs du fichier texte et celui de limage.
ii.
La classe FormatMsg Description Cette classe rcupre les messages du serveur, et les met sous la forme dune carte postale standard.
iii.
La classe Print Description Cette classe imprime les cartes postales.
33
III-4 Diagrammes de squences

Dans cette section, nous dfinissons dabord les diffrents scnarios dutilisation du service, ensuite nous reprsentons, pour chaque scnario, le diagramme de squences. Les scnarios daccs au service sont : Envoi dun seul message. Ajout dun nouveau contact. Envoi multiple. Transmission des messages vers le MMSC.
III-4-1 Envoi dun seul message

Ce scnario reprsente la fonctionnalit de base du service qui est lenvoi dun message un seul correspondant partir de linterface web.
Figure 15 : Diagramme de squences pour un envoi simple
34
III-4-2 Ajout dun nouveau contact

Ce scnario ne reprsente pas une utilisation du service lui mme, il sagit en fait de dfinir les groupes de correspondants et de les enregistrer avec leur coordonnes dans une base de donn.
Figure 16 : Diagramme de squences en cas d'ajout d'un contact
III-4-3 Envoi multiple

Laccs au service se fait de la mme faon que pour le premier scnario, mais avant que lutilisateur nenvoie son message, le systme vrifie son compte pour lui indiquer combien de destinataires il pourra envoyer des cartes postales. Aprs la slection des correspondants et lenvoi du message, le systme vrifie cette fois si lutilisateur a dpass ou non ce nombre. Med Amine BEN KHEMIS 35
Figure 17 : Diagramme de squences pour un envoi multiple
36
III-4-4 Transmission des messages vers le MMSC

Ce scnario fait intervenir une autre entit du rseau, qui est le MMSC. Le diagramme de squences suivant reprsente la succession chronologique des diffrentes tapes intervenant dans la ralisation de la deuxime solution voque prcdemment, c'est--dire, celle qui fait intervenir le MMSC.
Figure 18 : Diagramme de squences du service lorsque les messages passe par l' MMSC
III-5 Conclusion
Dans ce chapitre, nous avons prsent des solutions aux difficults conceptuelles rencontres, et nous avons, ensuite, dtaill la conception des diffrents modules de notre application. Cette conception va nous tre utile pour la ralisation du service.
37
Chapitre IV : Choix techniques et Ralisation
Chapitre IV
Choix techniques et Ralisation
Aprs avoir dtermin les besoins de lapplication et conu les diffrentes parties de ce service, nous sommes passs la ralisation de la solution conue. Mais avant tout, nous prsentons les outils utiliss pour le dveloppement du service MMS To Postcard
IV-1 Environnement logiciel

Le dveloppement des diffrentes classes de lapplication ainsi que la compilation du code ont t fait sur une plateforme Windows. Mais lintgration du service est ralise sur des serveurs Solaris, ce qui a impos une contrainte quand au choix de lenvironnement de dveloppement utilis pour limplmentation du service, ainsi cet environnement doit assurer la portabilit de lapplication finale dune plateforme une autre sans tre oblig de la recompiler. Nous avons opt pour Java, non seulement cause de la contrainte lie la portabilit voques prcdemment mais aussi, parce que ce langage est le plus utilis dans le domaine du dveloppement des services. De plus, la plupart des API disponibles sur Internet sont des API Java. Java est la fois un langage de programmation orient objet et une plateforme d'excution. Sa portabilit est garantie grce la machine virtuelle Java, il sagit dun programme appartenant la plateforme dexcution, qui interprte le code Java et le convertit en code natif. Ce code natif sera ensuite excut par le systme dexploitation.
- 38 -
Le schma ci dessous explique mieux le rle de la machine virtuelle.
Figure 19 : Architecture de la plateforme Java
IV-2 Outils logiciels IV-2-1 Les outils web

Lun des critres dcisifs pour le succs dun service est la simplicit de la manipulation de linterface daccs, cest pourquoi le choix des outils de programmation et surtout les outils du dveloppement web doit tre bien tudi. aLes servlets Lune des tapes primordiale du service dvelopp est de pouvoir envoyer des fichiers au serveur. Donc lapplication qui va tre install sur le serveur doit tre en mesure de rcuprer ces fichiers et le plus important cest de pouvoir rcuprer des fichiers de plusieurs utilisateurs en mme temps. Lune des solutions les plus efficaces qui respecte ces conditions est les servlets [10]. Ce sont des programmes Java qui sintgrent dans un serveur web pour fournir le traitement ct serveur des requtes issues dun navigateur client. Ces programmes permettent de rcuprer
39
Chapitre IV : Choix techniques et Ralisation des donns de plusieurs clients la fois, on dit quils sont multithread c'est--dire lecture multiple , ce mcanisme sexplique par le fait qu chaque requte dun client le servlet cre une instance ou un Thread qui soccupe de ce client. Lune des avantages de cette technologie par rapport dautres est la vitesse dexcution, cet avantage est tir du fait quun servlet est charg une seule fois en mmoire et sxcute depuis cette mmoire aprs son chargement initial. Comme ce programme Java s'excute dynamiquement sur le serveur Web il permet alors l'extension des fonctions de ce dernier, typiquement : accs des bases de donns, transactions d'e-commerce, etc Ce qui est intressant dans le cas du projet puisque lapplication finale sera amener faire des traitements sur les bases de donns et mme de communiquer avec dautres serveurs. bLes JSP Linterface utilisateur est compose de plusieurs pages web qui vont tre gnres dynamiquement selon les requtes de lutilisateur. Pour concevoir une telle interface, nous avons eu recourt aux pages JSP ou Java Server Pages . Cest une technologie base sur Java qui permet aux dveloppeurs de gnrer dynamiquement du code HTML, XML ou tout autre type de page Web [10]. Comme nous utilisons une plateforme java pour dvelopper ce service, ce choix se rvlera trs bnfique parce que nous pouvons utiliser les diffrentes mthodes des classes dj dveloppes et compiles sans avoir, chaque fois, rcrire ces mthodes. Lavantage des JSP par rapport dautres scripts, qui sexcutent du ct serveur, est que le temps du traitement est moins important, cela est d au faite que ces scripts sont compils une seule fois, et on naura pas besoin de les recompils chaque accs au service. Le principe de fonctionnement des JSP ressemble celui des servlets, mais ils prsentent quelques diffrences, comme la possibilit de les intgrer dans des pages HTML et de dfinir des liens entre eux. Un exemple dutilisation de cette technologie dans le projet est la transmission de l MSISDN de labonn dune page une autre.
40
Chapitre IV : Choix techniques et Ralisation cLe langage HTML Pour les pages statiques de linterface utilisateur nous avons utilis du code HTML classique. L' Hypertext Markup Language , est un langage informatique cr et utilis pour crire les pages Web. HTML permet en particulier d'insrer des liens dans du texte, donc de crer de l'hypertexte, d'o le nom du langage. En fait les pages HTML utilises pour reprsenter linterface daccs au service seront modifies, par la passerelle WAP, en des pages XHTML pour quelles soient adaptes au navigateur du client.
IV-2-2 Les API

Une API dfinit la manire dont un composant informatique peut communiquer avec un autre. Il s'agit gnralement d'une liste de fonctions considres comme utiles pour d'autres composants. Ces fonctions peuvent tre implmentes pour simuler un protocole de communication. Les API sont, gnralement, utilises comme interface dintgration de service. aEricsson mm7 API Cest une API Java base sur limplmentation Apache de SOAP. Elle simule le
transfre des messages entre le MMSC et le serveur du fournisseur de services via linterface MM7. Nous lavons utilis dans limplmentation de la deuxime approche, c'est--dire celle qui fait intervenir le MMSC. Cette interface de programmation dfinit des classes utilises pour lenvoi et la rception des messages. Comme ces messages sont des messages SOAP, donc il a fallut utiliser une API qui implmente le protocole SOAP pour pouvoir dvelopper cette solution.
41
Chapitre IV : Choix techniques et Ralisation Le schma suivant explique mieux lutilisation de cette API.
Figure 20 : Utilisation de l'api "Ericsson MM7 API"
b-
Diameter Charging API Cette API a t utilise pour offrir la possibilit loprateur de tarifer ce service. Cette
interface implmente le protocole Diameter [3] et offre des mthodes pour dialoguer avec le systme de tarification. Comme il a t indiqu dans la partie conception, cest le serveur de transfert qui soccupera de la tarification donc cest au niveau de ce serveur que cette API doit tre intgre. Le schma suivant explique comment cette API a t utilise.
Figure 21 : Utilisation de l'api "Diameter Charging API"
42
Chapitre IV : Choix techniques et Ralisation cLAPI JDBC L'API JDBC permet aux applications java daccder par le biais d'une interface commune des sources de donns pour lesquelles il existe des pilotes JDBC. Normalement, il s'agit d'une base de donns relationnelle, et des pilotes JDBC sont disponibles pour tous les systmes connus de bases de donns relationnelles. Nous avons utilis cette API pour permettre aux classes Java de communiquer avec les bases de donns.
IV-2-3 Les serveurs

Les JSP et les servlets ncessitent un serveur pour fonctionner nomm souvent moteur de servlets ou moteur de JSP. Le serveur le plus connu est le serveur Tomcat [10]. Cest un serveur Open Source qui agit comme un conteneur de servlets. Il fait partie du projet Jakarta, au sein de la fondation Apache. Tomcat implmente les spcifications des servlets et des JSP de Sun Microsystems.
IV-2-4 Le systme de gestion des bases de donns

Le systme de gestion des bases de donns utilis dans ce projet et MySQL, il sagit dun SGBD libre et gratuit. Il est trs utilis et trs populaire. MySQL est un serveur de bases de donns relationnelles SQL, trs rapide, multi-thread et multi-utilisateur
IV-3 Implmentation
Dans cette section nous expliquons comment nous avons utilis les outils tudis dans la section prcdente pour mettre en place le service MMS To Postcard en nous basant sur larchitecture prsente dans le chapitre prcdent.
43
IV-3-1 Description Fonctionnel

aLinterface daccs Cette interface est reprsente par des pages HTML gnres dynamiquement partir de script JSP. Lutilisation des JSP dans cette interface se traduit par le fait quil faut excuter des scripts de contrles et de vrifications avant de permettre lutilisation de ce service. Ces scripts de contrle sont bass sur les paramtres envoys par le rseau (comme l MSISDN) ou les paramtres envoys par les utilisateurs (le nom de nouveau groupe de contacts, les coordonns dun contact,.). bLa partie serveur Il sagit, comme cela tait dcrit dans la partie conception, de deux serveurs : le serveur de transfert et le serveur dapplication. Pour le serveur de transfert nous avons dvelopp deux interfaces de rception des messages. La premire est un servlet qui reoit les messages multimdias partir des formulaires HTML inclus dans linterface daccs. Cette interfaces, est utilise dans la solution qui est base sur le protocole WAP et qui est totalement indpendante de larchitecture du service MMS. La deuxime est une classe Java base sur lAPI Ericsson MM7 API , cette classe se sert des mthodes implmentes par cette API pour extraire les MMS des messages SOAP envoys du MMSC ce serveur. Ce serveur se charge aussi de la tarification et cela partir dune autre interface qui communique avec le systme de tarification. Cette interface est base sur lAPI Diameter Charging API , elle utilise les mthodes implmentes par cette API pour pouvoir communiquer avec le systme de tarification.
44
Chapitre IV : Choix techniques et Ralisation Le deuxime serveur est le serveur du fournisseur de service. Il contient une interface pour communiquer avec les bases de donns et une autre pour recevoir les messages multimdias. Ce serveur se charge de la transformation de ces messages en des cartes postales. Pour mieux dcrire le systme final voici un schma fonctionnel qui explique le choix des outils pour chaque module.
Figure 22 : Schma fonctionnel du produit final
IV-3-2 Prsentation de linterface utilisateur

Comme cela a dj t voqu, linterface daccs au service contient un ensemble de pages web. La premire page est gnre par une JSP aprs avoir effectu un contrle daccs au service. Si le solde de lutilisateur ne suffie pas pour accder au service alors cette premire page affichera un message derreur, sinon elle va indiquer les diffrentes options offertes par le service. Labonn peut ainsi choisir loption qui le conviendra.
Figure 23 : Les premires pages de l'interface
45
Pour cette premire version du service, nous navons implment que deux options possibles, celle de lenvoi dun message simple, c'est--dire, vers un seul destinataire, et celle de lenvoi multiple.
Figure 24 : Formulaire denvoi dun seul message et interface des options pour lenvoi multiple
Lenvoi multiple peut se faire de deux manires. Envoi de carte postale directement : Dans ce cas, la page relative cette option saffiche aprs avoir vrifi le nombre de destinataires possibles qui labonn pourra envoyer des cartes postales en mme temps. Ce nombre dpend du solde de labonn.
Figure 25 : Interface d'envoi multiple
46
Dfinir des groupes de contacts pour leur envoyer des cartes postales ultrieurement :
Dans ce cas, lutilisateur utilise un formulaire pour dfinir les groupes de contacts, ce formulaire transmet ensuite les diffrents paramtres au serveur. Le serveur, son tour, vrifie si le contact choisi ne figure pas dans la base de donns des groupes de contacts et lenregistre. Dans le cas contraire il envoie un message derreur lutilisateur. Ensuite lorsque labonn veut envoyer ses contacts enregistrs sur la base de donn, il na qu choisir cette option. Un script JSP rcupre la liste des contacts de la base de donns, et laffiche sur linterface en indiquant combien de personnes son solde lui permet denvoyer des cartes postales en mme temps.
Figure 26 : Mise jour et consultation de la liste des contacts
IV-4 Problme daffichage sur les mobiles et solution propose

Lors du teste du service, nous nous sommes rendus compte quil y a quelques problmes daffichages sur les terminaux mobiles. Ces problmes consistent au fait que linterface daccs au service ne saffiche pas de la mme faon sur touts les mobiles. Ce problme est prvisible puisque touts les terminaux ne possdent pas les mmes tailles dcran et surtout parce quils nutilisent pas le mme navigateur pour afficher les pages web, donc les balises HTML ne sont Med Amine BEN KHEMIS 47
Chapitre IV : Choix techniques et Ralisation pas interprtes de la mme faon et laffichage sera diffrent dun terminal lautre. Ce problme existait avant pour les navigateurs des micro-ordinateurs : les pages web ne saffichaient pas de la mme faon pour Internet Explorer et pour Netscape. Pour contourner ce problme, nous avons spar le contenu des pages web de leurs affichages. Nous avons utilis pour cela le langage XML et les feuilles de style XSL (voir Annexe B). Le principe est de rcrire toute linterface daccs en XML, il sagit l des donns, et dallouer chaque navigateur utilis par les terminaux mobile un fichier de style XSL, il sagit l de laffichage. Les feuilles de style XSL permettent dadapter laffichage des pages web au terminal utilis. Lorsquun utilisateur veut se connecter au serveur, son terminal envoie une requte HTTP, cette requte contient plusieurs variables, lune de ces variables est HTTP_USER_AGENT . Cette variable contient la marque du tlphone, son systme dexploitation et le navigateur utilis. La dtection du navigateur du terminal se fera par un script JSP qui va rcuprer cette variable et extraire le nom du navigateur, ensuite il le redirige vers un fichier de style XSL qui lui est adapt.
IV-5 Conclusion
Dans ce chapitre, nous avons trait les dtails de la ralisation du service MMS To Postcard . Nous avons expliqu les diffrents scnarios daccs ce service.
48
Conclusion et perspectives
Conclusion et perspectives
A lheure de lexplosion de la tlphonie mobile, tous les oprateurs veulent en profiter au maximum pour augmenter leurs chiffres daffaire. Pour cela, ils misent sur les services valeurs ajouts. Le service MMS To Postcard que jai dvelopp comme projet de fin dtude a pour objectif de rassembler les services offerts par les nouvelles technologies des communications et le traditionnel service postal dlaiss cause de lapparition de la messagerie lectronique et du service MMS. Llaboration de ce projet ma permit dapprofondir mes connaissances en informatique et surtout dans le domaine du dveloppement de services web. Nanmoins, ces connaissances, ne suffisent pas pour dvelopper des services mobiles valeurs ajouts. Il ma donc t donn dapprendre au cour de ce stage quil faut joindre le monde informatique au monde des tlcommunications pour pouvoir crer de nouveaux services. Le service MMS To Postcard est particulirement extensible. On pourrais par exemple intgrer des messages publicitaires sur les cartes postales envoyer, en respectant bien sur le contexte de lenvoi. Ainsi, ces cartes postales seront payes par lentreprise qui va intgrer son message publicitaire, offrant la possibilit aux abonnes de profiter gratuitement de ce service. Ce service peut tre utilis dune autre manire. Par exemple, on peut concevoir un service dimpression distance : labonn slectionne la photo ou lalbum de photos quil veut imprimer, lenvoi au fournisseur du service en prcisant la nature et la taille du papier. Le fournisseur du service se chargera alors de limprimer en respectant les contraintes spcifies. Il faudra alors prvoir des bornes dimpression.
- 49 -
Annexes
Annexes
Annexe A : Le protocole WAP 1Modle en couche du protocole WAP

Le WAP Forum a dfini un modle en couche pour le protocole WAP pour permettre aux quipements WAP, issus de diffrentes technologies, de communiquer ensemble. Le but est de mettre en place une architecture commune pour les diffrentes technologies de rseaux mobiles.
Figure 27 : Pile de protocoles du WAP1
Wireless Application Environment (WAE) Cette couche spcifie le langage de balise qui doit tre utilis pour afficher les pages WAP. Dans les premires version du WAP, le langage utilis est le WML (Wireless Markup Language), il sagit dun langage similaire au HTML mais optimis pour utilisation sur des terminaux mobile portables. Wireless Session Protocol (WSP) Ce protocole permet dassurer la persistance de la connexion, il offre la couche WAE une interface pour les services orients session.
-1-
Annexes Wireless Transaction Protocol (WTP) Cette couche opre au dessus dun service datagramme, elle prend en charge laspect transactionnel du systme et fiabilise la transmission. Wireless Transport Layer Security (WTLS) Ce protocole utilise la technologie SSL pour scuriser les changes de messages entre terminaux et serveurs. Il peut, grce cette fonctionnalit, tre utilis dans le cadre de lauthentification des cartes de paiement pour le commerce lectronique. WDP (Wireless Datagram Protocol) Il sagit de la couche transport du protocole WAP, cette couche offre une interface entre le type du rseau utilis et les couches application, session et scurit, ce qui permet ces couches de fonctionner en totale indpendance de la technologie du rseau. Ainsi, ce modle et toutes les applications qui pourront tre dveloppes seront disponibles dans le cas o un nouveau type de rseau apparatrait.
2a-
Modification des protocoles lors de lvolution du WAP1 au WAP2

WAP1
Figure 28 : Conversion des protocoles pour WAP1
Annexes
b-
WAP2
Figure 29 : Conversion des protocoles pour WAP2
Annexes
Annexe B : Les langages : WML, XHTML, XML et XSL

1Le langage WML
Le Wireless Markup Language (WML) est un langage balises conu spcifiquement pour le WAP, de manire pouvoir s'afficher sur un cran de tlphone portable. Il est bas sur XML. Sa syntaxe est proche de HTML. On peut noter que WML est dot de son propre format d'image, appel Wireless Bitmap (WBMP), driv du format BMP, mais en noir et blanc.
2-
Le langage XHTML
XHTML est un langage balis servant l'criture de pages du World Wide Web.
XHTML est le successeur de HTML (de l'anglais HyperText Markup Language), XHTML respecte la syntaxe dfinie par XML, plus rcente et plus simple que la syntaxe dfinie par SGML respecte par HTML.
3-
Le langage XML
Extensible Markup Language (langage de balisage extensible), gnralement abrg
XML, est un standard du World Wide Web Consortium qui sert de base pour crer des langages de balisage : c'est un mtalangage . En ce sens, XML permet de dfinir un vocabulaire et une grammaire associe sur base de rgles formalises. Il est suffisamment gnral pour que les langages bass sur XML, appels aussi dialectes XML, puissent tre utiliss pour dcrire toutes sortes de donns et de textes. Il s'agit donc partiellement d'un format de donns. L'extensibilit de XML est principalement assure par la notion d'espace de nommage. L'objectif initial de XML tait de faciliter le partage de textes et d'informations structures, par exemple au travers d'Internet, en sparant le contenu du contenant. Il constitue une simplification de SGML tout en continuant assurer la portabilit des documents, notamment grce l'intgration d'Unicode.
Annexes
4-
Le langage XSL
XSL (eXtensible Stylesheet Language) est le langage de description de feuilles de style
du W3C associ XML. Une feuille de style XSL est un fichier qui dcrit comment doivent tre prsents (c'est-dire affichs, imprims, pels) les documents XML bass sur une mme DTD ou un mme schma.
Annexes
Annexe C : Exemple de message SOAP transmis travers linterface MM7
Figure 30 : Exemple d'un message SOAP
Annexes
Annexe D : Les MIDlets

Le Mobile Information Device Profile (MIDP) est un profil J2ME utilis par certains tlphones mobiles. Abrviation de Mobile Information Device Profile , MIDP est un ensemble d'API J2ME qui dfinit la faon dont les applications de logiciel se connectent l'interface des tlphones cellulaires et les applications conformes cette norme s'appellent MIDlets. Les socits ayant travaills au MIDP incluent Ericsson, NEC, Nokia, NTT DoCoMo, Palm Computing, Research In Motion (RIM), DoCoMo, LG TeleCom, Samsung et Motorola.
Annexes
Annexe E : Intgration des services au niveau du systme de tarification 1Le serveur CCN
Le CCN ou Charging Control Node et lun des serveurs du systme de tarification prpay, il est construit sur la plateforme des serveurs tlcoms dEricsson (TSP), qui reprsente une plateforme multiservice. Le CCN est compos de deux parties : lapplication CCF et la plateforme TSP. Le schma ci-dessous reprsente larchitecture du CCN.
Le TSP est une plateforme matriel pour le CCN. Cest un systme distribu multiprocesseur. Le TSP reprsente aussi la partie qui implmente les ressources et les fonctions de systme dapplications partages. Le CCF (Charging Control Function), cest la couche o les services spcifiques du CCN sont implments, il est son tour divis en 3 couches :
La couche daccs : Cest linterface de communication avec les applications externes. La couche service ou encore la couche contrle: Cette couche est responsable du contrle des services. La couche fonction : Assure des fonctions avances pour la couche service.
Annexes
2-
Le protocole Diameter
Diameter est un protocole conu pour servir de support larchitecture AAA
(Authentication, Autorization, Accounting).Il fournit les mcanismes de base pour tablir un transport fiable, dlivrer les message et grer les erreurs. Diameter peut tre le successeur du protocole RADIUS, a qui il a repris les principales fonctions (Diameter est compatible avec Radius) et en a rajout de nouvelles pour sadapter aux nouvelles technologies (IPv4 Mobile, NASREQ ...) et plus particulirement offrir des services aux applications mobiles. En effet, Radius tait conu lorigine, uniquement pour des protocoles tel SLIP ou PPP. Il ntait pas extensible et ne pouvait donc offrir des services dauthentification pour les nouvelles technologies sans fils, cellulaire, VPN
3-
Intgration des services au niveau du systme de tarification

Pour permettre la tarification de leurs services, les fournisseurs de services intgrent leurs
applications au niveau du CCN qui sert dinterface pour le systme de tarification prpay. Le schma suivant explique cette intgration.
Figure 31 : Communication entre le fournisseur de services et le systme de tarification
Bibliographie
[1] 3GPP TS 23.140 V5.10.0 (2004-03) [2] 3GPP TS 23.140, version 5.3.0 (2002-03), et version 5.5.; 3rd Generation Partnership Project; Technical Specification Group Terminal; Multimedia Messaging Service (MMS); description fonctionnelle; Stage 2. [3] AAA Working Group; Pat R. Calhoun, Black Storm Networks, Haseeb Akhtar, Nortel Networks, Jari Arkko, Oy LM Ericsson Ab, Erik Guttman, Sun Microsystems Inc., Allan C. Rubens, Tut Systems Inc., Glen Zorn, Cisco Systems, Inc. Internet-Draft; Category: Standards Track; <draft-ietf-aaa-diameter-08.txt0> November 2001 [4] DANG Hoang Minh, tude du systme de service de message multimdia Institut de la Francophonie pour lInformatique, 15 juillet 2005 [5] Introduction to SOAP using Apache SOAP 2.1 for Java Pablo Fraile Iglesias, 26 Mars 2001 [6] http://www.soapuser.com/, Nicholas Quaine, Nicolas Gouteux, Sylvain Benoist, [7] http://uml.free.fr/index-cours.html, Laurent Piechocki [8] http://www.ericsson.com, Ericsson [9] http://fr.wikipedia.org/wiki/WAP, Wikimedia fundation, mis jour le 12 juin 2006 [10] http://www.java2s.com, Avril 2003, Java Source and Support,

Ben Khemis Amine

Transféré par

Informations du document

Copyright

Formats disponibles

Partager ce document

Partager ou intégrer le document

Options de partage

Avez-vous trouvé ce document utile ?

Ce contenu est-il inapproprié ?

Droits d'auteur :

Formats disponibles

Ben Khemis Amine

Transféré par

Droits d'auteur :

Formats disponibles

Introduction gnrale

Cycle de formation des ingnieurs en Tlcommunications

Rseaux et Services Mobiles (RSM)

Rapport de Projet de fin dtudes

Conception et ralisation du service MMS To Postcard

Mohamed Amine BEN KHEMIS

M. Abdennacer CHIKHI M. Zied CHOUKAIR

Anne universitaire : 2005/2006

Table des matires

Liste des figures

Liste des abrviations

Med Amine BEN KHEMIS

Med Amine BEN KHEMIS

Chapitre I : Service MMS to Postcard : tat de lart

Service MMS to Postcard : tat de lart

I-1 Prsentation du protocole WAP I-1-1 Dfinition

Med Amine BEN KHEMIS

Med Amine BEN KHEMIS

Figure 1 : Architecture du protocole WAP

Med Amine BEN KHEMIS

Chapitre I : Service MMS to Postcard : tat de lart

I-2 Prsentation du service MMS I-2-1 Dfinition

Med Amine BEN KHEMIS

Chapitre I : Service MMS to Postcard : tat de lart

La figure suivante met en vidence les diffrentes interfaces du MMSC.

Figure 2 : Architecture du service MMS

Med Amine BEN KHEMIS

I-2-3 Linterface MM7

Med Amine BEN KHEMIS

Chapitre I : Service MMS to Postcard : tat de lart

Med Amine BEN KHEMIS

Chapitre II : tude de faisabilit et spcification des besoins

tude de faisabilit et spcification des besoins

II-1 tude de faisabilit II-1-1 tude et critique de lexistant

Med Amine BEN KHEMIS

Chapitre II : tude de faisabilit et spcification des besoins

II-1-2 tude des solutions possibles

Med Amine BEN KHEMIS

Chapitre II : tude de faisabilit et spcification des besoins

Med Amine BEN KHEMIS

Chapitre II : tude de faisabilit et spcification des besoins

II-1-3 Bilan de lanalyse et choix de la solution

Med Amine BEN KHEMIS

Figure 3 : Architecture finale du service MMS To Postcard

Med Amine BEN KHEMIS

Chapitre II : tude de faisabilit et spcification des besoins

II-2 Spcification des besoins

II-2-1 Spcification gnrale des besoins

Med Amine BEN KHEMIS

Med Amine BEN KHEMIS

II-2-2 Modle de cas dutilisations

Med Amine BEN KHEMIS

Chapitre II : tude de faisabilit et spcification des besoins

a- Identification des diffrents acteurs agissant sur le systme

Med Amine BEN KHEMIS

Chapitre II : tude de faisabilit et spcification des besoins

Figure 4 : Diagramme de cas d'utilisation

Cas dutilisation EnvoyerMMS

Med Amine BEN KHEMIS

Med Amine BEN KHEMIS

Chapitre II : tude de faisabilit et spcification des besoins

Cas dutilisation TraiterMessage

Med Amine BEN KHEMIS

Chapitre III : Conception du service MMS To Postcard