Vous êtes sur la page 1sur 68
Introduction générale
Introduction générale

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

Option :

Réseaux et Services Mobiles (RSM)

Rapport de Projet de fin d’études

Thème :

Conception et réalisation du service MMS To Postcard

Réalisé par :

Mohamed Amine BEN KHEMIS

Encadrants :

M. Abdennacer CHIKHI M. Zied CHOUKAIR

Travail proposé et réalisé en collaboration avec

M. Abdennacer CHIKHI M. Zied CHOUKAIR Travail proposé et réalisé en collaboration avec Année universitaire :

Année universitaire : 2005/2006

M. Abdennacer CHIKHI M. Zied CHOUKAIR Travail proposé et réalisé en collaboration avec Année universitaire :

Dédicaces

A mes parents,

A mon frère,

A mes sœurs,

A la mémoire de mon cousin Hatem, A toute ma famille, Je dédie ce modeste travail.

- i -

Remerciement

Le travail présenté dans ce mémoire a été effectué dans le cadre de la préparation du diplôme d'ingénieur en télécommunications, option Réseaux et Services Mobiles (RSM) à l'Ecole Supérieure des Communications de Tunis (SUP'COM). Au terme de ce projet, je tiens à exprimer ma profonde gratitude et mon immense respect à Monsieur Zied CHOUKAIR, Maître de conférences à l'école supérieure des Communications de Tunis, et Madame Asma BEN LTAIFA, pour leur disponibilité, leur persévérance et leur dynamisme. J'aimerais témoigner du plaisir qu'était pour moi de travailler sous leurs directives. Mes vifs remerciements s'adressent également à Monsieur Abdennaceur CHIKHI, ingénieur à 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 supérieure 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 d’ingénieur en télécommunication à l’École Supérieur des communications de Tunis, j’ai effectué un projet de fin d’études au sein de l’entreprise Ericsson. Le sujet porte sur la conception et l’implémentation du service « MMS To Postcard » sur la plateforme du réseau d’essai d’Ericsson. Ericsson est l’un des plus grands équipementiers des systèmes mobiles dans le monde et soutient toutes les normes principales pour la communication sans fil. Les dix plus grands opérateurs mobiles du monde sont parmi ses clients et quelques 40% de tous les appels mobiles sont faits par les systèmes d'Ericsson. La société Ericsson fournit des solutions totales, des systèmes et des applications aux services. Elle a été en activité dans le monde entier depuis 1876 et elle est aujourd'hui présente dans plus de 140 pays. Ses sièges sociaux sont situés à Stockholm au Suède [8].

iii

Table des matières

Avant- Propos

vii

iii

Table des matières

iv

Liste des figures

vi

Liste des abréviations

Introduction générale

1

Chapitre I : Service MMS to Postcard : État de l’art

3

I-1 Présentation du protocole WAP

3

I-1-1 Définition

3

I-1-2 Généralités

3

I-2 Présentation du service MMS

6

I-2-1 Définition

6

I-2-2 Architecture

6

I-2-3 L’interface MM7

8

I-3 Conclusion Dans ce premier chapitre nous avons étudié les différentes normes et protocoles qui vont

9

être utilisés pour implémenter le service « MMS To Postcard ». Cette étude nous sera utile

pour spécifier les besoins de l’application finale et envisager une solution possible

9

Chapitre II : Étude de faisabilité et spécification des besoins

10

II-1 Étude de faisabilité

10

II-1-1 Étude et critique de l’existant

10

II-1-2 Étude des solutions possibles

11

II-1-3 Bilan de l’analyse et choix de la solution

13

II-2 Spécification des besoins

15

II-2-1 Spécification générale des besoins

15

II-2-2 Modèle de cas d’utilisations

17

II-3 Conclusion

21

Dans ce deuxième chapitre, nous avons utilisé une méthodologie UML pour spécifier les cas d’utilisations de la solution adoptée. Cette spécification va nous servir comme base pour concevoir le Chapitre III : Conception du service « MMS To Postcard » III-1 Étude conceptuelle III-2 Organigramme III-3 Conception détaillée III-3-1 Diagramme de paquetages III-3-2 Diagrammes de classes III-4 Diagrammes de séquences III-4-1 Envoi d’un seul message III-4-2 Ajout d’un nouveau contact III-4-3 Envoi multiple III-4-4 Transmission des messages vers le MMSC

21

22

22

26

27

27

28

34

34

35

35

37

iv

III-5 Conclusion

37

Chapitre IV : Choix technique et Réalisation

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 système de gestion des bases de donnés

43

IV-3 Implémentation

43

IV-3-1 Description Fonctionnel

44

IV-3-2 Présentation de l’interface utilisateur

45

IV-4 Problème d’affichage sur les mobiles et solution proposée

47

IV-5 Conclusion

48

Conclusion et perspectives

49

Annexes

1

Bibliographie

0

v

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 : Séparation entre le module de tarification et l'application

23

Figure 6 : Ajout d’une base de donnés pour connecter le serveur d’application 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 séquences pour un envoi simple

34

Figure 16 : Diagramme de séquences en cas d'ajout d'un contact

35

Figure 17 : Diagramme de séquences pour un envoi multiple

36

Figure 18 : Diagramme de séquences 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 : Schéma fonctionnel du produit final

45

Figure 23 : Les premières pages de l'interface

45

Figure 24 : Formulaire d’envoi d’un seul message et interface des options pour l’envoi 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 système de tarification

9

vi

Liste des abréviations

AAA

Authentication Autorization Accounting

API

Application Programming Interface

CCN

Charging Control Node

CCF

Charging Control Function

JDBC

Java Data Base Connectivity Interface

GSM

Global System for Mobile communications

GPRS

General Packet Radio Service

HLR

Home Location Registry

HTML

HyperText Markup Language

HTTP

HyperText Transfer Protocol

IP

Internet Protocol

JSP

Java Server Pages

J2ME

Java 2 MicroEdition

MIDP

Mobile Information Device Profile

MMS

Mobile Messaging Service

MMSC

Mobile Messaging Service Center

MSISDN

Mobile Station International ISDN Number

PPP

Point to Point Protocol

SCAP

Service Charging Application Protocol

SGBD

Système de Gestion des Base de Donnés

SGML

Standard Generalized Markup Language

SLIP

Serial Line Internet Protocol

SMTP

Simple Mail Transfer Protocol

SMS

Short Message Service

SOAP

Simple Object Access Protocol

SQL

Structured Query Language

SSL

Secure Socket Layer

TCP

Transmission Control Protocol

TSP

Telecommunication Server Platform

URL

Uniform Ressources Locator

UML

Unified Modeling Language

UMTS

Universal Mobile Telecommunication System

VASP

Value Added Service Provider

VPN

Virtual Private Network

WAE

Wireless Application Environment

WAP

Wireless Application Protocol

WDP

Wireless Datagram Protocol

WML

Wireless Markup Language

WSP

Wireless Session Protocol

WTP

Wireless Transaction Protocol

WTLS

Wireless Transport Layer Security

W3C

World Wide Web Consortium

XHTML

eXtensible HyperText Markup Language

XML

eXtensible Markup Language

XSL

eXtensible Stylesheet Language

Introduction générale

Introduction générale

Les réseaux mobiles ne sont plus utilisés que pour transporter la voix. Avec l’apparition du GPRS et de l’ UMTS, la bande passante a connu une amélioration considérable, ce qui a permis l’implémentation de nouveaux services multimédias. Ainsi, l’ouverture des réseaux radios mobiles à de nouveaux services à valeur ajoutée constitue l’un des segments les plus porteurs du marché des télécommunications dans les prochaines années. En effet, cette nouvelle vision permet, et pas seulement aux opérateurs de générer plus de trafic sur leurs réseaux, d’obtenir plus de gains, et permettre à des fournisseurs de service de profiter de l’infrastructure des réseaux pour proposer de nouveaux services aux abonnés. L’un des services les plus connus est le MMS. Il représente le successeur du célèbre SMS, et il offre la possibilité aux abonnés de transmettre des messages multimédias. Le problème avec ce service est qu’il ne connaît pas l’énorme succès que le SMS a connu, ce qui a poussé les opérateurs à permettre l’utilisation de ce service comme base pour d’autres services à valeurs ajoutées. C’est dans ce cadre que ce projet s’inscrit. Il s’agit de concevoir, implémenter et intégrer le service « MMS To Postcard » sur la plateforme du réseau radio mobile d’Ericsson. La plupart des terminaux mobiles de nouvelle génération sont compatibles avec le protocole WAP dans sa deuxième version. On pourra ainsi les utiliser pour transmettre et recevoir des donnés via le réseau radio mobile. De plus, la majorité de ces terminaux sont équipés d’appareil photo. L’idée de ce projet part du faite qu’on peut exploiter ces deux caractéristiques des nouveaux terminaux mobiles pour offrir aux abonnés d’un opérateur la possibilité d’envoyer des cartes postales personnalisées. En plus du gain qu’il pourra générer pour l’opérateur et pour le fournisseur, ce service peut rendre l’usage des cartes postales délaissées après l’apparition des services de messageries électroniques. Ainsi, la poste pourra générer des gains supplémentaires grâce à ce service. La différence entre ce service et l’envoi de cartes postales traditionnelles c’est que l’abonné pourra définir lui-même l’image qu’il va envoyer à son destinataire. Cet avantage est particulièrement intéressant puisqu’il permet d’autres usages de ce service que l’on verra plus loin dans ce rapport.

Introduction générale

L’implémentation de ce service requière le développement de deux parties principales à savoir l’interface utilisateur et la partie serveur. Il s’agit aussi de développer une interface qui permettra à cette application de communiquer avec le système de tarification. Dans ce rapport de fin d’étude, nous commencerons, dans un premier chapitre par une recherche bibliographique. Nous présenterons à travers cette partie l’infrastructure sur laquelle nous nous sommes basés pour implémenter ce service, Nous sommes passés, dans un deuxième chapitre, à une étude comparative entre les différentes solutions possibles. A partir de cette étude, nous avons choisi la solution qui va être implémentée, et nous avons spécifié les besoins de cette solution en précisant les différents cas d’utilisations du système final. Dans le troisième chapitre, nous nous sommes basés sur le formalisme UML pour concevoir la solution choisi. Dans le quatrième chapitre, nous présentons les différents outils utilisés et l’interface d’accès au service.

Chapitre I : Service MMS to Postcard : État de l’art

Chapitre I

Service MMS to Postcard : État de l’art

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 d’apporter leur touche personnelle aux cartes postales qu’ils envoient à leurs correspondants. Pour implémenter ce service, une étude de quelques protocoles et entités des réseaux radio mobiles s’imposent. Dans cette partie du rapport, nous présentons les différents protocoles et entités du réseau que nous avons utilisé pour mettre en place le service « MMS To Postcard ».

I-1 Présentation du protocole WAP I-1-1 Définition

Le WAP, standardisé par le WAP Forum, est un protocole de communication dont le but est de permettre aux abonnés d’un opérateur mobile d’accéder à Internet à l’aide de terminaux mobiles. En plus de la connectivité à Internet, ce protocole a été conçu pour offrir la possibilité aux opérateurs d’intégrer de nouveaux services multimédias sur leurs infrastructures [9].

I-1-2 Généralités

Le protocole WAP comprend deux versions. Pour la première version, on essayait de profiter du service de transmission de donnés basé sur la commutation de circuit comme pour le cas du GSM. Mais lorsqu’on est passé à la commutation de paquets dans les réseaux

Med Amine BEN KHEMIS

- 3 -

Chapitre I : Service MMS to Postcard : État de l’art

mobiles, en vue d’optimiser les ressources et d’améliorer la bande passante, le protocole WAP a aussi évolué pour s’adapter à cette nouvelle infrastructure.

a- Le WAP 1

Les premiers terminaux mobiles avaient des optionalités très limitées, ils ne permettaient pas d’afficher du contenu multimédia. Pour offrir des services basés sur la transmission de donnés, le WAP, dans sa première version, a spécifié des protocoles (voir Annexe A) qui avaient pour rôle d’optimiser le contenu des serveurs et de l’adapter à ces terminaux, offrant ainsi d’autres services aux abonnés que la téléphonie et le SMS. Cependant, cette version du WAP n’a pas connu un grand succès et a été très vite délaissée à cause de son manque d’interactivité.

b- Évolution vers le WAP 2

Avec l’évolution des réseaux mobiles et l’amélioration considérable de la bande passante. On était contraint de faire évoluer le protocole WAP pour mieux utiliser ces ressources, surtout avec la nouvelle génération des terminaux mobiles qui supportent les protocoles de transports classiques d’Internet. Cette nouvelle version du protocole WAP introduit de nouvelles fonctionnalités multimédias, telles que le « Streaming » ou le téléchargement de contenu multimédia volumineux. Pour cela, la pile protocolaire de ce standard a été redéfini (voir annexe A). En plus de la migration vers le TCP/IP comme protocole de transport. Ainsi, les utilisateurs équipés de terminaux compatibles WAP 2 auront l’accès à des applications plus riches, avec des graphiques en couleur et des possibilités textuelles accrues. Cette modification de la pile de protocole sur la quelle se base le WAP rend plus facile le développement et l’intégration de nouveaux services puisqu’on pourra profiter de l’expertise acquise du monde informatique et plus précisément du domaine du développement web pour implémenter des services multimédias.

Chapitre I : Service MMS to Postcard : État de l’art

c- La passerelle WAP

Afin de permettre aux terminaux mobiles d’accéder à Internet, le protocole WAP définit une architecture spécifique. Il s’agit de connecter le réseau mobile de l’opérateur à une passerelle, connue encore sous le nom de passerelle WAP ou « WAP Gateway », cette passerelle joue le rôle d’interface entre le mobile et le serveur et permet ainsi d’adapter les messages transmis au protocole de communication correspondant. Cette entité du réseau encode les documents WML ou XHTML (voir Annexe B), selon la version du protocole utilisée, avant leur envoi au mobile, et dans l’autre sens, elle crée des requêtes HTTP à partir des requêtes WAP. Elle est également utilisée par les fournisseurs de services pour récupérer certains paramètres de l’utilisateur, comme l’ MSISDN, pour contrôler l’accès à leurs services. Pour conclure voici un schéma récapitulatif de l’architecture du réseau sur laquelle se base le protocole WAP.

du réseau sur laquelle se base le protocole WAP. Figure 1 : Architecture du protocole WAP

Figure 1 : Architecture du protocole WAP

Chapitre I : Service MMS to Postcard : État de l’art

I-2 Présentation du service MMS I-2-1 Définition

L’MMS, est un service qui permet aux abonnés d’un opérateur mobile d’envoyer et de recevoir des messages multimédias à partir de terminaux compatibles. Considéré comme le successeur du célèbre SMS, ce service ne s’est pas limité qu’aux messages textuels mais il a permis en plus le transfert des images et des sons. Dans sa version la plus récente, il offre la possibilité de transmettre des séquences vidéo.

I-2-2 Architecture

a-

L’MMSC

Le MMSC, est l’entité qui reçoit les messages multimédias des expéditeurs et les transmet à leurs destinataires respectifs, elle permet aussi de récupérer des informations concernant les abonnés du HLR et les envoie au système de tarification pour décrémenter son compte suite à l’utilisation du service. Dans certaines configurations on peut trouver que le MMSC est décomposé en MMS Server et MMS Relay.

b- Les différentes interfaces du MMSC

Pour permettre au centre de messagerie multimédia de communiquer avec les différentes entités du réseau il a fallut définir des interfaces. On entend par interface, la spécification des communications entre deux entités. Ces interfaces séparent les spécifications en huit normes nommées MM1, MM2, … jusqu'à MM8. En réalité il existe 10 interfaces, mais les deux interfaces MM9 et l’MM10 sont en cours de développement [1] [4].

Chapitre I : Service MMS to Postcard : État de l’art

La figure suivante met en évidence les différentes interfaces du MMSC.

met en évidence les différentes interfaces du MMSC. Figure 2 : Architecture du service MMS -

Figure 2 : Architecture du service MMS

- L’interface MM1 C’est l’interface entre l’abonné et le MMSC.

- L’interface MM2 C’est l’interface entre MMS Server et MMS Relay. Puisque ces deux entités peuvent être combinées sous forme de MMSC, l’interface MM2 est propriétaire.

- L’interface MM3 Cette interface relie l’ MMSC aux différents serveurs externes comme les serveurs Mail et les centres SMS, dans cette interface on utilise le protocole SMTP pour transférer les messages entre les entités du réseau.

- L’interface MM4 Il s’agit de l’interface reliant les MMSC moyennant des connecteurs SMTP.

- L’interface MM5 C’est l’interface par laquelle l’ MMSC est connecté au HLR. Cette interface n’est pas encore complétée.

Chapitre I : Service MMS to Postcard : État de l’art

- L’interface MM6 Cette interface permet au MMSC d’accéder à des bases de donnés externes. Elle n’est pas encore normalisée.

- L’interface MM7 (ou l’interface VASP). C’est une interface standard qui permet à un fournisseur de service de connecter son serveur d’application à l’ MMSC pour offrir un service à valeur ajoutée basé sur l’MMS. Cette interface joue un rôle important dans l’intégration de nouveaux services.

- L’interface MM8 Cette interface est réservée aux échanges entre le MMSC et les systèmes de facturation.

I-2-3 L’interface MM7

L’interface qui nous intéresse le plus est l’interface MM7 car c’est à travers cette interface qu’on peut éventuellement intégrer de nouveaux services à valeur ajoutée. L’MM7 spécifie les différents protocoles qu’il faut respecter pour pouvoir mettre en place une application qui sera en mesure de communiquer avec L’ MMSC. Il s’agit des protocoles SOAP et HTTP.

a- Le protocole SOAP

SOAP pour « Simple Object Access Protocol » est un protocole de transmission de messages, il définit un ensemble de règles pour structurer les messages à transmettre, il est particulièrement utile pour exécuter des dialogues requête-réponse. Il n’est pas lié à une plateforme donné ce qui le rend intéressant pour développer des applications distribuées. Il n’est pas non plus lié à un système d’exploitation particulier, ce qui donne la possibilité aux applications tournants sur des systèmes différents de dialoguer ensemble du moment qu’ils puissent formuler et comprendre les messages SOAP [5] [6]. Le protocole SOAP est composé de deux parties :

Chapitre I : Service MMS to Postcard : État de l’art

Une enveloppe, contenant des informations sur le message lui-même afin de permettre son acheminement et son traitement.

Un modèle de donnés, définissant le format du message, c'est-à-dire les informations à transmettre.

Dans le cas de l’interface MM7, on utilise les messages SOAP pour transmettre les différents paramètres de l’utilisateur du service et une déclaration pour chaque fichier attaché au message. Dans cette déclaration, on spécifie le type du message, le codage utilisé, et plusieurs autres paramètres qui ont pour rôle d’informer le récepteur des caractéristiques des messages envoyés (voir Annexe C). Ces messages sont ensuite encapsulés par le protocole HTTP.

b- Le 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 transférer des messages avec des en-têtes décrivant 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 localisés grâce à une chaîne de caractères appelée URL.

I-3 Conclusion

Dans ce premier chapitre nous avons étudié les différentes normes et protocoles qui vont être utilisés pour implémenter le service « MMS To Postcard ». Cette étude nous sera utile pour spécifier les besoins de l’application finale et envisager une solution possible.

Chapitre II : Étude de faisabilité et spécification des besoins

Chapitre II

Étude de faisabilité et spécification des besoins

II-1 Étude de faisabilité II-1-1 Étude et critique de l’existant

Dans cette section, nous présentons les différentes implémentations déjà faites du service « MMS To Postcard ».

a- Solution implémentée par « Orange »

Il s’agit d’utiliser l’interface standard de composition des messages MMS qu’ont trouve sur tous les terminaux compatibles. Le problème avec cette interface est de comment indiquer au serveur l’adresse du destinataire parce que cette interface ne nous permet l’envoi de MMS que vers un autre mobile ou vers une adresse E-mail. La solution proposée par « Orange » est d’utiliser le champ texte pour indiquer l’adresse du destinataire, le nom de l’expéditeur et le contenu du message. Ils indiquent aux abonnés désirant utiliser ce service qu’ils doivent se conformer à un format précis du texte à envoyer avec l’image, il s’agit de séparer les différents champs par « # ». La partie serveur se chargera ensuite de décomposer les différents champs. L’avantage de cette méthode est qu’on peut profiter de l’infrastructure du service MMS. Son inconvénient réside dans la complexité d’utilisation.

Med Amine BEN KHEMIS

- 10 -

Chapitre II : Étude de faisabilité et spécification des besoins

b- Solution implémentée par « VODAFONE »

Ce service a déjà était implémenté par « VODAPHONE », leur solution consiste en la configuration des mobiles qui seront en mesure d’accéder à ce service. Ils ont installé directement l’interface utilisateur sur les terminaux. Cette solution a été adoptée par plusieurs fournisseurs de service c’est pourquoi dans certains terminaux mobiles on peut trouver l’option d’envoi de carte postale. L’inconvénient de cette solution est que l’interface utilisateur doit être installé sur le mobile. Cette mise à jour ne peut pas se faire automatiquement via l’interface radio parce que l’accès au mobile et la modification de ses paramètres via cette interface et très limité vu les problèmes de sécurité, ce qui implique que le fournisseur du service est obligé de configurer les mobiles des utilisateurs manuellement et individuellement ce qui est pratiquement irréalisable, ou de configurer certaines marques de mobiles, mais dans ce cas l’utilisateur désirant bénéficier de ce service doit acheter un mobile de ces marques ce qui est un facteur décourageant pour s’y abonner. Les solutions proposées dans ce PFE doivent permettent d’accéder à ce service sans configuration préalable du terminal.

II-1-2 Étude des solutions possibles

Dans cette section nous avons étudié les différentes solutions possibles en présentant les avantages et les inconvénients de chaque solution.

a- Interface utilisateur

L’interface utilisateur doit être compréhensible et simple à manipuler par tous les abonnés, il y a beaucoup de solutions possibles pour implémenter cette partie.

Chapitre II : Étude de faisabilité et spécification des besoins

i- Intégrer l’interface dans une MIDlet

Cette interface peut être intégrée dans une MIDlet (voir Annexe D), il s’agit d’une archive contenant des classes Java. Après le téléchargement de la MIDlet, la machine virtuelle Java qui se trouve sur le mobile se charge de l’exécution des classes java ouvrant ainsi une interface utilisateur. Cette interface a pour rôle la composition du message et sa transmission au serveur. L’avantage de cette méthode est que l’utilisateur télécharge une seule fois l’interface lui permettant de communiquer avec le serveur, et peut s’en servir à chaque fois qu’il veut utiliser ce service. L’inconvénient est que certains mobiles ne contiennent pas de machine virtuelle Java pour exécuter ce programme, de plus ce programme accède aux répertoires du mobile donc cela représente un problème de sécurité pour les abonnés.

ii- L’interface utilisateur est un formulaire HTML

L’idée est inspirée des formulaires HTML qu’on peut trouver sur certains sites web. Pour

accéder au service, l’utilisateur devra à chaque fois télécharger une page HTML contenant un formulaire, ce formulaire précise chaque champ du message à envoyer. On peut par exemple définir un champ pour l’adresse du destinataire, un deuxième pour le nom de l’expéditeur, un troisième champ pour le message textuel et un dernier avec lequel on peut attacher l’image à transmettre. Cette méthode présente beaucoup d’avantages :

- Profiter des technologies du développement web pour implémenter cette interface.

- Avec cette méthode on n’a pas un problème de compatibilité car touts les terminaux compatibles WAP peuvent afficher cette interface.

- Avec cette méthode, on pourra utiliser ce service en se connectant d’un poste de bureau.

Chapitre II : Étude de faisabilité et spécification des besoins

Cette méthode présente aussi quelques inconvénients :

- L’abonné doit impérativement passer par un service de connexion Internet pour bénéficier de ce service.

- Comme il y a une grande variété de navigateurs installés sur les terminaux mobiles, et que la taille de l’écran diffère d’un mobile à l’autre, alors il y a un problème d’affichage de cette interface, c'est-à-dire que cette page ne sera pas affichée de la même façon pour touts les terminaux.

b- Partie serveur

Cette partie reçoit les messages multimédias, 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 l’installer sur un serveur totalement indépendant de l’architecture du service MMS mais qui utilise le protocole WAP pour communiquer avec le client. Le choix qui sera fait dépend étroitement du choix de la solution à implémenter pour l’interface utilisateur. Ce module doit être en mesure de communiquer avec le système de tarification, il faudra donc développer une interface le reliant à ce système.

II-1-3 Bilan de l’analyse et choix de la solution

a-

Bilan

Selon ce qui a déjà été avancé, on remarque que chaque solution a ses avantages et ses inconvénients, le but de ce projet est de trouver un compromis entre ces différentes solutions pour que ce service soit accessible et facile à utiliser par tout le monde, pour cela, la solution intégrant l’interface utilisateur dans une MIDLet est à écarter, non seulement parce qu’elle ne permet pas aux terminaux qui ne sont pas équipés d’une machine virtuelle Java d’accéder à ce service mais aussi à cause des paramètres de sécurité des mobiles qui supportent ces

Chapitre II : Étude de faisabilité et spécification des besoins

programmes . L’approche qui a été développé par « VODAFONE » ne peut pas, aussi, être considéré à cause de son côté limitatif pour l’accès au service.

b- Choix de la solution à implémenter

La solution qui sera retenu pour l’implémentation de ce service est celle qui permettra un accès facile pour les utilisateurs. Pour cela j’ai opté pour la solution web, il s’agit de développer une interface web pour les abonnés, 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 présentation mais elle est très maniable et extensible, par exemple on pourra ajouter l’option d’envoi multiple vers un groupe de destinataires défini préalablement par l’utilisateur. Seulement, le problème avec cette solution est qu’elle oblige les utilisateurs à passer par une connexion Internet. Pour contourner ce problème, nous avons utilisé l’idée de « Orange » pour développé une autre approche complémentaire à la première, il s’agit d’utiliser l’interface classique d’envoi des messages multimédias en définissant un format spécifique du texte à envoyer avec l’image, cela implique que les messages vont transiter par le centre de messagerie multimédia, donc il y a deux contraintes dont nous devons tenir compte, la première est qu’il faut connecter l’application qui se chargera de la réception des messages à l’MMSC et la deuxième est qu’il faut configurer le centre de messagerie pour qu’il puisse router ces messages vers cette application. Pour récapituler, voici un schéma explicatif (figure 3) de l’architecture finale sur laquelle ce service va être basé :

finale sur laquelle ce service va être basé : Figure 3 : Architecture finale du service

Figure 3 : Architecture finale du service MMS To Postcard

Chapitre II : Étude de faisabilité et spécification des besoins

II-2 Spécification des besoins

La spécification des besoins du système final dépend étroitement de la solution retenue. Dans cette partie, nous avons spécifié les différents besoins fonctionnels et non fonctionnels requis pour l’implémentation de la solution évoquée précédemment et les cas d’utilisations possibles du système final. Nous sommes ensuite passés à la conception de cette solution.

II-2-1 Spécification générale des besoins

Même si les deux solutions adoptées sont complémentaires, ils présentent, toutefois, quelques besoins différents. Le travail demandé consiste :

- Pour la première approche, à implémenter une interface utilisateur et une application côté serveur qui aura pour rôle de recevoir les messages, les formater et les imprimer, ainsi qu’une solution pour la tarification du service.

- Pour la deuxième approche, à concevoir et implémenter une application qui utilisera l’interface standard MM7 pour recevoir les messages directement du MMSC, les formater et les imprimer. Donc ces applications doivent obéir aux besoins suivants :

a- Besoins fonctionnels

Certains besoins fonctionnels sont communs aux deux approches alors que d’autres sont spécifiques à chaque une.

- Besoins fonctionnels pour la première approche

L’interface utilisateur est une interface web qui permettra de contrôler l’accès à ce service et de vérifier le compte de l’utilisateur en cas d’envoi multiple.

Chapitre II : Étude de faisabilité et spécification des besoins

La solution proposée pour la tarification doit être indépendante de la tarification dans le service MMS puisque les messages ne passeront pas par l’ MMSC, elle doit être intégrée dans l’application à développer et doit pouvoir communiquer avec le système de tarification.

L’abonné doit se connecter au serveur et remplir un formulaire qui se chargera de transmettre le message, donc pour accéder à ce service, il doit être abonné à un service de connexion Internet.

-

Besoins fonctionnels pour la deuxième approche

Le serveur d’application doit être connecté au MMSC via l’interface MM7, donc l’application doit être en mesure de comprendre le format des messages définis par le protocole SOAP (voir Annexe C).

L’utilisateur doit connaître la structure du texte qu’il va envoyer avec l’image car c’est dans ce texte que doivent être spécifiés le nom de l’expéditeur, l’adresse du destinataire et le message à envoyer avec l’image.

-

Besoins fonctionnels communs

L’application qui se chargera du formatage des messages et de leur impression est commune aux deux solutions, donc, elle doit être indépendante de la méthode utiliser pour recevoir les messages.

De plus, cette application doit lancer un processus qui fonctionne continuellement et qui accède périodiquement au serveur où sont stockés les messages pour en imprimer les nouveaux.

b-

Besoins non fonctionnels

Ces besoins résultent des contraintes liées au produit final et à son développement.

-

Contraintes liées au produit final

Ce service doit être accessible par touts les terminaux mobiles compatibles avec le réseau de l’opérateur (GPRS, UMTS,…).

Chapitre II : Étude de faisabilité et spécification des besoins

Les interfaces utilisateurs doivent être compréhensibles, et l’utilisation de ce service ne doit pas exiger des connaissances techniques en informatique ou en télécommunication.

- Contraintes liées au développement

Concernant la première solution, pour l’interface utilisateur, il est commode qu’elle soit générée à partir d’un script qui s’exécute sur le serveur, cela nous permettra d’avoir une interface dynamique avec laquelle on pourra contrôler l’accès au service.

L’interface qui communiquera avec le système de tarification doit être en mesure de comprendre le protocole de communication avec ce système à savoir le protocole SCAP qui est basé sur le protocole Diameter (voir Annexe E) [3].

II-2-2 Modèle de cas d’utilisations

Le modèle de cas d’utilisations est un modèle conceptuel basé sur le formalisme UML [7]. Le but de la conceptualisation est de comprendre et structurer les besoins du client. Après qu’ils soient identifiés et structurés, ces besoins précisent le but attendu du système à implémenter. Ce modèle est décri par le diagramme de cas d’utilisations. Il s’agit de diagramme qui représente les cas d'utilisation, les acteurs et les relations entre les deux, il décrit le comportement d'un système du point de vue d'un utilisateur et permet de définir ses limites et ses relations avec l'environnement. Les acteurs se représentent sous la forme de petits personnages. Un acteur représente le rôle joué par une personne ou une chose qui interagit avec un système. Les acteurs se déterminent en observant les utilisateurs directs du système, ceux qui sont responsables de son exploitation ou de sa maintenance, ainsi que les autres systèmes qui interagissent avec le système en question. Un cas d'utilisation est une manière spécifique d'utiliser un système. Il représente une fonctionnalité du système, déclenchée suite à la stimulation d'un acteur externe.

Chapitre II : Étude de faisabilité et spécification des besoins

a- Identification des différents acteurs agissant sur le système

Un cas d’utilisation représente une suite d’interactions entre un acteur et le système, donc afin de déterminer tout les cas d’utilisation du système, il faut définir les différents acteurs qui interagissent avec ce système.

- L’expéditeur : C’est un abonné de l’opérateur qui utilise ce service.

- Le serveur CCN (voir Annexe E): Ce serveur représente l’interface d’intégration des services au niveau du système de tarification.

- Le serveur d’application : C’est le serveur qui va traiter les messages.

- L’MMSC : Cet acteur n’intervient que pour la deuxième approche.

b- Diagramme de cas d’utilisations

Dans ce qui suit , une explication textuelle accompagne le diagramme de cas d’utilisations (figure 4), elle comprend un ensemble de pré conditions nécessaires à la réalisation du cas d’utilisation, une description commentant le cas d’utilisation et un ensemble de post-conditions issu de la réalisation du cas d’utilisation considéré.

Chapitre II : Étude de faisabilité et spécification des besoins

II : Étude de faisabilité et spécification des besoins Figure 4 : Diagramme de cas d'utilisation

Figure 4 : Diagramme de cas d'utilisation

- Cas d’utilisation « EnvoyerMMS »

Ce cas d’utilisation représente deux scénarios possibles. Ces scénarios dépendent étroitement de la solution qui va être utilisée. Pré condition :

a) Si l’utilisateur va utiliser l’interface web pour accéder à ce service, son terminal

