Architecture du démonstrateur

Comme le montre la Figure 11.2, ce démonstrateur intervient au niveau des diérentes couches de visibilité : utilisateur, terminal, transport, contrôle et service. Il traite les aspects de signalisation, de gestion, de sécurité et de maintenance des informations dans les bases de connaissances.

Au niveau utilisateur, l'approche user-centric consiste à prendre en considération toutes les préférences de chaque utilisateur, ainsi que ses besoins et ses abonnements. Pour ce faire, un User Prole est créé et maintenue par chacune des bases de connais- sances : les Infoware qui sont associés aux plates-formes auxquelles l'utilisateur s'est abonné, et l'Infosphère qui est associée au terminal de ce dernier.

Au niveau du terminal, l'approche user-centric nécessite une plate-forme qui dé- nit des fonctionnalités de personnalisation et d'adaptation tout en tenant compte des préférences de l'utilisateur ainsi que son contexte ambiant. Pour ce faire, un Userware est intégré dans chaque terminal. Il agira comme un marché ouvert de services où les utilisateurs pourront vendre (ore) et/ou acheter (demande) les services, les uns des

Couche Utilisateur Infosphere O R A C LE Infoware O R A C LE Services de Base Plate-forme SAILFIN SIP Application Session Servlet HTTP Conteneur Web

Services du GlassFish J2EE

JSR JMX G LA S S F IS H … ... JMS Services de gestion des communautés Services de gestion du handover sémantique … JNDI JDBC … Events Manager Conteneur EJB _JPA Elément de services SEIB

Services Exposables Elément de services

Couche des Terminaux Couche de Transport Couche de Contrôle IMS

Couche Service S ec u ri tyw ar e Servlet SIP

Fig. 11.2: Architecture du Démonstrateur sur diérents niveaux de visibilité.

autres. De plus, il fournit l'ensemble des services nécessaires pour permettre un accès personnalisé aux services exposables demandés.

Au niveau de la couche de transport, l'approche user-centric nécessite une adap- tation dynamique et transparente des réseaux de transport suite à toute modication faite au niveau service. Pour ce faire, nous faisons appel à la virtualisation qui est introduite au niveau réseau par la solution VirtuOR [65]. Cette dernière propose l'in- tégration de plusieurs entités virtuelles sur une même machine physique. Ces entités virtuelles peuvent être des routeurs, des points d'accès virtuels, des serveurs SIP, etc. Ainsi, VirtuOR garantit l'accès à chaque service en lui associant un réseau virtuel spécique.

Au niveau de la couche de contrôle IMS, nous utilisons l'Open IMS de FOKUS [25]. Cette couche de contrôle est introduite entre les couches accès/transport d'une part et la couche de services de l'autre part. Son rôle principal est de contrôler les sessions ouvertes (établissement, modication et libération des sessions multimédias), en se basant sur le protocole de signalisation SIP. An de tenir compte de l'approche user-centric, et de maintenir une session continue et personnalisée, nous utilisons un protocole SIP+ qui est une version évoluée du protocole SIP.

Au niveau informationnel, nous ne pouvons pas nous contenter du HSS qui est introduit par le FOKUS Open IMS, puisqu'il constitue une simple base de données ayant un simple rôle de stockage d'informations. Or, l'approche user-centric nécessite d'avoir des bases de connaissances qui interviennent selon des inférences informationnelles an de tenir compte dynamiquement et en temps réel de l'information personnalisée et des ressources ambiantes. Dans notre démonstrateur, nous associons un Infoware à chaque plate-forme d'un fournisseur de services, et un Infosphère à chaque terminal d'un utilisateur donné. An de mettre en place nos bases de connaissances, nous avons eectué une migration de la base de données MySQL du HSS de FOKUS en une base de données Oracle 11g [49].

Au niveau de la sécurité, nous maintenons la sécurité de bout-en-bout en utilisant une plate-forme de services spécique, nommée Securityware. Cette dernière propose un ensemble de services de sécurité qui traitent l'authentication, l'autorisation, la fé- dération et l'audit. De plus, un Policy Agent est introduit dans chaque NGN/NGS Middleware et dans chaque terminal an que chaque plate-forme et chaque terminal puissent contacter le Securityware. Il faut noter que les services de sécurité sont déve- loppés de la même façon que les autres services de base et les services exposables.

Au niveau de la couche service, nous avons intégré notre NGN/NGS Middleware dans un serveur GlassFish [61]. Ce dernier est choisi puisqu'il constitue une plate- forme de services open source, standard, facilement utilisée pour construire et déployer des services de nouvelle génération (NGS), et idéale pour les architectures orientées services (SOA). De plus, GlassFish est le premier serveur à soutenir la technologie Java Enterprise Edition 6 qui fournit un accès rapide à une plate-forme sécurisée, portable et évolutive pour les services d'entreprise, et qui supporte diérentes APIs comme JMS (Java Message Service), JNDI (Java Naming and Directory Interface) et JDBC (Java Database Connectivity), etc. Au niveau de la signalisation, un serveur Sailn [63] est aussi intégré dans la plate-forme GlassFish. L'objectif de Sailn est de permettre au serveur GlassFish de répondre aux besoins de communication et des applications multimédias. De plus, il aide les fournisseurs de services et les opérateurs de réseau à accélérer l'adoption d'une architecture IMS, en leur orant une plate- forme standardisée qui simplie le développement des applications et des services à valeurs ajoutées. En eet, Sailn combine l'architecture SOA des entreprises et les capacités des services Web avec des HTTP Servlets et des SIP Servlets. Ces derniers sont à l'origine de nombreux services populaires, comme la voix sur IP, la messagerie instantanée, les conférences web, etc. De plus, ils jouent un rôle encore plus important dans la construction de la prochaine génération de services de télécommunications. Il faut noter que la plate-forme de services communique au niveau d'usage à l'aide du HTTP et au niveau de la signalisation à l'aide du SIP amélioré (SIP+).

