Vous êtes sur la page 1sur 38

Projet ANR-Verso 2008 UBIS

User centric: uBiquit et Intgration de Services

SP6 Dmonstrateur
Lot 6.1 Architecture du dmonstrateur

Auteurs :

R. NASSAR et N. SIMONI

Participants :

Partenaires

Version :

V2

Date :

27/07/2010

1 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Historique du Document

Version

Date

Modifications

V1

6/2010

R. NASSAR

V2

7/2010

N. SIMONI

Mots cls
User Centric, Userware, MAEMO, IMS, NGN/NGS Middleware, GlassFish, Sailfin, SIP +, Infoware/Infosphere, Oracle,
Open SSO.

2 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Table des matires


1.

INTRODUCTION ...................................................................................................................................................... 5

2.

USERWARE/MAEMO .............................................................................................................................................. 7

2.1.

Besoins..................................................................................................................................................................... 7

2.2.

Implmentation : Existant ......................................................................................................................................... 9

2.3.

Implmentation : UBIS............................................................................................................................................ 10

2.4.

Annexe : Autres plateformes mobiles ..................................................................................................................... 14

2.4.1
2.4.2
2.4.3
2.4.4
2.4.5

Java ME .......................................................................................................................................................... 15
Android ........................................................................................................................................................... 16
Windows Mobiles ........................................................................................................................................... 17
Symbian .......................................................................................................................................................... 18
iPhone OS ....................................................................................................................................................... 19

3.

IMS ......................................................................................................................................................................... 21

3.1.

Besoins................................................................................................................................................................... 21

3.2.

Implmentation : Existant ....................................................................................................................................... 22

3.3.

Implmentation : UBIS............................................................................................................................................ 23

4.

PLAN SERVICE ..................................................................................................................................................... 24

4.1.

Besoins au niveau services .................................................................................................................................... 24

4.2.

Implmentation : Existant ....................................................................................................................................... 25

4.3.

Implmentation : UBIS............................................................................................................................................ 26

4.3.1
4.3.2

Implmentation du NGN/NGS Middleware ................................................................................................... 26


Adaptation la signalisation SIP : SIP + ........................................................................................................ 28

5.

BASE DE CONNAISSANCES ............................................................................................................................... 31

5.1.

Besoins au niveau de la base de donnes ............................................................................................................. 31

5.2.

Implmentation : Existant ....................................................................................................................................... 31

5.3.

Implmentation : UBIS............................................................................................................................................ 32

6.

SECURITE ............................................................................................................................................................. 35

6.1.

Besoin .................................................................................................................................................................... 35

6.2.

Implmentation : Existant ....................................................................................................................................... 35

6.3.

Implmentation : Choix dans UBIS ......................................................................................................................... 36

7.

CONCLUSION ....................................................................................................................................................... 38

3 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Table des Illustrations


Figure 1: Schma de principe ............................................................................................................................................. 5
Figure 2: Package UBIS sur multiplateformes..................................................................................................................... 7
Figure 3: N900 .................................................................................................................................................................... 8
Figure 4: MAEMO Architecture ........................................................................................................................................... 9
Figure 5: Package UBIS - Userware et Ambient Grid ....................................................................................................... 10
Figure 6: Modle fonctionnel global du Userware ............................................................................................................. 11
Figure 7: Architecture fonctionnelle de l'Active Profile....................................................................................................... 12
Figure 8: Architecture fonctionnelle de l'Ambient Grid....................................................................................................... 13
Figure 9: Architecture fonctionnelle de l'Access Grid ........................................................................................................ 14
Figure 10: Java ME dans lcosystme java ..................................................................................................................... 15
Figure 11: Java ME Architecture ....................................................................................................................................... 15
Figure 12: Listes des principales JSRs ............................................................................................................................. 16
Figure 13: Diagramme darchitecture Android ................................................................................................................... 17
Figure 14: Principales fonctions de Windows Mobile ........................................................................................................ 18
Figure 15: Diagramme darchitecture Symbian ................................................................................................................. 19
Figure 16: Modle en couches de lOS iPhone ................................................................................................................. 20
Figure 17: Spcification 3GPP, Architecture IMS .............................................................................................................. 21
Figure 18: Architecture globale dIMS ............................................................................................................................... 22
Figure 19: IMS et le Fokus IMS ......................................................................................................................................... 22
Figure 20: NGN/NGS Middleware ..................................................................................................................................... 24
Figure 21: NGN/NGS Middleware dans GlassFish/Sailfin ................................................................................................. 25
Figure 22: Comparaison GlassFish V2.x/V3 ..................................................................................................................... 27
Figure 23: Vision globale de SIP+ ..................................................................................................................................... 29
Figure 24: QoS description of service component............................................................................................................. 29
Figure 25: Le modle de QoS description dans SIP+ ....................................................................................................... 30
Figure 26: FHoSS ............................................................................................................................................................. 31
Figure 27: Structure de la base de donnes FHoSS (version FOKUS)............................................................................. 32
Figure 28: Structure de la base de donnes FHoSS (version UBIS)................................................................................. 33
Figure 29: HSS +............................................................................................................................................................... 34
Figure 30: Authentification unique du user avec OpenSSO .............................................................................................. 36
Figure 31: Cas dusage : Extension OpenSSO ........................................................................................................... 37

4 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

1. Introduction
Ce SP vise fournir une description du dmonstrateur UBIS. Ce dernier a pour but la mise
en uvre de lensemble des propositions (du SP2 au SP5) et des tests des cas dusages (SP1) en
faisant ressortir les innovations des middlewares.
Le document actuel, livrable SP6.1, se focalise sur les choix faits pour le dmonstrateur et la
description de larchitecture de ce dit dmonstrateur. Cette architecture est rpartie sur plusieurs
couches comme on le voit dans la Erreur ! Source du renvoi introuvable.:

Figure 1: Schma de principe

Au niveau Utilisateur , suite lapproche user-centric que nous adoptons, lutilisateur


est au centre et tous les oprateurs et les fournisseurs doivent interagir et sadapter de
manire assurer ses besoins et ses prfrences. Pour atteindre ce but, chaque
utilisateur doit prciser ses exigences et ses prfrences dans un profil dutilisateur
qui sera stock dans la base de connaissances.

Au niveau Terminaux , Business Anywhere dveloppera une architecture Userware


qui permettra lintgration entre lusage et la personnalisation de services. Cet Userware
fournit les fonctionnalits et les capacits ncessaires pour permettre une
personnalisation, et un accs orient usage et transparent de bout-en-bout aux services
voulus. Au niveau de limplmentation de cette architecture, la plateforme MAEMO de
NOKIA est retenue, entre autre pour son assise sur lOS Linux/Debian, permettant une
plus grande souplesse multiplateformes et terminal.

5 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Au niveau Rseau de transport , nous utilisons la solution VIRTUOR qui