doit être configuré pour le WAP 2.

b) Si l’utilisateur va utiliser l’interface classique d’envoi des MMS, alors son

mobile doit être configuré pour le service MMS.

Chapitre II : Étude de faisabilité et spécification des besoins

Bien sur, nous supposons que les utilisateurs qui vont accéder à ce service sont équipés de terminaux compatibles WAP 2. Description :

L’utilisateur compose un message multimédia, c'est-à-dire qu’il va choisir l’image, écrire le texte, et spécifier l’adresse du destinataire puis envoie le touts au serveur. Post condition :

Les messages envoyés vont être reçus et traités par le serveur d’application.

- Cas d’utilisation « GérerLesRequêtes »

Pré condition :

Le serveur d’application doit être accessible aux utilisateurs désirant bénéficier du service. Description :

Le serveur d’application reçoit les requêtes des utilisateurs, leur envoie la page web contenant l’interface utilisateur et récupère les messages envoyés. Post condition Les messages sont enregistrés sur le serveur d’application.

- Cas d’utilisation « TransférerMessage »

Pré condition :

Le MMSC doit être configuré pour router les MMS vers le serveur d’application Description :

Les MMS des utilisateurs utilisant ce service sont routés vers le serveur s’application. Post condition :

L’MMSC encapsule les MMS dans le protocole définit par l’interface MM7 qui le relit au serveur d’application.