Au sein du serveur GlassFish, nous avons validé nos propositions en développant chaque service de gestion et chaque service exposable sous forme d'un EJB (Enterprise Java Bean) indépendant [60]. Nous utilisons les EJBs car ils permettent la création de diérents composants autonomes et connectés à travers des liens lâches. En outre, les EJBs fournissent une transparence pour les transactions distribuées et aident à la création de solutions extensibles et à longue portée.

Conteneur Web (SEs Web) _J P A Serveur JMS Applications Convergentes JSR JNDI Conteneur EJB (SEs de Gestion) Conteneur EJB (SEs Exposables) Serveur Sailfin

Conteneur de Servlets Convergents

Servlet SIP/HTTP Requête SIP/HTTP SEs de gestion des VSCUs SEs de gestion du Handover Sémantique !"#$"%#&'()**+,*-& JDBC Infoware

Fig. 11.3: Aspects fonctionnels du démonstrateur au niveau service.

D'après la Figure 11.3, nous montrons les composants fonctionnels qui permettent d'intégrer notre NGN/NGS Middleware dans le serveur GlassFish/Sailn. Il y a un conteneur Web pour les services Web, un conteneur EJB pour les services exposables et un un conteneur EJB pour nos services de gestion, y compris ceux pour la gestion du handover sémantique et ceux pour la gestion par les communautés virtuelles. An de supporter une interaction asynchrone entre les composants de services développés, nous utilisons le serveur JMS intégré dans la plate-forme GlassFish. En eet, JMS est une API qui permet d'envoyer et de recevoir des messages de manière asynchrone entre des composants Java. An de relier les services développés aux données relationnelles stockés dans la base informationnelle, nous utilisons la technologie JPA (Java Persis- tence API ). Cette dernière s'appuie sur un ensemble de chiers qui correspondent à des classes d'entités de persistance, et qui contiennent des références vers les connecteurs JDBC à utiliser. Ainsi, le JDBC fournit les méthodes pour lancer les requêtes et les mises à jour pour les données dans la base. An de gérer les noms des les d'attente associées à chaque composant de service, nous utilisons le JNDI Directory. Ce dernier est un annuaire qui introduit des fonctionnalités de nommage permettant d'associer un nom à chaque service. Ainsi, chaque service développé utilise le JNDI pour se connec- ter à l'annuaire et trouver le service suivant dans la logique de services. Enn, pour que les services puissent répondre aux requêtes envoyées par l'utilisateur (des requêtes SIP pour la signalisation et le provisioning et des requêtes HTTP pour l'usage), nous utilisons le JSR Converged Applications. Ce dernier relie les conteneurs de services et les conteneurs des Servlets. En eet, les SIP Servlets sont intégrés dans Sailn pour former des interfaces pour les requêtes SIP, et les HTTP Servlets sont intégrés dans Sailn pour former des interfaces pour les requêtes HTTP.

Stateless Session Bean

Entity Bean Entity Manager

Message Driven Bean

Mapping O/R JPA

JMS Provider

EJB

Fig. 11.4: Structure d'un EJB.

Après avoir décrit le rôle de chacun des diérents composants fonctionnels utilisés pour l'intégration de nos composants de services, nous présentons dans la Figure 11.4 la structure fonctionnelle d'un EJB. En eet, chaque composant de service implémenté en EJB respecte la structure suivante :

 Message Driven Bean : il permet le traitement des messages asynchrones. Il reste à l'écoute de la le d'attente de JMS et réagit dès l'arrivée d'une requête. Ainsi, il extrait cette dernière de la le d'attente, en récupère le contenu puis exécute un traitement.

 Stateless Session Bean : il est un bean qui tient des conversations à un seul appel de méthodes avec des utilisateurs et avec d'autres EJBs. Il n'exige pas que l'état soit maintenu à travers les diérentes requêtes. Par conséquent, le Stateless Session Bean permet la réutilisation et la mutualisation du composant. Il faut noter que ces Stateless Session Beans sont utilisés an d'implémenter nos composants Stateless mais ils interfèrent en sessions Statefull.

 Entity Bean : il est un objet avec un domaine de persistance léger. Il représente un ou plusieurs tables dans notre base de données relationnelles.

 Entity Manager : il est utilisé an de créer et d'enlever des entités persistantes, de trouver ces entités par leurs clés primaires, et d'envoyer des requêtes à la base de données an de s'informer sur ces entités.