commercialise une machine physique acceptant de nombreuses entits virtuelles de
diffrents types : routeurs IPv4 et IPv6, point daccs virtuel, serveur SIP, etc. Cette
solution permet la mise en place de plusieurs rseaux virtuels, spcifiques aux
applications supportes, qui sont vus de la part des utilisateurs comme des rseaux
physiques distincts.
Au niveau Cur IMS , le FOKUS OPEN IMS sera utilis comme plan de contrle pour
ce dmonstrateur.
Au niveau Service , une architecture de service, appele NGN/NGS Middleware, est
mise en oeuvre par TELECOM ParisTech afin de tenir compte des dfis au niveau NGN
(mobilit, htrognit et aspect user-centric) et afin dintroduire une nouvelle vision de
services nomme NGS (Next Generation Services). De point de vue implmentation, Sun
mettra disposition du projet, un serveur d'application Java, nomm GlassFish auquel
sajoute un serveur pour la signalisation, nomm Sailfin. Cela permettra de dvelopper la
couche Telco ncessaire UBIS. Au niveau signalisation, une version SIP amliore est
propose. Nous la nommons SIP +.
Au niveau base de connaissance , UBIS prconise linfrence informationnelle. Deux
bases dinformation, nommes respectivement Infoware (cot fournisseur / Infosphere
(cot utilisateur). Ces bases de connaissances seront implmentes dans une base
Oracle.
Au niveau scurit , une approche OpenSSO a t retenue dans un premier temps,
afin de proposer la solution dauthentification unique lutilisateur. Des volutions sont
ltude pour couvrir les besoins de mobilit dUBIS, en particulier la mobilit de
lutilisateur.

Dans la suite de ce document, nous allons prsenter la partie Userware/MAEMO (2), puis la
couche IMS (3), suivie de la partie Serviceware/GlassFish-Sailfin-SIP + (4). Ensuite, nous
introduisons la partie des bases de connaissances Infoware/Infosphere (5), et nous terminons par
la scurit (6) et la conclusion.

6 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

2. Userware/MAEMO
2.1. Besoins
Un des buts essentiels de notre projet UBIS est dassurer nimporte quel service nimporte
quel utilisateur. En effet, chaque utilisateur, indpendamment de ses capacits particulires, ses
handicaps ou ses comptences techniques, doit tre capable d'utiliser et de personnaliser ses
services. Pour y parvenir, nous devons fournir tous les moyens ncessaires afin dassurer tous
les utilisateurs un accs simplifi aux services tout en tenant compte de leurs prfrences et de
leurs besoins.
Pour cette raison, dans notre dmonstrateur, nous proposons un Userware qui est considr
comme une plateforme qui soutient des services futurs. Il dfinit des fonctionnalits de
personnalisation et d'adaptation tout en tenant compte des prfrences de l'utilisateur ainsi que le
contexte ambiant. Dans la finalit, Il agira comme un march ouvert de services o les utilisateurs
pourront vendre (offre) et/ou acheter (demande) les services, les uns des autres. De plus,
lUserware rassemble lensemble de loutillage de lutilisateur pour grer ses sessions, ses
logiques de service en fonction de ses prfrences et de sa mobilit. Cette gestion sentend sans
coupure et sans couture seamless Userware afin dassurer la continuit du service global.
La portabilit des terminaux est lun des verrous, essentiel que nous voulons lever. Ce verrou
est aussi particulirement crucial dans le cadre du projet UBIS qui tudie la faisabilit pratique de
la mobilit sans couture des sessions et des services dans un environnement physique
htrogne. De nombreux hardwares, supportant eux-mmes de nombreuses versions de
firmware et d'OS parfois incompatibles entre elles, sont distribus sur le march, embarqus dans
les tlphones mobiles, les PDA ou les ordinateurs. Cette situation reflte les conditions hrites
de la construction de loffre des terminaux au cours de la courte histoire des tlcommunications et
fait de luniformisation de lexprience utilisateur dans un univers de rseaux ambiants ( context
aware ) supportant la composition dynamique de services un vritable challenge technologique.
Toutefois, on assiste des tentatives duniformisation soit verticales (Microsoft, Apple, Nokia) soit
transversales (Google Apps, Adobe AIR+FLEX, etc.) touchant lensemble des terminaux fixes et
mobiles, mais toujours dans une approche client/serveur plus ou moins proche des architectures
classiques orientes services et du WEB 2 ou 3.

Figure 2: Package UBIS sur multiplateformes

La problmatique pose par UBIS nest donc absolument pas adresse et encore moins
rsolue, mme si lvolution des offres dans ce sens est nettement perceptible et constitue un

7 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

encouragement. Pour parvenir son but, UBIS devra tre capable de proposer un modle
dabstraction du terminal, de son environnement et de la composition de service capable de
produire une exprience utilisateur uniforme et continue quelle que soit la plateforme support. Pour
cette raison, nous cherchons dans ce premier dmonstrateur crer un modle dinstanciation
multiplateforme pour lUserware. En effet, nous avons deux cas de figures : les tlphones mobiles
et les terminaux fonction PC. Au niveau des terminaux, nous cherchons implmenter notre
modle de Userware, indpendamment des plateformes sous-jacentes (Figure 2), tout en tenant
compte de notre volont datteindre lexcution dynamique des composants de services, bien que
cet objectif est en soit un challenge dintgration dans les terminaux mobiles, car ce mode
fonctionnement est une ralit dans les architecture PC, mais loin dtre une ralit des systmes
et framework dvelopper par les industriels des terminaux mobiles. Dans ce march de ldition
des framework/systme mobile le dveloppement de client lourd est la rgle.

Figure 3: N900

Aprs avoir tudi les avantages et les dsavantages des diffrents systmes dexploitation
des Smartphones (voir section 1.4 Annexe), il nous semble que le Nokia N900 (Figure 3),
utilisant la technologie MAEMO, est le plus proche de nos besoins. En effet, MAEMO sapplique
sur un des systmes dexploitation les plus souples qui est le Linux/Debian. Suivant les
informations fournies, cette plateforme nous permet de nous approcher de larchitecture cible
Userware , en termes de souplesse et de dynamicit de systme Userware. De plus, laide de
MAEMO, nous pourrons accder un certain nombre doutils dj existants dans le monde Linux,
et nous pourrons assurer la portabilit de notre package UBIS entre diffrents dispositifs mobiles
ou PC. En outre, la ressente fusion des plateformes MAEMO Nokia et MOBLIN Intel, pour la
plateforme Meego, ouvre des opportunits intressantes de portabilit et de performance de notre
dmonstrateur.
En conclusion, nous avons choisi le N900/MAEMO comme plateforme dimplmentation de
notre package UBIS contenant notre Userware. Mais, la dynamicit du secteur des constructeurs
de tlphones mobiles peut nous prsager dautres terminaux dici la fin du projet UBIS. En
loccurrence, nous porterons un effort sur limplmentation du Dmonstrateur 1 sur un dispositif
mobile architecture PC.

8 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

2.2. Implmentation : Existant


MAEMO est un systme d'exploitation avanc bas sur Linux. Comme il s'agit d'une plateforme ouverte, il permet la communaut MAEMO de modifier et de dvelopper librement des
logiciels dans le cadre d'un objectif commun: apporter une valeur ajoute tous les utilisateurs
MAEMO. Cette plateforme ouverte pourra agir sur des dispositifs ouverts. De plus, elle est base
sur des technologies bien connues qui sont largement utiliss dans la communaut des logiciels
libres. Au niveau des langages de dveloppements, MAEMO est bas sur le langage C qui est un
langage natif coupl ainsi que le langage C++. De plus, il utilise le langage de programmation
Python qui est dot dun typage dynamique fort et dune gestion automatique de la mmoire. Ce
langage est plac sous une licence libre et fonctionne sur la plupart des plateformes informatiques.
En outre, un framework Qt orient objet est intgr dans MAEMO depuis le rachat de TrollTech
par Nokia. Elle offre des composants dinterface graphique (widgets), daccs aux donns, de
connexions rseaux, etc. Qt permet aussi la portabilit des applications qui nutilisent que ses
composants par simple recompilation du code source. De plus, le fait dtre une bibliothque
logicielle multiplateforme attire un grand nombre de personnes qui ont donc loccasion de diffuser
leurs programmes sur les principaux OS existants.
Ayant dcrit les principaux technologies supportes par MAEMO, nous allons dcrire dans la
suite de cette sous-section larchitecture existante de MAEMO (Figure 4) :
Hildon
Matchbox
GTK+

D-Bus
X Window System
Debian
OS GNU/Linux

Figure 4: MAEMO Architecture

X Window System ou X11 ou simplement X : cest une interface graphique de type


fentre qui gre linteraction homme-machine.
D-Bus : Cest un bus logiciel IPC permettant de communiquer entre processus. Il est mis
en uvre en tant que dmon (daemon). Les utilisateurs peuvent en lancer plusieurs
instances, chacune tant appele un canal (channel). Gnralement, il y a un canal
privilgi, nomm le canal systme (system channel), et des instances prives pour
chaque utilisateur connect.
GTK+ : Cest un ensemble de bibliothques logicielles, cest--dire un ensemble de
fonctions informatiques permettant de raliser des interfaces graphiques. Cest un projet
libre multiplateforme.
Matchbox : Cest un gestionnaire de fentres (Window Manager) libre pour XWindow
spcialement conu pour les systmes embarqus.
Hidon : Cest un framework graphique orient widget (surcouche de GTK+).

En outre, larchitecture MAEMO comporte dautres fonctionnalits qui napparaissent pas


dans le schma ci-dessus :

Busybox : Cest un couteau suisse optimis intgrant les principales commandes Shell
UNIX standard.
Package Manager : Cest un gestionnaire de packages .deb.
Gstreamer : Cest un player A/V multimedia

9 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

RTCom : Cest un sous-systme fournissant des services et des applications pour les
communications internet temps-rel (VoIP, Instant Messaging).
Location framework : Ceux sont des services de localisation GPS.
Connectivity framework : Ceux sont des services de connectivit WLAN et local
(Bluetooth, UPnP).

2.3. Implmentation : UBIS


Parmi les points durs qui sont traits dans notre dmonstrateur, larchitecture du Userware,
la fois serveur et compositeur de services dans des environnements pouvant tre contraints en
ressources de calcul et nergtiques, constitue un principal rsultat, tangible via ce premier
dmonstrateur, du projet UBIS.
Dans cette sous-section, nous dcrivons larchitecture du package UBIS intgr, comme on
le voit dans la Figure 5, dans nimporte quelle plateformes mobiles ou PC. Cette architecture en
blocs fonctionnels est constitue dun Ambient Grid qui interagit avec un Userware. Ce dernier est
constitu dun Active Profile et dun Access Grid.

Figure 5: Package UBIS - Userware et Ambient Grid

Ayant prcis les blocs architecturaux essentiels de notre Userware, nous dcrivons dans la
le modle fonctionnel global de ce Userware. Ce modle explique clairement comment on
peut tenir compte des prfrences de lutilisateur et de ce contexte user-centric. En effet, ce
Userware permet dassurer la dtection et la gestion dynamique des communauts auxquelles
lutilisateur peut potentiellement adhrer et par suite de ragir aux requtes de lutilisateur en
crant une organisation virtuelle qui accomplie une session particulire de services (quipements,
rseaux, services applicatifs).

Figure 6

10 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 6: Modle fonctionnel global du Userware

Dans la suite de cette sous-section, nous allons expliquer en dtails le fonctionnement de


notre Userware tout en prcisant la contribution de chacun des blocs fonctionnels. En effet, ce
fonctionnement est rparti en deux phases :

Phase 1 : Elle est excute avant la requte de lutilisateur. Elle est base sur la cration
de lActive Profile grce la consolidation des Resource Usage Profiles, et sur la
dcouverte des ressources ambiantes afin de mettre en place les communauts
dutilisateurs, nommes VUC (Virtual User Community).
Phase 2 : Elle est excute pour une requte active. Elle est base sur la cration du
Request Profile partir dune analyse de la requte de lutilisateur, et sur la construction
de lorganisation virtuelle, nomme VPUN (Virtual Private User Network), laide de
lAccess Grid. Par la suite, il y aura lactivation de ce VPUN et lutilisateur obtiendra son
service demand.

Comme nous lavons dj prcis, la premire tape du fonctionnement de notre Userware


est la cration de lActive Profile. Ce profil permet didentifier lensemble des ressources
ambiantes ligibles, cest--dire pouvant tre utilises par lutilisateur. Les ressources retenues
sont le rsultat dun filtrage via les prfrences de lutilisateur et ses droits daccs. Daprs la
Figure 7, lUserware cre lActive Profile en dtectant les ressources ambiantes (services, rseaux
et terminaux) entourant lutilisateur. Cette dtection est en ralit une sollicitation des diffrents
Resource Usage Profiles (Service Usage Profile, Network Usage Profile et Terminal Usage
Profile). Dans le cadre de ce dmonstrateur et afin de faciliter limplmentation, nous considrons
que lUserware dtecte, au niveau des terminaux, seulement le profil dusage de son terminal. Ce
profil est considr statique. Aprs avoir sollicit les diffrents Resource Usage Profiles, le
Userware applique comme filtre lUser Profile afin de tenir compte des prfrences de lutilisateur.
Ces prfrences sont prcises dans cet User Profile par rapport au lieu et la date o se trouve
lutilisateur. Suite ce filtre appliqu sur les profils dusage des ressources, lActive Profile est ainsi
form et il comporte lensemble des ressources ambiantes entourant lutilisateur et respectant ses
prfrences.

11 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 7: Architecture fonctionnelle de l'Active Profile

La deuxime tape de ce modle fonctionnel est ralise par lAmbient Grid (Figure 8). Il
reoit, daprs lActive Profile, les ressources ambiantes filtres par les prfrences de lutilisateur.
Il fait ainsi le matching de profiles afin didentifier des triplets (terminal / rseau / service)
rpondant au mieux aux prfrences de lutilisateur. Et ainsi, il cre des communauts virtuelles
dutilisateurs (au sens fournisseurs de service), nommes VUCs. Chaque VUC est une
communaut dutilisateurs offrant des ressources identiques. La liste de VUCs cres par
lAmbient Grid est maintenue dynamiquement. Par suite, un mme service pourra tre offert par
plusieurs utilisateurs appartenant la mme communaut. Ainsi, lutilisation des VUCs permet une
gestion plus efficace des ressources au sein de chaque communaut. Par exemple, dans le cas
dune dfaillance, un service S0 offert par un utilisateur U3 pourra tre remplac par le mme
service puisque ce dernier est partag avec un autre utilisateur U4 au sein dun mme VUC. En
outre, les utilisateurs dun mme VUC restent conscients de la prsence des uns des autres, en
envoyant et recevant des annonces de services. Quand lUserware dun utilisateur reoit une
annonce, il conserve linformation dans sa bade de connaissances pour un futur usage. Par
consquent, on peut considrer cette grille ambiante comme une table de routage dynamique qui
contient des informations sur les services et sur les utilisateurs offrants ces services.

12 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 8: Architecture fonctionnelle de l'Ambient Grid

Une fois que les VUCs sont crs par lAmbiant Grid, lUserware passe la troisime tape
qui est base sur lAccess Grid et sur un Request Profile (Figure 9). LAccess Grid permet
dapparier la demande utilisateur avec les offres de services disponibles afin de dfinir le rseau
de fournisseurs en charge dlaborer le service expos. Cette opration est ralise partir de la
liste des VUCs issus du service de calculs ambiants, et dune liste de services dcouverts
dynamiquement. La sortie de cet Access Grid est un VPUN qui est construit instantanment afin
de rpondre la requte de lutilisateur.
En effet, quand lUserware reoit une requte de la part de lutilisateur, il lanalyse et met en
place un Request Profile format comprhensible par lAccess Grid. Une fois ce dernier est
initialis et rempli avec les listes doffreurs appropris (les VUCs forms par lAmbient Grid), le
Userware dterminera le VPUN optimal qui satisfit les requtes de cet utilisateur. Les critres de
choix sont les exigences prcises par lutilisateur dans ses profiles. En effet, le service de bouten-bout pourra tre fournit par plusieurs utilisateurs. Chacun dentre eux participe la construction
de ce service de bout-en-bout, en offrant un ou plusieurs lments de ce service global. Les
utilisateurs dun VPUN form peuvent appartenir des VUCs diffrents et/ou aux mmes VUCs.

13 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 9: Architecture fonctionnelle de l'Access Grid

Enfin, les avantages de cette approche utilise pour ce Userware apparaissent sur le plan
fonctionnel ainsi que le plan de gestion :

Du point de vue fonctionnel, la dtection des VUCs potentiels assure lUserware une
base de connaissances mise jour dynamiquement. Une fois la requte de lutilisateur
est reue, lUserware sollicite sa base de connaissances et choisit les VUCs qui offrent le
ou les services participant(s) lexcution du service de bout-en-bout demand.
Evidemment, le temps de traitement pour trouver les services et pour assurer la
personnalisation est largement rduit si nous le comparons celui dune approche surdemande.
Du point de vue de gestion, cette approche permet la distribution de la gestion de bouten-bout entre diffrents VUCs qui forment le VPUN global. Dans cette configuration,
chaque VUC gre ses services offerts (ceux qui sont offerts par les utilisateurs de ce
VUC). En effet, lutilisation de plusieurs VUCs pour la gestion assure une possibilit de
gestion spare pour chaque lment de service, et plus doptions pour maintenir la QoS
globale de bout-en-bout.

2.4. Annexe : Autres plateformes mobiles


Le but de cette partie est de prsenter les principales plateformes mobiles du march dun
point de vue technologique. Cela nous a aids la slection de la plateforme de dveloppement
retenue pour le dmonstrateur Ubis. A ce titre, nous nous proposons dtudier les plateformes
suivantes : Java ME, Android, Windows Mobile, Symbian et iPhone.

14 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

2.4.1 Java ME
Java ME signifie Java Micro Edition . Cette plateforme de dveloppement java a t
dfinie par Sun Microsystems pour cibler les terminaux mobiles et autres systmes embarqus.
Larchitecture modulaire de Java ME a t pense pour rpondre diffrents segments du march
comme latteste le diagramme de la Figure 10.

Figure 10: Java ME dans lcosystme java

Globalement une implmentation type est constitue dune configuration, dun profile et
dextensions (ou librairies) additionnelles. Larchitecture qui nous intresse est celle dploye dans
la tlphonie mobile (Figure 11). Elle est constitue de la configuration dnomme CLDC, dun
profile dnomm MIDP et de librairies tendues dnommes JSR.

Figure 11: Java ME Architecture

En effet, le CLDC inclut lenvironnement dexcution java (KVM - machine virtuelle) ainsi
quun sous-ensemble des classes java standard. Le MIDP dfinit des APIs ddis aux terminaux
mobiles parmi lesquelles : connectivit rseau (http, tcp/ip), interface graphique, stockage en
mmoire persistante (RMS) et vnement Push (SMS, NFC, Socket, Bluetooth). Les JSRs sont
des librairies java tendues qui offrent des fonctions supplmentaires. Les plus importantes pour le
projet UBIS sont listes dans la table de la Figure 12:

15 / 38

Projet ANR Verso 2008 - UBIS

Numro
de JSR
30
75

SP6 Lot 6.1 Architecture du dmonstrateur

Nom

Description

CLDC
File Connection and PIM

Accs au systme de fichier et donnes PIM (Contacts,


ToDo, Events)

82
118
120
135

Bluetooth
MIDP 2.0
Wireless Messaging API (WMA)
Mobile Media API (MMAPI)

172
177
179
180
185

Web Services
Security and Trust Services
Location
SIP
Java Technology for the Wireless
Industry (JWTI)
Content Handler API
Advanced Multimedia Supplements
Mobile Service Architecture
Mobile Service Architecture 2
Contactless API
IMS Services

211
234
248
249
257
281

Permet denvoyer des SMS


Player audio/video (bas sur des flux rtsp)
Accs basique Camra (APN)
Librairie SOAP + Parser XML
Accs carte SIM + API de cryptographie
GPS
Dfinit un ensemble de JSRs obligatoires parmi lesquelles :
JSR 118 (MIDP2), JSR30 (CLDC) et JSR120 (WMA)
Lancement dapplication Java partir dune autre
Fonctions multimedia avances
Dfinit un ensemble de JSRs obligatoires
Dfinit un ensemble de JSRs obligatoires
Accs au chip NFC

Figure 12: Listes des principales JSRs

Aujourdhui 99% des terminaux mobiles sont compatibles Java ME. On notera deux
exceptions : liPhone et les plateformes Android.
La plateforme rpondant au besoin Ubis requiert les JSR suivantes : JSR 180 (SIP), JSR
179 (golocalisation), JSR 248 (MSA), JSR 205 (MMS), JSR 184 (3D graphics), JSR 135/234
(multimedia + camera) et JSR 75 (Filesystem + PIM).
En standard, la plateforme MIDP 2.0 offre les librairies suivantes : interface utilisateur (haut
niveau / bas niveau), connectivit rseau IP / Datagram / HTTP / HTTPS, stockage mmoire locale
(RMS), et la tlphonie (numrotation dappel).
Au niveau des restrictions, cette plateforme mobile comporte un certain nombre de JSRs
optionnelles et ne permet pas les appels natifs/systme. De plus, cest impossible de lancer une
application en tche de fond et de lancer un service J2ME au boot du tlphone. En outre, le
lancement dune application partir dune autre via la JSR211 (except navigateur web) est
optionnel. Et enfin, les donnes du calendrier sont accessibles de manire optionnelle et sont
limits via la JSR 75.

2.4.2 Android
Android est une plateforme logicielle ouverte pour terminaux mobiles incluant un OS
Linux 2.6, un middleware et des applications. Google fournit un kit de dveloppement (SDK)
incluant des outils et les librairies (API) ncessaires pour le dveloppement dapplications. La
dernire version est la version 1.5 (nom de code CupCake). Visant sexcuter sur cette
plateforme, toutes les applications sont crites en java. Android inclut un grand nombre de classes
identiques aux classes J2SE de SUN. Il faut noter que depuis la version 1.5, il est possible de
dvelopper des modules en langage natif C accds depuis le monde java par le NDK (adaptation
de JNI par Google). Cela ouvre des perspectives pour rutiliser des briques open sources (par
exemple une stack SIP). Le diagramme de la Figure 13 prsente les principaux composants de la
plateforme :

16 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 13: Diagramme darchitecture Android

En standard, la plateforme 1.5 offre les librairies (ou services) suivantes : interface
utilisateur (haut niveau / bas niveau), connectivit rseau IP / Datagram / HTTP / HTTPS, mmoire
persistante (filesystem, SD et SQL Lite), tlphonie, messagerie, golocalisation, 3D, scurit,
appel natif, player multimdia (3gpp, mpeg-4, aac et mp3) supportant RTSP depuis Android 1.5
(Cupcake), accs camra, et linvocation dapplications par rsolution dURI (approche SOA).
Au niveau des restrictions, cette plateforme mobile ne permet pas laccs SIM ni laccs
lAPI Calendrier . Elle ne possde aucune API de web services (except un parser XML). De
plus, il y a une absence de stack SIP. En outre, sur le march franais, il y a peu de mobile
Android prsent.

2.4.3 Windows Mobiles


Windows Mobile est la plateforme de Microsoft dcline pour les Smartphones et PDAs. Les
versions chronologiquement dveloppes sont : WM 2003, WM 5.0 (2005), WM 6.0 (2007) et WM
6.5 (2009). Cette plateforme permet de dvelopper des applications natives (C++) et des
applications interprtes (C# et Visual Basic.NET). Il est ncessaire dutiliser lIDE Visual Studio
avec le SDK Windows Mobile. Le diagramme de la Figure 14 prsente les principaux composants
de la plateforme:

17 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 14: Principales fonctions de Windows Mobile

En standard, la plateforme offre les librairies (ou services) suivantes : interface utilisateur
(haut niveau / bas niveau), connectivit rseau IP / Datagram / HTTP / HTTPS, mmoire
persistante (filesystem, SD et SQL Lite), tlphonie, messagerie, golocalisation, 3D, framework
de scurit, player multimdia (3gpp, mpeg-4, aac et mp3), accs camra, LDAP API,
COM/DCOM, SIP, et laccs au calendrier.
Au niveau des restrictions, cette plateforme mobile ne permet pas laccs SIM et elle ne
possde aucune API de web services.

2.4.4

Symbian

Symbian est une plateforme logicielle propritaire pour terminaux mobiles dtenue 100%
par Nokia, elle se dcline en 3 versions : S40 - tlphones mobiles (entres de gamme), S60
Smartphones et S80 - tablettes PC. Nokia fournit un kit de dveloppement (SDK) incluant des
outils et les librairies (API) ncessaires pour le dveloppement dapplications. La dernire version
est la version S60 5th Edition quipant les derniers Nokia N97 et XPressMusic 5800. Les
plateformes S60 et S80 supportent un grand nombre de langage de programmation : C/C++,
Python, Flash, Java et autres (Ruby, #C). Le diagramme de la Figure 15 prsente les principaux
composants de la plateforme :

18 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 15: Diagramme darchitecture Symbian

En standard, la plateforme offre les librairies (ou services) suivantes : interface utilisateur
(haut niveau / bas niveau), connectivit rseau IP / Datagram / HTTP / HTTPS, mmoire
persistante (filesystem, SD et SQL Lite), tlphonie, messagerie, golocalisation, 3D, framework
de scurit, player multimdia (3gpp, mpeg-4, aac et mp3), accs camra, SIP en natif, et laccs
au calendrier.
Au niveau des restrictions, cette plateforme mobile ne permet pas laccs SIM et elle ne
possde aucune API de web services. De plus, le language C++ utilis est spcifique Symbian.
En outre, la procdure de certification pour accder aux APIs avances est contraignante.

2.4.5 iPhone OS
Driv hybride de Mac OS X, liPhone OS est le systme dexploitation quipant les
terminaux iPhone ; la version actuelle est la 3.0. Les applications sexcutant sur liPhone sont des
applications Cocoa. Cocoa est un environnement de dveloppement applicatif : il inclut un
environnement dexcution, un ensemble de librairies logicielles orientes objet et un IDE (Xcode)
coupl un diteur wysiwyg (Interface Builder). Le langage de programmation est lObjective C, un
driv du langage C avec des aspects objet prononcs. Il est toutefois possible de mixer du C/C++
avec lObjective C. Il faut noter que contrairement Cocoa pour Mac OS X, on ne peut dvelopper
que des applications (pas de dmons, ni plugin ou autres services) avec Cocoa pour iPhone OS.
Le diagramme de la Figure 16 prsente les principales couches logicielles de la plateforme :

19 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 16: Modle en couches de lOS iPhone

En effet, le Core OS inclut le noyau, le filesystem, la gestion rseau, la scurit, la gestion


dnergie et les drivers. Le Core Services fournit des services de bases tels que la manipulation de
chaines de caractres, la gestion de collection, la gestion de prfrences et de contacts
utilisateurs, utilitaires rseaux. Le Mdia inclut des services graphiques 2D et 3D (via OpenGL),
vidos et audio. Le Cocoa Touch inclut deux frameworks essentiels pour le dveloppement : UIKit
qui est un gestionnaire dvnements UI, et Foundation qui est un gestionnaire dobjets et cycle de
vie des applications.
En standard, la plateforme offre les librairies (ou services) suivantes : interface utilisateur
(haut niveau / bas niveau), connectivit rseau IP / Datagram / HTTP / HTTPS / FTP, mmoire
persistante (filesystem, SD et SQL Lite), tlphonie, messagerie, golocalisation, 3D, framework
de scurit, player multimdia (3gpp, mpeg-4, aac et mp3) et un accs camra.
Au niveau des restrictions, cette plateforme mobile ne permet pas laccs SIM et elle ne
possde aucune API pour accder au calendrier. Dans cette plateforme, le dveloppement dun
service (ou dmon) est impossible, et le dmarrage dune application se fait au boot du tlphone.
De plus, le langage de programmation est non portable. En outre, cette OS est compatible
uniquement avec les terminaux iPhone. Enfin, la procdure de publication/diffusion TRES via
lAppStore est contraignante.

20 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

3. IMS
3.1. Besoins
Avec lavnement de lInternet, IP est devenu le protocole le plus intressant et le plus utilis
dans le monde entier. En chiffre, presque 1,5 billions de personnes sont interconnects laide de
lInternet, ce qui correspond au 1/4 de la population mondiale. De plus, le taux de croissance de
lusage de lInternet est de 380,3% entre les annes 2000 et 2009. En effet, lIP, encore connu
sous le nom Best Effort Protocol , permet une communication et une transmission avec les
moindres dlais. Il est devenu de plus en plus utile suite lapparition des applications temps-rel
comme la Voix sur IP et les confrences vocales et vido.
Tous ces aspects ont motiv les recherches dune architecture de rseau qui est tout IP, et
qui est appele par la suite, NGN (Next Generation Networks). Or, cette innovation dans le plan de
transport est incapable dassurer toute seule un dploiement facile et rapide de nouveaux services
bass sur IP, ni de contrler laccs ces services. Pour cela, une innovation dans le plan de
contrle tait ncessaire. Do la cration de lapproche IMS (IP Multimedia Subsystem). En effet,
IMS est conue pour permettre le plein contrle sur les offres de services IP. Cette technologie est
le chemin vers un cadre unifi de prestation de services pour les rseaux fixes et mobiles.
En outre, IMS fournit les fonctions de signalisation, de livraison et de facturation, qui sont
ncessaires lexcution des appels et des services temps-rel et orients paquets. Elle offre de
plus, aux utilisateurs, la possibilit dtablir des sessions multimdia en utilisant tout accs haut
dbit et une commutation de paquets IP. En fait, les fonctionnalits dIMS sont fournies pour
nimporte quelle technologie utilise au niveau du rseau sous-jacent (Figure 17).

Architecture IMS
3GPP Specs: TS 23.228 (V8.0.0) R8

gsmSCF

SIP - AS

IM-SSF

SCIM

HSS
(Home Subscriber Server)

Couche de
Control et
Session

Signaling

IMS Stage 2

Couche
dApplication et
Services

Donnes IMS

Data

Sh
CSCF

Si

(Call Session Control Function)

Cx
Diameter

S-CSCF
I-CSCF

HLR/AUC

Diameter

SLF

Couche de
Transport

P-CSCF

Dx

PSTN

MRFC

I: Interrogation

BGCF
P: Proxy

PDF

Internet

IP/MPLS

S: Serving

Media
Resource
Function
Control

MGCF

GPRS
GSM

GGSN

MGW

Dispositifs

Figure 17: Spcification 3GPP, Architecture IMS

De point de vue architectural, IMS est une architecture introduite au cur du rseau. Cest
une couche de contrle introduite entre les couches accs/transport dune part et la couche de
services de lautre part. Son rle principal est de contrler une session IP mobile entre les abonns
(tablissement, modification et libration de sessions multimdias), en se basant sur le protocole
de signalisation SIP. Larchitecture IMS, selon la Figure 18, peut tre structure en quatre couches :

21 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 18: Architecture globale dIMS

La couche Accs peut reprsenter tout accs haut dbit tel que : UTRAN, xDSL, rseau
cble, Wireless IP, WiFi, etc;
La couche Transport reprsente un rseau IP. Ce rseau IP pourra intgrer des
mcanismes de QoS avec MPLS, DiffServ, RSVP, etc ;
La couche Contrle consiste en de contrleurs de session responsable du routage de
signalisation entre usagers et de linvocation des services. Ces nuds sappellent des
CSCF (Call State Control Function) forms de Proxy-CSCF, Interrogating-CSCF et de
Serving-CSCF;
La couche Application introduit les applications (services valeur ajoute) proposes aux
usagers et consiste en des serveurs dapplication (AS, Application Server). Loprateur
peut se positionner grce sa couche Contrle en tant quagrgateur de services offerts
par loprateur lui-mme ou par des tiers.

3.2. Implmentation : Existant


Au niveau de lexistant dans la couche de contrle, nous allons citer deux solutions qui sont
le Fokus IMS et lUMA (Unlicensed Mobile Access). Le Fokus IMS a t dvelopp par linstitut
Fraunhofer FOKUS en Allemagne et est destin des plateformes du monde Linux.

Figure 19: IMS et le Fokus IMS

22 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Les modules du Ser-ims (CSCF) (Figure 19) sont implments en utilisant SER (SIP Express
Router) :

Module Proxy-CSCF (pcscf) : Joue le rle de Parfeu pour la signalisation et laffirmation


didentit de lutilisateur (SER + pcsf).
Module Interrogating-CSCF (icscf) : Questionne le HSS partir didentits publiques
indiqus par lappelant ou lappel et bas sur ses rponses roote les messages vers le
S-CSCF appropri, CDiameterPeer (cdp) charg auparavant car il communique avec le
HSS sur l'interface Cx d'IMS (SER + icsf + cdp).
Module Serving-CSCF (scscf) : Communique galement avec le HSS en utilisant
diameter (au-dessus de l'interface Cx) pour tlcharger le profil utilisateur et dcider vers
quel serveur d'application (AS) le message sera expdi travers linterface ICS (SER +
scscf + cdp + ics).
Les ASs sont des entits o on trouve hberge la partie logique de la session. LAS peut
se trouver dans le User Home network ou dans un rseau externe. Si elle se trouve dans
le User home network elle peut rejoindre le HSS en utilisant le protocole Diameter.

Dune autre part, lautre solution existante, UMA, a t dveloppe par un consortium
d'entreprises comptant entre autres Alcatel, Nokia, T-mobile, etc. Elle voudrait ce jour faire
converger les protocoles de communication des tlphones mobiles, fixe et informatiques. Ses
objectifs initiaux taient:
Pour l'utilisateur,

Permettre dutiliser des services mobiles voix et data (y compris SMS et MMS) par
lintermdiaire de rseaux wireless.
Permettre aux utilisateurs de possder la mme identit sur des rseaux GSM ou
wireless.
Permettre la transition sans coupure entre des rseaux GSM et des rseaux wireless.
tre indpendant de la technique sans fil utilise (Wi-Fi, Bluetooth).

Pour l'oprateur,

Couvrir les zones de ccit du rseau GSM (intrieur de btiment, souterrain, ...)
moindre cot
Continuer utiliser les mmes quipements, et les mmes mthodes d'authentification et
de facturation que dans le rseau GSM.
Fidliser ses consommateurs.

3.3. Implmentation : UBIS


La non prise en compte de laspect QoS quand un mobile de lUMA bascule sous les rseaux
sans fil et la ncessit de contrats entre oprateurs pour le roaming limitent lUMA un
environnement domestique ou un petit bureau. Cette limitation au niveau UMA est confronte
par un avantage essentiel au niveau du Fokus IMS qui est la seule version open source fiable
existante pour reprsenter la couche de contrle. Pour cette raison, dans le cadre de notre projet
UBIS, on a adopt le Fokus IMS comme plateforme de contrle.
En effet, le Fokus Open IMS sera utilis comme couche de contrle de notre dmonstrateur
mais dans une version dite volue. Il est noter que la version actuelle dIMS possde quelques
limitations. Notre IMS amlior contient une base de donnes HSS volue pour offrir des
informations compltes mise jour dynamiquement temps rel (par exemple les prfrences des
utilisateurs, les terminaux des utilisateurs, les rseaux auxquels avaient souscrit les utilisateurs,
les services etc). Les modifications apportes au HSS se trouvent au 5. En outre, afin de
maintenir la signalisation de la session dynamique de services, nous utilisons le protocole SIP+ qui
est une forme volue de SIP afin de tenir compte des exigences dUBIS. Notre objectif de
proposer un SIP qui sadapterait larchitecture UBIS est dtaill dans le 4.3.2.

23 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

4. Plan service
4.1. Besoins au niveau services
Inspir par lvolution du NGN et par lapproche horizontale applique au niveau rseau, le
projet UBIS cherche appliquer cette vision horizontale au niveau service. Pour cette raison, UBIS
trouve primordial la cration dune architecture horizontale qui intgre des services flexibles et
innovants, ce qui va permettre dintroduire un niveau dabstraction plus lev pour les couches
sous-jacentes. En effet, loriginalit que cherche UBIS apparait : Premirement, dans son potentiel
supporter les dfis au niveau NGN (mobilit, htrognit et approche user-centric) ;
deuximement, dans sa capacit assurer une session mobile unique pour chaque utilisateur tout
en tenant compte des contraintes de QoS ; troisimement, dans sa contribution la cration de
nouveaux services personnaliss qui rpondent aux besoins des utilisateurs ; et finalement, dans
son potentiel dpasser le modle client-serveur en introduisant une nouvelle approche NGS
(Next Generation Services) qui est base sur une composition dynamique et couplage lche de
services.
Afin de rpondre tous ces dfis au niveau rseau et au niveau service, on introduit une
nouvelle architecture de service, appele NGN/NGS Middleware. Comme son nom lindique, ce
Middleware dpasse les dfis au niveau NGN (mobilit, htrognit et approche user-centric)
tout en fournissant une nouvelle vision de service appele NGS. Cette dernire est base sur un
ensemble dlments de services qui sont lis les uns les autres selon une composition dynamique
et couplage lche de services. En effet, cette architecture est un ensemble de composants
fonctionnels bien structurs qui supportent la personnalisation de services et qui maintiennent une
session continue pour chaque utilisateur dans un environnement mobile et htrogne, tout en
respectant les exigences au niveau QoS et les prfrences de lutilisateur.

Figure 20: NGN/NGS Middleware

Comme on voit dans la Figure 20, le NGN/NGS Middleware est divis en trois parties
principales: Services de Base , SEIB et Services Exposables . Les Services de Base
sont un ensemble de fonctionnalits responsables d'offrir et d'assurer les besoins fondamentaux
numrs ci-dessus (mobilit, htrognit et User-Centric). Pour cette raison, cette partie est
divise en trois sous-parties: Community Management, sous-partie qui rpond aux besoins de
mobilit ; QoS Management, sous-partie qui couvre les exigences de lhtrognit ; et enfin le
User Management, sous-partie qui assure lapproche user-centric. Ainsi, tous ces services de base

24 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

rendent transparent l'environnement sous-jacent et renforcent le concept NGN. Au dessus de la


partie Services de Base , nous avons le SEIB (Service Elements Interconnection Bus) qui est le
support d'interconnexion (agrgation/composition) entre des lments de services partageables,
mutualisables et trans-organisationnels. Au dessus de ce SEIB, nous avons la partie Services
Exposables . Cette partie est constitue dun groupe de services applicatifs qui seront exposs
dans les catalogues des clients UBIS. En effet, daprs lapproche P2P horizontale, nimporte quel
client UBIS pourra tre en mme temps un fournisseur et un consommateur de services.
Aprs avoir introduit cette nouvelle architecture de service, la question qui se pose est :
Quels sont les outils ncessaires pour implmenter cette architecture et pour assurer la
signalisation SIP avec le rseau IMS sous-jacent ?

4.2. Implmentation : Existant


Vu que SUN Microsystems est un partenaire ce projet, le choix intuitif existant pour
limplmentation de notre NGN/NGS Middleware est le serveur GlassFish Enterprise Server (Figure
21). Ce serveur est le rsultat dun projet men par Sun Microsystems ayant comme but de crer
un serveur dapplication open source pour la plate-forme Java Enterprise Edition. Sun
Microsystems dfinit GlassFish comme tant limplmentation pour la plate-forme Java, dition
entreprise (Plate-forme Java EE), et le premier serveur d'applications soutenir la technologie
Java EE 5, qui fournit un accs rapide une plateforme scurise, portable et volutive pour les
applications d'entreprise. Pour les dveloppeurs, il rend la programmation plus simple et plus claire
travers des annotations, Plain Old Java Objects (POJO), etc. .

Figure 21: NGN/NGS Middleware dans GlassFish/Sailfin

GlassFish est une plate-forme open source , standard, facilement utilises pour construire
et dployer des services de nouvelle gnration (NGS), et il est idal pour les architectures
orientes services (SOA) et pour les applications Internet riches utilisant la plate-forme Java EE,
Asynchronous JavaScript and XML (AJAX). Selon ces caractristiques, GlassFish est considr
comme un supplment pour notre solution; il nous aide atteindre la cration base NGS dans un
environnement SOA.
En outre, selon le projet METRO de Sun, intgr dans GlassFish, Sun propose une
interoprabilit scurise, fiable, transactionnelles et hautement performante avec Microsoft .NET.
D'ailleurs, le projet METRO soutient plusieurs normes et spcifications de services Web, y

25 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

compris l'API Java pour les services Web (JAX-WS 2.1), ce qui rduit le codage, et Java
Architecture for XML Binding (JAXB 2.1) qui prcise les bindings Java et XML. Comme
consquence de ce projet intgr, GlassFish pourra srement garantir ladoption du NGN/NGS
Middleware par les domaines IT et Web.
Au niveau communication, SIP (Session Initiation Protocol) et les Servlets SIP sont l'origine
de nombreux services populaires, comme la Voix sur IP (VoIP), la messagerie instantane, les
confrences web, etc., et ils vont jouer un rle encore plus important dans la construction de la
prochaine gnration de services de tlcommunications. SIP et SIP Servlets sont galement
importants dans l'entreprise; ils peuvent tre utiliss pour ajouter des interactions riches en mdias
sur les applications dentreprise. Afin d'atteindre ces objectifs, un projet de Sun, nomm Sailfin
a t lanc. Il introduit un Sun GlassFish Communication Server (SGCS) (Figure 21) qui ajoute une
extension de la technologie SIP Servlets (JSR 289) au GlassFish Enterprise Server. En effet,
SGCS est un serveur dapplication qui est bas sur la technologie Java EE et qui combine
larchitecture SOA des entreprises et les capacits des services Web avec les SIP Servlets.
Effectivement, cest une extension pour le serveur d'application GlassFish, qui permet de rpondre
aux besoins de communication et des applications multimdias. En considrant GlassFish comme
base, Sailfin offre une gestion, une haute disponibilit et des caractristiques de clustering ainsi
que la performance de rpondre des dploiements critiques de services.
Pour supporter la charge grande chelle que l'on peut gnralement s'attendre des
applications Telco et des applications Web, Sun High Availability Team dveloppe un algorithme
de rplication dynamique pour les sessions SIP, combin avec un support existant de la part de
GlassFish pour un algorithme de rplication pour les sessions HTTP. Dans cette approche, chaque
instance slectionne une (ou plusieurs) autre instance(s) dans le cluster afin de rpliquer n'importe
quelle et toutes ses sessions. Lors dun disfonctionnement au niveau dune instance, le cluster doit
tre rajust et une nouvelle relation doit tre forme avec une autre instance qui soit survivante.
Par consquent, cette approche GlassFish/Sailfin pourra supporter notre vision de services
(VPSN- VSC) base sur la rplication d'un lment de service donn.
Enfin, le SGCS aide les fournisseurs de services et les oprateurs de rseau acclrer
l'adoption d'une architecture IMS, en leur offrant une plate-forme standardise qui simplifie le
dveloppement des applications et des services valeur ajoute qui gnrent de nouveaux
modles de revenus, comme par exemple: VoIP, IPTV et la convergence fixe-mobile.
Pour rcapituler, nous avons choisi le GlassFish Enterprise Server avec son serveur Sailfin
(SGCS) puisquils sont des supports standards, riches et de haute performance, permettant ainsi
limplmentation de notre NGN/NGS Middleware.

4.3. Implmentation : UBIS


4.3.1 Implmentation du NGN/NGS Middleware
Dans cette partie, nous faisons une comparaison entre les deux versions V2 et V3 du
GlassFish (Figure 22). Cette comparaison nous a men dans UBIS considrer le GlassFish V2.x
est le choix idal pour notre dmonstrateur.

26 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 22: Comparaison GlassFish V2.x/V3

En effet, cette version supporte le principe de cluster pour les applications. Les clusters
dapplications peuvent tre crs dynamiquement et sadaptent facilement pour rpondre aux
demandes des utilisateurs, sans interruption des services. Grce cette caractristique, la
composition de services dynamique (VPSN-VSC) sera assure. De plus, au niveau scurit,
OpenSSO est galement intgr dans cette version.
galement, une composante essentielle de GlassFish V2 est l'ESB (Enterprise Service Bus),
qui est bas sur Open ESB. Il permet une intgration facile des services Web et des ressources
existantes de l'entreprise afin de crer des applications entreprise couplage lche. Il est le
Backbone des dploiements SOA et il permet des composants couplage lche de
communiquer ensemble par l'intermdiaire de messages standardiss. Il fournit galement
l'intgration cur, y compris la connectivit des applications, la messagerie garantie, les capacits
robustes de transformation ainsi quun environnement unifi pour le dveloppement, le
dploiement et la gestion. En consquence, cet ESB, en lui ajoutant les deux fonctionnalits de
Composition et dAgrgation de services, constitue le SEIB de notre NGN/NGS Middleware.
De plus, au niveau communication, le projet Sailfin intervient afin de supporter lchange SIP
entre le serveur GlassFish et le rseau IMS sous-jacent. En effet, les fonctionnalits ajoutes par
Sailfin napparaissent que dans GlassFish V2, ce qui favorise aussi le choix de cette version du
serveur dapplication.
Aprs avoir choisi le GlassFish Enterprise Server V2 et aprs avoir dmontr la compatibilit
entre notre solution et ce seveur dintgration, il est indispensable d'introduire quelques lments
de base de ce serveur GlassFish:

Serveur HTTP avec un Listener HTTP pour communiquer avec les clients et les serveurs
Web.
ORB (Object Request Broker) qui permet aux utilisateurs de construire des systmes en
rassemblant des objets, provenant de diffrents fournisseurs, qui communiquent entre
eux via l'ORB.
Conteneur Web qui utilise un driv de lApache Tomcat comme conteneur de servlet
afin de servir le contenu Web.

27 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

EJB (Enterprise JavaBeans) qui encapsule la logique mtier d'une application. Il est
habituellement appliqu dans le cadre du dveloppement niveau entreprise, tels que le
commerce lectronique, le systme bancaire, etc. Ce composant implmente la logique
de traitement pour chaque composant de services UBIS.
NetBeans, un environnement de dveloppement intgr (IDE) qui est riche, facile tre
utilis et particulirement adapt au dveloppement SOA. L'IDE NetBeans est encapsul
avec le GlassFish ESB et il est capable de supporter le dveloppement, le debugging, la
construction et le dploiement de la nouvelle gnration dapplications composites SOA.

4.3.2 Adaptation la signalisation SIP : SIP +


Afin de satisfaire les besoins de continuit de QoS dans la session user-centric, une
signalisation plus flexible sur le plus haut niveau (niveau de service), pour changer des
informations de QoS et des informations de lutilisateur entre les composants de service travers
n'importe quel rseau mobile ou fixe, serait opportune. Base sur l'architecture VPSN et le concept
de gestion dynamique, une Signalisation dynamique dE2E QoS sur le niveau de service est
propose pour couvrir la session afin de parvenir la fourniture des services demands et de se
conformer aux SLA (Service Level Agreement). Cette QoS signalisation communiquera en plus
de la description des mdias, les exigences au niveau des composants de service. En outre, elle
enverra ltat de la QoS surveille (in/out contrat) dans le message de contrle lors de la phase
d'exploitation.
Le rseau de service implique l'ensemble des visibilits des nuds des sous-rseaux au
titre de sa couverture. la suite de cette intgration de la couche de service et de la couche de
transport, lorsque l'on change de composant des services (couche de service) pour sadapter la
demande des utilisateurs ou aux impacts de la mobilit, les sous-rseaux crent un chemin
correspondant au lien logique entre les composants de service. Cest ainsi que la QoS
signalisation applique la couche de service avec interactions avec l'utilisateur final nous
permet de faire de la gestion de la QoS E2E.
Nous dveloppons ce type de signalisation dans le cadre du protocole SIP, donc nous
l'appelons SIP plus (SIP +). SIP + a la capacit de faire circuler la description des mdias, ainsi
que les notifications des critres de QoS du composant de service pour le provisionnement des
ressources. Notre proposition SIP+ repose sur larchitecture dIMS de lETSI. Nous proposons
dtendre le protocole SIP au VPSN (couche de service) lorsque les composants de service (SE)
sont mis en uvre avec un middleware NGN, comme la Figure 23 le montre. Le middleware NGN
compose un ensemble de SEs pour un service globale. Il choisit et appelle (selon l'tat du SE) les
services la rception d'un message SIP du middleware dIMS. Le middleware NGN offre les
services de base, qui permettent une gestion de qualit de service, gestion des utilisateurs et
autres fonctions de gestion. Les composants du service sont dans des conteneurs diffrents. Ces
composants de services sont enchans selon la logique de service par le SIP +. En outre, les
informations QoS des composants de service peuvent tre ngocies avec les utilisateurs grce
SIP +.

28 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 23: Vision globale de SIP+

SIP+ fonctionne dans la couche de service afin de provisionner les ressources pour E2E
session user-centric selon notre modle de QoS ( quatre critres: disponibilit, dlais, fiabilit et
capacit). SIP+ fournit une description de QoS de haut niveau en couvrant un service global
demand (QoS de nud de service, QoS de rseau, QoS d'quipement) par dclinaison TopDown , comme la Figure 24 le montre.

Figure 24: QoS description of service component

Un modle unifi de la QoS applicable tous les composants et tous les niveaux travers
de multiples fournisseurs permettra l'agrgation des E2E QoS.

La QoS de nud de service contient les caractristiques de la fonction. .

La QoS de rseau recueille la table de routage qui enregistre la QoS de chacun des
chemins possibles dans la couche de transport. La qualit de service temps rel est
calcule et mise jour dans le tableau.

29 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

La QoS d'quipement est la qualit de service de la machine (capacits CPU et


mmoire.)

Nous proposons un modle de QoS Spcification dans le SIP+, qui a deux objets : la QoS
demande et la QoS courante (Figure 25), pour dcrire les conditions et les contraintes de l'lment
de service (len-tte du SIP) qui complte les demandes pour le transport des mdias dans la
session (SDP). Dans chaque objet, les paramtres de QoS sont classs selon quatre sensibilits
des critres essentiels.

Figure 25: Le modle de QoS description dans SIP+

Chaque nud du VPSN/VSC a un agent de QoS qui stocke un contrat de QoS (la fourchette
des valeurs seuil) en fonction du SLA. La QoS demande et la QoS offerte sont ngocies durant
la phase de provisionnement aprs le dploiement de services selon le contrat de QoS. Ainsi, les
composants de services ont connaissance du contrat remplir et l'image de ses performances
actuelles.

30 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

5. Base de Connaissances
5.1. Besoins au niveau de la base de donnes
Laspect user-centric est un besoin primordial pour le projet UBIS. Pour cette raison,
toute demande de service ncessite la personnalisation par lutilisateur, laccessibilit par
nimporte quel terminal, une meilleure connectivit, une continuit dans le service et un
provisionnement dynamique de ressources. Toutes ces exigences ncessitent une infrence
informationnelle et non pas une simple mise jour de la base de donnes. Pour cela, on a
propos une base de connaissances (Infosphere/Infoware) afin de tenir compte dynamiquement et
en temps rel de linformation personnalise et des ressources ambiantes.
LInfoware est une base dinformation structure qui est situe au niveau du fournisseur. Il
gre efficacement et de manire dynamique les informations dcisionnelles et ractives. En effet,
cette structure informationnelle est compose de plusieurs profils (profil de service, profil temps
rel, profil de session, profil utilisateur, etc.). Dune autre part, afin de permettre lutilisateur de
prendre la bonne dcision au bon moment, lInfosphere est situ au niveau de lutilisateur. Dans
ces deux bases de connaissances, on applique un mta-modle bien dfini qui tient compte des
quatre niveaux de visibilit (utilisateur, service, rseau et quipement). Ce modle informationnel
organise toutes les informations ncessaires tout en adoptant une vision de QoS, afin davoir
partout une adaptation dynamique de service.

5.2. Implmentation : Existant


Comme nous lavons dj not dans la partie Cur IMS , nous utilisons le FOKUS Open
IMS comme plan de contrle pour le projet UBIS. Cette solution de contrle introduit comme base
de donnes le FHoSS (FOKUS Home Subscriber Server) (Figure 26).

Figure 26: FHoSS

Cest une base de donne centralise contenant certaines informations comme le profil des
usagers (identits des usagers, services auxquels les usagers sont souscris, le S-CSCF alloue
chaque usager, etc.) et des informations de scurit (contrle daccs: authentification et
autorisation). Elle est entirement code en Java. Les donnes de lutilisateur sont stockes dans
une base de donnes MySQL. FOKUS Open IMS dfinit FHoSS comme un configurateur pour le
systme de gestion de la base de donnes et pour les interfaces Diameter avec les CSCFs et la
couche applicative. Cette base de donnes permet la gnration des vecteurs dauthentification et

31 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

fournit une interface de gestion HTTP afin de faciliter la gestion des profils des utilisateurs et des
iFCs associs.
Les donnes sont structures dans le FHoSS selon plusieurs tables (Figure 27) :

Identifiants et info de lutilisateur (IMPI, IMPU)


Relation Identifiants publiques et privs (IMPU2IMPI)
Localisation (networks, roam)
Adresse de lAS assign luser (apsvr, as_perm_list)
Tarification (chrginfo)
Etat de lutilisateur register/no register (notify_ims_user_state)
Tables de SCSCF (scsf et scscf_capabilities)
Table repository data (rep_data)
Etc.

Figure 27: Structure de la base de donnes FHoSS (version FOKUS)

Malgr les donnes de base fournies par ce FHoSS, ses informations sont considres
limites et non suffisamment dynamiques pour offrir des informations temps rel aux ressources
actuellement utilises lors du dplacement de lusager. Par exemple, dans les informations
concernant lusager, il ny a pas les prfrences et la liste des terminaux de cet usager, bien que
ces donnes soient importantes lors de la slection du service. De plus, dans les informations
concernant le service, il ny a pas la QoS relie au service dcrit. Dans la partie qui suit, nous
allons expliquer comment nous avons dpass ce problme de donnes figes et limites.

5.3. Implmentation : UBIS


Afin de mettre en place notre base de connaissances (Infosphere/Infoware), nous utilisons
dans UBIS une base de donnes ORACLE 11g. Pour cette raison, nous avons migr la base de
donnes MySQL de FHoSS en une base de donnes Oracle. Cette dernire apparait dans la Figure
28 ci-dessous.

32 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 28: Structure de la base de donnes FHoSS (version UBIS)

Afin dassurer cette migration de base de donnes, nous utilisons Oracle Migration
Workbench et le SwisSQL. Oracle SQL Developer est utilis afin de grer la base de donnes.
Quand la gestion des vnements, Oracle Complex Event Processing est utilis. La modlisation
(UML) de cette base de donnes est faite laide de loutil Oracle SQL Developer Data Modeler.
Au cours de la migration de la base de donnes du MySQL en Oracle, nous avons tenu
compte des quatre niveaux de visibilit (user, service, rseau et quipement) afin de rendre cette
simple base de donnes une base de connaissances avec laquelle le FHoSS sera nomm HSS+
(Figure 29).

33 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 29: HSS +

34 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

6. Scurit
6.1. Besoin
UBIS veut offrir une nouvelle architecture de services dynamique unifie, base sur
larchitecture IMS, associant la mobilit, lhtrognit et laspect user-centric. En plus dtre User
centric, UBIS voudrait maintenir la continuit de la session sans couture, ce qui implique la
possibilit pour lutilisateur davoir accs aux composants de service quelque soit sa localisation, et
avoir le choix de ses composants quelque soit le fournisseur, do le besoin du transorganisationnel. Cest ainsi quUBIS propose une architecture compose de composants de
services mutualisables rpartis selon un dploiement plus intelligent.
Le challenge pour le projet UBIS, est dintgrer la scurit ds la conception de cette
nouvelle architecture avec la mme philosophie dans la dmarche, savoir, la scurit vue
comme un ensemble de services de base associer aux diffrents processus travers une
composition de services.
Nous avons ainsi un certain nombre de questions nous poser : la mobilit na-t-elle pas un
impact sur la scurit ? Lutilisateur doit-il sauthentifier chaque fois quil sollicite un nouveau
composant de service (ou quil change de fournisseur), ou alors quil change de dispositif, de
rseau daccs? Comment lauthentification, lautorisation peuvent-elles tre fournies de faon
transparente vis--vis de lutilisateur? Et ceci sans oublier le fait que la session doit tre sans
coupure et sans couture.
Une attention particulire sera donc accorde lauthentification unique pour la session
centre utilisateur de faon viter des contrles chaque accs de rseau, de services, etc.

6.2. Implmentation : Existant


Le SSO (Single Sign On) est une mthode permettant un utilisateur de ne procder qu'
une seule authentification pour accder aux diffrents services dun systme. Il permet ainsi de
simplifier la dfinition et la mise en uvre de politiques de scurit, simplifier la gestion des
donnes dtenues par les diffrents services en ligne, en les cordonnant par des mcanismes de
type mta-annuaire, et galement il permet de simplifier, pour lutilisateur, la gestion de ses mots
de passe.
Il existe deux grandes classes d'approches pour la mise en uvre de systmes
d'authentification unique : les approches centralises dont le principe est de disposer d'une base
de donnes globale et de centraliser tous les utilisateurs travers dun annuaire, et les approches
fdratives o chaque service gre une partie des donnes d'un utilisateur (l'utilisateur peut donc
disposer de plusieurs comptes), mais partage les informations dont il dispose sur l'utilisateur avec
les services partenaires. La fdration consiste ainsi pour chaque partenaire maintenir le service
dauthentification unique tout en conservant la matrise de sa propre politique de scurit. Ce qui
facilite les changes entre partenaires sans avoir dupliquer les rfrentiels utilisateurs et donc en
faisant de la dlgation de gestion des utilisateurs sur la base de confiance.
En ce qui concerne les produits existants, sans tre exhaustif, nous allons citer le OpenID,
Kerberos, CAS, Open SSO ainsi que Liberty Alliance, Shibboleth, WS-Federation ; tous les trois
sont bass sur SAML (Security Assertion Markup Language).
Quelle que soit la norme utilise pour l'authentification unique, l'infrastructure scurise fait
intervenir, entre le client et le serveur fournissant le service, un serveur d'authentification o est
gr un identifiant.

35 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

La solution de SUN, Open SSO a t retenue et elle permet de grer lauthentification unique
sur un change de cookie entre lapplication et le serveur dauthentification. Ce cookie de session
va permettre de rcuprer auprs du serveur dauthentification le jeton SSO (SSOToken). Le client
adresse une requte daccs lapplication qui est intercepte par lagent SSO install sur le
serveur d'application protger. Son but est d'intercepter la requte du client et de dialoguer avec
OpenSSO (le moteur SSO) pour vrifier si l'utilisateur a le droit d'accder la ressource qu'il
demande et de rpondre en consquence au client.
Le client est redirig vers le serveur dauthentification OpenSSO. Aprs authentification,
OpenSSO dlivre un SSOToken et redirige lutilisateur vers lagent. Lagent vrifie ensuite auprs
du serveur OpenSSO la validit de la session. Puis, il lui demande si le client a lautorisation
daccder au service (nous avons plus de dtails dans le dlivrable 5.1).

Figure 30: Authentification unique du user avec OpenSSO

6.3. Implmentation : Choix dans UBIS


Pour rpondre aux besoins de la mobilit de lutilisateur, nous proposons une extension de
Open SSO qui permet de grer lauthentification unique pas seulement auprs des composants de
services applicatifs mais aussi au niveau de lensemble des terminaux qui forment le VPDN (PAN)
dun utilisateur dans une session. Cette extension sappuie sur un Policy Agent qui jouera le
mme rle du cot des terminaux pour contrler les droits de chaque utilisateur selon son rle
par rapport son VPDN (PAN).
Au niveau des terminaux, lchange des permissions se fait entre le Policy Agent et le
serveur dauthentification Open SSO pour vrifier si lacteur fait bien partie de la session. Par
contre, aux niveaux composants de services applicatifs lagent vrifie si lacteur est de la mme
session.

36 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

Figure 31: Cas dusage : Extension OpenSSO

Lutilisateur adresse une requte partir de son terminal T1 qui est intercepte par lagent
Policy (VPDN). Il est redirig vers le serveur dauthentification Open SSO. Aprs authentification,
Open SSO dlivre un SSOToken et redirige lutilisateur vers lagent qui vrifie auprs dOpen SSO
la validit de la session et lautorisation dutilisation de terminal T1 (appartenance au VPDN).
Ensuite, la requte est envoye la plateforme de services et l elle est intercepte par lagent
Policy (VPSN) et celui-ci procde la vrification de la correspondance des droits de lutilisateur
et des permissions des lments de service (Autorisation).
Pour changer de terminal dans le cas de SIP, lutilisateur adresse un INVITE au terminal
T2 pour lequel il se dplace. Lagent vrifie auprs dOpen SSO si le terminal T2 est autoris et
fait partie de la session. Enfin, lagent renseigne Open SSO pour la journalisation des actions
effectue.
Cest ainsi que nous avons analys les mcanismes de Single Sign On, tout en dployant
Open SSO pour valuer la pertinence des rponses nos besoins. Puis, nous avons propos une
extension dOpen SSO bas sur un agent Policy qui permet grer lauthentification unique des
composants de services et la mobilit de lutilisateur en mme temps. Ce qui rpond dans un
premier temps pour lensemble des services aux problmatiques P2 et P4 (voir dlivrable 5.1).

37 / 38

Projet ANR Verso 2008 - UBIS

SP6 Lot 6.1 Architecture du dmonstrateur

7. Conclusion
Dans ce dlivrable SP6.1, nous avons expliqu en dtails toutes les parties architecturales
de notre premire version de dmonstrateur UBIS. Cette architecture comporte des propositions
thoriques de conception ainsi que des propositions technologiques dimplmentation. En effet,
larchitecture de notre dmonstrateur est base sur tous les travaux qui sont faits dans les sousprojets (SP2 SP5) et elle est rpartie sur plusieurs couches :

Niveau Utilisateur : un profil dutilisateur sera stock dans la base de connaissances afin
de tenir compte des exigences de ces utilisateurs et de rpondre leurs besoins.
Niveau Terminal : une architecture Userware est cre afin de permettre aux utilisateurs
un accs simplifi aux services tout en tenant compte de leurs prfrences et de leurs
besoins. De plus, elle leur permet de personnaliser leurs services demands. Le choix
technologique dimplmentation de ce Userware est le MAEMO pour les plateformes
mobiles. Ce Userware pourra tre implment aussi sur des plateformes PC.
Niveau Rseau de transport : la solution VIRTUOR est utilise afin de mettre en place
plusieurs rseaux virtuels qui constitueront une plateforme rseau pour excuter nos
tests.
Niveau Cur IMS : le FOKUS OPEN IMS est utilis comme plan de contrle pour notre
dmonstrateur.
Niveau Service : une architecture NGN/NGS Middleware est cre afin de rpondre aux
besoins du NGN (mobilit, htrognit et approche user-centric) et afin de supporter la
personnalisation des services en introduisant une nouvelle vision NGS (Next Generation
Services). Au niveau implmentation, GlassFish et Sailfin sont utilises comme
plateforme de service. En outre, pour la signalisation et ltablissement de la session, un
protocole SIP + est utilis.

Dune autre part, dans le plan de scurit, une extension OpenSSO est retenue. Quand au
niveau de la base de connaissances, un Infoware et un Infosphere sont respectivement conus
dans le plan du fournisseur et dans le plan de lutilisateur. Ils assurent linfrence informationnelle
exige dans UBIS. Au niveau de limplmentation, une base Oracle est adopte.
Finalement, nous avons dcris dans ce dlivrable SP6.1 larchitecture de notre
dmonstrateur. Dans les prochains dlivrables de ce sous-projet SP6, nous fournirons :

SP6.2 - Codage (spec) des composants de service de la plateforme UBIS (hors


terminal) supportant les appels de services de l'Userware et dfinir les mthodes et outils
de portage ncessaires un dploiement industriel.
SP6.3 - Tests de composants de service : prparer l'intgration et vrifier la compatibilit
des Userware et Serviceware.
SP6.4 - Tests dintgration : Valider larchitecture du dmonstrateur en phase
oprationnelle en procdant de manire incrmentale (incrments essentiels :
Dmonstrateur 1, Dmonstrateur 2).
SP6.5 - Dmonstrateur 1 : Crer la version 1, pour avoir des rsultats au bout de 20 mois
et en faire la dissmination.
SP6.6 - Dmonstrateur 2 : Crer la version 2 incluant la gestion et la scurit et en faire
la dissmination.

38 / 38