Chapitre II : Étude de faisabilité et spécification des besoins

- Cas d’utilisation « TraiterMessage »

Pré condition :

Le message est enregistré sur le serveur d’application. Description :

Ce cas d’utilisation englobe les différents traitements des messages pour générer 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 :

Création

par

l’utilisateur.

d’une

carte

postale

à

partir

du

message

multimédia

envoyé

II-3 Conclusion

Dans ce deuxième chapitre, nous avons utilisé une méthodologie UML pour spécifier les

cas d’utilisations de la solution adoptée. Cette spécification va nous servir comme base pour

concevoir

le

service.

Chapitre III : Conception du service « MMS To Postcard »

Chapitre III

Conception du service « MMS To Postcard »

Après la détermination des besoins fonctionnels et non fonctionnels et la spécification des besoins de l’application, nous sommes passés, dans ce troisième chapitre à la conception du projet. Notre étude se base sur le formalisme UML, dans un premier temps, nous présentons une étude conceptuelle comportant les difficultés conceptuelles rencontrées et les solutions proposées pour les surmonter, ensuite , nous passons à une conception détaillée du projet puis les diagrammes de classe relatifs à l’application.

III-1 Étude conceptuelle

Le service qui va être implémenté peut être déployé par un fournisseur de service indépendant de l’opérateur, donc ce fournisseur ne doit pas avoir accès au système de tarification, or d’après la spécification des besoins, il faut prévoir un module qui sera en mesure de communiquer avec ce système, et ce module appartient à l’application elle-même, donc il sera installé sur le serveur d’application. Le problème est que le fournisseur pourra, par malveillance, se servir de ce module pour décrémenter les comptes des abonnés alors qu’ils n’ont pas accédé au service. La solution que nous avons proposée consiste à installer la partie tarification sur un serveur nommé « serveur de transfère » (voir figure 5) indépendant de celui du fournisseur de service, ce serveur appartiendra à l’opérateur. Le fournisseur de service n’aura, donc, aucun accès au système de tarification et s’occupera seulement du traitement des messages envoyés.

