Dans la plate-forme, nous avons adopté une architecture Client/Serveur afin de rendre accessibles les applications aux utilisateurs mobiles. Pour la conception du serveur, la solution logicielle est basée sur un serveur Tomcat et un conteneur de servlets java. Ecrit en Java, Tomcat nécessite pour pouvoir fonctionner la présence d’une machine virtuelle Java, et plus précisément du SDK - Sun Developpement Kit - complet. A ce titre, Tomcat est totalement portable et peut être, très aisément mis en œuvre sur un grand choix de plates-formes, tels que Unix, Linux ou Windows. Il peut fonctionner seul ou en amont d’un serveur Apache ou Microsoft.
Cette plate-forme serveur permet une grande évolutivité dans le panel des services par la facilité de développement, héritée du langage Java, des servlets et Java Server Page. A partir de la version 1.4, Java intègre directement la librairie JSSE. Celle-ci permet la gestion des connexions sécurisées par SSL. En outre, l’installation d’un serveur Tomcat est des plus simples. Robuste et fiable, il fournit un service HTML de base, et reste résolument dédié en priorité aux servlets Java. Les applications peuvent être installées manuellement ou automatiquement (fichiers WAR).
Une autre solution consisterait à utiliser le couple Apache - serveur HTML. Dans ce cas de figure, le serveur Apache sert de portail d’accès. L’interconnexion entre Apache et Tomcat s’effectue au moyen d’un connecteur logiciel JK2. Celui-ci permet à Apache de considérer Tomcat comme un de ses modules. L’intérêt de cette architecture est la grande robustesse grâce à la possibilité de faire du partage de charge automatique. Cependant, le connecteur JK2 est toujours en cours de développement. De plus, il dispose d’un en-
semble de fonctionnalités restreintes en terme d’échange d’information intra plate-forme. Ce défaut est malheureusement rédhibitoire pour le développement du serveur Ambience.
Fig. 5.4 – Architecture Client/Serveur
5.4.1
Les services
Les services offerts par le serveur sont développés sous forme de modules indépendants (classes java) et offrent aux clients les possibilités de communication suivantes :
– authentification vocale du client,
– localisation du client (ou d’autres clients connectés au réseau) par affichage d’une carte du site et positionnement,
– envoi et réception de messages courts, – consultation de documents.
5.4.2
La sécurisation de l’échange des données
La sécurité des communications est assurée par l’utilisation de SSL et des certificats X- 509 en une authentification mutuelle client - serveur et en cryptant les données échangées. Cette authentification sécurisée est gérée par Tomcat. L’accès aux services offerts par le serveur est de plus soumis à la vérification de l’identité et de l’empreinte vocale.
au travers d’une base de données MySQL. Le système de gestion de base de données MySQL est disponible pour les principaux systèmes d’exploitation et s’intègre parfai- tement à une plate-forme serveur Apache Tomcat. Cette base de données regroupe les informations principales suivantes :
– La liste des participants,
– Les paramètres vocaux des participants (pour l’authentification), – La liste des participants présents sur le site de la conférence, – La position géographique des participants,
– L’inscription des participants aux conférences, – La liste des documents consultables.
La gestion des données propres à une conférence est réalisée à travers l’interface Chair- man, développée en marge du serveur. La gestion technique de la base de données s’effectue grâce à l’interface de type Web fournie par PHPMyAdmin (celle-ci nécessite la présence d’un serveur de type Apache).
Fig. 5.5 – Architecture du serveur
5.4.3
Le Client
Dans la plate-forme, la réalisation du client a été développée par CCC. Les iPAQ où sont implantés les clients sont équipés du système d’exploitation Familiar Linux et l’environnement d’exécution Java Blackdown. L’application Client est compatible avec
l’édition Java 1.3.1. Tous les échanges de messages entre les clients et le serveur sont basés sur XML, qui peut être facilement étendu pour des besoins futurs. Le choix des standards ouverts, tels que Java et XML, donne l’avantage de la flexibilité et le support d’une grande variété d’équipements et environnements client.
5.4.4
L’interface utilisateur graphique de l’iPAQ (Graphical User
Interface)
Elle est basée sur Java et permet à l’utilisateur de choisir et de commander les ap- plications disponibles. Elle fournit une interface utilisateur simple qui permet d’alterner entre un certain nombre d’onglets, dont :
Le plan : carte d’affichage du plan local avec localisation de l’utilisateur mobile, Information : affiche les informations d’état du système à un moment donné,
Find a meeting : fournit au client la localisation géographique de la salle de conférence, Find a person : fournit au client la localisation géographique d’une personne partici-
pant à la même conférence,
Read a document : offre la possibilité de consulter des documents numériques corres- pondants à la conférence,
Send a message : permet au client d’envoyer un message à une personne ou à un groupe, Update : permet la mise à jour régulière des informations disponibles pour le client.
5.4.5
Principe de fonctionnement général entre le client et le ser-
veur
A la première connexion d’un client, le serveur Tomcat réalise l’authentification SSL. Une fois celle-ci passée, la connexion sécurisée est établie. La servlet Ambience est ins- tanciée. Le nom et le prénom du détenteur du client sont extraits du certificat SSL et comparés à la liste des participants. Dans le cas d’une concordance, la servlet Ambience autorise la poursuite de la connexion et une instance des classes Adapter et de celles correspondant à chaque service sont crées.
Le client envoie au serveur un premier message ’client update’. le serveur répond par un message ’server challenge’ demandant l’identifiant vocal du client. Celui-ci renvoie une empreinte vocale, encodée en base64, et encapsulée dans un message ’client bioauth’. L’empreinte vocale est comparée à celle présente dans la base de données au moyen de la routine développée par la société Thalès. Si le client est enfin authentifié, le serveur renvoi un ’server update’ contenant toutes les informations qui le concernent : liste des parti- cipants, liste des documents disponibles, et messages (éventuellement). Une fois passée toute l’étape d’authentification, les messages échangés sont de deux types :
– Les messages provoqués par une demande de service de la part du client. Il s’agit de l’envoi d’un message à un autre participant, d’une demande de localisation, de la lecture d’un document.
– Les messages automatiques. Ce sont les messages ’update’ et ’beacon’.
Les messages ’update’ sont régulièrement envoyés par le client au serveur. Celui-ci renvoie toutes les modifications intervenues dans la listes des clients, des documents et les nouveaux messages, depuis le dernier update. Les messages ’beacon’ renvoient au serveur une liste des balises détectées par le Zigbee (paramètres : identifiant, puissance, distance). Le serveur récupère ces données pour calculer la position du client. Tout client déconnecté du réseau doit repasser par l’étape de l’authentification.