Med Amine BEN KHEMIS

- 22 -

Chapitre III : Conception du service « MMS To Postcard »

Ce serveur aura pour rôles le transfère des messages au fournisseur du service et la communication avec le système de tarification. Cette solution est représentée dans le schéma suivant.

Cette solution est représentée dans le schéma suivant. Figure 5 : Séparation entre le module de

Figure 5 : Séparation entre le module de tarification et l'application

La deuxième difficulté réside dans le faite qu’il faut que, à chaque arrivé d’un nouveau message, le serveur d’application puisse le récupérer pour l’imprimer. Cette condition implique qu’il doit pouvoir faire la différence entre les nouveaux messages arrivés et les anciens messages pour ne pas imprimer deux fois ou plus le même message. La solution qui vient directement à l’esprit est d’effacer à chaque foie le message après son impression, or, d’après les exigences de l’entreprise, il faudra garder une trace de touts les messages envoyés. La solution que nous avons proposées pour contourner ce problème consiste à garder les messages sur le serveur de transfère, définit précédemment, et enregistrer le chemin d’accès de chaque message envoyé dans une base de donné.

Chapitre III : Conception du service « MMS To Postcard »

Ainsi, le serveur d’application, c'est-à-dire celui du fournisseur de service, devra consulter périodiquement cette base, retirer les chemins d’accès des nouveaux messages envoyés, récupérer ces messages pour les imprimer et finalement, effacer ces chemins d’accès de la base de donné. La solution finale qui sera implémentée est modélisée par le schéma suivant.

sera implémentée est modélisée par le schéma suivant. Figure 6 : Ajout d’une base de donnés

Figure 6 : Ajout d’une base de donnés pour connecter le serveur d’application au module de tarification

Chapitre III : Conception du service « MMS To Postcard »

Pour permettre plus de flexibilité dans l’utilisation de ce service nous avons ajouté l’option d’envoi multiple avec la possibilité de définir des groupes de contacts. Cette option permet aux utilisateurs d’envoyer la même carte postale à plusieurs correspondants sans qu’ils soient obligés de répéter la même action plusieurs fois. Pour assurer cette fonctionnalité nous avons ajouté une base de donnés pour enregistrer les groupes d’amis des utilisateurs. Cette modification ajoute une nouvelle contrainte à respecter dans le système final. Il faut accéder à la balance de l’utilisateur, à chaque fois qu’il utilise cette option, pour déterminer le nombre maximum de personnes à qui il peut envoyer une carte postale en même temps.

à qui il peut envoyer une carte postale en même temps. Figure 7 : Extension du

Figure 7 : Extension du service MMS To Postcard

Chapitre III : Conception du service « MMS To Postcard »

III-2 Organigramme

Dans l’organigramme suivant nous décrivons les différentes étapes qui représentent le système final.

différentes étapes qui représentent le système final. Figure 8 : Organigramme du service MMS To Postcard

Figure 8 : Organigramme du service MMS To Postcard

Chapitre III : Conception du service « MMS To Postcard »

III-3 Conception détaillée

Les diagrammes de classe modélisent les interactions et les hiérarchies entre les classes les plus importantes conçues pour la réalisation de ce service. Pour modéliser les différentes classes du système final nous avons regroupé les principales classes en des paquetages selon leurs rôles. Dans ce qui suit nous représentons le Diagramme de paquetages suivi des diagrammes de classes constituants chaque paquetage. Nous nous sommes appuyés sur le formalisme UML [7] pour représenter ces différents diagrammes.

III-3-1 Diagramme de paquetages

ces différents diagrammes. III-3-1 Diagramme de paquetages Figure 9 : Diagramme de paquetages Dans ce diagramme,

Figure 9 : Diagramme de paquetages

Dans ce diagramme, nous avons modélisé les différentes relations entre les paquetages du système. Ces relations dépendent étroitement de la spécification des besoins.

Chapitre III : Conception du service « MMS To Postcard »

III-3-2 Diagrammes de classes

Dans ce qui suit une description détaillé de chaque paquetage.

a- Paquetage « UserInterface »

de chaque paquetage. a- Paquetage « UserInterface » Figure 10 : Diagramme de classes du paquetage

Figure 10 : Diagramme de classes du paquetage "UserInterface"

i. La classe « UserAccess » Description Cette classe permet de contrôler l’accès au service et d’afficher l’interface utilisateur. Méthodes La méthode « getMSISDN () » permet de récupérer l’ MSISDN de l’utilisateur pour pouvoir accéder à son compte. La méthode « showUserInterface () » permet d’envoyer l’interface utilisateur à l’abonné.

ii. La classe « VerifyAccount » Description Cette classe permet de calculer, d’après la balance de l’utilisateur, le nombre de destinataires à qui il pourra envoyer des cartes postales en utilisant l’option d’envoi multiple.

Chapitre III : Conception du service « MMS To Postcard »

iii.

La classe « FriendGrp » Description

 

Cette classe gère les groupes de contacts des utilisateurs. Méthodes

 

Les méthodes

« getGrpList() »

et

« getFriendList() »

permettent

de récupérer,

respectivement, la liste des groupes de contacts et la liste d’amis pour chaque groupe, ces listes sont ensuite affichées sur l’interface utilisateur.

b-

Paquetage « UploadParam »

 

Le rôle principal de ce paquetage est la réception des messages multimédias, il est aussi utilisé pour recevoir d’autres donnés des utilisateurs.

utilisé pour recevoir d’autres donnés des utilisateurs. Figure 11 : Diagramme de classes du paquetage

Figure 11 : Diagramme de classes du paquetage "UploadParam"

Chapitre III : Conception du service « MMS To Postcard »

i. La classe « Upload » Description Cette classe représente la classe mère de ce paquetage. Attribut L’attribut « MSISDN » contient l’ MSISDN de l’utilisateur Méthodes On utilise la méthode « getMSISDN () » pour récupérer l’ MSISDN de l’abonné. La méthode « getParamFromUser () » récupère les paramètres utilisés pour définir les groupes d’amis

ii. La classe « UploadGrpParam » Description Cette classe hérite de la classe « Upload » et elle est utilisée pour définir les groupes d’amis.

iii. La classe « UploadFromHMLForm » Description Cette classe hérite de la classe « UploadMessage », son rôle est de recevoir les messages multimédias à partir de l’interface web et de les enregistrer sur le serveur. Méthode La méthode « filterMsg ()» filtre les messages envoyés pour ne laisser passer que les textes et les images. La classe « UploadFromMMSC » Description Le système utilise cette classe pour récupérer les messages envoyés du MMSC à travers l’interface MM7. Méthodes Les méthodes de cette classe sont utilisées pour extraire les MMS des messages SOAP.

Chapitre III : Conception du service « MMS To Postcard »

c- Paquetage « DBConnection » Ce paquetage joue le rôle d’interface entre les autres paquetages et les différentes bases de donnés du système, ses classes sont donc utilisées pour se connecter aux bases de donnés et y effectuer les différents traitements.

bases de donnés et y effectuer les différents traitements. Figure 12 : Diagramme de classes du

Figure 12 : Diagramme de classes du paquetage "DBConnection"

i. La classe « ConnectionDB » Description Cette classe est utilisée pour se connecter ou se déconnecter des bases de donnés. Attribut L’attribut « success » indique si la connexion à une base de donné s’est effectuée avec succès ou si elle a échouée. Méthodes Les méthodes de cette classe, comme leur nom l’indique, sont utilisées pour créer ou fermer une connexion vers une base de donnés.

Chapitre III : Conception du service « MMS To Postcard »

d-

Package « CCNInterface » Ce paquetage représente l’interface qui permet d’accéder au système de tarification.

qui permet d’accéder au système de tarification. Figure 13 : Diagramme de classes du paquetage

Figure 13 : Diagramme de classes du paquetage "CCNInterface"

i.

La classe « DecUserBalance » Description Cette classe est utilisée pour décrémenter les comptes des utilisateurs.

ii.

La classe « DecUserBalance » Description Le rôle de cette classe est de consulter la balance des utilisateurs.

e-

Package « Printing »

Ce

paquetage

effectue

les

derniers

traitements

finalement, générer la carte postale.

aux

messages

multimédias

pour,

générer la carte postale. aux messages multimédias pour, Figure 14 : Diagramme de classes du paquetage

Figure 14 : Diagramme de classes du paquetage "Printing"

Chapitre III : Conception du service « MMS To Postcard »

i. La classe « GetMsg » Description Cette classe récupère le chemin d’accès de chaque message enregistré sur le serveur. Méthodes

Les

respectivement, le chemin d’accès du fichier texte et celui de l’image.

méthodes

« getTextPath() »

et

« getImgPath() »

sont

utilisées

pour

récupérer,

ii. La classe « FormatMsg » Description Cette classe récupère les messages du serveur, et les met sous la forme d’une carte postale standard.

iii. La classe « Print » Description Cette classe imprime les cartes postales.

Chapitre III : Conception du service « MMS To Postcard »

III-4 Diagrammes de séquences

Dans cette section, nous définissons d’abord les différents scénarios d’utilisation du service, ensuite nous représentons, pour chaque scénario, le diagramme de séquences. Les scénarios d’accès au service sont :

- Envoi d’un seul message.

- Ajout d’un nouveau contact.

- Envoi multiple.

- Transmission des messages vers le MMSC.

III-4-1 Envoi d’un seul message

Ce scénario représente la fonctionnalité de base du service qui est l’envoi d’un message à un seul correspondant à partir de l’interface web.

à un seul correspondant à partir de l’interface web. Figure 15 : Diagramme de séquences pour

Figure 15 : Diagramme de séquences pour un envoi simple

Chapitre III : Conception du service « MMS To Postcard »

III-4-2 Ajout d’un nouveau contact

Ce scénario ne représente pas une utilisation du service lui même, il s’agit en fait de définir les groupes de correspondants et de les enregistrer avec leur coordonnées dans une base de donné.

enregistrer avec leur coordonnées dans une base de donné. Figure 16 : Diagramme de séquences en

Figure 16 : Diagramme de séquences en cas d'ajout d'un contact

III-4-3 Envoi multiple

L’accès au service se fait de la même façon que pour le premier scénario, mais avant que l’utilisateur n’envoie son message, le système vérifie son compte pour lui indiquer à combien de destinataires il pourra envoyer des cartes postales. Après la sélection des correspondants et l’envoi du message, le système vérifie cette fois si l’utilisateur a dépassé ou non ce nombre.

Chapitre III : Conception du service « MMS To Postcard »

Figure 17 : Diagramme de séquences pour un envoi multiple
Figure 17 : Diagramme de séquences pour un envoi multiple

Chapitre III : Conception du service « MMS To Postcard »

III-4-4 Transmission des messages vers le MMSC

Ce scénario fait intervenir une autre entité du réseau, qui est le MMSC. Le diagramme de séquences suivant représente la succession chronologique des différentes étapes intervenant dans la réalisation de la deuxième solution évoquée précédemment, c'est-à-dire, celle qui fait intervenir le MMSC.

c'est-à-dire, celle qui fait intervenir le MMSC. Figure 18 : Diagramme de séquences du service lorsque

Figure 18 : Diagramme de séquences du service lorsque les messages passe par l' MMSC

III-5 Conclusion

Dans ce chapitre, nous avons présenté des solutions aux difficultés conceptuelles rencontrées, et nous avons, ensuite, détaillé la conception des différents modules de notre application. Cette conception va nous être utile pour la réalisation du service.

Chapitre IV : Choix techniques et Réalisation

Chapitre IV

Choix techniques et Réalisation

Après avoir déterminé les besoins de l’application et conçu les différentes parties de ce service, nous sommes passés à la réalisation de la solution conçue. Mais avant tout, nous présentons les outils utilisés pour le développement du service « MMS To Postcard »

IV-1 Environnement logiciel

Le développement des différentes classes de l’application ainsi que la compilation du code ont été fait sur une plateforme Windows. Mais l’intégration du service est réalisée sur des serveurs Solaris, ce qui a imposé une contrainte quand au choix de l’environnement de développement utilisé pour l’implémentation du service, ainsi cet environnement doit assurer la portabilité de l’application finale d’une plateforme à une autre sans être obligé de la recompiler. Nous avons opté pour Java, non seulement à cause de la contrainte liée à la portabilité évoquées précédemment mais aussi, parce que ce langage est le plus utilisé dans le domaine du développement 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'exécution. Sa portabilité est garantie grâce à la machine virtuelle Java, il s’agit d’un programme appartenant à la plateforme d’exécution, qui interprète le code Java et le convertit en code natif. Ce code natif sera ensuite exécuté par le système d’exploitation.

Med Amine BEN KHEMIS

- 38 -

Chapitre IV : Choix techniques et Réalisation

Le schéma ci dessous explique mieux le rôle de la machine virtuelle.

ci dessous explique mieux le rôle de la machine virtuelle. Figure 19 : Architecture de la

Figure 19 : Architecture de la plateforme Java

IV-2 Outils logiciels IV-2-1 Les outils web

L’un des critères décisifs pour le succès d’un service est la simplicité de la manipulation de l’interface d’accès, c’est pourquoi le choix des outils de programmation et surtout les outils du développement web doit être bien étudié.

a- Les servlets

L’une des étapes primordiale du service développé est de pouvoir envoyer des fichiers au serveur. Donc l’application qui va être installé sur le serveur doit être en mesure de récupérer ces fichiers et le plus important c’est de pouvoir récupérer des fichiers de plusieurs utilisateurs en même temps. L’une des solutions les plus efficaces qui respecte ces conditions est les servlets [10]. Ce sont des programmes Java qui s’intègrent dans un serveur web pour fournir le traitement côté serveur des requêtes issues d’un navigateur client. Ces programmes permettent de récupérer

Chapitre IV : Choix techniques et Réalisation

des donnés de plusieurs clients à la fois, on dit qu’ils sont « multithread » c'est-à-dire « à lecture multiple », ce mécanisme s’explique par le fait qu’à chaque requête d’un client le servlet crée une instance ou un « Thread » qui s’occupe de ce client. L’une des avantages de cette technologie par rapport à d’autres est la vitesse d’exécution, cet avantage est tiré du fait qu’un servlet est chargé une seule fois en mémoire et s’éxécute depuis cette mémoire après son chargement initial. Comme ce programme Java s'exécute dynamiquement sur le serveur Web il permet alors l'extension des fonctions de ce dernier, typiquement : accès à des bases de donnés, transactions d'e-commerce, etc… Ce qui est intéressant dans le cas du projet puisque l’application finale sera amener à faire des traitements sur les bases de donnés et même de communiquer avec d’autres serveurs.

b- Les JSP

L’interface utilisateur est composée de plusieurs pages web qui vont être générées dynamiquement selon les requêtes de l’utilisateur. Pour concevoir une telle interface, nous avons eu recourt aux pages JSP ou « Java Server Pages ». C’est une technologie basée sur Java qui permet aux développeurs de générer dynamiquement du code HTML, XML ou tout autre type de page Web [10]. Comme nous utilisons une plateforme java pour développer ce service, ce choix se révèlera très bénéfique parce que nous pouvons utiliser les différentes méthodes des classes déjà développées et compilées sans avoir, à chaque fois, à réécrire ces méthodes. L’avantage des JSP par rapport à d’autres scripts, qui s’exécutent du côté serveur, est que le temps du traitement est moins important, cela est dû au faite que ces scripts sont compilés une seule fois, et on n’aura pas besoin de les recompilés à chaque accès au service. Le principe de fonctionnement des JSP ressemble à celui des servlets, mais ils présentent quelques différences, comme la possibilité de les intégrer dans des pages HTML et de définir des liens entre eux. Un exemple d’utilisation de cette technologie dans le projet est la transmission de l’ MSISDN de l’abonné d’une page à une autre.

Chapitre IV : Choix techniques et Réalisation

c- Le langage HTML

Pour les pages statiques de l’interface 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'insérer des liens dans du texte, donc de créer de l'hypertexte, d'où le nom du langage. En fait les pages HTML utilisées pour représenter l’interface d’accès au service seront modifiées, par la passerelle WAP, en des pages XHTML pour qu’elles soient adaptées au navigateur du client.

IV-2-2 Les API

Une API définit la manière dont un composant informatique peut communiquer avec un autre. Il s'agit généralement d'une liste de fonctions considérées comme utiles pour d'autres composants. Ces fonctions peuvent être implémentées pour simuler un protocole de communication. Les API sont, généralement, utilisées comme interface d’intégration de service.

a- Ericsson mm7 API

C’est une API Java basée sur l’implémentation Apache de SOAP. Elle simule le transfère des messages entre le MMSC et le serveur du fournisseur de services via l’interface MM7. Nous l’avons utilisé dans l’implémentation de la deuxième approche, c'est-à-dire celle qui fait intervenir le MMSC. Cette interface de programmation définit des classes utilisées pour l’envoi et la réception des messages. Comme ces messages sont des messages SOAP, donc il a fallut utiliser une API qui implémente le protocole SOAP pour pouvoir développer cette solution.

Chapitre IV : Choix techniques et Réalisation

Le schéma suivant explique mieux l’utilisation de cette API.

schéma suivant explique mieux l’utilisation de cette API. Figure 20 : Utilisation de l'api "Ericsson MM7

Figure 20 : Utilisation de l'api "Ericsson MM7 API"

b- Diameter Charging API

Cette API a été utilisée pour offrir la possibilité à l’opérateur de tarifer ce service. Cette interface implémente le protocole Diameter [3] et offre des méthodes pour dialoguer avec le système de tarification. Comme il a été indiqué dans la partie conception, c’est le serveur de transfert qui s’occupera de la tarification donc c’est au niveau de ce serveur que cette API doit être intégrée. Le schéma suivant explique comment cette API a été utilisée.

suivant explique comment cette API a été utilisée. Figure 21 : Utilisation de l'api "Diameter Charging

Figure 21 : Utilisation de l'api "Diameter Charging API"

Chapitre IV : Choix techniques et Réalisation

c- L’API « JDBC »

L'API JDBC permet aux applications java d’accéder par le biais d'une interface commune à des sources de donnés pour lesquelles il existe des pilotes JDBC. Normalement, il s'agit d'une base de donnés relationnelle, et des pilotes JDBC sont disponibles pour tous les systèmes connus de bases de donnés relationnelles. Nous avons utilisé cette API pour permettre aux classes Java de communiquer avec les bases de donnés.

IV-2-3 Les serveurs

Les JSP et les servlets nécessitent un serveur pour fonctionner nommé souvent moteur de servlets ou moteur de JSP. Le serveur le plus connu est le serveur Tomcat [10]. C’est un serveur Open Source qui agit comme un conteneur de servlets. Il fait partie du projet Jakarta, au sein de la fondation Apache. Tomcat implémente les spécifications des servlets et des JSP de Sun Microsystems.

IV-2-4 Le système de gestion des bases de donnés

Le système de gestion des bases de donnés utilisé dans ce projet et MySQL, il s’agit d’un SGBD libre et gratuit. Il est très utilisé et très populaire. MySQL est un serveur de bases de donnés relationnelles SQL, très rapide, multi-thread et multi-utilisateur

IV-3 Implémentation

Dans cette section nous expliquons comment nous avons utilisé les outils étudiés dans la section précédente pour mettre en place le service « MMS To Postcard » en nous basant sur l’architecture présentée dans le chapitre précédent.

Chapitre IV : Choix techniques et Réalisation

IV-3-1 Description Fonctionnel

a- L’interface d’accès

Cette interface est représentée par des pages HTML générées dynamiquement à partir de script JSP. L’utilisation des JSP dans cette interface se traduit par le fait qu’il faut exécuter des scripts de contrôles et de vérifications avant de permettre l’utilisation de ce service. Ces scripts de contrôle sont basés sur les paramètres envoyés par le réseau (comme l’ MSISDN) ou les paramètres envoyés par les utilisateurs (le nom de nouveau groupe de contacts, les coordonnés d’un contact,….).

b- La partie serveur

Il s’agit, comme cela était décrit dans la partie conception, de deux serveurs : le serveur de transfert et le serveur d’application. Pour le serveur de transfert nous avons développé deux interfaces de réception des messages.

La première est un servlet qui reçoit les messages multimédias à partir des formulaires HTML inclus dans l’interface d’accès. Cette interfaces, est utilisée dans la solution qui est basée sur le protocole WAP et qui est totalement indépendante de l’architecture du service MMS.

La deuxième est une classe Java basée sur l’API « Ericsson MM7 API », cette classe se sert des méthodes implémentées par cette API pour extraire les MMS des messages SOAP envoyés du MMSC à ce serveur.

Ce serveur se charge aussi de la tarification et cela à partir d’une autre interface qui communique avec le système de tarification. Cette interface est basée sur l’API « Diameter Charging API », elle utilise les méthodes implémentées par cette API pour pouvoir communiquer avec le système de tarification.

Chapitre IV : Choix techniques et Réalisation

Le deuxième serveur est le serveur du fournisseur de service. Il contient une interface pour communiquer avec les bases de donnés et une autre pour recevoir les messages multimédias. Ce serveur se charge de la transformation de ces messages en des cartes postales. Pour mieux décrire le système final voici un schéma fonctionnel qui explique le choix des outils pour chaque module.

qui explique le choix des outils pour chaque module. Figure 22 : Schéma fonctionnel du produit

Figure 22 : Schéma fonctionnel du produit final

IV-3-2 Présentation de l’interface utilisateur

Comme cela a déjà été évoqué, l’interface d’accès au service contient un ensemble de pages web. La première page est générée par une JSP après avoir effectué un contrôle d’accès au service. Si le solde de l’utilisateur ne suffie pas pour accéder au service alors cette première page affichera un message d’erreur, sinon elle va indiquer les différentes options offertes par le service. L’abonné peut ainsi choisir l’option qui le conviendra.

L’abonné peut ainsi choisir l’option qui le conviendra. Figure 23 : Les premières pages de l'interface

Figure 23 : Les premières pages de l'interface

Chapitre IV : Choix techniques et Réalisation

Pour cette première version du service, nous n’avons implémenté que deux options possibles, celle de l’envoi d’un message simple, c'est-à-dire, vers un seul destinataire, et celle de l’envoi multiple.

vers un seul destinataire, et celle de l’envoi multiple. Figure 24 : Formulaire d’envoi d’un seul

Figure 24 : Formulaire d’envoi d’un seul message et interface des options pour l’envoi multiple

L’envoi multiple peut se faire de deux manières.

- Envoi de carte postale directement :

Dans ce cas, la page relative à cette option s’affiche après avoir vérifié le nombre de destinataires possibles à qui l’abonné pourra envoyer des cartes postales en même temps. Ce nombre dépend du solde de l’abonné.

en même temps. Ce nombre dépend du solde de l’abonné. Figure 25 : Interface d'envoi multiple

Figure 25 : Interface d'envoi multiple

Chapitre IV : Choix techniques et Réalisation

- Définir des groupes de contacts pour leur envoyer des cartes postales ultérieurement :

Dans ce cas, l’utilisateur utilise un formulaire pour définir les groupes de contacts, ce formulaire transmet ensuite les différents paramètres au serveur. Le serveur, à son tour, vérifie si le contact choisi ne figure pas dans la base de donnés des groupes de contacts et l’enregistre. Dans le cas contraire il envoie un message d’erreur à l’utilisateur. Ensuite lorsque l’abonné veut envoyer à ses contacts enregistrés sur la base de donné, il n’a qu’à choisir cette option. Un script JSP récupère la liste des contacts de la base de donnés, et l’affiche sur l’interface en indiquant à combien de personnes son solde lui permet d’envoyer des cartes postales en même temps.

lui permet d’envoyer des cartes postales en même temps. Figure 26 : Mise à jour et

Figure 26 : Mise à jour et consultation de la liste des contacts

IV-4 Problème d’affichage sur les mobiles et solution proposée

Lors du teste du service, nous nous sommes rendus compte qu’il y a quelques problèmes d’affichages sur les terminaux mobiles. Ces problèmes consistent au fait que l’interface d’accès au service ne s’affiche pas de la même façon sur touts les mobiles. Ce problème est prévisible puisque touts les terminaux ne possèdent pas les mêmes tailles d’écran et surtout parce qu’ils n’utilisent pas le même navigateur pour afficher les pages web, donc les balises HTML ne sont

Chapitre IV : Choix techniques et Réalisation

pas interprétées de la même façon et l’affichage sera différent d’un terminal à l’autre. Ce problème existait avant pour les navigateurs des micro-ordinateurs : les pages web ne s’affichaient pas de la même façon pour Internet Explorer et pour Netscape. Pour contourner ce problème, nous avons séparé 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 réécrire toute l’interface d’accès en XML, il s’agit là des donnés, et d’allouer à chaque navigateur utilisé par les terminaux mobile un fichier de style XSL, il s’agit là de l’affichage. Les feuilles de style XSL permettent d’adapter l’affichage des pages web au terminal utilisé. Lorsqu’un utilisateur veut se connecter au serveur, son terminal envoie une requête HTTP, cette requête contient plusieurs variables, l’une de ces variables est « HTTP_USER_AGENT ». Cette variable contient la marque du téléphone, son système d’exploitation et le navigateur utilisé. La détection du navigateur du terminal se fera par un script JSP qui va récupérer 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 détails de la réalisation du service « MMS To Postcard ». Nous avons expliqué les différents scénarios d’accès à ce service.

Conclusion et perspectives

Conclusion et perspectives

A l’heure de l’explosion de la téléphonie mobile, tous les opérateurs veulent en profiter au maximum pour augmenter leurs chiffres d’affaire. Pour cela, ils misent sur les services à valeurs ajoutés. Le service « MMS To Postcard » que j’ai développé comme projet de fin d’étude a pour objectif de rassembler les services offerts par les nouvelles technologies des communications et le traditionnel service postal délaissé à cause de l’apparition de la messagerie électronique et du service MMS. L’élaboration de ce projet m’a permit d’approfondir mes connaissances en informatique et surtout dans le domaine du développement de services web. Néanmoins, ces connaissances, ne suffisent pas pour développer des services mobiles à valeurs ajoutés. Il m’a donc été donné d’apprendre au cour de ce stage qu’il faut joindre le monde informatique au monde des télécommunications pour pouvoir créer de nouveaux services.

par

exemple intégrer des messages publicitaires sur les cartes postales à envoyer, en respectant bien sur le contexte de l’envoi. Ainsi, ces cartes postales seront payées par l’entreprise qui va intégrer son message publicitaire, offrant la possibilité aux abonnées de profiter gratuitement de ce service. Ce service peut être utilisé d’une autre manière. Par exemple, on peut concevoir un service d’impression à distance : l’abonné sélectionne la photo ou l’album de photos qu’il veut imprimer, l’envoi au fournisseur du service en précisant la nature et la taille du papier. Le fournisseur du service se chargera alors de l’imprimer en respectant les contraintes spécifiées. Il faudra alors prévoir des bornes d’impression.

Le service « MMS To Postcard » est particulièrement extensible. On pourrais

Med Amine BEN KHEMIS

- 49 -

Annexes

Annexes

Annexe A : Le protocole WAP

1- Modèle en couche du protocole WAP

Le WAP Forum a défini un modèle en couche pour le protocole WAP pour permettre aux équipements WAP, issus de différentes technologies, de communiquer ensemble. Le but est de mettre en place une architecture commune pour les différentes technologies de réseaux mobiles.

pour les différentes technologies de réseaux mobiles. Figure 27 : Pile de protocoles du WAP1 •

Figure 27 : Pile de protocoles du WAP1

Wireless Application Environment (WAE)

Cette couche spécifie le langage de balise qui doit être utilisé pour afficher les pages WAP. Dans les premières version du WAP, le langage utilisé est le WML (Wireless Markup Language), il s’agit d’un langage similaire au HTML mais optimisé pour utilisation sur des terminaux mobile portables.

Wireless Session Protocol (WSP)

Ce protocole permet d’assurer la persistance de la connexion, il offre à la couche WAE une interface pour les services orientés session.

Annexes

Wireless Transaction Protocol (WTP)

Cette couche opère au dessus d’un service datagramme, elle prend en charge l’aspect transactionnel du système et fiabilise la transmission.

Wireless Transport Layer Security (WTLS)

Ce protocole utilise la technologie SSL pour sécuriser les échanges de messages entre terminaux et serveurs. Il peut, grâce à cette fonctionnalité, être utilisé dans le cadre de l’authentification des cartes de paiement pour le commerce électronique.

WDP (Wireless Datagram Protocol)

Il s’agit de la couche transport du protocole WAP, cette couche offre une interface entre le type du réseau utilisé et les couches application, session et sécurité, ce qui permet à ces couches de fonctionner en totale indépendance de la technologie du réseau. Ainsi, ce modèle et toutes les applications qui pourront être développées seront disponibles dans le cas où un nouveau type de réseau apparaîtrait.

2- Modification des protocoles lors de l’évolution du WAP1 au WAP2

a-

WAP1

protocoles lors de l’évolution du WAP1 au WAP2 a- WAP1 Figure 28 : Conversion des protocoles

Figure 28 : Conversion des protocoles pour WAP1

Annexes

b-

WAP2

Annexes b- WAP2 Figure 29 : Conversion des protocoles pour WAP2 Med Amine BEN KHEMIS 3

Figure 29 : Conversion des protocoles pour WAP2

Annexes

Annexe B : Les langages : WML, XHTML, XML et XSL

1- Le langage WML

Le Wireless Markup Language (WML) est un langage à balises conçu spécifiquement pour le WAP, de manière à pouvoir s'afficher sur un écran de téléphone 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), dérivé 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 définie par XML, plus récente et plus simple que la syntaxe définie par SGML respectée par HTML.

3- Le langage XML

Extensible Markup Language (langage de balisage extensible), généralement abrégé XML, est un standard du World Wide Web Consortium qui sert de base pour créer des langages de balisage : c'est un « métalangage ». En ce sens, XML permet de définir un vocabulaire et une grammaire associée sur base de règles formalisées. Il est suffisamment général pour que les langages basés sur XML, appelés aussi dialectes XML, puissent être utilisés pour décrire toutes sortes de donnés et de textes. Il s'agit donc partiellement d'un format de donnés. L'extensibilité de XML est principalement assurée par la notion d'espace de nommage. L'objectif initial de XML était de faciliter le partage de textes et d'informations structurées, par exemple au travers d'Internet, en séparant le contenu du contenant. Il constitue une simplification de SGML tout en continuant à assurer la portabilité des documents, notamment grâce à l'intégration 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 décrit comment doivent être présentés (c'est-à- dire affichés, imprimés, épelés) les documents XML basés sur une même DTD ou un même schéma.

Annexes

Annexe C : Exemple de message SOAP transmis à travers l’interface MM7

de message SOAP transmis à travers l’interface MM7 Figure 30 : Exemple d'un message SOAP Med

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 téléphones mobiles. Abréviation de « Mobile Information Device Profile », MIDP est un ensemble d'API J2ME qui définit la façon dont les applications de logiciel se connectent à l'interface des téléphones cellulaires et les applications conformes à cette norme s'appellent MIDlets. Les sociétés ayant travaillés au MIDP incluent Ericsson, NEC, Nokia, NTT DoCoMo, Palm Computing, Research In Motion (RIM), DoCoMo, LG TeleCom, Samsung et Motorola.

Annexes

Annexe E : Intégration des services au niveau du système de tarification

1- Le serveur CCN

Le CCN ou « Charging Control Node » et l’un des serveurs du système de tarification prépayé, il est construit sur la plateforme des serveurs télécoms d’Ericsson (TSP), qui représente une plateforme multiservice. Le CCN est composé de deux parties : l’application CCF et la plateforme TSP. Le schéma ci-dessous représente l’architecture du CCN.

Le schéma ci-dessous représente l’architecture du CCN. • Le TSP est une plateforme matériel pour le

Le TSP est une plateforme matériel pour le CCN. C’est un système distribué multiprocesseur.

Le TSP représente aussi la partie qui implémente les ressources et les fonctions de système d’applications partagées.

Le CCF (Charging Control Function), c’est la couche où les services spécifiques du CCN sont implémentés, il est à son tour divisé en 3 couches :

- La couche d’accès : C’est l’interface de communication avec les applications externes.

- La couche service ou encore la couche contrôle: Cette couche est responsable du contrôle des services.

- La couche fonction : Assure des fonctions avancées pour la couche service.

Annexes

2- Le protocole Diameter

Diameter est un protocole conçu pour servir de support à l’architecture AAA (Authentication, Autorization, Accounting).Il fournit les mécanismes de base pour établir un transport fiable, délivrer les message et gérer 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 s’adapter

aux nouvelles technologies (IPv4 Mobile, NASREQ

services aux applications mobiles. En effet, Radius était conçu à l’origine, uniquement pour des

protocoles tel SLIP ou PPP. Il n’était pas extensible et ne pouvait donc offrir des services d’authentification pour les nouvelles technologies sans fils, cellulaire, VPN …

) et plus particulièrement offrir des

3- Intégration des services au niveau du système de tarification

Pour permettre la tarification de leurs services, les fournisseurs de services intègrent leurs applications au niveau du CCN qui sert d’interface pour le système de tarification prépayé. Le schéma suivant explique cette intégration.

prépayé. Le schéma suivant explique cette intégration. Figure 31 : Communication entre le fournisseur de services

Figure 31 : Communication entre le fournisseur de services et le système 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 système de service de message multimédia Institut de la Francophonie pour l’Informatique, 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,