UBIS SP2 - Lot2.1 Défintion et spécification de l`architecture

Transcription

Projet ANR-Verso 2008 UBIS
«User centric»: uBiquité et Intégration de Services
SP2 – Architecture UBIS
Lot 2.1 – Définition et spécification de l’architecture
Auteurs :
N. SIMONI
Participants :
YIN C. ; NASSAR R.
Version :
V2
Date :
1/2010
1 / 80
Projet ANR Verso 2008 - UBIS
SP2 – Lot 2.1 – Définition et spécification de l’architecture
Historique du Document
Version
Date
Modifications
V0
9/2009
N. SIMONI
V1
11/2009
N. Simoni
V2
1/2010
N. SIMONI
2 / 80
Table des matières
1.
INTRODUCTION ...................................................................................................................................................... 5
1.1.
Contexte NGN....................................................................................................................................................... 5
1.2.
Les éléments d’évolution .................................................................................................................................... 16
1.2.1
1.2.2
1.2.3
1.2.4
1.2.5
2.
Evolution du contexte ..................................................................................................................................... 17
Evolution des Télécoms .................................................................................................................................. 18
Evolution des architectures ............................................................................................................................. 19
Evolution de la conception.............................................................................................................................. 20
Evolution de la convergence ........................................................................................................................... 20
LE QUOI ................................................................................................................................................................. 22
2.1.
La nouvelle vision : ............................................................................................................................................. 22
2.2.
Définition d’une architecture ............................................................................................................................... 23
2.3.
L’ingénierie des architectures ............................................................................................................................. 24
2.4.
Les architectures de service : analyse de l’existant ............................................................................................ 26
2.4.1
2.4.2
2.4.3
3.
Les architectures Telco ................................................................................................................................... 26
Les architectures Web ..................................................................................................................................... 41
Les architectures IT : SOA ............................................................................................................................. 48
LE POURQUOI : .................................................................................................................................................... 52
3.1.
Les défis ............................................................................................................................................................. 52
3.2.
La continuité de service ...................................................................................................................................... 53
4.
LE COMMENT : LA NATURE DES REPONSES UBIS ......................................................................................... 54
4.1.
Architecture de service UBIS .............................................................................................................................. 54
4.2.
La session de bout en bout UBIS........................................................................................................................ 56
5.
DE L’ARCHITECTURE AUX BLOCS FONCTIONNELS ....................................................................................... 58
5.1.
Topologie fonctionnelle ....................................................................................................................................... 58
5.2.
« Serviceware » et le VPSN ................................................................................................................................ 60
5.3.
Gestion des mobilités.......................................................................................................................................... 63
5.3.1
5.3.2
5.3.3
5.3.4
Dysfonctionnements de la QoS du composant................................................................................................ 63
Des acteurs ...................................................................................................................................................... 64
Concept de communauté d’intérêt .................................................................................................................. 65
Autogestion de communautés ......................................................................................................................... 68
5.4.
Sessionware : Continuité de service intégrée ..................................................................................................... 74
5.5.
« Seamless Userware » ...................................................................................................................................... 74
5.6.
Synthèse ............................................................................................................................................................. 75
6.
CONCLUSION ....................................................................................................................................................... 79
3 / 80
Table des Illustrations
Figure 1 : « User Centric » dans un contexte NGN .................................................................................................................................. 5
Figure 2: Les mobilités............................................................................................................................................................................. 6
Figure 3: HHO et VHO ............................................................................................................................................................................. 7
Figure 4 : L’architecture de l’UMA (spécification de l’UMA) ...................................................................................................................... 9
Figure 5 : l’architecture de l’UMA ........................................................................................................................................................... 10
Figure 6 : L’architecture de la norme de 802.21 ..................................................................................................................................... 10
Figure 7 : PS Handover : Phase de Préparation .................................................................................................................................... 11
Figure 8: Mobilité de l’utilisateur ............................................................................................................................................................ 12
Figure 9: mobilité de l’utilisateur supporté par SIP ................................................................................................................................. 13
Figure 10: mobilité de service ................................................................................................................................................................ 14
Figure 11 : Définition de sessions dans TINA ........................................................................................................................................ 15
Figure 12 : Session service.................................................................................................................................................................... 16
Figure 13: System Centric ..................................................................................................................................................................... 17
Figure 14: Application Centric ................................................................................................................................................................ 17
Figure 15: Network Centric .................................................................................................................................................................... 18
Figure 16: User Centric.......................................................................................................................................................................... 18
Figure 17: Evolution des Télécoms ........................................................................................................................................................ 19
Figure 18: Evolution des architectures ................................................................................................................................................... 20
Figure 19: Evolution de la conception .................................................................................................................................................... 20
Figure 20: Evolution des convergences ................................................................................................................................................. 21
Figure 21: Le quoi : Contexte et Périmètre ............................................................................................................................................ 22
Figure 22: Nouvelle Vision ..................................................................................................................................................................... 23
Figure 23: Modèle générique au niveau d’un nœud de l’architecture ..................................................................................................... 24
Figure 24 : Architecture fonctionnelle du réseau intelligent .................................................................................................................... 28
Figure 25 : Modèle organisationnel du Parlay/OSA................................................................................................................................ 31
Figure 26 : Architecture du Parlay/OSA ................................................................................................................................................. 32
Figure 27: Le framework Parlay ............................................................................................................................................................. 32
Figure 28 : Le modèle métier de l'abonnement Parlay ........................................................................................................................... 33
Figure 29 : Architecture Parlay X ........................................................................................................................................................... 36
Figure 30: Architecture OSE .................................................................................................................................................................. 38
Figure 31: Architecture IMS SCIM ......................................................................................................................................................... 40
Figure 32 : Cadre architectural des services Web .................................................................................................................................. 42
Figure 33 : Structure d'ensemble SOA des services Web ...................................................................................................................... 45
Figure 34 : Web 2.0 ............................................................................................................................................................................... 46
Figure 35 : exemple de la plate-forme de SaaS ..................................................................................................................................... 48
Figure 36 : Modèle SOA ........................................................................................................................................................................ 49
Figure 37 : composition de service exemple 1 ....................................................................................................................................... 50
Figure 38 : composition de service exemple 2 ....................................................................................................................................... 51
Figure 39 : Architecture de SOA ............................................................................................................................................................ 51
Figure 40 : architecture de la Plate-forme Fiorano SOA™ 2007............................................................................................................. 52
Figure 41 : Modèle vertical des architectures de services ...................................................................................................................... 53
Figure 42 : Le Pourquoi : la continuité de service................................................................................................................................... 54
Figure 43: La plateforme NGN Middleware proposée ............................................................................................................................ 55
Figure 44 : Sessions Multiples vs. Session Unique ................................................................................................................................ 57
Figure 45:Concept de la session « User Centric » ................................................................................................................................. 57
Figure 46 : Topologie fonctionnelle ........................................................................................................................................................ 58
Figure 47: Mutualisation d’un ES pour différente Composition de Service ............................................................................................. 61
Figure 48: Scénario de la mutualisation d‘un ES et Composition de Service .......................................................................................... 62
Figure 49: Serviceware .......................................................................................................................................................................... 63
Figure 50: les cas d’utilisation de la gestion de mobilité ......................................................................................................................... 65
Figure 51: Création de communauté...................................................................................................................................................... 69
Figure 52: Exemple de la gestion de la communauté des utilisateurs .................................................................................................... 71
Figure 53: Gestion de la communauté des utilisateurs ........................................................................................................................... 71
Figure 54: Exemple de la gestion de la communauté des équipements 1 .............................................................................................. 72
Figure 55: Exemple de la gestion de la communauté des équipements 2 .............................................................................................. 72
Figure 56: Gestion de la communauté des équipements ....................................................................................................................... 73
Figure 57: Exemple de la gestion de la communauté des services ........................................................................................................ 73
Figure 58: Gestion de la communauté de services ................................................................................................................................ 74
Figure 59 : « NGN Sessionware » ......................................................................................................................................................... 74
Figure 60 : « Seamless Userware » ....................................................................................................................................................... 75
Figure 61 : Carte fonctionnelle ............................................................................................................................................................... 76
Figure 62: Scénario final ........................................................................................................................................................................ 77
Figure 63 : Schéma générique d'un middleware .................................................................................................................................... 79
Figure 64 : Architecture du middleware UBIS ........................................................................................................................................ 80
4 / 80
1.
Introduction
Ce SP vise à déterminer l’architecture globale d’UBIS ainsi que l’ensemble des
spécifications sur les rôles et interactions de ses différents composants. Il s’agira
d’une architecture en couches, distribuée adaptée au concept « user centric ». Cette
architecture préconise un réseau de services basé SOA et SaaS. Elle traduira sous
l’angle « user centric », l’approche innovante d’une session unique reposant sur la
composition de services et l’ubiquité de service. Les aspects signalisation et gestion
seront également couverts pour contribuer à l’évolution de la NGS (nouvelle
génération de services).
1.1. Contexte NGN
L’orientation qui nous intéresse dans ce projet est celle de « User-Centric » (Figure 1)
dans un contexte NGN. C'est-à-dire que notre utilisateur est avant tout nomade. Il
souhaite d’abord avoir la possibilité de se connecter sans coupure pour accéder à ses
services, même si il traverse plusieurs réseaux hétérogènes. La connectivité ne
s’arrête pas à l’établissement de la liaison, la connectivité ne signifie plus juste le
maintien du lien, mais elle doit permettre à l’utilisateur d'être facilement relié à tout
moment pendant ses déplacements, à tout réseau de sa préférence dont il possède
les droits d’accès et à partir de n’importe quel terminal.
Figure 1 : « User Centric » dans un contexte NGN
Pouvoir se déplacer au gré de ses besoins ou de ses envies est aujourd'hui tellement
simple, que la location physique n’est plus la contrainte majeure pour les utilisateurs
modernes. Grâce à une grande couverture et à la diversité des technologies sur les
offres d’accès, les utilisateurs peuvent avoir leurs services n’importe où. Mais dans le
contexte de NGN où l’hétérogénéité est omniprésente le maintien de la communication
et du service d’un utilisateur qui se déplace est de plus en plus complexe. Pour
comprendre cette complexité, analysons les différents types de mobilité.
Les communications personnelles induisent des mobilités essentiellement d’ordre
spatial comme la « mobilité du terminal », la « mobilité de l’utilisateur » et la « mobilité
du réseau ».
La « mobilité de terminal » implique la continuité de la connexion. Les technologies du
genre « tout IP » permettent de considérer une architecture de réseau unifié, laquelle
peut traiter divers réseaux d’accès indépendants. Lorsque l’utilisateur passe d’un
terminal à un autre, cela relève de la « mobilité de l’utilisateur », nous devons alors
résoudre les adaptations pour préserver la personnalisation. La « mobilité du réseau »
5 / 80
concerne le déplacement de l’infrastructure du support de transport. C’est le cas des
réseaux locaux (trains ou avions) en mouvement. En fait, quand c’est le sous réseau
qui bougent avec tous ces nœuds, la problématique est la même que pour la mobilité
de terminal. Par contre, lorsque c’est un nœud du réseau cœur qui se déplace, nous
avons une problématique d’interconnexion et d’adaptation des débits à considérer.
Ces trois types de mobilité sont relatifs à des aspects de connectivité. Dans le monde
réel, il faut également considérer les aspects de service. Avec l’évolution de fourniture
de service, un même service demandé par l’utilisateur peut être offert par plusieurs
fournisseurs et supporté par différentes plates-formes de service. Quand l’utilisateur
se déplace, comment fait-il son choix pour avoir la meilleure adéquation à ses
besoins ?
Nous avons dénommé ce quatrième type de mobilité : la « mobilité de service » car au
delà de la préférence de l’utilisateur, elle sera utilisée par le système pour respecter la
QoS de bout en bout.
Cette « mobilité de service » induit en fait une autre mobilité d’ordre temporel que
nous avons dénommé « mobilité de session » (Figure 2 - A). En effet, pour assurer
une continuité de service avec la chaîne des mobilités spatiales, le système doit gérer
dynamiquement la session de l’utilisateur et son unicité de bout en bout (« seamless,
sans couture ») en temps réel. En fait, chaque mobilité relève d’un niveau
architectural, et ne permet pas à lui seul d’assurer la QoS de bout en bout. C’est la
session, gestionnaire dynamique en temps réel qui maintiendra cette QoS de bout en
bout.
Figure 2: Les mobilités
Mobilité de terminal
Les solutions existantes dans le domaine de la mobilité reposent sur les techniques de
handover qui s’appliquent plutôt à la « mobilité du terminal ».
Elle se rapporte à un terminal qui change de location, c’est-à-dire qui se déplace soit à
travers différents points d'accès d’un réseau, soit à travers différents réseaux d’accès,
tout en maintenant l’accès à un même ensemble de services. Ce type de mobilité doit
permettre le déplacement de terminal sans coupure. Deux types de solutions existent
le Roaming et le Handover.
Le Roaming est l’itinérance qui fait plutôt référence au changement d’opérateur ou de
domaine administratif. Ce type d’itinérance offre donc une possibilité d’obtenir des
services qui sont dans des domaines administratifs différents gérés par des contrats
entre opérateurs. Il est d’ordre commercial et réglementaire.
Le Handover est d’ordre technique. Ce processus permet, à un terminal mobile,
d'effectuer le passage entre deux points d'attachement de façon transparente. Le
changement de point d'attachement entraîne parfois une déconnexion momentanée
6 / 80
du terminal mobile et des perturbations des communications en cours. Néanmoins
l’objectif est d’assurer des communications sans coupure.
Nous distinguons le HHO (Horizontal HandOver) et le VHO (Vertical HandOver)
(Figure 3). Le HHO permet au terminal de passer d’un domaine d’accès à un autre en
utilisant la même technologie, la procédure se déroule dans un même niveau
d’architecture. Quant au VHO, il permet le passage d’un terminal, d’un type de réseau
à un autre (ex : de WiFi, à la 3G), ce handover se traite souvent par plusieurs niveaux
et dans un environnement hétérogène.
Figure 3: HHO et VHO
L’utilisation de la procédure de HandOver Horizontal (HHO) la plus usitée se trouve en
téléphonie mobile du niveau L2. D’une manière générale, le handover va être effectué en
analysant trame par trame le signal reçu des deux cellules impliquées et la meilleure
trame sera retenue. Ainsi, progressivement, le nombre de trames traitées par la cellule
d’accueil devient prépondérant devant le nombre de trames traitées par la cellule cédante.
Plusieurs techniques de handover ont été proposées. Par exemple, dans UMTS
(Universal Mobile Telecommunications System), nous trouvons du soft handover, softer
handover et hard handover.
Le Soft Handover s’effectue « en douceur ». Ce type de handover change de station de
base. Le mobile est dans la zone de couverture qui est commune à deux stations de base.
Les communications utilisent deux canaux différents, un pour chacune des deux stations.
Contrairement au mécanisme de handover traditionnel, tel que rencontré dans un réseau
analogique ou GSM, il n’y a pas d’interruption de la communication, même de très courte
durée.
Dans un système W-CDMA, on distingue le cas où le mobile reste dans la zone couverte
par une station de base en changeant juste de secteur, on l’appelle alors Softer Handover.
Le mobile est en communication avec une seule station de base, il utilise simultanément
deux canaux radio. Dans le sens descendant, deux codes d’étalement sont activés pour
que le mobile distingue les signaux issus des deux secteurs. Dans le sens montant, les
signaux émis par le mobile sont reçus par les deux secteurs de la station de base et
dirigés vers le même récepteur. Ils sont donc combinés au niveau de la station de base.
Du côté du mobile, il n’y a pas de différence avec un soft handover. Dans le sens montant,
par contre, les données sont combinées au niveau du contrôleur de réseau radio (RNC) et
non plus au niveau de la station de base. Cela permet de sélectionner la meilleure trame
parmi celles qui sont reçues, après chaque période d’entrelacement, toutes les 10 à 80
ms.
7 / 80
En dehors des handovers en douceur qui viennent d’être décrits et qui sont les plus
courants, on rencontre dans un système W-CDMA deux autres types de transfert
intercellulaire, qu’on appelle Hard Handover par opposition aux mécanismes précédents :
o Handover inter fréquence, lorsque le mobile passe dans une cellule où les
fréquences sont différentes de celle qu’il quitte ;
o Handover inter système, quand le mobile change de système, par exemple
pour quitter une plaque UMTS et entrer dans une plaque GSM, ou plus
simplement pour passer du mode FDD au mode TDD.
Nous avons également un HandOver Horizontal de niveau L3 en mode « paquet »,
c'est-à-dire, au niveau de l’IP à travers la technologie « Mobile IP ». Nous trouvons pour
IPV4 le RFC3344, pour IPV6 le RFC 3775 qui réalise le handover en cachant le
changement de l’adresse IP et la technologie mSCTP (mobile Stream Control
Transmission Protocol) qui met à jour l’adresse IP dynamiquement.
Mobile IP garde deux types d’adresse IP, une adresse permanente (Home address) qui
peut être utilisée au dessus du niveau transport; l’autre adresse IP modifiable (Care of
address) qui peut être utilisée au dessous du niveau transport. Dans la version IPV4, ce
protocole propose trois composants :
•
MN (Mobile Node) qui représente le terminal qui a changé de points
d’attachement tout en maintenant la communication grâce au « Home Address »,
•
HA (Home Agent) qui est un routeur dans le réseau mère et
•
FA (Foreign Agent) qui se trouve dans le réseau visité par le MN.
Quand le MN bascule, le MN enregistre le « Care of address » auprès le HA à travers le
FA. Quand un hôte de communication (CH) envoie les paquets de données par le routage
IP au MN dans le réseau mère, HA intercepte ces paquets, les encapsule en mettant la
CoA comme adresse destinataire. Finalement, le HA les envoie à MN. Un tunnel virtuel
entre CH et MN est alors supporté. Mais ce routage triangulaire peut provoquer de la
congestion au niveau transport.
L’évolution de IPV6 est un routage optimisé. Grâce à l’enregistrement de l’association de
deux adresses d’un MN (Binding) dans le nœud correspondant (CN), la communication
peut être maintenue directement entre le MN et le CN.
mSCTP est défini comme SCTP avec la capacité de la reconfiguration dynamique pour
l’adresse. Il est principalement prévu pour une architecture de type client/serveur, avec le
client mobile qui initie l’association avec le serveur fixe (FS). Le mobile obtient une
nouvelle adresse IP auprès de cette association et remplace l’ancienne.
Cependant, pour la continuité de service, devant l’hétérogénéité des ressources, nous
avons recours au HandOver Vertical (VHO) pour assurer l’adaptation requise pour la
QoS de bout en bout. Une décision du handover vertical dépend de plusieurs paramètres
concernant le réseau auquel le terminal est relié et celui auquel il sera connecté. Par
exemple, nous aurons les informations de largeur de bande de réseau, la charge, la
couverture, le coût, la sécurité, la QoS, ou même la préférence de l'utilisateur. La
préférence de l'utilisateur est importante, par exemple, si le nouveau réseau, dans lequel
un dispositif mobile exécute un handover, n'offre pas la sécurité, l'utilisateur peut décider
de rester dans l’ancien réseau. Selon la couverture, un utilisateur peut souhaiter employer
un lien sécurisé pour son trafic officiel d'Email (par exemple en utilisant GPRS), mais peut
choisir un lien moins coûteux pour accéder à l'information du Web (par exemple WLAN).
8 / 80
Dans l’environnement hétérogène, nous avons étudié la technologie de l’UMA (Unlicensed
Access mobile) et la norme de IEEE 802.21 MIH (Media Independant Handover) pour
savoir les façons de rendre possible le handover Vertical dans un environnement
hétérogène (handover hétérogène).
Dans la suggestion d'UMA (Unlicensed Access mobile) ce genre de handover hétérogène
est basé sur l’idée qu'à l'avenir les utilisateurs préfèreront avoir un seul terminal puissant
(faisant tout) que plusieurs équipements indépendants.
La technologie UMA rend possible le basculement automatique du réseau WiFi aux
réseaux mobiles sans intervention de l'utilisateur. Elle a pour objectif d'offrir un accès aux
réseaux GSM (Global System for Mobile communications) et GPRS (General Packet
Radio Service) par l'intermédiaire de réseaux Bluetooth ou WiFi. La connexion de l’UMA
se fait soit de manière classique via le réseau mobile (lorsque l'abonné est à l'extérieur),
soit par le biais d'un réseau local radio (lorsque ce même abonné se trouve chez lui, dans
une entreprise ou dans la zone de couverture d'un hot spot Wi-Fi). Elle a été développée
par un consortium d'entreprises nommé UMAC comptant entre autre Alcatel, Cingular,
Ericsson, Motorola, Nokia, Nortel Networks, Siemens, T-Mobile et Kineto Wireless.
L'objectif ultime de l'UMA est de faire converger les protocoles de communications des
téléphones mobiles, fixes et informatiques.
Le standard UMA permet le handover hétérogène entre les deux réseaux en autorisant le
transport des communications et de la signalisation sur le réseau IP. Avec l’architecture
proposée par l’UMA (Figure 4), quand le téléphone mobile détecte un UMAN, il établit une
connexion IP sécurisée à travers une passerelle vers un « UMA Controller » (ou GANC,
GAN Controller). Ce dernier transforme le signal provenant du mobile pour le faire
apparaître comme provenant d’un autre relais GSM. Par conséquent quand un utilisateur
passe d’un réseau GSM vers un réseau Wifi, le cœur du réseau téléphonique considère
simplement que le mobile a changé de relais GSM, comme pour un handover GSM
classique. Il n’y a donc pas de coupure de communication alors que l’on passe d’un média
GSM à un média Wi-Fi ou bluetooth.
Figure 4 : L’architecture de l’UMA (spécification de l’UMA)
Pour supporter la mobilité, dans l’architecture UMA proposée par le 3GPP 43.318 (Figure
5), la passerelle de sécurité (SGW : Security Gateway) authentifie l'utilisateur avant sa
connexion de WLAN au réseau cœur. SGW peut consulter le HLR dans le réseau Home
9 / 80
pour les informations de l’utilisateur. Après l’authentification faite par le Serveur de AAA,
les paquets peuvent être envoyés.
Mais la non prise en compte de l’aspect QoS quand un mobile de l’UMA bascule vers les
réseaux sans fil et la nécessité de contrats entre opérateurs pour le roaming limitent l’UMA
à un environnement domestique ou à un petit bureau.
Figure 5 : l’architecture de l’UMA
IEEE 802.21 introduit le concept de MIH (Media Independant Handover) (pour réaliser le
handover hétérogène entre technologies sans fils hétérogènes (Figure 6). Le but principal
de ce standard est de gérer une connectivité sans discontinuité des différents réseaux
sans fil. Cette norme gère le handover entre les réseaux cellulaires, la téléphonie mobile,
le WiFi et le Bluetooth (concept de handover diagonal).
Figure 6 : L’architecture de la norme de 802.21
10 / 80
Son objectif est de combler les lacunes des réseaux 802 qui permettent la détection et la
connexion aux points d’accès de leurs réseaux mais pas encore aux points d’accès des
autres réseaux. Il faut donc gérer la continuité de la connexion et les paramètres de
sécurité liés aux différentes normes. De plus, il faut lier les différents réseaux sans fil entre
eux.
De plus, pour évaluer les temps de réaction, il est important d’identifier le rôle des acteurs
(terminal et réseau) intervenant dans le mécanisme de handover. Les types suivants sont
définis, à savoir : Initiateur, Contrôleur et Agent (collecteur des informations).
Les différents cas sont :
• Dans une procédure du handover, l’acteur qui active la procédure est appelé Initiateur,
celui qui contrôle le changement est appelé Contrôleur et celui qui prend les mesures
pour alimenter les informations décisionnelles est appelé Agent.
MS
Source
BSS
Target
RNC/BSS
3G/2G
SGSN
1. Handover decision
2. PS Handover Required
3. Relocation Request
4. Relocation Request Acknowledge
Figure 7 : PS Handover : Phase de Préparation
•
Par exemple (Figure 7), dans une phase de préparation du handover dans le domaine
de PS (Packet Switch), c’est le BSS ancien qui décide de faire le handover, la procédure
de handover est contrôlée par le SGSN qui se trouve en bordure du réseau cœur, le
rapport de mesure sur la cellule où le terminal mobile arrive est fourni par le mobile,
l’information de capacité de la cellule est indiquée par le RNC/BSS du réseau d’accès.
En résumé, dans la plupart des cas que nous avons étudiés, le handover est initialisé par
le point d’attachement du sous réseau d’accès au réseau cœur (réseau initiateur), contrôlé
par le point d’attachement du réseau cœur (réseau contrôleur) et selon un rapport de
mesure fourni par le terminal (Agent terminal) et l’environnement de réseau (Agent
réseau).
Par ailleurs, le handover peut être classé aussi selon les différents objectifs de qualité de
service :
• Seamless handover : ce type de handover est destiné à offrir une session sans
coupure pour l’application et à respecter la QoS de bout en bout, ainsi que la
continuité de la session sans couture.
• Smooth handover : ce type de handover est destiné à minimiser la perte de paquet.
• Fast handover : ce type de handover est destiné à minimiser le délai du handover.
Le délai du handover est la différence temporelle entre l’émission/réception de
paquet du router précédent et l’émission/réception de paquet du router suivant.
11 / 80
En conclusion, les différentes techniques que nous venons d’évoquer couvrent bien la
mobilité du terminal de façon transparente à l’utilisateur. Mais le terminal ne représente
q’une partie de la mise en relation de bout en bout, qu’en est-il de cette liaison lorsque
l’utilisateur se déplace et change de terminal ? Et que devient la QoS de bout en bout par
rapport au service auquel nous accédons. C’est ce que nous allons étudier dans les
paragraphes suivants.
Mobilité de l’utilisateur
La « mobilité de l’utilisateur », dénommée aussi « mobilité personnelle », se rapporte à la
capacité de l'utilisateur (everyone) à utiliser n'importe quel terminal (anyhow) pour accéder
à des services (every services) anywhere et anytime (Figure 8). L’utilisateur désire au
cours d’une même session changer de terminal tout en gardant la personnalisation de son
service.
•
•
•
•
•
•
•
Cette mobilité personnelle induit les fonctions suivantes sur lesquelles nous reviendrons
par la suite :
Localisation
Adaptation (les profils)
Accès sécurisé
Identification
Authentification
Autorisation (contrôle d’accès)
Enregistrement/ dé-enregistrement.
Figure 8: Mobilité de l’utilisateur
Les solutions existantes sont peu nombreuses.
Nous retrouvons le protocole Mobile IP en établissant l’association entre le CoA du
terminal destinataire et l’adresse permanente de l’utilisateur.
Il y a aussi le protocole SIP (Session Initiation Protocol) qui supporte cette mobilité (Figure
9) dans la couche Application par la fourniture d’une même adresse logique. Il y a une
mise en correspondance des différentes adresses. C’est au Proxy (P CSCF) et à la
12 / 80
fonction de redirection de faire la traduction entre plusieurs identités sur différents
terminaux. Cette dernière redirige la communication durant la session de service. Les
[email protected];
[email protected];
et
adresses
logiques
de
[email protected]; pointent en fait vers le même utilisateur (Alice).
Par ailleurs, l’utilisateur d’aujourd’hui possède plusieurs terminaux et plusieurs accès, ce
qui pose le problème de sa joignabilité.
Figure 9: mobilité de l’utilisateur supporté par SIP
En effet, la communication s'est enrichie au cours des âges d'une panoplie d'outils d’abord
de diffusion (telex, TSF, télévision, …), puis d’échange (courrier, le fax, le télex…) et
beaucoup plus récemment de moyens de communication plus interactifs et libérés des
contraintes de temps, de lieu et d’espace (téléphone, visioconférence, internet…) rendant
ainsi les interactions plus faciles et accessibles. L’arrivée des nouvelles technologies
numérisant les échanges et les contenus a apporté plus de flexibilité mais également un
florilège de technologies facilement accessibles et personnelles. En fait, on peut dire que
l’utilisateur dispose maintenant d’une «bulle de communication», individuelle, personnelle,
avec différentes possibilités pour communiquer tels que téléphone fixe, téléphone mobile,
fax, messagerie électronique, messagerie instantanée. En s’affranchissant de problèmes
spatiaux et temporels. Mais il ne faut pas oublier que c’est la même personne qui le matin
est abonné entreprise et le soir abonné résidentiel. Même parfois, il porte les casquettes
alternativement soit à son domicile soit à son lieu de travail. C’est pourquoi nomadisme et
ubiquité sont désormais intégrés dans les usages et les comportements.
En conclusion, pour résoudre la « mobilité de l’utilisateur », nous devons gérer cette
joignabilité à travers la connaissance de son parc de terminaux et de sa localisation pour
qu’il puisse, dans toutes les occasions (lieu et temps), indépendamment des terminaux
utilisés être accessible. Nous devons également tenir compte des préférences et de la
QoS demandée afin d’organiser de façon transparente et sans couture les changements
de ressource suite à ce type de mobilité.
Mobilité de service
L’augmentation massive des besoins de service a conduit ces dernières années les
opérateurs de télécommunications à prendre en compte de plus en plus sérieusement la
préparation des offres de service dans leurs stratégies. De plus, les opérateurs
s’intéressent au développement de service prêt à être lancée sur le marché avec un TTM
minimum et un ROI le plus rapide. En considérant les services existant et les
13 / 80
concurrences entre les différents opérateurs, la transorganisation devient un verrou à
lever. Ce dernier introduit la notion de la « mobilité de service ».
En fait, si l’on traite cette mobilité à travers une vraie transorganisation avec
l’hétérogénéité du paysage du monde Télécom, nous devons repenser l’architecture.
Cette architecture doit tenir compte des aspects de services composables provenant de
plusieurs fournisseurs et du contexte ubiquitaire.
Pour l’instant nous trouvons (Figure 10- gauche) principalement des architectures
orientées « client-serveur », c’est-à-dire des architectures verticales et monolithiques. Or
la prise en compte de la mobilité de terminal peut impacter la QoS de bout en bout. Donc,
si on veut offrir l’accès au service de n’importe où, il faut pouvoir offrir le même service
dans la zone de présence de l’utilisateur. L’architecture devient alors de type horizontal
(Figure 10-droite) avec des propriétés d’ouverture.
Figure 10: mobilité de service
Ce que préconise ce schéma, c’est une couche indépendante qui supporterait la
composition de service comme nous le verrons plus tard. Cette composition de service
permettrait de répondre à tous les besoins de notre « User Centric ».
Grâce à cette vision de service, la virtualisation des services, la mutualisation de services
et le support de la décision flexible sont possibles. La mobilité de service peut donc être
supportée.
Mobilité de session
La prise en compte des mobilités lance un défi important pour maintenir les sessions sans
coupure.
Dans le domaine de télécommunication, la notion de « session » est une succession
d’interactions entre les deux extrémités du transport. Les services de transport sont des
services de communication point à point, c'est-à-dire avec deux interlocuteurs. Une
session est définie comme un ensemble d’échanges point à point avec un interlocuteur
engagé dans la mise en relation. Mais le modèle référentiel OSI (Open Systems
Interconnection) doit convenir s’étendre aux communications multipoints.
Dans le domaine d’IP, session est définie comme la connexion logique entre les parties
impliquées dans une communication basée sur PS (Packet Switched). Ce terme est utilisé
pour les connexions IP. Dans le cas des «sessions Web» notamment, le terme «session»
désigne une connexion de niveau application, voire un contexte partagé par plusieurs
connexions de niveau application sans support protocolaire. C'est un usage dérivé des
systèmes d'exploitation.
14 / 80
Il y a des sessions proposées entre différentes entités du réseau. Par exemple, la session
de la carte UICC (UMTS Integrated Circuit Card) à partir d’un terminal. La séquence de
commandes reliées est livrée à cette carte, à partir de laquelle nous obtenons les
réponses. Une application commence par la sélection et se termine par la fin de la session
de la carte. Dans la session de la carte, il y a la session du canal, qui est là pour échanger
les requêtes et les réponses entre la carte et l’entité externe dans le réseau. Au niveau de
l’accès, il y a la session GPRS qui couvre l’attachement GPRS. Pour le mode PS, la
session IP-CAN concerne l’association entre UE et réseaux IP. Avant l’entrée du monde
IP, pour la session du domaine de PS, il y avait la session PDP pour l’échange des
contextes PDP qui indiquent les profils de QoS jusqu’au GGSN.
TISPAN (Telecommunications and Internet converged Services and Protocols for
Advanced Networking) définit une session multimédia multicast entre des expéditeurs et
récepteurs, contenant les flux de données. Elle est supportée par les réseaux NGN (Next
Generation Network) et les connectivités IP.
IMS (IP Multimedia Subsystem) fournit une couche intermédiaire pour passer du mode
appel classique (circuit) au mode session. Un utilisateur peut ouvrir plusieurs sessions
multimédia IP au cours d'une même communication. Par exemple rajouter une session de
chat à de la vidéo, envoyer une photo pendant la conversation.
Par ailleurs, TINA (Telecommunications Information Networking Architecture) introduit
trois types de session (Figure 11): la session d’accès, la session de service et la session
de communication pour identifier les différents acteurs intervenant dans le service
demandé par l’utilisateur.
Figure 11 : Définition de sessions dans TINA
La session d’accès est un environnement pour garantir l’association entre les objets
définis. Elle couvre les objets ainsi que les interactions nécessaires pour la création et la
gestion de la session service.
La session de service (Figure 12) est un environnement pour un service spécifique, elle
relie un utilisateur (résidant dans le contexte d’un terminal) et un fournisseur de services
sur le réseau.
15 / 80
Figure 12 : Session service
Cette session permet de véhiculer la signalisation à destination des services. Une
session de services peut déboucher, dans le cadre de l’exécution de certains services,
à l’établissement d’une session d’information au dessus de la session de services,
correspondant à un flux d’information entre une source d’information et un récepteur.
C’est par exemple le cas pour des services à base de transfert de fichiers (FTP).
La session de communication représente la relation existante entre le terminal de
l’utilisateur et le réseau. L’existence d’une telle session assure à l’utilisateur la
possibilité de communiquer avec le réseau, ce qui lui permet le cas échéant d’ouvrir
une session de services.
En conclusion, la session est toujours la mise en relation temporelle, concernant un
service dédié. Des spécifications récentes sont proposées pour la redéfinition de
session de bout en bout et multi services. Plus précisément, en rajoutant un appel
basé sur le circuit à la session d’IMS, la session de bout en bout devient une session
combinée entre deux utilisateurs. Dans ce cas là, les instances de services individuels
sont orientées par un UE de l’utilisateur A et se terminent dans un autre UE de
l’utilisateur B.
Par ailleurs, le protocole SIP fournit une transparence de redirection du service vers un
autre terminal par « SIP Registrer » et « Location Services Server ». Ces composants
maintiennent tous les terminaux possibles liés à un utilisateur et les adresses
permanentes et provisoires de chacun de ces terminaux. SIP est un support qui nous
permet, entre autre, d’avoir une vision de tous les équipements qui sont autour d’un
utilisateur et d’avoir la possibilité de choisir la destination pour un utilisateur.
Mais si l’on veut prendre en compte les besoins de NGN, notamment les impacts de
toutes les mobilités, il nous reste à traiter le dernier tronçon de la mise en relation c'est-àdire, la prise en compte de la mobilité de service. Surtout qu’un ensemble de sessions
parallèles (une par application) ne permet pas d’avoir une vision « User Centric ».
En effet, pour l’instant la « mobilité de session » n’est proposée que du côté des
terminaux et du réseau, avec un handover BBM (Break-before-make), dans le cas « avec
couture ».
Le handover BBM coupe le raccordement existant avant d’en établir un autre, donc avant
que la transmission avec le nouveau point d’accès soit établie.
Par contre, le « sans couture » demande un handover MBB (make-before-break) qui fait le
nouveau raccordement avant de couper celui qui existe.
Évidemment, les utilisateurs ne sont pas disposés à accepter la dégradation de la qualité
de service, de la sécurité et des capacités. Si on veut faire de la qualité de service de bout
en bout, il nous faut aussi avoir un « handover de service » avec une continuité de service
et une certaine flexibilité pour couvrir toutes les mobilités en même temps.
1.2. Les éléments d’évolution
Les éléments d’évolution sont de plusieurs natures. Nous avons ceux relatifs au contexte
(§1.2.1) de mise à disposition d’outils de traitement. Puis vient ensuite l’évolution des mise
16 / 80
en relation, des liens télécoms (§1.2.2). L’évolution de l’organisation de ces composants
de traitement et de leur interconnexion conduit à une évolution des architectures (§1.2.3)
qui induit un changement dans la conception (§1.2.4) de ces mêmes composants. Pour
terminer, l’objectif de convergence (§1.2.5) finit par concerner tous les éléments de notre
nouveau paysage.
1.2.1 Evolution du contexte
Pour bien comprendre la notion de « User Centic », il nous faut la positionner par rapport
à « System Centric », « Network Centric » et « Application Centric ».
« System Centric » (Figure 13) est basé sur OS (Operating System) supporté par le
hardware où il est installé. Les applications tournent parallèlement dans cet OS grâce
au Compilateur C’est le Compilateur qui fait la traduction et l’optimisation statique pour
avoir une meilleure exécution de service. Si l’utilisateur a besoin d’une application qui
n’existe pas dans le système, les algorithmes associés sont obligés d’être traduits par
le Compilateur.
Il est à noter que pour éviter les re-traductions pour une application à cause des
changements des OS, VM (Virtual Machine) (Figure 13- droite) est proposé comme un
middleware pour cacher l’hétérogénéité des OS. Grâce à cette couche intermédiaire,
les applications développées n’ont besoin que d’une seule Compilation pour être
utilisées sur n’importe quel OS.
Figure 13: System Centric
Par contre, « Application Centric » (Figure 14) se concentre sur l’application et la
considère comme le point de départ et le système est contingenté par l’application.
Dans un système « Application Centric », le programme est chargé en premier, le
Compilateur s’exécute en temps réel pour une adaptation de l’OS. Pour l’aspect
architectural, la capacité de calcul parallèle est demandée.
Hardware
OS
Compiler
Application
Figure 14: Application Centric
« Network Centric » (Figure 15) implique que les infrastructures du réseau soient au
cœur de l’architecture, elles conditionnent toutes demandes de services.
L’hétérogénéité du réseau impose des solutions différentes pour un service
demandé à travers un support de connexion. Les communications peuvent être
17 / 80
parallèles mais des technologies de handover sont nécessaires pour passer d’un
réseau à l’autre.
Figure 15: Network Centric
Avec une approche « User Centric » (Figure 16) c’est l’utilisateur qui conditionne le
système, la personnalisation des services qui doit être mise en œuvre, à travers une
connexion temporelle avec le système, c'est-à-dire, à travers une session unique que
l’utilisateur désire établir dynamiquement à travers les accès offerts durant ses
déplacements selon ses préférences et selon la QoS (Quality of Service) désirée. Le
principal impact de cette approche est que le système complet est « au service » de
l’utilisateur contrairement aux autres approches où l’utilisateur doit se plier aux différentes
contraintes de traitement (System Centric) ou de connexions (Network Centric).
Figure 16: User Centric
1.2.2 Evolution des Télécoms
Comme le montre la Figure 17 , les mises en relation sont passées d’une relation de N
utilisateurs vers une unité de traitement centralisée, vers des organisations décentralisée
où chaque utilisateur possède son unité de traitement. Puis devant les problèmes de
synchronisation des applications et de consolidation des données, nous sommes passés
dans une structure distribuée où l’utilisateur a plusieurs moyens d’accès à son
environnement. Les mises en relation d’aujourd’hui sont de type N à N car notre utilisateur
à plusieurs rôles. Il peut être utilisateur, client, collaborateur, etc.
18 / 80
Figure 17: Evolution des Télécoms
1.2.3 Evolution des architectures
Une architecture est une structure d’ensemble pour obtenir les propriétés désirées. C'està-dire que la structure est porteuse de la sémantique des objectifs à atteindre. C’est
pourquoi, dans un couplage fort entre l’utilisateur et chacune de ses applications, nous
avions et avons encore des architectures spécifiques répondant aux propriétés de chacun
des flux applicatifs. Ces architectures sont dites verticales par opposition à celles que
nous devons mettre en place où le lien avec l’application devient lâche, puisque cette
application n’est plus monolithique mais est le résultat d’une composition d’éléments de
service. Nous pouvons résumer cette évolution (Figure 18) dans le Tableau 1 ci-dessous.
Architecture verticale
Architecture horizontale
Client serveur
Distribuée
Un fournisseur
Plusieurs fournisseurs
Plusieurs liens de services
Un lien de services
Couplage fort
Couplage lâche
Tableau 1: L’architecture verticale versus architecture horizontale
19 / 80
Figure 18: Evolution des architectures
1.2.4 Evolution de la conception
Cette évolution (Figure 19) est capitale car elle impacte l’aspect fonctionnel et
informationnel. En effet au niveau de la conception, on est passé de l’orientée traitement
qui produisait des applications séquentielles et monolithiques d’où les architectures en
silos, à l’orientée objet. Les architectures furent distribuées mais la structuration objet
induit des liens forts. C’est pourquoi nous nous orientons vers la notion de service qui
préconise des liens lâches. Donc le périmètre fonctionnel de notre service se définit par
rapport à des spécifications d’utilisation indépendamment des enchainements. Ainsi les
spécifications de production peuvent reposer sur plusieurs technologies différentes pour
un même rendu.
Figure 19: Evolution de la conception
Pour l’aspect informationnel, on passe d’une approche fichier, base de données
(BdD) à une approche modèle informationnel (MI) et base de connaissance afin
d’avoir des données décisionnelles (BdC).
1.2.5 Evolution de la convergence
Le mot convergence (Figure 20) réunit en fait deux convergences : celle des réseaux
et celle des services.
La convergence de réseau désigne la possibilité d'offrir les mêmes services à partir
de différents réseaux d'accès. Par exemple, le même service de téléphonie peut être
20 / 80
utilisé à travers un accès ADSL ou un accès mobile 3G. C’est ce que nous trouvons
sous des appellations comme "convergence fixe-mobile" ou "convergence
voix/données"
Figure 20: Evolution des convergences
La convergence de services désigne l'intégration de services différents (différentes
fonctionnalités, voire différents fournisseurs) au sein d'un même environnement de
service, à l'initiative de l'utilisateur, ces services pouvant alors partager certains
attributs et coopérer entre eux. Par exemple, dans un tel environnement, l'utilisateur
peut avoir souscrit à un service de téléphonie et à un service de webmail qui
partageront tous deux le même carnet d'adresse contenant à la fois les numéros de
téléphone et les adresses email. Ou alors, l'état de présence d'une personne, captée
par un service de présence, peut être un critère pour le déclenchement d'un renvoi
d'appel. Lorsqu'un nouveau service est ajouté à l'environnement d'un utilisateur, ce
service coopérera avec les services existants. Mais cette convergence de services
va maintenant jusqu’à intégrer les services IT (de type billing) et les services Web.
Effectivement, un service IPTV, au-delà du transfert du média, il faut intégrer des
services de découverte, de sélection et du billing on line pour des vidéo à la
demande (VoD).
Cette convergence de service peut être réalisée indépendamment de la convergence
de réseau, comme on peut le constater avec les services Internet. Des fournisseurs
de services comme Google offre déjà des services user-centric. Le mail (gmail),
l'agenda (google agenda) et la communication instantanée (google talk) sont
capables de coopérer afin de fournir un environnement de service unifié à
l'utilisateur.
Mais notre but dans UBIS c’est de combiner la convergence de services et la
convergence de réseaux quelque soit le type de service demandé.
21 / 80
2. Le quoi
Ce que nous venons de décrire se représente et se résume sur le schéma suivant la
Figure 21, avec une vision User Centric qui tient compte des préférences, de l’agenda et
de la localisation de l’utilisateur :
Figure 21: Le quoi : Contexte et Périmètre
Ce nouveau contexte englobe donc :
• Le futur Internet, Internet des services, les réseaux et services ambiants
• La coopération entre réseaux hétérogènes
• La convergence fixe-mobile (Réseaux)
• La convergence des services (Telco, Web, IT)
• La convergence des trois plans (interfaces)
• La gestion autonome et automatique
• La gestion du contexte
2.1. La nouvelle vision :
L'utilisateur est donc métaphoriquement au centre d'un écosystème de services. Nous
avons nommé cette nouvelle vision (Figure 22) "user-centric".
22 / 80
Figure 22: Nouvelle Vision
Nous avons structuré en quatre niveaux de visibilité notre monde UBIS :
- le niveau de l’utilisateur avec un environnement de « seamless Userware » lui
permettant d’accéder au système à travers n’importe quel terminal et même de changer
de terminal durant la même session.
- Le niveau Réseau d’accès, sachant que nous avons déjà la convergence à ce niveau.
- Le niveau Réseau cœur
- Le niveau Service pour lequel nous préconisons la convergence.
Les enjeux stratégiques de cette nouvelle vision reposent sur les deux piliers que sont le
TTM (Time To Market) le RoI (Return on Investisment).
2.2. Définition d’une architecture
Une architecture est une structure d’ensemble ;
Elle définit des règles de composition du système et de coopération des composants, à des
fins de transparence pour l’utilisateur.
Une cohérence parfaite des différentes parties du réseau et une grande modularité sont
nécessaires, car chaque partie doit pouvoir être modifiée ou remplacée sans affecter les
autres.
Une architecture s’analyse selon deux aspects :
• Une architecture physique qui repose sur l’organisation, le dimensionnement et
l’interconnexion des composants matériels ainsi que sur une topologie à des fins de
configuration optimisée à des coûts appropriés.
• Une architecture logique, fonctionnelle qui rend un service à travers des entités
logicielles distribuables et migrables.
Une architecture se décline en trois plans :
• Plan usager pour le transfert des données utilisateur ;
• Plan de contrôle pour la signalisation ;
• Plan de gestion pour les transferts de données d’administration.
23 / 80
Une architecture se compose de trois axes de gestion :
• La gestion du nœud l’équipement ;
• La gestion du flux ;
• La gestion du service.
Figure 23: Modèle générique au niveau d’un nœud de l’architecture
Ce modèle générique (Figure 23) permet de représenter l’ensemble des éléments
définissant l’architecture. En particulier nous avons les trois plans et les trois axes de
gestion.
2.3. L’ingénierie des architectures
Afin de faire face aux évolutions que nous avons identifiées, il nous faut des solutions qui
considèrent l’architecture globale. En effet, on peut noter que les solutions du niveau
réseau d’acheminement étudient l’évolution de l’infrastructure des plates-formes de
connectivités (UMTS, xDSL, IP/MPLS, etc.) et les problématiques de QoS qui en
découlent (différentiation des flux, routage, réservation de ressources réseau, etc.) en ne
considérant que ce niveau réseau et le bout en bout transport. Or il nous faut intégrer le
niveau service pour répondre aux besoins de réactivité et de flexibilité exigés par les
architectures d’aujourd’hui pour deux raisons :
La première raison est que l’organisation de l’architecture est faite de manière « overlay »,
c'est-à-dire que les deux niveaux coexistent sans interaction dynamique entre eux.
La deuxième raison est que le développement des services dépend d’une pile protocolaire
pour chaque nouveau service, c’est-à-dire que pour chaque nouveau service, une pile
protocolaire est développée. Cette solution (architecture verticale) n’est plus viable à
l’heure des services personnalisés où chaque utilisateur peut définir son propre service.
Dans un tel environnement, la variété de services proposés peut être très importante et le
cycle de vie des services peut être très court.
Pour répondre au besoin d’optimisation du Revenu Moyen par Utilisateur (ARPU), les
opérateurs et fournisseurs de services doivent avoir les moyens leur permettant d’évaluer
24 / 80
les impacts d’un niveau architectural (réseau, service, etc.) sur l’architecture globale, afin
de faire face à l’évolution rapide des besoins à travers une rapidité de déploiement de
nouveau services à valeurs ajoutées et la fourniture de ces services conformes aux
attentes des utilisateurs (QoS de bout en bout).
Cette vision nécessite l’intégration de l’architecture des fournisseurs de service à tous les
niveaux (les équipements matériels, le réseau de transport, les plates-formes de services RI, OSA, SIP AS, etc.- et les plates-formes de prise en charge de la personnalisation des
services), et à toutes les vues, à savoir : l’intégration verticale, c’est-à-dire, qu’une
décision ne peut être prise à un niveau sans une cohabitation avec les autres niveaux et
sans pouvoir évaluer les impacts d’une telle décision sur les autres niveaux et notamment
sur la perception des usagers finaux (QoS de bout en bout), et l’intégration horizontale,
c’est-à-dire, que sur un niveau donné, quelque soit les sous-domaines traversés
(exemple, pour le niveau réseau de transport, les sous-domaines peuvent être des sousréseaux dans le sens adressages, des zones de routage dans le sens routage intradomaine, des systèmes autonomes dans le sens routage inter-domaines, ou simplement
une juxtaposition de réseaux hétérogènes (IP, ATM, Wifi, etc.)), une coopération de ces
sous-domaines doit être maintenue afin que la QoS (horizontale) de ce niveau soit
respectée.
L’objectif global est de donner des clés à cette problématique en mettant en œuvre un
concept d’intégration globale des architectures de télécommunications en incluant tous les
acteurs superposés de la chaîne de bout en bout : équipements matériels, le réseau de
transport, les service et les usagers de ces services. Nous avons baptisé ce
concept « Ingénierie d’Architecture » qui se base sur des modèles de cohabitation et
coopération pour rendre cette superposition la plus transparente et réactive possible aux
nouveaux besoins qui régissent le monde des télécommunications aujourd’hui,
notamment les besoins aux nouveaux services personnalisés et à valeurs ajoutées qui par
conséquent nécessitent le maintien de la QoS de bout en bout tout au long de leur cycle
de vie.
Nous parlons de cohabitation pour une intégration verticale, afin d’assurer la consistance
de la structure d’ensemble, c’est-à-dire, que la superposition des blocs architecturaux
entre les niveaux soit fonctionnellement complémentaire et non redondante pour la QoS
de bout en bout, l’objectif étant d’automatiser les processus de déploiement de nouveaux
services et traduire leurs besoins en QoS. Notre approche repose sur deux principes :
principe de la déclinaison de la QoS et principe de l’agrégation de la QoS.
La déclinaison de la QoS fait référence au processus d’analyse de l’architecture globale
de haut en bas (top-down) en visant deux objectifs :
•
•
o
trouver une solution pour une QoS de bout en bout,
o
maintenir la cohérence de la structure d’ensemble.
L’agrégation fait référence au processus d’analyse de l’architecture globale de bas en
haut (bottom-up), c’est à dire les couches supérieures doivent recevoir des informations
de rétroaction des couches inférieures afin que les niveaux supérieurs s’assurent du bon
déroulement de la déclinaison et éventuellement relancer le processus de déclinaison
suivant ces informations de rétroaction.
Nous parlons de coopération pour une intégration horizontale, pour superviser et évaluer
en temps réel la QoS offerte à travers les différents « sous-réseaux » (domaine)
constituant le niveau horizontal (équipement, réseau, service ou usagers). Chaque
domaine est autonome, c’est-à-dire, responsable de la supervision de sa propre QoS
(SLA entre domaines).
Ce concept d’Ingénierie d’Architecture à travers la cohabitation et la coopération permet
de prendre en charge l’architecture des opérateurs et fournisseurs de services de
25 / 80
télécommunications, ainsi que l’introduction de nouveaux services et le maintien de la
QoS de bout en bout.
Mais, comment structurer ce niveau de service applicatif ? Pour ce faire nous allons
d’abord analyser l’existant.
2.4. Les architectures de service : analyse de l’existant
Dans la communauté de télécommunication, quelques acteurs ont développé une vision
plus prospective d'une prochaine génération des services, souvent représentée par le
terme « convergence ». Comme nous l’avons mentionné dans l’introduction, cette vision
unifie réellement deux genres de convergence qui devraient être distingués : convergence
de réseau et convergence de service. La convergence de réseau est l'essence du modèle
architectural du NGN ; elle vise à fournir les mêmes services par les différents réseaux
d'accès. Par exemple, le même service de téléphonie pourra être utilisé en se basant sur
un réseau d'accès câblé « ADSL » ou par un réseau mobile d’accès 3G. Cette
convergence de réseau a été métaphoriquement décrite comme un déplacement d'une
architecture verticale (où l’accès au réseau, le contrôle du réseau, et le contrôle de service
sont fermement liés) à une architecture en couches (où l’accès au réseau, le contrôle de
ce réseau, et le contrôle des services sont faites dans des couches indépendantes). Le
contrôle unifié de services fournit une interface aux applications. Cette interface pourrait
être un protocole (typiquement SIP) ou une interface applicative (API), comme dans le cas
de l’architecture Parlay/OSA (Open Service Architecture), ou bien un ensemble de
spécifications appelées « Enablers » comme dans le cas de l’architecture OMA (Open
Mobile Alliance). En effet, dans toutes ces architectures qu’on a cité ci-dessus, c’est
l’approche Telco (§2.4.1) qui apparait.
D’autre part, une deuxième approche existe, c’est l’approche Web (§2.4.2). En fait, elle
vise l’établissement et la maintenance en ligne de connexions plus fluides, plus flexibles et
plus riches entre les personnes, les services et/ou l'information. Spécifiquement, ces
connexions améliorées peuvent être créées et maintenues entre deux ou plusieurs
personnes, entre deux ou plusieurs ordinateurs et organisations fournissant des services
en ligne, ou entre des individuels et le contenu numérique et informationnel qu’ils créent,
manipulent et enregistrent.
En effet, il y a plusieurs architectures qui utilisent cette approche Web et qui assurent la
communication avec les utilisateurs, les opérateurs tiers et les 3rd parties en utilisant les
API Web Services comme dans le cas du Parlay X, ou bien les Web Services lors de la
création d’un processus métier.
Dans ce qui suit, on va présenter les différentes architectures de services selon ces deux
approches Telco et Web 2.0, ainsi que l’approche SOA recommandée par le monde de
l’IT (§2.4.3). La présentation de ces différentes architectures de services nous permettra
de proposer une solution pour l’architecture de services.
2.4.1 Les architectures Telco
Ce sont les architectures télécoms qui proposent des interfaces pour faciliter l’introduction
de composants de services, telles que celle du RI (§2.4.1.1), de Parlay/OSA (§2.4.1.2), de
Parlay X (§2.4.1.4), d’OMA (§2.4.1.4) et la dernière en date IMS (§2.4.1.5).
2.4.1.1 RI
Dans les années 1990, l’idée que le réseau téléphonique ne pouvait fournir que les
services qui étaient programmés dans le logiciel des unités de contrôle des commutateurs
26 / 80
devenait intolérable. Un nouveau concept se développa, celui du Réseau Intelligent (RI). Il
s’agit de trouver un moyen de rendre le réseau plus coopératif pour pouvoir programmer
plus rapidement et plus commodément des services dans des plates-formes extérieures
aux centraux téléphoniques.
Une première norme, développée par le laboratoire américain Bellcore, est publiée en 1990
sous le nom Advanced Intelligent Network (AIN). Cette norme est reprise et remaniée par
l’UIT (Union internationale des télécommunications). Elle est publiée en 1992 sous le nom
d’Intelligent Network (IN). L’industrie informatique, qui voit là un moyen de prendre pied
dans le monde des télécommunications par l’intermédiaire des plates-formes de services,
s’intéresse beaucoup à l’élaboration de cette nouvelle norme. Dans beaucoup de pays, en
particulier dans les pays en voie de développement, la Killer application (application à
succès phénoménal) des réseaux intelligents pour le grand public est réalisée par les
services prépayées qui évitent les surprises de facturation en fin de mois. Ces services
sont d’abord développés pour le réseau mobile. Pour ce faire, l’ETSI (European
Telecommunication Standards Institute) publie une nouvelle norme de réseau intelligent
adaptée aux nécessités du réseau mobile sous le nom de CAMEL (Customized
Applications for Mobile Enhanced Logic).
Après avoir introduit le concept du réseau intelligent, il faut maintenant le définir. En effet,
le RI est une technologie, basée sur un mécanisme de substitution du traitement d’appel
« par défaut » du commutateur par un autre traitement exécuté dans une plate-forme de
service. Nous disons ainsi qu’un réseau est intelligent, s’il est possible de substituer à la
séquence de connexion par défaut des commutateurs (service POTS), une autre séquence
programmée dans une autre plate-forme dite plate-forme de services appelée aussi SCP
« Service Control Point ».
Il découle de cette définition qu’un service se déclenche à partir du processus d’appel. La
technique « réseau intelligent » ne s’adresse donc pas à n’importe quel type de service,
elle ne s’adresse qu’à des services qui ne peuvent être réalisés que par le réseau et plus
précisément que par une séquence d’actions élémentaires qu’un commutateur peut
réaliser.
Pour créer des normes, les concepteurs du RI ont proposé un modèle dit « modèle
conceptuel » (Intelligent Network Conceptual Model, INCM) destiné à représenter un
ensemble de sujets devant être normalisés. Il est constitué de quatre plans où chacun
représente un type de sujet nécessitant d’être normalisé.
Le plan service décrit une vue qui ne prend en compte que les services. Le service est
décrit en langage naturel. Il consiste en un ou plusieurs éléments de service (FE, Service
Feature) dont chacun est un composant de service correspondant à une partie du service
ou au service lui-même. Cela signifie qu’un élément de service peut lui-même être un
service, c.à.d. correspondre à une offre commerciale. Généralement, un élément de
service est indépendant d’un service donné. Cela est le cas par exemple du service
d’authentification.
Le plan fonctionnel global donne une méthode formelle pour décrire le service de manière
non ambiguë. Selon cette méthode, le service est décrit par un enchaînement logique
d’éléments de description (ou composants) formels réutilisables (éléments de description
indépendants du service) appelés Service Independent Building Blocks SIB. En effet, au
cours de l’appel normal appelé BCP (Basic Call Process), le service du réseau intelligent
(traitement substitutif) peut démarrer à un point de débranchement de l’appel normal
appelé POI (Point Of Initialization). Ce service sera décrit par une suite de SIB. Il y aura un
ou plusieurs point de retour possibles vers l’appel normal, appelés POR (Point Of Return).
Cette suite de SIB obéit à la logique globale de service GSL (Global Service Logic).
Un SIB n’est pas un programme, c’est une description formelle d’activités (un opérateur)
agissant sur des données (des opérandes). Les SIB définissent une activité complète avec
un point de départ logique et un ou plusieurs points d’arrivées logiques. Les SIB doivent
théoriquement être réutilisables d’un service à l’autre et permettre de décrire tout service
ou toute fonctionnalité de service.
27 / 80
Treize SIB ont été définis : algorithm, charge, compare, distribution, limit, log, queue,
screen, service data management, status notification, translate, user interaction,
verification. A ces treize SIB, on doit ajouter le BCP considéré également comme un SIB.
Le plan fonctionnel réparti définit une architecture fonctionnelle d’exécution de service,
c.à.d. des fonctions logicielles appelées « entités fonctionnelles » constituant un
environnement d’exécution de tout type de service défini en conformité avec les méthodes
spécifiées dans les plans supérieurs. Les points de déclenchement et la signalisation INAP
(Intelligent Network Application Part) font également partie de la description de ce plan.
En effet, une entité fonctionnelle est un groupe spécifique de fonctions localisées dans un
même emplacement et constituant un sous-ensemble de toutes les fonctions nécessaires à
la fourniture d’un service. Du point de vue de la répartition des entités fonctionnelles dans
les entités physiques (du plan physique), il est à noter qu’une entité fonctionnelle
correspond entièrement à une entité physique spécifique et ne peut donc être répartie sur
plusieurs entités physiques. En revanche, des entités fonctionnelles différentes peuvent
être regroupées sur une même entité physique. De plus, toute interaction entre deux
entités fonctionnelles qui communiquent entre-elles est appelée « flux d’information ». Les
relations entre entités fonctionnelles sont donc définies par des flux d’information qui sont
normalisés.
L’architecture fonctionnelle d’exécution de service du RI est indiquée sur Figure 24. Dans ce
diagramme, on trouve deux types d’entités fonctionnelles : celles qui sont relatives à
l’exécution des services et celles relatives à la création et la gestion des services.
Figure 24 : Architecture fonctionnelle du réseau intelligent
Les fonctions relatives à l’exécution des services sont les suivantes :
• CCAF (Call Control Agent Function) représente le traitement d’appel d’un PABX
RNIS qui traite la signalisation avec la CCF et qui assure une exploitation de type
PABX à l’utilisateur ;
• CCF (Call Control Function) est la fonction de contrôle d’appel. Il s’agit du logiciel
de traitement d’appel des commutateurs ;
• SSF (Service Switching Function) est la fonction de commutation de service. Elle
détecte que les critères de débranchement vers un service substitutif sont vérifiés.
Cette entité assure l’ensemble des fonctions nécessaires à l’interaction avec les
entités CCF et SCF en particulier la détection des points de déclenchement du
service (d’appels à la SCF) et l’interprétation des commandes de la SCF. En effet,
28 / 80
dans le cas du réseau IMS relié aux applications du réseau intelligent, on parle
d’IM-SSF (IP Multimedia Service Switching Function) qui est équivalent au SSF.
• SCF (Service Control Function) est la fonction de commande de service. Elle
réalise le traitement d’appel substitutif pour les demandes de services RI. Elle
dispose de la logique et de la capacité nécessaires au traitement des services RI ;
• SDF (Service Data Function) est la fonction « données de service ». Elle regroupe
les données utilisateurs et réseau auxquelles la SCF doit accéder en temps réel
pour l’exécution d’un service RI ;
• SRF (Specialized Resource Function) est la fonction ressource spécialisée. C’est
la fonction de contrôle des ressources spécialisées (essentiellement des serveurs
vocaux) nécessaires à l’exécution des services assurés par le RI (réception de
chiffres, passerelles, etc.).
Les fonctions relatives à la gestion/création des services sont les suivantes :
• SMF (Service Management Function) est la fonction gestion de services. Elle
permet l’installation puis l’exploitation et la surveillance de services RI ;
• SMAF (Service Management Access Function) est la fonction agent d’accès de
service. Elle assure l’interface entre le personnel chargé de la gestion de services
et l’entité SMF ;
• SCEF (Service Creation Environment Function) est la fonction environnement de
création de services. Elle permet de définir, créer et tester des services assurés
par le RI puis de les transférer dans l’entité SMF.
Le plan physique du modèle conceptuel du RI décrit des scénarios pour implanter des
différentes entités fonctionnelles du plan fonctionnel réparti dans des machines physiques.
Le plan physique correspond donc à l’architecture matérielle d’un réseau structuré en RI.
La technologie réseau intelligent a eu un immense mérite : c’est la première tentative pour
mettre fin au modèle monolithique des commutateurs. Pourtant, cette avancée géniale n’a
pas porté ses fruits. La raison principale est la difficulté à introduire des nouveaux
concepts, compréhensibles de tous (surtout des développeurs) et propageables dans des
environnements où les technologies en vigueur ont la peau dure. Une non maîtrise des
concepts est source d’obstacles à leur mise en œuvre.
En effet, en analysant les normes du RI, on peut pointer du doigt deux écueils. Celui d’une
mauvaise définition des éléments de services du plan service et celui d’une utilisation non
adéquate du SIB.
Les éléments de service ont certainement été les plus mal lotis. La norme les cite presque
à titre d’exemple, sans définir les règles de structure, ni celles de composition de service.
C’est ainsi que nous avons été très vite confrontés « à l’interaction de ces services ». Or,
puisqu’aucun modèle d’information n’a été évoqué, la place était laissée à l’imagination et
donc aux problèmes d’interfonctionnement et de portabilités des composants.
Pour les SIB, on peut constater que devant la complexité du problème, les industriels
prirent de grandes libertés avec les normes. Au bout d’un an, il était courant de trouver
des réalisations avec quatre-vingt-dix SIB au lieu des treize initiales.
En fait, le plan fonctionnel global doit permettre l’expression de la logique de service. Donc
un SIB doit représenter « l’opérateur » permettant l’enchaînement. C’est un automate qui
exécute une opération logique. Ce n’est pas l’opérande, ce n’est pas la donnée qui
intervient dans l’opération. De plus, selon son nom « Service Independent building
Blocks », il ne faut pas prendre les SIB pour des blocks au sens composants de service,
car ce qui est important, c’est le mot building qui reflète le rôle des SIB dans la
construction des blocks de service. Si on va prendre les SIB pour des composants de
services, bien sûr que treize c’est peu.
Néanmoins, le réseau intelligent nous a fait rentrer dans l’ère des services.
Dans la suite, on va décrire les autres architectures de services existants.
29 / 80
2.4.1.2 Parlay/OSA
Pour que les applications distribuées puissent être mises en œuvre, elles se basent sur
les services offerts par le réseau sous-jacent. Cependant, cela induit une forte
dépendance de l’application à son environnement réseau et à la façon dont les services
réseaux sont implémentés. Or de nos jours, il y a plusieurs types de réseaux d’accès et un
grand nombre de vendeurs et de fournisseurs qui vont utiliser et proposer leurs services.
Par suite, la diversification des environnements est le premier défi devant lequel se trouve
le monde des télécommunications.
D’autre part, de point de vue « Business », les fournisseurs, les opérateurs et les 3rd
parties se confrontent à des problèmes budgétaires qui sont fermement reliés à trois
points clé, le premier est les lacunes au niveau de la création de nouveaux services
innovants, le deuxième est le TTM « Time to Market » et le troisième est le ROI « Return
of Investment ». C’est trois éléments influencent fortement sur les revenus, d’où un
deuxième défi se pose au niveau « Business » du monde des télécommunications. De
plus, si on fait une enquête pour savoir le pourcentage des services développés par les
développeurs IT, on trouve une faible valeur. En effet, la plupart des services sont
développés par les grands experts de télécommunication. Cela mène vers une limitation
du nombre des services développés et par suite vers un troisième défi auquel se confronte
le monde de télécommunication.
Pour adresser ces différentes problématiques et pour résoudre ces défis, trois
organisations ont échangées leurs expertises et leurs points de vue. Ces organisations
sont le 3GPP (The Third Generation Partnership Program), l’ETSI (European
Telecommunication Standards Institue) et le groupe Parlay. Ce dernier est un consortium
de multi-vendeurs ayant différents profils (vendeurs de services Internet, développeurs de
logiciels, bureaux de services, vendeurs et fournisseurs d’appareils réseaux, …). Le travail
commun de ces trois organisations a permis l’apparition d’une solution appelée
« Parlay/OSA ».
C’est une architecture de services ouverts, basée sur un ensemble d’API ouverts,
sécurisés et standardisés. Ces API sont facilement utilisables, riches en terme de
fonctionnalités, et tiennent compte de l’innovation dans les entreprises. Ainsi, les
applications développées seront sources de nouveaux revenus pour les opérateurs
réseaux, vendeurs de logiciels et fournisseurs de services d’applications. Cela répond au
premier défi.
D’autre part, les APIs développés sont indépendants des technologies du réseau (CDMA,
GSM, …) et permettent par suite le développement de nouveaux services multi-réseaux et
multi-environnements. En effet, l’apport de l’architecture de l’OSA concerne aussi bien les
développeurs d’applications que les opérateurs de réseaux. Du point de vue des
opérateurs, elle permet aux applications d’accéder de manière extensible et ouverte aux
capacités de réseaux. Ainsi, les opérateurs peuvent introduire de nouvelles fonctionnalités
sans avoir besoin de modifier les applications existantes. Du point de vue des
développeurs, elle fournit un ensemble standardisé d’interfaces permettant d’accéder aux
mêmes fonctionnalités de réseau indépendamment des technologies de réseaux sousjacents. Elle assure ainsi la portabilité des applications sur des réseaux différents. Cela
répond bien au deuxième défi.
Quand au troisième défi, ces APIs permettent la jonction entre le monde des télécoms et
le monde des IT. Ce couplage fort entre ces deux mondes mènent vers le développement
de nouveaux services innovants, non seulement par les experts du monde de
télécommunications mais aussi les développeurs IT.
Selon le modèle organisationnel, OSA (Open Service Access) est un ensemble d’API
permettant la médiation (Interface sécurisée) entre les réseaux de télécommunications et
les applications des opérateurs, des fournisseurs de services, des 3rd parties et des
MVNOs (Mobile Virtual Network Operators). Ces APIs sont définis par le langage CORBA
(Ex. Call Control, Terminals capacity, Presence, User Interaction, Generic Messaging,
Mobility APIs, Data Session, Charging, Connectivity and Account Management, …).
30 / 80
Figure 25 : Modèle organisationnel du Parlay/OSA
En se référant à la Figure 25, on constate le rôle central que joue le Parlay/OSA SCS, qui
est une passerelle qui permet aux fournisseurs de services, aux MVNOs et aux 3rd parties
d’accéder aux applications et services internes offertes par l’opérateur propriétaire de ce
SCS. L’accès aux services internes se fait en utilisant les OSA APIs définis selon le
langage CORBA. Cela facilite la création de nouveaux services innovants en se basant
sur des services de base. Le Parlay/OSA SCS joue dans ce cas le rôle du courtier qui va
assurer l’interconnexion entre les services de base et les services exposables.
D’autre part, on voit clairement les deux fonctionnalités du réseau IMS, qui viennent se
relier au SCS à l’aide de leurs protocoles correspondants. En effet, le S-CSCF (Serving
Call Session Control Function) va jouer le rôle d’un registre qui va mettre à jour le HSS et
qui va télécharger les profils des usagers. Cette fonctionnalité accède à la passerelle en
utilisant le protocole SIP. En outre, le HSS (Home Subscriber Server) qui est une base de
données centralisée, va enregistrer les profils des usagers et les paramètres d’accès
sécurisé (Authentification et Autorisation). Le HSS communique avec la passerelle en
utilisant le protocole DIAMETER.
En fait, toutes les fonctionnalités du réseau IMS y compris ces deux, vont jouer un rôle
intermédiaire permettant aux utilisateurs selon leurs profils et selon les contrats signés
avec l’opérateur, d’accéder aux services internes offerts par cet opérateur tout en
passant par la passerelle SCS. Ce dernier va assurer le partage des ressources offertes
par le réseau IMS.
D’une manière plus architecturale et plus précise, on peut voir, d’après la figure 4,
comment les OSA APIs sont situées. De plus, les applications qui apparaissent dans
cette figure et qui reposent sur OSA peuvent aussi bien être des services à valeur
ajoutée que des services offerts par des fournisseurs tiers.
L’interface OSA est composée de deux ensembles d’entités :
• Les SCF (Service Capability Function) sont des interfaces CORBA standardisées
qui fournissent aux applications l’ensemble des fonctionnalités du réseau. Il existe
deux types de SCF. Les premiers sont de type framework et offrent des
fonctionnalités afin de supporter la gestion d’abonnement et l’enregistrement aux
fonctionnalités réseaux et de fournir les mécanismes d’accès sécurisé. Les
seconds sont de type service réseau et offrent l’accès aux fonctionnalités de
réseau (par exemple User Interaction, Terminal Capabilities, Charging, Call
Control, Policy Management, …).
31 / 80
•
Les SCS (Service Capability Server) sont des serveurs de fonctionnalité de
services qui jouent le rôle d’intermédiaire entre l’interface SCF et l’entité de réseau.
Ils traduisent les invocations sur les SCF aux événements sur les éléments de
réseau.
Figure 26 : Architecture du Parlay/OSA
De plus, d’après cette même Figure 26, on peut constater la présence des OSA APIs
internes qui permettent l’interaction entre les différentes SCF afin d’en tirer des nouvelles
fonctionnalités et de nouveaux services à valeur ajoutée. D’autre part, les OSA APIs
externes permettent l’accès des applications externes aux services et fonctionnalités SCF
internes d’un opérateur donné. De plus, les SCF qui sont un ensemble de classes
d’interfaces, accèdent aux ressources offertes par le réseau sous-jacent en passant par le
SCS et par suite par les fonctionnalités S-CSCF et HSS du réseau IMS.
Le framework spécifié par le groupe Parlay fournit des fonctionnalités diverses pour gérer
la personnalisation de l’accès aux services réseaux. Cette personnalisation est fournie par
une architecture fonctionnelle et des informations de gestion de l’abonnement.
En effet, on peut voir, d’après la Figure 27, que le framework Parlay comporte trois
interfaces distinctes, l’une avec l’application, la seconde avec le SCS et la troisième avec
l’opérateur d’entreprise, qu’on va détailler ci-dessous :
Figure 27: Le framework Parlay
Les mécanismes entre le framework et l’opérateur d’entreprise : elles représentent
l’abonnement de service. Cette fonction représente un accord contractuel entre l’opérateur
d’entreprise et le framework. Dans le modèle métier d’abonnement (Figure 28), l’opérateur
32 / 80
d’entreprise joue le rôle de souscripteur/client et les applications jouent le rôle
d’utilisateurs ou consommateurs de services. Le framework lui-même joue le rôle de
détaillant de services.
Figure 28 : Le modèle métier de l'abonnement Parlay
L’interface entre framework et SCS qui permet l’enregistrement des SCF : les SCF offerts
par un SCS peuvent être enregistrés auprès du framework. Dans ce cas, le framework
serait capable de renseigner les applications sur les SCF disponibles (découverte).
Les mécanismes de base entre framework et Application :
• Authentification : le modèle d’authentification d’OSA suit un modèle peer to peer,
sans imposer une authentification mutuelle. En effet, une fois qu’un accord (horsligne) existe, l’application peut accéder à l’interface d’authentification.
L’authentification doit obligatoirement précéder l’accès à n’importe quelle autre
interface d’OSA.
• Autorisation : elle consiste à déterminer les droits d’une application déjà
authentifiée.
• Découverte de framework et les SCF : après une authentification réussie,
l’application reçoit les interfaces framework disponibles. Elle peut utiliser l’interface
de découverte (discovery interface) afin de recevoir des informations concernant
les SCF auxquels elle a le droit d’accéder.
• Etablissement du contrat de service : avant qu’une application puisse interagir
avec un SCF, un contrat de service doit être établi. En effet, ce contrat est déjà
signé entre l’opérateur d’entreprise et le framework. En outre, le contrat de service
peut comprendre deux parties, une partie hors-ligne et une partie en ligne.
L’application doit signer la partie en ligne avant de pouvoir accéder aux SCF.
• Accès aux SCF : après l’accès au framework, ce dernier doit fournir des fonctions
de contrôle d’accès afin de permettre l’accès aux SCF ou aux services de données
et ceci, pour n’importe quelle méthode d’API d’une application.
Finalement, après toutes ces étapes, les applications pourront ainsi accéder aux
fonctionnalités du réseau et aux services internes de l’opérateur.
D’autre part, si on étudie le modèle et l’aspect informationnel du Parlay/OSA, on constate
qu’il est constitué de trois éléments essentiels :
33 / 80
•
Le contrat de service : une fois que la négociation entre l’opérateur d’entreprise et
le framework est achevée, ce dernier génère un contrat de service qui correspond
au contrat passé avec l’opérateur d’entreprise pour un service donné. Il contient
les conditions d’usage d’un service réseau.
• SAG (Subscription Assignment Group) : l’opérateur d’entreprise peut regrouper au
sein de l’entreprise l’ensemble des applications qui utilisent un même service
réseau de la même manière. Chaque groupe constitue un SAG.
• Le profil de service : il est assigné à un SAG pour un service donné (défini par
l’opérateur d’entreprise). Il constitue une restriction du contrat passé pour un
service. En effet, des SAG différents peuvent avoir des contraintes différentes pour
un service qu’ils utilisent. Leurs profils de service différents permettent cette
différenciation.
Pour conclure, même si l'architecture Parlay/OSA cherche à permettre l'intégration des
différentes capacités de service spécifiés par différents organismes de normalisation, elle
ne peut pas être directement appliquée comme des moyens pour la gestion de la
composition de services dans l'IMS. En fait, afin d'adapter l'architecture Parlay/OSA à
l'IMS, une passerelle SCS doit être utilisée au dessus des composants IMS, tout en
utilisant les OSA APIs. Dans ce cas-là, la passerelle doit traduire les méthodes Parlay
APIs en des messages SIP. En outre, les fonctionnalités définies par cette passerelle
couvrent seulement le contrôle d'accès aux services et les notions de découverte de ces
services. La gestion de composition des services et la manière à partir de laquelle ils
devraient partager des blocs communs de composition de service ne sont pas spécifiées.
Ainsi, un environnement ouvert de convergence de service est nécessaire pour employer
des services Parlay/OSA dans un environnement de réseau réparti. Finalement, cette
solution implique une forte dépendance des services sur ceux définis dans les normes du
Parlay/OSA.
2.4.1.3 Parlay X
La solution Parlay X est conçue pour permettre la création des applications de téléphonie
aussi bien que des applications IT. Les développeurs IT, qui développent et déploient des
applications en dehors du modèle économique et de l’espace traditionnel de réseaux de
télécommunications, sont vus comme cruciale pour créer une forte croissance dans tout le
marché des applications, des services et des réseaux de nouvelle génération.
En effet, cette solution est basée sur un ensemble de « API Web Services » qui sont
facilement utilisables et qui assurent un haut niveau d’abstraction pour ces développeurs
IT. Ces services Web sont prévus pour stimuler le développement d’une nouvelle
génération d’applications par les développeurs IT qui ne sont pas nécessairement des
experts dans le monde de téléphonie ou de télécommunication.
De plus, ces services Web sont sélectionnés selon une utilité commerciale et non
nécessairement selon une élégance technique. Le but est de définir un ensemble de
possibilités et de capacités puissantes pourtant simples, fortement abstrait, imaginatives,
de télécommunications que les développeurs IT puissent rapidement comprendre et
utiliser afin de créer de nouvelles applications innovantes. De plus, ces services Web
suivent une simple sémantique d’application, ce qui permet aux développeurs de se
concentrer sur l'accès aux ressources et aux capacités de télécommunication tout en
utilisant des techniques de programmation communes de services Web.
En outre, les services Web utilisés sont indépendants des réseaux sous-jacent et des
équipements de ces réseaux, ce qui rend les capacités et les possibilités offertes par ces
services Web, accessibles par n’importe quel type d’équipement tout en utilisant n’importe
quel type de réseau.
34 / 80
D’autre part, afin de représenter les services Web et leurs caractéristiques, on associe à
chacun d’eux un document qui lui correspond. Ce document contient beaucoup
d’informations comme des définitions, des abréviations, une description détaillée du
service, l’espace de nom, un diagramme de séquences, une définition des types de
données (schéma XML), une définition des interfaces, une définition des pannes, une
définition du contrat de service et une représentation WSDL de l’interface. Quand aux
protocoles échangés et utilisés par les services Web, on a le WSDL, XML, http et SOAP.
En effet, le WSDL 1.1 (Web Services Description Language) décrit les services Web du
Parlay X et les modélise comme étant des “endpoints” qui opèrent sur les messages XML.
Voici certains « API Web Services » : Call Control (Call Handling, Audio Call, Multimedia
Conference, Third Party Call, Call Notification), Short Messaging (SMS), Multimedia
Messaging (MMS), Payment, Account Management, Terminal & User Status, Terminal &
User Location, Address List Management, Presence & Availability, Message Broadcast,
Geocoding and Mapping, Application driven Quality of Service (QoS). Il est quand même
possible qu’un service Web du Parlay X assure deux fonctionnalités hétérogènes
simultanément (localisation d’un terminal et savoir le statut de l’usager).
Par ailleurs, les services Web du Parlay X sont des interfaces d'application qui ne
fournissent pas une implémentation d’AAA (authorization, authentication, et accounting),
des accords de niveau de services (service level agreements) ou d'autres possibilités et
capacités spécifiques à un environnement. En revanche, ils se basent sur des solutions
prouvées et fiables, fournies par l'infrastructure de services Web.
En comparant le Parlay X au Parlay/OSA (Tableau 2), on constate qu’il est simplement une
technologie ayant pour valeur ajoutée l’interfaçage Web. Ces API Web services facilitent
l’accès aux services afin de les réutiliser.
Nom
Parlay/OSA
Description
Un ensemble de riches APIs
télécom,
utilisées
dans
différents
environnements
(Corba (C, C++), Java, …)
Parlay X
Un ensemble de haut niveau
APIs télécom, simples à être
utilisées
dans
des
environnements
Web
services.
Il y a 17 interfaces
Web services (APIs
Web services)
Utilisation
- Adéquate pour être utilisées par
les développeurs professionnels de
logiciels.
- Adéquate pour développer
une application prépayée
- Adéquate pour être utilisées
par les développeurs Web.
- Conçues pour être déployées
avec
un
environnement
de
développement
intégré
(IDE :
Integrated Development Environment).
- Adéquate pour développer
un bouton « Call-me » sur
une page Web.
Tableau 2 : Comparaison Parlay/OSA - Parlay X
Comme on l’a vu dans la partie précédente, les services Web subissent un « booming »
dans leur popularité et dans leur utilisation. Cela a poussé le groupe Parlay, en 2000 à
mettre à jour leurs Parlay 4.0 APIs pour devenir des services Web, avec l'intention de
permettre la création de SOA (architecture orientée services). Nous rappelons que le
produit de cette migration était appelé, SOA Parlay X Web Services. Ainsi, avec la
naissance des SOA Parlay X Web Services, les développeurs IT, avec les moindres
connaissances en télécommunication peuvent maintenant manœuvrer avec les services
35 / 80
de télécommunication comme s’ils appellent n’importe quel service Web ordinaire : ils font
juste un simple appel de fonction à partir de leur programme Java, et ils puissent ainsi se
brancher au monde complexe de télécommunication d'une manière simple et directe.
Mais, afin d’atteindre ce haut niveau d’abstraction, un changement doit avoir lieu au
niveau architectural. D’après Figure 29, on peut voir le rôle de médiation que joue le Parlay
X Gateway. Il est une passerelle qui permet aux fournisseurs de services, aux MVNOs et
aux 3rd parties d’accéder aux applications et services Web internes offertes par
l’opérateur propriétaire de cette passerelle.
En effet, l’accès et l'interaction entre une application incorporant un service Web Parlay X
et le serveur implémentant ce service sera faite selon un échange basé sur des messages
XML. L'échange de message devrait suivre le modèle synchrone requête/réponse et
devrait être lancé par l'application ; la « réponse » du service Web Parlay X est facultative.
Parfois, des messages asynchrones de l’implémentation des Parlay X Web Services (sur
la passerelle Parlay X) à l'application peuvent être définis. Cela aura lieu pour des raisons
indiscutables, par exemple, implémenter un service Web de type « Notification ».
Les invocations des services Web Parlay X devraient être dé-corrélées et le service Web
lui-même devrait être « stateless » selon la perspective de l'application, à moins qu'il y ait
des raisons indiscutables. En particulier, dans le cas des notifications asynchrones
envoyées de l’implémentation du service Web Parlay X (sur la passerelle Parlay X) à une
application, aucune invocation lancée par l’application pour provisionner (ou déprovisionner) les critères reliés aux notifications dans le service Web Parlay X, ne devrait
être implémentée.
Figure 29 : Architecture Parlay X
36 / 80
D’après cette Figure 29, on peut constater aussi que la communication entre la passerelle
Parlay X et le réseau IMS ou tout autre réseau sous-jacent se fait soit d’une manière
directe (échange de messages SIP dans le cas d’IMS) soit en passant par la passerelle
Parlay/OSA.
Pour conclure, suite à l’utilisation des passerelles et les APIs Web services, le niveau
d’abstraction est amélioré pour les développeurs IT, ce qui les stimule à développer des
applications de nouvelle génération d’une façon de plus en plus rapide.
2.4.1.4 OMA
L’OMA (Open Mobile Alliance) est une organisation internationale qui s’est constituée en
Juin 2002 et qui développe des spécifications ouvertes et orientées usagers. Elle est
conçue pour être au centre du travail de spécifications pour les services mobiles, en
stimulant et contribuant à la création des services interopérables. Plusieurs types
d’entreprises sont membres de cette organisation, il y a par exemple des fournisseurs des
réseaux sans fil, des entreprises IT, des opérateurs mobiles et des fournisseurs
d’application, etc.
OMA considère comme objectif primordial, la création des services interopérables à
travers des régions géographiques diverses, des opérateurs mobiles multiples, et une
variété de terminaux et de systèmes d'exploitation. En effet, pour n’importe quels terminal,
service et réseau que je veux ou j’utilise, je peux communiquer, accéder et échanger des
informations.
Au niveau stratégique, le travail d’OMA est concentré sur la définition des besoins du
marché selon des cas d’utilisation, une plate-forme architecturale commune, des
standards ouverts et une interopérabilité de bout-en-bout.
Pour atteindre ses objectifs, OMA développe et annonce plusieurs spécifications appelées
“OMA Enablers”. Ces enablers sont des blocks qui étaient conçus au début pour la
composition des services mobiles. Mais, au cours du temps, plusieurs spécifications liées
aux réseaux fixes apparaissent, ce qui a assuré la prolifération des services mobiles tout
en permettant l’interopérabilité entre les réseaux fixes et mobiles.
En effet, l’utilisation de ces enablers est très avantageuse :
Les Enablers fournissent des composants interopérables qui permettent l'interaction entre
différents composants et applications développés par différents fournisseurs (par exemple
des fournisseurs de dispositif et de réseau, des entreprises de technologie de l'information
et des fournisseurs de service) ;
Les spécifications des enablers réduisent les efforts de déploiement et permettent aux
mêmes applications de fonctionner à travers une large variété d'environnements d'une
façon cohérente ;
Les spécifications des enablers tiennent compte également de la réutilisation, de sorte
que des fonctions utilisées généralement puissent être données par des composants
standards, au lieu de recréer ces mêmes fonctions dans chaque application.
D’autre part, OMA contribue fortement dans la croissance du marché, tout en assurant
une plate-forme architecturale commune qui accélèrera l’innovation des produits et
minimisera le time-to-market. De plus, de nos jours, l’industrie adopte largement les
spécifications ouvertes d’OMA au lieu de celles propriétaires. Un autre avantage
qu’assure OMA, c’est la diminution du coût opérationnel, en améliorant l’efficacité au sein
des entreprises, et à travers l'industrie. Quand au niveau des utilisateurs, OMA améliore
leur expérience en assurant une interopérabilité multistandard et de bout-en-bout.
Il faut bien noter que tous les exigences et les fonctionnalités qui ne sont pas intrinsèques
à un enabler ne devraient pas être spécifiées dans sa spécification. La spécification d’un
enbaler devrait seulement spécifier la fonctionnalité intrinsèque exigée pour accomplir son
rôle. De plus, les spécifications devraient spécifier comment se fait l’appel des fonctions.
37 / 80
En effet, une implémentation d’un enabler peut appeler n’importe quelle fonction
standardisée, comme par exemple l’authentification ou la gestion du groupe, dont elle
aura besoin pour satisfaire ses fonctions intrinsèques définies dans ses spécifications.
D’après l’introduction, on a pu voir nettement l’intérêt d’utiliser les enablers. Mais
maintenant, on a besoin de savoir où sont placer ces enablers au niveau architectural.
Pour cette raison, on introduit dans cette partie l’architecture OSE (OMA Service
Environment) qui est une structuration pour le déploiement et l’intégration des enbalers et
pour la création des nouveaux services.
Dans n’importe quel domaine OSE (domaine du fournisseur de services, du terminal, ou
bien de l’entreprise), les implémentations des enablers exposent des interfaces standards
pour l’application et l’usage des enablers. Ces implémentations se relient aux ressources
actuelles présentes dans le domaine OSE. A l’aide de cette abstraction, il sera possible
d’ajouter ou de modifier les ressources sous-jacents sans affecter l’interface exposée par
les implémentations de l’enabler (et par suite, sans affecter les apllications), ce qui est très
important dans le cas de multiple vendeurs, de différents technologies réseaux ou dans le
cas de différents fournisseurs.
D’autre part, afin de contrôler l’accès aux enablers, on utilise des politiques. Ces politiques
d’évaluation et leur réalisation assure la protection de l'enabler. Une fois requises, les
définitions de politique peuvent aider dans l'extensibilité en employant le mécanisme de
délégation.
Figure 30: Architecture OSE
D’après la Figure 30, on peut voir les différents éléments constituant l’architecture OSE :
Enablers : c’est une technologie prévue pour l'usage dans le développement, le
déploiement ou l'exploitation d'un service. Elle est définie dans des spécifications, ou
dans des groupes de spécifications.
• Les interfaces : les spécifications des enablers définissent des interfaces afin d’invoquer
les fonctions intrinsèques de la spécification d’un enabler d’une manière interopérable,
de supporter l’interopérabilité entre les entités d’un enabler, et de permettre la possibilité
de fournir la gestion du cycle de vie des enablers. Cependant, comme principe
fondamental d'OMA, les spécifications des enablers et l’OSE en général ne spécifient
•
38 / 80
•
•
•
•
•
pas des APIs. En effet, l’interface I0 permet l’accès aux fonctions intrinsèques des
Enablers voulus. L’interface I1 permet aux enablers de s’exécuter dans un
environnement d’exécution qui assure plusieurs fonctions (Gestion, surveillance,
administration, …). L’interface I2 permet aux enablers d’accéder aux ressources du
réseau (Ex. IMS). Et finalement, l’interface I0+P permet l’imposition des préférences de
l’usager et la protection contre des requêtes non autorisées, tout en réalisant les
politiques de gestion.
Enabler interface bindings : les interfaces doivent être spécifiées selon un langage
neutre. Cependant, les spécifications peuvent aussi définir des bindings pour ces
interfaces. Enabler interface bindings fournissent les formats spécifiques (ex. syntaxes
et protocoles utilisés pour accéder aux enablers tout en utilisant des langages
particuliers de programmation (ex. Java ou C) ou bien des protocoles réseaux (ex.
services web)).
Ressources : c’est un élément de l’architecture représentant une capacité dans le
domaine du fournisseur de service ou dans le domaine du terminal. Dans l’OSE,
l’implémentation d’un enabler peut directement invoquer ou accéder aux ressources.
Application: c’est une implémentation d’un ensemble de fonctions reliées qui assurent
un travail bien défini qui est, pour la plupart des fois, le déclenchement d’un ou de
plusieurs services. Elle peut être un élément software et/ou hardware. Les applications
sont définies comme des éléments de l’OSE car elles sont des moyens primordiaux pour
initier et utiliser un enabler.
Environnement d’exécution: c’est une plate-forme qui englobe logiquement plusieurs
fonctions comme la surveillance du processus, gestion du cycle de vie du software,
support du système (ex. gestion des threads, load balancing, etc.), opération, gestion et
administration qui permettent le domaine OSE de contrôler les enablers. Les fonctions
assurées par cet environnement d’exécution pourraient ne pas être directement
exposables pour les applications, cependant, ces fonctions pourraient être directement
invoquées par les implémentations des enablers. En outre, les ressources pourraient se
baser sur ces fonctions. La gestion du cycle de vie du software contient un ensemble de
fonctions de l’environnement d’exécution du fournisseur de services et pourrait être
implémentée comme un enabler séparé, ou elle pourrait être distribuée sur plusieurs
enablers.
Policy enforcer: il assure un mécanisme de gestion par politique afin de protéger les
ressources des requêtes non autorisées et afin de gérer l’usage de ces requêtes tout en
tenant compte par exemple, du chargement et de l’évaluation/réalisation des
préférences de l’usager.
2.4.1.5 IMS et le SCIM
Afin de fournir IMS avec un mécanisme de gestion de la composition de services basés
SIP, on a besoin :
• D’introduire une entité fonctionnelle qui gère l’interopérabilité et la coopération
entre les différents serveurs d’application et qui contrôle comment les différentes
capacités de service sont partagées et réutilisées par différents services intégrés.
• De définir les mécanismes requis pour cette entité fonctionnelle afin de contrôler
l'accès des services intégrés aux capacités de service et de gérer l'intégration de
service.
Pour cette raison, le 3GPP a introduit le SCIM (Service Capability Interaction Manager) qui
est un serveur d’application SIP dont le rôle est de gérer les interactions entre les serveurs
d’application. Cependant, ses fonctionnalités de gestion de l’interaction des services ne
sont pas spécifiées jusqu’à maintenant.
En effet, il y a différentes manières pour concevoir le SCIM :
• C’est un dispatcher des logiques de services dans l'environnement local
d'exécution ;
39 / 80
•
C’est une entité qui gère l’interaction entre les composants qui implémentent les
serveurs proxy SIP ou les agents utilisateurs ;
• C’est une entité qui gère l’interaction entre les capacités de services qui sont
exposées en utilisant le WSDL (Web Service Definition Language) et les
abstractions d’IMS qui sont basées sur SOAP (Simple Object Access Protocol).
• C’est une entité qui gère l’interaction entre les fonctions SIP et les composants du
système de signalisation.
En fait, le choix parmi ces différents comportements de SCIM dépend essentiellement sur
le modèle technologique et économique des différents fournisseurs de services.
D’après la Erreur ! Source du renvoi introuvable., le SCIM se trouve entre le S-CSCF
(dans la couche de contrôle de session) et les serveurs d’application (dans la couche
service) afin d’assurer à IMS un mécanisme pour supporter la coopération et
l’interopérabilité entre les services.
Selon ce modèle, la composition de chaque serveur d’application sera gérée par un seul
SCIM et chaque SCIM pourra gérer la composition de plusieurs serveurs d’application.
Figure 31: Architecture IMS SCIM
En fait, le SCIM représente une frontière entre le domaine de l'opérateur du réseau et le
domaine des fournisseurs tiers de services. Ainsi en incluant des mécanismes de gestion
de la composition de service dans SCIM, différents fournisseurs de services pourraient
introduire des serveurs d’application intégrés et à valeur ajoutée tout en partageant un
ensemble limité de capacités standardisées de service fournies par l’opérateur du réseau
IMS.
De plus, le SCIM permet à l’opérateur du réseau IMS de contrôler la coopération et
l’interopérabilité entre les services tout en se basant sur les contraintes et les accords
spécifiés entre l’opérateur du réseau et le fournisseur de service.
Par exemple, un serveur d’application Presence (qui permet l’appel seulement si l’appelé
est valable) utilise la capacité Presence Service Capability afin de savoir la disponibilité de
l’appelé. Un autre exemple, c’est le cas d’un serveur d’application Voicemail (qui transmet
les appels entrants vers un serveur de messagerie vocale si l’appelé est non disponible)
peut réutiliser la même capacité Presence Service Capability pour envoyer les appels
entrants vers le serveur de messagerie vocale quand l’appelé est non disponible.
Pour conclure, on va essayer de comparer la solution architecturale basée sur SCIM avec
les mécanismes de gestion de la composition de services basée sur l’architecture
Parlay/OSA. Les résultats de cette comparaison apparaissent dans le Tableau 3.
40 / 80
Basée SIP
Définition modulaire de services
Adaptable pour IMS
Sécurité
Binding dynamique des services
Indépendance du réseau
Communauté des développeurs
Condition d’invocation des services
Parlay/OSA
+
+
+
++
++
IT
-
SCIM
++
+
++
+
A faire
-(Spécifique à IMS)
SIP et Télécom
++
Tableau 3: Comparaison entre Parlay/OSA et SCIM
Selon ce tableau, on peut constater que l’avantage le plus signifiant est le fait d’assurer à
IMS un mécanisme de gestion de la composition de services basée SIP. Contrairement à
Parlay/OSA, la solution SCIM est flexible, adaptable à IMS et peut améliorer le
mécanisme IMS actuel d’invocation de services.
En conclusion, l’approche Telco par sa structure à travers une API induit une architecture
« client-serveur » au niveau des services. Le RI avait une vue plus intégrée mais passe
par le processus d’appel qui conduit à une approche « bottom-up ». L’IMS, grâce au SIP a
plutôt une approche « Top-down ».
2.4.2 Les architectures Web
Le monde du Web propose d’autres types d’architectures pour mettre en œuvre les
services, leur contrôle et leur gestion, avec son ensemble de concepts et de règles. Dans
cette partie on consignera quelques caractéristiques d’architectures de services Web
(§2.4.2.1) et de ses évolutions (§2.4.2.2). Puis on abordera le SaaS (§2.4.2.3) qui nous
conduit vers une approche« tout service ».
2.4.2.1 Service Web
Un service Web est une application logicielle identifiée par une URL, et à laquelle on peut
accéder à distance à partir de différents langages basés sur XML. Indépendamment de
l'ordinateur, du système d'exploitation ou du langage utilisés par le client, une application
peut ainsi utiliser plusieurs services Web qui s'exécutent sur plusieurs serveurs
d’application distants.
En simplifiant les choses, les services Web peuvent être considérés comme les
composants d’une fonctionnalité en ligne, ayant la possibilité d’être branchés ensemble
comme un genre de lego numérique. Par exemple, si une organisation a besoin de
prendre en ligne des paiements par carte de crédit, elle pourrait, soit créer son propre
compte bancaire d'affaires, soit, plus raisonnablement, intégrez sur son site, le service de
Web d'un fournisseur de services de paiement (PSP) comme Worldpay, Netbanx ou
Paypal. Les visiteurs feront leur achat à partir du propre site Web de la compagnie, mais à
la fin, ils seront transportés au site Web du PSP où ils doivent remplir tous les détails
nécessaires sur leur carte de crédit et ainsi le paiement sera arrangé. Tout cela se
produira automatiquement, avec deux organismes faisant intégrer leur offre
électroniquement en ligne.
En effet, pour se servir des services de Web, des « mashups » sont créés en incluant un
bout de code d'un fournisseur de services Web dans la page du site Web accédant au
service. Un tel code peut être aussi simple qu’un lien vidéo incluse sur le site Web de
41 / 80
YouTube, comme il peut être aussi un bout de code plus complexe écrit dans l'interface
de programmation d’applications API du fournisseur de services de Web.
De point de vue architectural, la mise en œuvre d’un service web repose sur plusieurs
couches. Nous trouvons d’après la Figure 32, ci-dessous:
Figure 32 : Cadre architectural des services Web
•
La couche Transport : le HTTP est le protocole de réseau standard pour les
services Web accessibles par Internet. HTTP est un protocole permettant
l'échange des requêtes et des réponses entre clients et serveurs, quel que soit le
type des données. Les autres protocoles d’Internet comme le SMTP et le FTP
peuvent aussi être supportés. Les domaines Internet peuvent utiliser des
infrastructures d’appel et d’échange de messages comme MQSeries, CORBA, etc.
•
La couche Message : SOAP (Simple Object Access Protocol) est le protocole
choisi pour l’échange des messages XML. Il fournit un cadre standard, extensible
et composable pour l’encapsulation. Il est indépendant de la technologie de
transport sous-jacente. SOAP définit une enveloppe contenant un entête et un
corps. L'entête fournit les instructions indiquant comment traiter le message et
fournit également un mécanisme pour référencer des capacités (fonctionnalités
déclarées offertes ou demandées par un agent). Le corps contient l'appel de la
procédure distante dans un sens et la réponse du serveur dans l'autre. L'envoi de
documents attachés à un message SOAP se fait en encapsulant le message
SOAP et les documents attachés dans un document au format MIME
(Multipurpose Internet Mail Extensions) ou au format DIME (Direct Internet
Message Encapsulation), qui est moins souple mais plus simple que MIME.
•
La couche Description : est en réalité une pile de documents de description. WSDL
(Web Service Description Language) introduit une grammaire commune pour la
42 / 80
description des services. Il est le standard pour la description de service basée sur
XML, indépendamment de toute plate-forme ou langage de programmation. C’est
en effet, la contrainte obligatoire pour pouvoir supporter l’interopérabilité entre les
services. Les messages sont décrits de manière abstraite puis associés
concrètement à un protocole de réseau et un format de message. Dans la
description du service Web, on précise les méthodes acceptées et les paramètres
correspondants, les réponses fournies en retour, les protocoles et les formats de
données pouvant être traités, et les URL du service.
•
La couche Découverte et Enregistrement : la découverte des services Web peut se
faire avec la technologie UDDI (Universal Description and Discovery Integration ),
dont les mécanismes reposent sur les services de nommage et d’enregistrement
proposé par un répertoire de service appelé Service Repository. En
particulier, l’UDDI définit la structure des données et les API pour la publication des
services dans le répertoire. Il permet de répondre à des requêtes qui concernent la
recherche des descriptions de services publiées. Le service d’enregistrement
permet d’une part, aux développeurs de trouver les informations sur les services,
ils pourront ainsi développer les clients qui utiliseront ces services. D’autre part, le
service d’enregistrement permet de faire le binding (la mise en relation) d’un client,
d’interroger le registre et d’obtenir les références des services en question. En
effet, les services enregistrés peuvent appartenir à l'une des trois catégories
suivantes :
o "Public" : service ouvert à tous. Plusieurs éditeurs majeurs proposent de
tels services, par exemple IBM et Microsoft.
o "Private" : service accessible seulement à l'intérieur d'une compagnie. Pour
celle-ci, le catalogue UDDI permet la réutilisation de logiciels en interne.
o "Restricted" : service accessible seulement par certaines organisations
autorisées (par exemple les fournisseurs et certains clients d'une
entreprise).
Un fournisseur, ayant créé un Service Web "public", doit l'enregistrer auprès du
Service Registry de son choix, par exemple le "Microsoft public registry". Ce
registre réplique chaque nuit ses entrées sur les autres registres publiques
existants. Ainsi, un client potentiel, interrogeant quelques jours après le "IBM
public registry", trouvera ce nouveau service Web et pourra l'utiliser s'il le souhaite.
•
La couche de composition : dans le cadre de services Web, la composition est vue
comme étant la combinaison sur certaines conditions d’un ensemble d’activités qui
décrivent des fonctionnalités attendues du système. Dans le contexte actuel des
normalisations, les opérations concernant la composition sont décrites suivant
deux approches : la chorégraphie ou l’orchestration.
o L’orchestration utilise le WSFL (Web Services Flow Language) pour décrire
comment sont effectuées les communications, les collaborations et les flux
entre les services au niveau implémentation.
o La chorégraphie permet de gérer des processus métier complexes qui
nécessitent la coordination entre différents services métier « Business
Services » afin de répondre à une requête de mise en œuvre d’un Business
Service.
Pour la composition de services, on a plusieurs approches et technologies dont on va citer
deux : l’approche BPEL et l’approche sémantique.
• L’approche BPEL (Business Process Execution Language): BPEL est un langage
qui permet de définir un processus de composition des services. La composition
BPEL interagit avec un sous-ensemble de services Web pour accomplir une tâche
donnée. Dans BPEL, le résultat de la composition est appelé un processus, les
43 / 80
services participants sont des partenaires et l’échange de messages ou la
transformation intermédiaire de résultat s’appelle une activité. Un processus se
compose ainsi d’un ensemble d’activités. Un processus interagit avec des services
partenaires externes à travers une interface WSDL. De point de vue couches
protocolaires, l’approche BPEL utilise WSDL comme langage de description. Pour
la découverte et la publication, il utilise l’UDDI. Pour la chorégraphie et
l’orchestration, il utilise le WSCI (Web Service Choreography Interface) et le WSCL
(Web Service Conversation Language). Quand au niveau du « Business Process »
et « Workflow », on parle du WS-BPEL (Web Services BPEL).
•
L’approche sémantique OWL-S (Web Ontology Language for Services): La vision
sémantique consiste à rendre les services Web accessibles par le contenu aussi
bien que par les mots-clés. Les utilisateurs et les agents logiciels devraient pouvoir
découvrir, composer et appeler le contenu en utilisant des services complexes. La
DARPA Agent Markup Language (DAML) a fournit un ensemble de constructions
pour créer des ontologies compréhensibles par les machines. Cette contribution
sémantique a mené vers l’OWL-S. C’est une ontologie de services permettant la
découverte de service, l’invocation, la composition, l’inter opération et la
surveillance automatique de l’exécution. Elle modélise les services Web en trois
parties: le profil de service: décrit ce que le service exige des utilisateurs et ce qu’il
leur produit ; le modèle de service: indique comment le service fonctionne (Ex.
comment l’appeler, …) ; le modèle « mis à terre (grounding) »: fournit l’information
sur l’usage du service. En effet, pour l’OWL-S, la couche de description est basée
sur le profil de service et sur le mode grounding. La découverte est basée sur le
profile de service. Quand au « Business Process » et « Workflow », c’est la modèle
de service qui va décrire le processus métier.
Après avoir expliqué chaque partie et chaque couche à part, on peut voir la structure
d’ensemble orientée services (SOA) appliquée aux services Web, dans la Figure 33 qui
apparait ci-dessous.
Dans cette architecture, on peut voir comment le message qu’on veut envoyer sera
encapsuler en lui ajoutant l’adresse de routage et puis on le représente sous forme de
messages SOAP, dont chaque champ a sa propre modélisation par le modèle XML ou
URI schema. Ensuite, l’ensemble pourra être comprimé (Packaging) et ensuite envoyé par
les protocoles de transport HTTP, FTP, SNMP, etc.
Si on monte un peu dans cette architecture, on peut voir, autre que les fonctions de
sécurité et de gestion, la couche de description (WSDL) et de découverte (UDDI) utilisées
dans l’approche BPEL, ainsi que la partie d’orchestration et chorégraphie.
A droite, on peut voir l’approche sémantique OWL-S qui vient pour remplacer les couches
de description, découverte, chorégraphie et orchestration du BPEL, par son profil de
service, son modèle de service et son modèle de grounding.
D’autre part, au niveau de la partie accessibilité, il y a l’I18N : comme on vient de voir, la
sémantique est basée sur une description des services. Cette description est rendue
accessible à l’internationale à travers les efforts du I18N. (On abrège souvent
internationalisation en I18N car, en anglais, il y a 18 lettres dans le mot, entre le i et le n).
De plus, il y a le P3P qui, pour rassurer les usagers des services, va définir un langage de
description de leurs privacy preferences.
44 / 80
Figure 33 : Structure d'ensemble SOA des services Web
2.4.2.2 Web2.0/3.0
Le Web 2.0 [4] est défini comme un concept d'utilisation d'Internet qui a pour but de
valoriser l'utilisateur et ses relations avec les autres. L’Internet est alors redéfinie comme
non seulement un média (où les sites Web sont autant d'îlots d'informations isolées) mais
aussi comme une plate-forme. Les données sont considérées comme les connaissances
implicites.
Web 2 .0 est en fait un socle d'échanges entre les utilisateurs (l'auteur parle d'intelligence
collective) de services ou d’applications en ligne (Erreur ! Source du renvoi
introuvable.).
L'infrastructure du Web 2.0 est complexe et changeante, mais elle inclut les logiciels de
serveur, la syndication de contenu (RSS qui signifie Really Simple Syndication), les
protocoles de messagerie des standards de navigation, et des applications clientes
diverses (les plugins, ou greffons, non-standard sont généralement évités).
Ces approches complémentaires fournissent au Web 2.0 les capacités de stockage, de
création et de diffusion qui vont au-delà de ce qui était précédemment attendu des sites
web.
45 / 80
Figure 34 : Web 2.0
Application comme "many-to-many publishing” (blogs, social book marking et wikis),
logiciel social, les interfaces de la programmation application web et les services en ligne
nous permettent d’avoir une possibilité de renforcer le service demandé par l’utilisateur.
Des « Communauté d’intérêt » sont constituées pour partager les connaissances (Swicki),
ou pour avoir un même sujet de discussion (Facebook) ou le réseau social (Expedia pour
la réservation des billets basée sur une comparaison de prix en temps réel).
Avec certaine plate-forme ou outil (Yahoo! Pipes Mash-up platform), l’utilisateur peut
même créer son journal par le filtrage des nouvelles en fonction de ses préférences
prédéfinies.
L’approche « Services Web » constitue un changement fondamental dans la manière de
concevoir et réaliser les applications informatiques et de programmer les ordinateurs. Pour
cela, plusieurs études et plusieurs efforts sont faits dans ce domaine, ce qui a mené à
l’apparition de la deuxième version Web, appelé Web 2.0.
Le « Web 2.0 » consiste à utiliser l'Internet pour le partage interpersonnel de contenu et
pour la distribution de services en ligne. Quand au « Web 1.0 » qui est venu avant, était
largement concerné par la création et la consultation du contenu en ligne (cela apparait
dans les guerres de navigateur et dans une prolifération des sites Web que peu de
personnes visite). Les acteurs principaux dans le marché du Web 2.0 incluent, jusqu’à
maintenant, Google, YouTube, MySpace et Wikipedia, etc.
À un niveau conceptuel, le Web 2.0 est concerné par l’établissement et la maintenance de
connexions en ligne, plus fluide, plus flexibles et plus riches, entre les personnes, les
services et/ou l'information. Spécifiquement, de telles connexions améliorées peuvent être
créées et maintenues entre deux ou plusieurs personnes, entre deux ou plusieurs
ordinateurs et organisations qui fournissent des services en ligne, ou entre des individus
et le contenu numérique qu’ils créent, manipulent et stockent. L'isolement de ces trois
catégories possibles de connexions du Web 2.0 nous permet rapidement de définir les
trois aspects clé du Web 2.0 :
• Interpersonal computing: impliquant des interactions entre personnes, facilitées par
l'intermédiaire des sites Web qui permettent la création, le partage et la
manipulation du contenu collaboratif.
• Web Services : comportant des échanges de données et de service entre les
applications (et par conséquent entre les organisations), facilités par les
connexions automatisées entre les serveurs web et toute autre technologie
d'Internet.
46 / 80
•
Software as a service (SaaS) : impliquant des interactions humaines avec des
contenus numériques, facilitées par des applications délivrées à partir du Web ce
qui libère l'utilisateur des logiciels localement installés.
D’une autre part, et suite à ce développement dans le domaine du Web, la notion de
« Cloud Computing » devient de plus en plus le centre d’intérêt de tous les chercheurs et
les développeurs.
En effet, le Cloud Computing est où les ressources informatiques sont accédées à partir
d'un « nuage » virtuel en ligne, et non plus à partir d’un ordinateur local ou d’un centre de
données organisationnel. Cloud Computing est une tendance rapidement croissante qui
est fortement liée au développement du Web 2.0. Il faut quand même noter que d’un point
de vue conceptuel, Cloud Computing et le Web 2.0 sont tout à fait distincts.
Spécifiquement, le concept clé du Web 2.0 est d’assurer de nouvelles formes de
connexions en ligne entre les personnes, les services et les applications, tandis que le
concept clé du Cloud Computing est le détachement des ressources informatiques de
n'importe quel endroit ou localisation, même national.
Enfin, en tandem avec le Web 2.0, le Cloud Computing peut changer tout l’état actuel de
l'industrie informatique. Amazone, Google, IBM et d'autres sont déjà au centre de cette
révolution de Cloud Computing. Les géants traditionnels de l'industrie, comme Microsoft,
vont surement confronter un défi de plus en plus dur s'ils essayent de continuer à nous
vendre des logiciels pour les installer sur notre hardware local.
Web 3.0 est considéré comme la troisième génération des services de web basé sur
l’Internet, qui a pour but d’offrir à l’utilisateur des expériences plus ou moins productives et
intuitives. La définition officielle du web 3.0 est “la création de contenu de grande qualité
et de services produits par des individus utilisant la technologie de web 2.0 comme plateforme“.
Par rapport à Web2.0, Web 3.0 voudrait donner plus de personnalisation et rechercher
plus efficacement les données Web. Malheureusement, bien que Web 2.0 et Web 3.0
supportent le partage d’UGC (User Generated Content) et UGA (User Generated
Application), ils proposent également une composition de service avec les composants
réutilisables et partageables, aucun ne supporte vraiment le partage d’un même service.
De plus, l’utilisateur ne peut faire qu’une seule invitation pour une application, l’ajout d’une
application induit obligatoirement une autre invitation..
Ces approches adressent plus le contenu, sans oublier que l’architecture reste de type
client-serveur. Elles ne sont pas suffisantes pour faciliter la création de service orienté
utilisateur.
2.4.2.3 SaaS
Architecturalement, l’application de SaaS est similaire aux autres applications qui suivent
le concept de l’orienté service. Tout comme l'ASP (Application Service Provider) ou les
applications à la demande, les applications SaaS s'inscrivent dans le groupe des logiciels
gérés ou hébergés. A la différence de l'ASP, les applications basées sur le modèle SaaS
sont construites d'emblée en mode Web et optimisées pour être délivrées par l’Internet. Le
modèle SaaS permet de se décharger de la maintenance, de l'exploitation et de
l'hébergement des applications. Le paiement à la consommation est un moyen d'optimiser
les coûts.
Par exemple, la plupart des composants (Figure 35) sont reconnus : « Process service »
qui est en fait une interface entre les demandeurs de service (smart clients) et le
47 / 80
fournisseur de service. Les services business interagissent avec les bases de données
pour les données concernant le business. “Security services” sont responsables du
contrôle de l’accès de services logiciels de l’utilisateur.
Figure 35 : exemple de la plate-forme de SaaS
La différence la plus significative est l'ajout de services de métas données, qui sont
responsables de la gestion de configuration de l'application pour certains services
hébergés. Services et smart clients interagissent avec les services de métas données, afin
d'extraire l'information qui décrit les configurations et les extensions qui sont spécifiques à
chaque service hébergé.
En conclusion nous pouvons dire que, le Service Web contribue à la simplification et à la
réutilisation de service, mais son architecture est orientée « client-serveur ». Web 2.0 et
Web 3.0 ont pour objectif la partageabilité de contenu et des applications sous la forme
d’option de service. Alors que SaaS propose de gérer les composants de service
ubiquitaires, mais l’architecture a un couplage fort car vertical.
Nous devons donc poursuivre cette démarche de décomposition de service pour satisfaire
les besoins du NGS.
2.4.3 Les architectures IT : SOA
Un des besoins les plus essentiels du monde IT, c’est la création et l’adoption d’un
processus métier. De plus, l'évolution des services autonomes aux services qui
s’interagissent pour accomplir un besoin spécifique de l'utilisateur apparait également au
sein des entreprises. Afin d'adapter leur système d'information (SI) à cette ère de service,
les compagnies doivent casser les frontières entre leurs diverses applications et les faire
coopérer.
En effet, cette évolution a eu lieu suite à l’utilisation du paradigme SOA (Service Oriented
Architecture): les applications ne devraient plus continuer à être des entités autonomes,
mais, par contre, elles devraient être divisées en services, c.-à-d., des unités de métier qui
sont discrètes et indépendantes, qui effectuent une tâche bien spécifique et qui sont
seulement accessibles par une interface ouverte et bien définie de service.
L'architecture orientée-services est généralement définie comme « une architecture
d'application, dans laquelle toutes les fonctions sont définies en tant que services
indépendants ayant des interfaces d’invocation bien définies qui peuvent être appelées
selon des séquences bien précises afin de former des processus métier ».
48 / 80
En outre, les compagnies ont découvert que le défi principal pour appliquer ce paradigme
de SOA n'était pas un défi technique. Techniquement, les produits et les technologies
(SOAP, UDDI, …) sont disponibles. Leur déploiement n'est pas évident, mais peut être
techniquement maîtrisé. Le problème principal est en effet le fait d’identifier et de définir
les services, ces unités de métier discrètes et indépendantes.
De plus, l'architecture orientée-services est mature comme concept d'architecture. Il est
largement adopté dans l'industrie des télécoms et l'industrie d'Internet. L'objectif principal
de SOA est de créer des applications utilisées comme des services réutilisables et puis de
permettre la composition de ces applications afin de réduire le délai d'accès au marché
(Time To Market).
En ce qui concerne la composition de services, les développeurs SOA:
• Cherchent les services Web disponibles dans un répertoire de services « Service
Repository », où le service est décrit en utilisant un document WSDL (Web Service
Description Language) ;
• Invoquent les services Web dont ils ont besoin, en utilisant SOAP (Simple Object
Access Protocol) ;
• Composent le service Web voulu à partir des services invoqués, en utilisant les
langages de programmation et les scripts ;
• Et finalement, ils publient le nouveau service Web dans le répertoire, avec un
nouveau document WSDL.
De point de vue architectural, le modèle SOA contient trois entités et trois opérations qui
apparaissent dans la Figure 36:
• Le « Service Repository » qui est un répertoire dans lequel seront publiés les
différents services Web, selon des documents WSDL (Web Service Description
Language) ;
• Le fournisseur de service qui va développer les services Web et qui va les publier
dans le répertoire ;
• Le client qui va envoyer des requêtes pour trouver un service, dans le répertoire,
selon des critères de recherche bien définis, et pour s'y connecter ainsi.
•
Figure 36 : Modèle SOA
D’autre part, de point de vue « business », l’architecture SOA consiste à diviser l’activité
« business » en plusieurs processus distincts qui seront délivrés selon des services Web
assurés par plusieurs organisations et liés ensemble en ligne.
Par exemple, l'activité « business » de vendre quelque chose à un client peut être
décomposée en trois processus : de prendre leur ordre, de prendre leur argent, et de leur
fournir les marchandises voulues.
En effet, le propre site Web de l’entreprise pourrait être employé pour prendre les détails
d'ordre du client, puis l’entreprise utilise les services d'un fournisseur de services de
paiement auquel elle est liée en ligne afin de permettre le traitement des paiements par
49 / 80
carte de crédit, et enfin, une compagnie maritime (telle que Federal Express) liée
également à l’entreprise par l'intermédiaire des services Web, joue son rôle de faciliter la
livraison des marchandises et le cheminement en ligne de la livraison.
Ces affaires de vente de marchandises à un client par l'intermédiaire de l'arrangement en
ligne ci-dessus (qui offre au client un service « seamless » assuré par trois compagnies
distinctes inter-liées par l'intermédiaire des services Web) sont souvent décrites comme
légèrement couplées « loosely coupled ». C'est parce que les services spécifiques utilisés
dans leur processus métier global pourraient facilement être enlevés et remplacés par
ceux offerts par d'autres fournisseurs. La compagnie pourrait, par exemple, commuter
facilement d'un fournisseur de services de paiement ou compagnie maritime à un autre dû
à la flexibilité du couplage par internet des systèmes informatiques, et par conséquent des
organisations.
L’idée principale de SOA est de mettre en œuvre les services ou les applications sous
forme des composants logiciels. Par exemple, a proposé des services (Figure 37) qui sont
en fait des composants autonomes qui implémentent une ou plusieurs fonctionnalités bien
définies à des acteurs humains, à d’autres services, ou à d’autres parties du système. Le
service fournit un accès vers une ou plusieurs fonctions en masquant l’hétérogénéité du
système. Le service est utilisé sous un Contrat de service pour une demande de
l’application.
L’interaction et de la communication d’une collection de services permet de composer des
applications par une agrégation de services.
Cette organisation et décomposition de services rendent possible la mise en place rapide
de processus métiers réellement transverses tout en préservant un couplage faible
facilitant leur modification ou refonte totale et la réutilisabilité de services eux même.
Figure 37 : composition de service exemple 1
Dans une autre proposition (
Figure 38), SOA, la décomposition est faite en trois étapes :
• La première est la découverte des opérations et l’identification de phases
exposées pour un processus modélisé. Il s'agit d'un regroupement d'activités
rattachées aux catégories formant le périmètre fonctionnel des utilisateurs.
• La seconde consiste à décomposer les opérations et les phases. Chaque
opération et phase deviennent ainsi un orchestrateur d’appel vers les services.
50 / 80
•
La troisième décompose chaque service exposé en catégorie sous la forme de
méthodes attachées aux classes qui constituent la catégorie d’appartenance.
Figure 38 : composition de service exemple 2
La notion de SOA (Service Oriented Architecture) renvoie à une nouvelle manière
d'intégrer et de manipuler les différentes briques et composants applicatifs d'un système
informatique (comptabilité, gestion de la relation client, production, etc.) et de gérer les
liens qu'ils entretiennent. Un modèle populaire de SOA, modèle référentiel OASIS définie
SOA comme : “…Un paradigme de l'organisation et de l'utilisation des capacités
distribuées. Il peut être sous le contrôle de différents domaines. Il fournit un moyen
uniforme d'offrir, de découvrir, d’interagir et d’utiliser les capacités de produire les effets
désirés avec les conditions préalables et les attentes”.
SOA supporte le développement de système distribué en termes de services avec un
couplage lâche. Ci-dessous une architecture (Figure 39) proposée par BEA.
Dans SOA, les ressources ambiantes sont mises en réseau pour être autonomes et
accessibles sans connaître leurs technologies sous-jacentes. Une caractéristique de SOA
est que les services sont des entités indépendantes. Ils peuvent être invoqués de façon
standard.
Figure 39 : Architecture de SOA
51 / 80
Par exemple, la Plate-forme Fiorano SOA™ 2007 (Figure 40) propose un bus de services
entreprises pour traiter les business en temps réel. Tous les services sont présentés sous
forme de PS (Peer Server). Les messages s’échangent sur le bus JMS pour faciliter FES
(Fiorano Entreprise Server) d’orchestrer les services.
Figure 40 : architecture de la Plate-forme Fiorano SOA™ 2007
Cette approche SOA est prometteuse par sa recommandation de couplage lâche et par
ses propriétés de composants réutilisables. Elle devrait se généraliser aux services
réseaux et aux services Web.
3. Le pourquoi :
Quels défis (§3.1) et quels verrous (§3.2) devons nous relevés ?
3.1. Les défis
Durant toutes ces dernières années, les différentes architectures de services qu’on a déjà
expliquées avant étaient derrière le « booming » dans le marché Telco et Web services.
Mais malgré leur rôle pionnier dans la croissance du marché, on ne peut plus négliger les
défis et les contraintes provenant de l’utilisation de ce genre d’architectures.
En comparant ces différentes structures d’ensemble, on constate que le point commun
entre eux, c’est la vue application pour chaque architecture.
En effet, toutes ces structures sont basées sur une passerelle et un ensemble de serveurs
d’application. Par exemple, dans Parlay/OSA, on a le Parlay Gateway et les serveurs
d’applications OSA, dans l’IMS SCIM, on a le SCIM comme passerelle et un ensemble de
serveurs d’application SIP, etc.
Par conséquence, ce genre d’architecture mène à une centralisation au niveau des
passerelles : chaque Gateway sera considéré comme un élément central, sans lequel les
serveurs d’application ne seront plus organisés, et n’interagissent pas. Cela mène aussi à
des lacunes dans les performances à cause du problème de « Bottleneck » qui apparait
ainsi dans les différentes passerelles.
En outre, un deuxième défi commun pour toutes ces architectures de services, c’est le fait
qu’elles soient toutes verticales. En effet, la communication entre la passerelle et les
serveurs d’application d’une part, et entre la passerelle et le réseau sous-jacent d’autre
part, est basée sur le principe client/serveur. Ainsi, pour récupérer un service d’un serveur
d’application, la passerelle doit envoyer une requête et attendre une réponse. Par
conséquence à cet échange requête/réponse entre les entités de l’architecture services,
une augmentation aura lieu au niveau du nombre de messages échangés pour obtenir
une session de services. Cela cause une augmentation de la durée entre la demande d’un
service et l’exécution de ce service et par suite cela mène à une diminution dans la
demande et dans l’influence de ce genre d’architecture sur le marché.
D’autre part, si on considère que le réseau sous-jacent à ces architectures de services
était un réseau IMS, comme il apparait dans la Figure 41 ci-dessous, un autre défi s’ajoute
52 / 80
au niveau du HSS (Home Subscriber Server) qui est une base de donnée centralisée
contenant certaines informations comme le profil des usagers (identités des usagers,
services auxquels les usagers sont souscris, le S-CSCF allouée à chaque usager, etc.) et
des informations de sécurité (contrôle d’accès: authentification et autorisation). Malgré les
données de base fournies par ce HSS, ces informations sont considérées limitées et non
suffisamment dynamiques pour offrir des informations temps réel aux ressources
actuellement utilisées lors du déplacement de l’usager.
Par exemple, dans le profil de l’usager, il n’y a pas les préférences et la liste des
terminaux de cet usager, bien que ces données soient importantes lors de la sélection du
service. De plus, dans le profil du service, il n’y a pas la QoS reliée au service décrit.
Figure 41 : Modèle vertical des architectures de services
Afin de dépasser ces défis, on a besoin, au niveau architectural, d’une structure
horizontale, dans laquelle la relation client/serveur sera remplacée par une relation peerto-peer où chaque entité de l’architecture peut développer, publier et utiliser n’importe quel
service.
D’autre part, les quatre types de mobilité (terminal, usager, service, session) introduit une
certaine dynamicité qui nécessite une inférence informationnelle et non pas une simple
mise à jour du HSS. Pour cette raison, on a besoin d’une base de données plus
intelligente dans laquelle la mise à jour sera temps-réel.
Pour répondre à ces besoins, UBIS propose une nouvelle architecture de services basée
sur la notion du NGN Middleware. Elle sera présentée dans la suite du document.
3.2. La continuité de service
Nous avons mentionné dans notre introduction que les propriétés de notre contexte
étaient concentrées dans l’intersection des « mobilités », de « l’hétérogénéité » et de
l’approche « User Centric ». La mise en relation de l’ensemble des acteurs passe par la
session qui doit supporter la dynamicité et la flexibilité des échanges. La session devient
mobile et le verrou à lever est donc une continuité de service (Figure 42) quelque soit les
changements que doit opérer la session. En effet, pendant une session « User Centric »,
l’utilisateur est amené à composer dynamiquement le service (global) dont il a besoin
53 / 80
durant un espace temps. Par exemple, ajouter un service de visiophonie à son appel voix
ou transférer un programme de TV de son poste de télévision à son PDA lorsqu’il se
déplace. Mais, on peut avoir des processus, des logiques de services plus élaborées. Par
exemple, pour une session qui se déroulerait, dans le créneau horaire 8h45-10H45,
l’utilisateur désire avoir ses emails en priorité quand il quitte son domicile, puis étant dans
son véhicule, il souhaite recevoir ses SMS en vocal, puis une fois rendu à son bureau il
voudrait avoir simultanément sur son PC email, SMS et ses fichiers.
Cela implique une continuité du service global durant la session. Cette problématique
est capitale pour les nouvelles générations de service et constitue un des points focaux du
projet UBIS.
Figure 42 : Le Pourquoi : la continuité de service
4. Le comment : la nature des réponses UBIS
La réponse UBIS sera prioritairement d’ordre architectural (§4.1) et protocolaire (§4.2)
sachant qu’il faudra opérer sur les trois plans que nous devons faire converger pour
atteindre nos objectifs de dynamicité et de flexibilité.
4.1. Architecture de service UBIS
Dans la vision du NGN, les services devraient être accessibles, n'importe où et n'importe
quand. Nous avons proposé d'avoir une vision de service à la place de la vision
d'application. Par conséquent, nous proposons un NGN Middleware qui peut être
considéré comme un serveur d’application avancé d'IMS. Ce NGN Middleware offre les
services de base, ce qui permet :
•
La composition des éléments de services SE (Service Elements) selon une logique
de création de servies ;
•
L’établissement d’une session de service selon une table de routage basée sur la
QoS (dans la partie QoS Management) ;
54 / 80
•
La mobilité du service en utilisant la partie Community Management ;
•
La gestion de l’usager en utilisant la partie User Location.
Pendant l'exploitation, le NGN Middleware décompose les services globaux en un
ensemble de SEs. Ce qui remplace la logique d’orchestration des serveurs d’application,
assurée par le S-CSCF ou le SCIM. Puis, ce NGN Middleware compose, choisit d’une
manière optimale et invoque (selon l'état du SE) les services, lorsqu’il reçoit un message
SIP provenant de l’IMS Session Middleware. Dans notre vision, le protocole SIP devrait
être évolué en tenant compte de l'information dans le tableau de routage « QoS Routing
Table ». Nous appelons ce type de messages, des messages SIP+ afin d'obtenir la
session complète de service d'un SE à l'autre.
Nous pouvons noter qu’avant l'exploitation, en tenant compte du dimensionnement, un SE
pourra être déployé dans le(s) NGN Middleware(s) avec une QoS appropriée, c.-à-d. les
différentes instances du SE vont fonctionner sur différents NGN Middleware.
En outre, on a proposé dans cette nouvelle plateforme un HSS avancé pour agir comme
un Infoware. Cet Infoware offre une certaine inférence informationnelle afin d'avoir plus de
dynamicity que la simple mise à jour du HSS. Dans ce HSS avancé, l'information de QoS
de bout en bout est également prise en compte. Puisque les NGS (Next Generation
Services) que nous avons considérés sont des services à informations intensives, les
utilisateurs vont interagir avec le réseau selon des dispositifs sophistiqués, et vont avoir la
possibilité de choisir parmi une large variété d'options de QoS. Grâce à l'information
complète comme les préférences de l’utilisateur, les terminaux de l’utilisateur et la
souscription au réseau dans ce HSS avancé, la session IMS peut être enchaînée du
terminal de l’utilisateur, la porteuse, le réseau cœur IMS jusqu'à la session de service.
On voit ci-dessous, dans la Figure 43, la plateforme NGN Middleware proposée. On
constate la présence de trois parties essentielles correspondant aux services de base. On
a le « Community management », le « QoS Management » et le « User Management ».
Figure 43: La plateforme NGN Middleware proposée
D’après la définition de Hillery (1955) : « la communauté est constituée de personnes en
interaction sociale dans une zone géographique et ayant chacun une ou plusieurs
cravates additionnelles. » Dans le contexte du NGN Middleware, la gestion de la
communauté (Community Management) est constituée par trois fonctions principales : le
55 / 80
Service Location, le Service Presence et le Service Discovery. Ces trois fonctions
principales permettent de construire la communauté. Quand nous avons une adresse d'un
membre, Service Location détermine la localisation (position) du membre de la
communauté. Quand nous avons la localisation d'un utilisateur (par exemple), le Service
Presence permet de trouver les membres de la communauté, qui sont à proximité. Si
nécessaire, le Service Discovery lance une recherche des membres de la communauté,
qui ont les potentiels et les compétences voulus.
Nous définissons le Community Management comme un contrôle fonctionnel des
systèmes par les communautés (utilisateur, réseau, service ou terminal) selon leurs
comportements et/ou caractéristiques communs. Elle se contrôle automatiquement selon
la mobilité en temps réel. Les comportements communs peuvent être : la même
localisation, la même organisation, le même besoin et préférence, etc.
En fait, la communauté la plus intéressante est la communauté de service. Tous les
composants, qui sont fonctionnellement équivalent (les instances d'un SE) et QoS
équivalent (NGN Middleware offrant la même QoS), constitueront le VSC (Virtual Service
Community). Le rôle de ce VSC est de continuer à grouper automatiquement les
membres de la communauté qui ont les mêmes comportements et caractéristiques (QoS).
Cette communauté virtuelle de services contrôle également toutes les entrées et les
sorties des membres de la communauté. La sortie d'un SE peut se produire après un
dysfonctionnement/dégradation au niveau QoS.
D’autre part, la gestion de QoS (QoS Management) est constituée de deux services
principaux: Routing Table qui garde l'information de QoS des SEs et les liens entre ces
SEs; Service Logic qui donnera le déroulement des interactions entre les SEs.
Ces deux services nous permettent de proposer une session dynamique de service
utilisant les messages SIP+ proposés. En fait, nous avons besoin de la liste des SEs à
exécuter. Elle est fournie par la logique de service et nous la mettons dans le message
SIP+. La table de routage est gérée en temps réel afin de s'assurer que les SEs optimaux
sont appelés.
Il nous reste enfin, le User Management qui dans notre conception, devrait contrôler une
communauté d’utilisateurs. Il comporte plusieurs services. On cite par exemple le User
Location qui permet de prendre en considération la mobilité de l’usager.
Afin de mieux comprendre l’interaction entre les différentes entités de composition de
services de cette nouvelle architecture, on va représenter autrement le NGN Middleware
dans le paragraphe suivant, et on va expliquer ces différentes parties.
4.2. La session de bout en bout UBIS
Les demandes d’utilisateur, telle que la réalisation d’un plan de voyage, ont besoin de
plusieurs services coordonnés ensemble. Aujourd’hui, l’utilisateur est obligé de gérer ce
processus de coordination lui-même. Il doit d’abord ouvrir le premier site pour réserver des
tickets, et après le deuxième pour l’hôtel. En terme technique, il doit ouvrir deux sessions
différentes séparément. Plus généralement, nous pouvons dire qu’aujourd’hui nous
sommes « application centric », c'est-à-dire que suivant les contraintes des applications,
l’utilisateur est amené à ouvrir autant de sessions particulières que d’applications.
Pour palier cet inconvénient, nous proposons de mettre en œuvre une seule session de
bout en bout regroupant toutes les applications demandées. L’objectif étant que la session
soit orientée utilisateur, basée sur des blocs fonctionnels qui seront en plus ubiquitaires
pour supporter la mobilité.
Cette proposition de la session « User-Centric » vise à fournir les services personnalisés
automatiquement au travers d’une demande utilisateur. L’utilisateur suivant sa logique de
service, formule sa demande une seule fois au début et il obtient le déroulement des
56 / 80
opérations de façon automatisée et transparente. La session « User-Centric » est
responsable de la composition de service dynamique, ainsi que son support en termes de
la connectivité de bout en bout. Il combine tous les services séparés ensemble et génère
une session unique (Figure 44).
Figure 44 : Sessions Multiples vs. Session Unique
Tous les échanges de données, l’établissement et la destruction de la session, ou toutes
les autres activités comme modification, se passeront dans cette session spéciale.
Nous traiterons la sécurité de cette session dans la tâche qui lui est consacrée, sachant
que l’un des objectifs de cette session est que l’utilisateur ne soit obligé de s’authentifier
qu’une seule fois. Le système devant prendre en charge la relation avec les différents
services sollicités par la session.
Basé sur le modèle VPSN, la session « User-Centric » suit aussi le principe du service de
routage. La demande de l’utilisateur invoque le premier service. C’est au premier service
de trouver le deuxième service et d’invoquer son successeur automatiquement. De cette
façon, une chaîne de services peut être générée pendant ce processus. Ces services sont
activés un après l’autre pour réaliser l’application demandée par l’utilisateur.
Figure 45:Concept de la session « User Centric »
Comme le montre la Figure 45, grâce à notre modèle architectural VPXN, la session
« User-Centric » a des services supports dans chacune des couches. Donc la session
elle-même doit s’adapter à toutes les modifications selon la mobilité ou l’environnement
ambiant. Nous introduirons un automate pour réaliser la gestion automatique et
dynamique de cette session. C’est cette session « User-Centric » qui garantit une mise en
relation complète, pratique et continue pour les utilisateurs.
57 / 80
5. De l’architecture aux blocs fonctionnels
5.1. Topologie fonctionnelle
Partant des besoins de « User-Centric » et les manques des technologies existantes,
nous essayons ici de consigner et de valider avec la première étude faite dans le SP1.2,
les « services supports » et leurs interfonctionnements pour soutenir la continuité de
service intégrée et sans couture. Ces « services supports » sont des services proposés
par la plate-forme de services pour soutenir les services qui sont en train d’être délivrés et
que nous désignerons comme des « services applicatifs » ou des services utilisateurs.
Nous pensons tout d’abord lever l’ambiguïté de NGN et NGS. Notre vision de NGN est
comme le montre la Figure 2 pour couvrir toutes les mobilités. Un « seamless userware »
est situé dans la couche de user pour avoir des informations décisionnelles afin de faciliter
la personnalisation.
Les services dans notre contexte, les NGS, sont proposés à travers un réseau de services
horizontal pour supporter la mobilité de service. Les composants de services doivent être
interopérables, accessibles par plusieurs acteurs, provenant de plusieurs fournisseurs
dans un contexte ubiquitaire.
Pour ce faire, nous avons besoins de « services supports » pour construire et gérer ce
réseau de service. C’est pourquoi nous proposons le « Serviceware » (Figure 46 -1) pour
traiter la composition de service et sa gestion dans une architecture horizontale. Son
objectif principal est la virtualisation des services, la mutualisation de services et le
support de décisions flexibles.
Figure 46 : Topologie fonctionnelle
La propriété de virtualisation des services demande que les services aux clients soient
fournis d’une façon transparente. Il faut donc se doter de mécanismes offrant an client la
58 / 80
transparence de la localisation des services qu’il demande, à leur composition, à leur
organisation et gestion. Le client aura donc accès aux services qu’il demande sans se
soucier de leur localisation réelle ou des mécanismes qui sont mis en œuvre pour le
maintien de leur QoS et de leur continuité. La virtualisation de service permet l’utilisation
optimale des ressources par une allocation dynamique de service en fonction des besoins
de chaque application à un instant donné. Elle offre également une isolation des différents
utilisateurs simultanés d'un même service ce qui rend la sécurité de service.
La propriété de mutualisation de service impose non seulement la réutilisabilité de ce
service, mais aussi sa partageabilité en tant que ressource en réseau et accessible par
réseau. Cela commence par une conception du composant de service au contour bien
délimité afin de favoriser leurs interactions et leur communication. Des propriétés de
simplicité et d’indépendance entre les éléments de service induiront la viabilité du
système. La mutualisation de service est gérée à travers un Provisioning dynamique sur
n’importe quelle plate-forme de service. La scalabilité sera assurée par le contexte
ubiquitaire.
Au-delà de la mutualisation, nous pouvons appliquer tous les autres concepts de la
« technologie réseaux » pour supporter des décisions flexibles. En particulier, la
modélisation permet de représenter les composants de services sur le réseau et en
réseau grâce au processus d’enchaînement d’élément de composants de services
(VPSN). Ainsi, nous pouvons optimiser ces liens en ayant recours à la simulation pour
évaluer les performances de ce réseau de service. La décision flexible est alors assurée
par le routage sémantique et dynamique des composants de service et la base de
connaissances décisionnelle.
Fondé sur les quatre niveaux de visibilité, nous allons gérer chaque type de mobilité par le
niveau architectural approprié. Nous rappelons que les VPxN (x=Equipement, Réseau,
Service ou Utilisateur) sont préconisés par notre modélisation pour identifier les
composants coopérant pour fournir le service. Donc chaque niveau gèrera
dynamiquement son réseau de composants coopérant en fonction des mobilités. Ainsi tout
changement intervenant lors des différentes mobilités au cours de la session « UserCentric » sera pris en compte.
Ce qui nous manque sont alors les solutions abouties pour auto gérer l’échange de
composant sans interrompre le service. Est-ce que les technologies existantes sont
suffisantes pour supporter les mobilités ? Nous avons constaté dans l’étude du contexte
que des solutions comme le handover étaient possibles au niveau L2 et L3, mais que rien
n’existe pour la mobilité de services et des utilisateurs. Comme nous le détaillerons plus
tard, nous proposons de constituer des communautés virtuelles des composants jouant le
même rôle dans un contexte donné. C’est ainsi que nous allons regrouper selon des
critères de coopération, les utilisateurs (Users community), les terminaux (Devices
community) et les services (Services community). Ce qui permettra la gestion de mobilités
à travers les autogestions de ces communautés virtuelles dans chaque niveau de visibilité.
Les utilisateurs d’aujourd’hui peuvent jouer plusieurs rôles, en les mettant selon un intérêt
commun dans une organisation virtuelle, nous pourrions suivre leurs activités et offrir des
services qui les satisferont. C’est pourquoi nous proposons « Users community
management » (Figure 46 - 2).
Il en est de même pour les ressources ambiantes que nous devons gérer autour de
l’utilisateur. Nous trouvons donc « Devices community management » (Figure 46- 3) pour
les terminaux auxquels l’utilisateur a potentiellement accès. En effet, pour notre vision
« User-Centric », nous prenons en compte les préférences de l’utilisateur qui précèdent la
mise en œuvre des Handover Horizontal et Vertical. La gestion aura pour but de préparer
le changement de terminal demandé par la mobilité de l’utilisateur.
59 / 80
Quand un terminal bouge, l’utilisateur rencontrera différents choix des réseaux d’accès.
Nous supposons que les réseaux d’accès sont gérés par une organisation d’accès
(« Accesses organisation management »). Le choix de la connectivité de réseau d’accès à
réseau cœur se fait par le fournisseur de connectivité. Ces deux types d’organisation sont
gérés par les fournisseurs de connexion.
Grâce au « Serviceware », les composants de service sont devenus les services
ubiquitaires et sont gérés par la communauté virtuelle correspondante « Service
community Management » (Figure 46 - 4). La communauté de service organise les
composants de service des différents opérateurs selon les besoins de « User-Centric ».
L’autogestion de la communauté des services répondra la mobilité de service.
Avec ces gestions des mobilités, nous pouvons maintenant considérer la mise en relation
de bout en bout, c'est-à-dire, la « mobilité de session ». La session que nous essayons de
construire et de maintenir est la session mobile orientée utilisateur. Dans cette session, le
service demandé par l’utilisateur est le résultat de l’agrégation des services offerts par
chacun des niveaux VPXN. L’ensemble de ces composants fonctionnels constitue les
« services supports » que nous avons dénommé « NGN Sessionware » (Figure 46 - 5).
Par ailleurs, dans notre topologie fonctionnelle (Figure 46) nous trouvons « seamless
userware » qui est situé dans la couche utilisateur. Ce dernier intègre les « services
supports » de l’Userware auxquels nous rajoutons les fonctionnalités pour assurer la
continuité de service sans couture.
L’« Infoware » rassemble les informations coopératives et décisionnelles de chaque
niveau. Il contribue à la continuité de service à travers le profil real time. Ce profil donne
une image globale en temps réel et supporte la QoS de bout en bout de façon
transparente. Cette composante informationnelle sera traitée plus tard.
5.2. « Serviceware » et le VPSN
Nous rappelons que pour avoir une continuité de service sans couture, c'est-à-dire, une
omniprésence de composition de service, nous préconisons la gestion à travers le réseau
de service dans une architecture de type P2P.
Tant que le déploiement de services autonomes et auto gérables consommeront temps et
argent, la mutualisation du ES fournira un moyen d'optimiser les ressources en partageant
de manière efficace entre les différents utilisateurs.
A travers la mutualisation, sera assignée une tranche du ES, qui comprend seulement les
ressources nécessaires à chaque demande utilisateur. Le ES peut être mutualisés parmi
plusieurs VPSN et utilisés dans différents contextes (Figure 47). Toutes les ressources
non utilisées dans le ES seront libres d'être assignés à de nouveaux utilisateurs à la
demande. En outre, plusieurs tranches du même ES peut être trouvé dans le même
VPSN, chacun d'eux servant à remplir la même fonction, mais avec des cibles différentes,
avec ses propres exigences et contrat.
60 / 80
Figure 47: Mutualisation d’un ES pour différente Composition de Service
Afin de visualiser la flexibilité de la composition de service, nous proposons un scénario
(Figure 48) qui prend cas de deux utilisateurs, chacun d'eux avec sa propre session, donc
ils disposent des VPSN indépendants.
L’utilisateur A veut afficher un film offert par son fournisseur de VoD chez des amis.
L’utilisateur A ouvre sa session, et accède à l’interface de la vidéo à la demande du
fournisseur qui lui permet de choisir le film qu'il souhaite regarder de la base de données.
Pour autoriser l'accès à l’utilisateur A, une authentification (authentification ES) sera faite
par le fournisseur de vidéo à la demande afin de vérifier son identité. Le service qui
permettra le choix du film sera fait par le choix du contenu du ES.
Une fois le film choisi, une nouvelle instance de l'authentification du ES sera nécessaire,
cette fois, pour authentifier l'utilisateur à sa compte afin de charger le coût du film
demandé. L’ES autorisation sera également demandé afin de vérifier si le film choisi n'est
pas interdit à cet utilisateur particulier (d'après sa politique de contenu, si une scène
d’action s’applique dans le film). Notez que l'authentification et l'autorisation des services
sera effectuée d'une manière transparente, sans l'intervention de l'utilisateur A.
Une fois le film est choisi et approuvé, l’ES Localisation sera utilisé pour localiser
l’utilisateur A et les terminaux susceptibles à être utilisés pour l’affichage du film.
Après avoir analysé toutes les possibilités, les meilleurs équipements sont un vidéo
projecteur connecté à l’ordinateur de l’utilisateur A pour afficher l'image et pour le son, il y
a un équipement avec des haut-parleurs de bonne qualité avec Hi-fi. L’ES streaming,
transcodage, séparation de l’image/et Son, affichage de l'image et affichage du son
travailleront ensemble pour fournir le service demandé par l'utilisateur A avec les
meilleures performances possibles.
61 / 80
Figure 48: Scénario de la mutualisation d‘un ES et Composition de Service
Notre deuxième cas est situé dans un contexte complètement différent.
Un utilisateur B est en vacances et conduit sa voiture pendant quelques heures à la plage
la plus proche. Il a ouvert sa session avant de quitter son domicile et choisi parmi une liste
la musique qu'il veut écouter au cours de son trajet (ES play-liste choix).
Selon les préférences de l'utilisateur spécifié dans son contrat, l'utilisateur B veut recevoir
tous ses messages SMS comme SMS-vocaux pendant qu’il conduit sa voiture.
L’utilisateur B quitte sa maison en écoutant la musique choisie précédemment (ES lecture
de CD et affichage du son pour adapter le son au type de musique joué).
Alors qu’il est sur la route, il reçoit un SMS. L’ES Localisation sera appelé pour localiser
l'utilisateur afin de trouver la meilleure façon de délivrer le SMS.
Une fois localisé, l'authentification et autorisation du réseau sont nécessaires. Le service
de lecture de musique est en pause tout en offrant la communication vocale-SMS et ES:
SMS de livraison, transcodage texte à voix et affichage du son, sont utilisés pour y
parvenir. Le service de jouer la musique sera repris après que la livraison des SMS soit
terminée.
On peut observer dans ces deux cas, comment le même ES peut être mutualisé parmi les
différents utilisateurs et comment le même ES peut être utilisé dans des contextes
différents, grâce à la généricité du ES. Cela rendra la composition souple et permettra aux
utilisateurs de personnaliser leurs services et d’en créer de nouveaux en fonction de leurs
besoins.
Basé sur les propositions sur la composition de service et la fourniture de service à travers
le VPSN, nous pouvons maintenant préciser le bloc fonctionnel de le « Serviceware »
comme la suite (Figure 49) :
62 / 80
Figure 49: Serviceware
Nous expliquons les fonctions importantes :
•
•
•
•
Service Composition
Cette fonction doit effectuer toutes les spécifications que nous venons de
proposer.
Service delivery (VPSN)
La livraison de service concerne la gestion d’une session continue basée sur un
tableau d’entrée/sortie de l’agrégation de service (QoS routing table). Ce tableau
est maintenu par la fonction de continuité dans chacune des communautés. La
construction dynamique du VPSN permet une session de service sans couture et
sans coupure.
E2E QoS management
Cette fonction nous permet d’avoir une continuité de QoS de bout en bout.
Charging
Ces fonctions nous permettent d’enchaîner tous les composants de service des différents
fournisseurs de service et offrir à l’utilisateur un charging global et une seule facture.
5.3. Gestion des mobilités
En considérant les mobilités qui sont les causes principalement des discontinuité de
service, nous pouvons retrouver les solutions traditionnelle de la gestion de mobilité pour
le réseau tout IP : Mobile IP et SIP Mobility. Partant la première réponse à notre
problématique obtenu, pour avoir une gestion de la mobilité à la façon générique, nous
nous intéressons la gestion de mobilité un environnement P2P.
Nous rappelons que pour avoir une continuité de service respectant la QoS, tous les
dysfonctionnements de la QoS (§5.3.1) sont considérés comme les événements qui
lanceront une gestion. La première étape est d’essayer d’identifier les acteurs (§5.3.2) qui
invoqueront la coupure de la fourniture de service à cause de mobilités. Nous proposons
une gestion autonomique et dynamique par les communautés virtuelles pour gérer ces
mobilités. Nous démarrons du concept de communauté d’intérêt (§5.3.3) pour donner un
règle d’organisation. L’autogestion de la communauté (§5.3.4) est alors proposée.
5.3.1 Dysfonctionnements de la QoS du composant
Nous avons choisi quatre critères pour exprimer les caractéristiques de service. Comme
nous l'avons exprime la QoS traduit le comportement du service. Or ce comportement
63 / 80
peut se modifier durant les différents déplacements. Nous allons recenser les raisons du
dysfonctionnement de la QoS du composant lors des mobilités à travers les critères.
La Disponibilité
•
•
Au delà des indisponibilités dues aux pannes du composant, nous pouvons avoir, lors de
la mobilité du terminal, qui entraîne des changements de réseau d'accès, des
dépassements de seuil de temps de réponse ou des coupures de connectivité.
Dépassement de seuil du temps
Par exemple, on prend un composant de service. Pour ce composant, le dépassement de
seuil du temps peut être à cause de l'expiration de crédit du côté utilisateur, l’autorisation
pour accéder à ce composant n’est plus valable. Ainsi que l’utilisation du composant
comme un dépassement d’une mise à jour ou d'un changement des paramètres.
Coupures de connectivité
Elles se produisent suite à des pannes de matériel ou de logiciel. Une panne du hard
indique une faute dans les équipements par exemple les serveurs, les câbles, les
terminaux, etc. Celle du soft peut être la congestion du réseau ou des fautes / time out
dans les protocoles de la communication.
De plus, si on se trouve dans un contexte 'transorganisationnel' on peut également avoir
des coupures lors du changement de fournisseur de service ou d'une remise à jour de la
configuration à cause du changement de location.
Délai
Là aussi la mobilité du terminal, entraîne des temps de traversé plus long, qui impactent le
temps de réponse demandé initialement par l'utilisateur dans son SLA. Dans notre
contexte ubiquitaire, on aura des possibilités de préserver les temps de réponse.
Capacité
Il s'agit ici d'un manque de ressource pour les traitements aussi bien au niveau du
terminal, que du réseau ou du composant de service. Les fonctions de Provisioning
(terminal, réseau, composant de service) n'ont pu aboutir lors de la mobilité de l'utilisateur
(changement de terminal) ou lors de la mobilité du terminal (changement de réseau
d'accès) ou lors du changement du composant de service.
Fiabilité
Nous trouvons sous ce critère les dysfonctionnements dus à la perte de données lors des
différents handovers qui interviennent lors des déplacements.
Le dysfonctionnement de ces quatre critères traduit le fait que la QoS demandée n’est
plus garantie par les composants de service lors des déplacements de l'utilisateur. Tous
ces dysfonctionnements sont considérés comme des événements qui déclencheront la
gestion.
5.3.2
Des acteurs
Après le recensement des dysfonctionnements de la QoS, nous allons identifier les
acteurs extérieurs et les blocs fonctionnels correspondants pour traiter les différents types
de mobilité.
D’après les exigences de NGN et les besoins de l'user centric, on trouve donc (Figure 50):
64 / 80
Figure 50: les cas d’utilisation de la gestion de mobilité
Devices, qui représentent les terminaux autour d’un utilisateur, ces terminaux peuvent
être ceux qui sont utilisables et ceux qui sont prêts à être utilisé.
Access Networks, qui représentent les différents types de technologies d’accès, ces
réseaux d’accès peuvent être homogènes ou hétérogènes.
Services, qui représentent les services variés supportés par les fournisseurs de services.
Users, qui représentent les utilisateurs avec une identification unique.
Contents, qui représentent les contenus de service comme textes, images, audio, vidéos
et animations. Ils ont un rôle important dans le format de service.
5.3.3 Concept de communauté d’intérêt
Pour pallier les dysfonctionnements de la QoS concernant les composants, on propose
une organisation fondée sur "les communautés d'intérêt".
Nous disposons d'une définition de Hillery (1955): «la communauté est composée de
personnes avec des interactions sociales au sein d'une zone géographique et ayant un ou
plusieurs autres liens."
Une autre définition de la «communauté d'intérêt» (CoI), est donnée par US DoD: "Un
groupe de personnes connectées les unes aux autres par un besoin de résoudre des
problèmes communs, de développer les compétences et de partager des pratiques
communes "
Le concept de “Communauté d’intérêt” est applicable par exemple à un groupe de
personnes dans une location résidentielle et ayant au moins une des trois dimensions
suivantes:
1. la dimension Perception : Un sentiment d'appartenance à une région ou à une localité
qui peut être clairement définie.
2. la dimension Fonctionnelle : la capacité de coordonner les services demandés avec les
exigences de la communauté.
3. la dimension Politique: la capacité à l’élection d'une représentativité pour exprimer
l’intérêt de la communauté et concilier les conflits de tous ses membres.
C’est important de mentionner que cette définition inclue deux dimensions de la notion de
communauté d'intérêt. Elles sont identifiables en tant que dimension subjective
(perception) et objective (fonctionnelle) et de ce fait, chacune se rapporte à différentes
mesures et qualités. La dimension politique implique à la fois l’aspect subjectif et objectif.
Les mesures fonctionnelles de la communauté d'intérêts devraient également analyser
l'étendue de l'administration locale comme un fournisseur de services surtout dans le
cadre de la gestion. Il peut aussi être utile d’évaluer l’existence ou la tendance de la
coopération entre différentes communautés d’intérêts. La différence des communautés
peut aussi se faire selon les activités et les services fournis.
65 / 80
L’évaluation des caractéristiques politiques peut être la direction, la distribution de
l’information et le réseau de gestion.
En conclusion, plusieurs approches peuvent exister pour concevoir une CoI :
•
•
•
•
•
Une approche organisationnelle ou structurelle : la CoI a un caractère organique et
stable dans le temps. Elle ne dépend pas des missions/objectifs attribuées. Par
exemple, la communauté politique que nous venons de mentionner.
Une approche fonctionnelle : la CoI est constituée pour la durée de vie d’une application.
Par exemple, une équipe de construction, un groupe de soldats pour un convoi, celle de
position,.
Une approche informationnelle : la CoI permet d’organiser des constructions
d’ensembles pour faciliter la mise en œuvre du partage de l'information. Ses membres
sont chargés de rendre l'information visible, accessible, compréhensible, et de
promouvoir la confiance - ces facteurs contribuent à l'interopérabilité nécessaires des
données pour avoir l'efficacité du partage de l'information.
Une approche collaborative : la CoI est formée pour regrouper des acteurs
complémentaires. L'intérêt majeur est d'associer les capacités des membres participés
et d'obtenir ce qu'il y a de mieux avec les ressources disponibles.
Une approche coopérative : la CoI regroupe des acteurs soumis à des règles communes
de comportement.
Le but des communautés d'intérêts est d'acquérir des accords sémantiques et structuraux
sur l'information partagée. Pour que la communauté d'intérêt soit efficace, il faut que leur
champ d'application, c'est-à-dire la sphère de leurs accords, soit aussi restreinte que
raisonnable.
On s’appuie sur cette notion de communauté d’intérêt pour gérer la composition et la
recomposition aussi bien de services que des réseaux, lors des différentes mobilités.
Nous précisons que dans notre contexte, l’intérêt commun, la mission, est de fournir la
continuité de service quelque soit la mobilité considérée.
Nous considérons d’abord la dimension organisationnelle de la CoI. L’organisation de CoI
doit être au sein d’un cadre commun, c’est le cadre qui formalise l’existence commune des
composants comme une entité. Il protège également ses membres pour que les données
et les services intérieurs ne soient pas proposés à l’extérieur. De plus, en considérant la
partie collaborative, ce premier filtrage nous permet de réunir un ensemble d’acteur qui,
au lieu de d’additionner leurs ressources, les multiplient, c'est-à-dire, plusieurs membres
peuvent profiter du même service.
Ensuite, la CoI met en commun des acteurs jouant des rôles. Les rôles sont instanciés par
des acteurs. Il est souhaitable de proposer les supports permettant le travail collaboratif,
c'est-à-dire, le partage de l’objectif soit porte non seulement sur les informations, mais
aussi sur les services, de façon transverse, dans le cadre d’une mission, indépendamment
de l’organisation hiérarchique. Ainsi, une entité peut avoir plusieurs représentations dans
ce plan : appartenance à plusieurs CoI simultanément.
Finalement, la CoI possède les moyens procurant des capacités opérationnelles. Cette
dimension permet de proposer ou de souscrire à des ressources d’après les
comportements des composants de service. Les ressources ont des capacités qui sont en
fait les services offerts.
Donc, les communautés d’un même type d’organisation peuvent être précisées par leur
dimension fonctionnelle et dimensions opérationnelles.
Nous appliquons ces propriétés (cadre- rôle- capacité) pour obtenir la définition formelle
de la CoI. Avec l'architecture proposée, chaque mobilité relève d'un niveau de visibilité.
66 / 80
Nous proposons de créer à chaque niveau des communautés, chacune anticipant les
actions à prendre pour la mobilité dont elle est responsable. Nous trouvons donc les
acteurs extérieurs mentionnés :
•
Communauté des utilisateurs (Users community)
Organisationnellement, cette communauté a d’abord pour but de gérer un groupe
d'utilisateurs qui sont accessibles par une identification personnelle unique.
De plus, d’après les rôles joués par chaque utilisateur, ceux qui ont le même intérêt ou
bien participent à la même activité peuvent être placés dans une même communauté
d’utilisateur. L’objectif pour les mettre dans une même communauté est de partager au
maximum des ressources ou/et des services.
A travers la vision opérationnelle, chaque l’utilisateur apporte des comportements
différents pour des activités différentes. Un utilisateur peut être un demandeur
d’information, mais il peut en être aussi un fournisseur si, il possède des services
intéressant d’autres utilisateurs. Dans ce cas là, ceux qui ont les mêmes comportements
doivent être mis dans la même communauté.
•
Communauté des équipements (Devices community)
Cette communauté est identifiée pour gérer les équipements en répondant différents
besoins.
Pour un utilisateur donné, une seule communauté est donnée pour gérer son groupe des
équipements. Cette communauté est donc conçue pour être responsable de la gestion
des équipements dans le PAN (Personal Area Network). La propriété des équipements est
donc protégée.
Par contre, fonctionnellement, le travail principal de cette communauté est de gérer la
mobilité des utilisateurs, chaque type de équipement a ses propres services offerts mais il
a aussi des contraintes comme la batterie, le poids, le coût d’utilisation. En considérant les
préférences de l’utilisateur sur les équipements, toutes ces informations doivent être bien
organisées.
Un équipement participe donc à plusieurs communautés selon ses services possibles et
ses contraintes techniques. La mutualisation de ressources est donc garantie.
De plus, si nous considérons la capacité opérationnelle, les comportements de chaque
service offert par un équipement doivent être pris en compte.
Dès qu’un composant de service est installé pour un déploiement de service d’une
session « User-Centric », sa QoS devient également un critère pour la construction de la
communauté des équipements.
•
Organisation des accès (Accesses organization)
Cette communauté est nommée ‘organisation’ car elle gère tous les réseaux d’accès
utilisables ou potentiellement utilisables en considérant un terminal mobile. A cause du
basculement du terminal entre différents domaines d’administratifs, cette communauté doit
aider à la gestion du handover et à la gestion de localisation.
L’objectif de la gestion du handover est de garder toujours la connexion malgré le
mouvement du terminal.
L’objectif de la gestion de la localisation est de garder la trace du terminal même sous
l’état de veille pour être prêt à fournir les services demandés.
La gestion est prise en compte par les fournisseurs de réseau, nous avons considéré que
la plupart des solutions actuelles répondaient à cette mobilité du terminal.
La mobilité de réseau doit également être supportée par cette organisation.
•
Communauté des services (Services community)
La mobilité de service doit être supporté grâce à l’auto gestion de cette communauté. La
communauté organise les services qui ont la même caractéristique organisationnelle, par
exemple, l’endroit où se trouvent les composants de service. De plus, les services dans
une même communauté peuvent être fournis par différents fournisseurs.
67 / 80
Principalement, on peut avoir plusieurs communautés de service simultanément en
fonction de différentes exigences fonctionnelles. Cette communauté gère tous les
composants de service fonctionnellement équivalents.
Pour que l’aspect non fonctionnel soit respecté, les composants de service qui sont QoS
équivalents doivent être mis dans une même communauté de service.
•
Communauté du contenu (Content community)
Cette communauté a pour but de gérer la migration du contenu lors des différents types
de mobilité. Par exemple, la fonction de choisir les différents codages pour un même film a
besoin du support de la gestion de contenu pour avoir tous les formats de fichiers
disponibles pour le transcodeur. Nous proposons de gérer également les contenus à
travers la gestion de communauté appropriée car ce dernier est très important dans le
cycle de vie d'un service. La gestion d’un système distribuée et le problème de sécurité
peuvent être gérés par l’auto gestion de cette communauté. Cette communauté n’est pas
dans le périmètre d'étude du projet UBIS.
5.3.4 Autogestion de communautés
Pour satisfaire le besoin de flexibilité demandé par « User-Centric », nous avons d'abord
proposé de répondre aux différentes mobilités par la gestion d'un réseau représenté à
travers les enchaînements de composants de même natures dénommés VPXN
(X=Utilisateur, Service, Connectivité, Equipement). Nous rappelons que les communautés
d’intérêt définies ici ont pour l’objectif la continuité de service, et sont proposées comme
les « services supports » de chacun de réseau virtuel (VPXN). La gestion de ces éléments
en communauté et leurs interfonctionnements doivent être donc autonomiques et
dynamiques.
Nous définissons la gestion de communauté comme un contrôle fonctionnelle du système
par la communauté virtuelle en fonction de leurs comportements communs et/ou leurs
caractéristiques communes. Elle s’auto gère automatiquement en fonction des mobilités
en temps réel. Leurs comportements communs peuvent être : la même localisation, la
même organisation, les mêmes besoins et les mêmes préférences, etc.
Nous organisons les utilisateurs qui ont la même caractéristique dans une même
Communauté Virtuelle (CV), ce qui permet à un utilisateur de recevoir les informations
intéressant le groupe ou de remplacer l’un et l’autre suivant leur activité sociale (VPUN).
Le VPSN est alors construit et maintenu par sélection des ESs appropriés des différentes
Communautés Virtuelles de Services (CVS). Les remplacements des ESs doivent être
faits dans chacune des CVS de façon dynamique et autonomique.
Quant à VPCN, les NEs (Network Element) sélectés doivent pouvoir être remplacés par
les NEs qui ont la même fonctionnalité. Les CV de Réseau (CVR) sont responsables de
l’organisation des noeuds de type backup.
Finalement, les EEs (Element d’équipement) qui ont la même caractéristique doivent être
regroupés dans une même CV de Equipement (CVE) pour garantir le bon fonctionnement
du VPEN.
De plus, la construction et l’autogestion de CV depend non seulement des
fonctionnements équivalents mais aussi de la partie non fonctionnelle : les besoins de
QoS de bout en bout. Le VPXN correspondant doit sélecter le composant qui répond au
mieux au SLA (Service Level Agreement) et maintenir la QoS de bout en bout en cas de
dégradation de QoS causée par les différentes mobilités pendant l’exploitation.
A travers ces exigences que nous avons retenues, nous essayons de préciser les
fonctions génériques de gestion selon les différentes phases.
Création d'une communauté
Nous nous concentrons dans la couche de service. Nous prenons un ES comme un Peer.
Quand un ES est installé dans la plate-forme de service, il déclare tout de suite le service
68 / 80
qu'il peut offrir, ce qui permet aux autres ESs d'y accéder. Il annonce également sa
fonctionnalité, ce qui permet de l'associer au groupe des Peers adéquat, c'est-à-dire au
bon CVS. Par exemple (Figure 51), une CVS est construite en fonction de la fonctionnalité
équivalente (Fun1).
Quand un utilisateur demande une application, un VPSN est créé pour gérer les
composants de service répondant à son besoin. Pour la fonction Fun1, le VPSN consulte
le CVS avec une QoS1 afin de décider quel composant prendre. Le CVS est donc filtré
d’abord selon les ES ayant la QoS demandée et met les candidatures dans une
communauté. Nous avons alors une communauté où se trouve le composant A avec ses
ES fonctionnellement et QoS équivalentes. Dans l’exemple, c’est le composant A qui est
finalement sélecté par le VPSN.
Figure 51: Création de communauté
Les fonctionnalités que nous pensons nécessaires pour la création de la communauté
virtuelle sont:
• Authentification
L'authentification est la procédure qui consiste, pour un système informatique, à vérifier
l'identité d'une entité (personne, ordinateur...), afin d'autoriser l'accès de cette entité à des
ressources (systèmes, réseaux, applications...). L'authentification permet donc de valider
l'authenticité de l'entité en question. Elle est nécessaire à tout accès et celle du coût
(Cost) nécessaire à tout choix.
• Cost
Cette fonction a pour but de calculer le montant total des dépenses pour réaliser un
service. Le coût peut être décomposé en frais de base et en coût de transaction
demandée par le fournisseur.
• Profile & usage profile
Pour avoir une représentation homogène de tous les composants, on adopte la QoS
comme le dénominateur commun. Les critères de QoS sont sélectés pour construire les
profils qui caractérisent un membre d’une communauté. Les informations de la capacité
QoS (le valeur conception de la QoS maximum d’un composant peut offrir) sont dans le
profil de ce composant, l’usage de ces composants se trouve dans le profil de usage.
L’usage est relié avec l’environnement d’exécution d’un composant, donc le profil d’usage
doit comprendre les informations pertinentes pour décider comment utiliser ce composant.
On propose de le structurer à travers la QoS demandée, la QoS offerte et les contraintes.
L’exploitation d'une communauté
Dans la phase d’exploitation du CV, nous devons tenir compte non seulement des
exigences spatiales mais aussi de celles de nature temporelle car le composant doit être
toujours connecté malgré son changement de localisation ou d'activité. Or, les éléments
69 / 80
associés à localisation et à l'activité doivent être accessibles en temps réel avec les
contraintes.
Avec ces besoins, nous identifions les services de base suivants :
• LBS (Location Based Service)
Ce service de base a pour but de déterminer l’endroit géographique d’un composant
de la communauté en fonction de l’information donnée. Ce qui peut être l’adresse ou
la position de ce composant. LBS peut servir de trouver un composant avec une
fonction et une QoS précise pour l’ajouter à la communauté.
• PBS (Presence Based Service)
Ce service de base a pour but de trouver les composants qui sont à proximité d’une
position connue d’un composant avec des critères. Les résultats de PBS peuvent
servir à donner les possibilités concernant une demande.
• DBS (Discovery Based Service)
Ce service de base a pour but de découvrir les nouveaux membres qui sont qualifiés
pour entrer dans la communauté actuelle.
• ABS (Activity Based Service)
Ce service de base est pour identifier l’activité commune des composants dans un
même groupe.
Ces fonctions sont les fonctions de base pour gérer tous les membres de la communauté
en temps réel. En considérant un dysfonctionnement d’un membre de la communauté,
grâce aux services de base, on peut offrir les réactions correctes et faire les mises à jour
des membres de la communauté. Nous allons détailler des cas d’usage représentatifs
pour montrer comment ces services de base peuvent être utilisées afin d’avoir la gestion
de communauté. De plus, avec cette gestion, la mobilité correspondante peut être résolue.
Gestion de communautés des utilisateurs
Supposant que (Figure 52) Alice veut acheter un cadeau noël samedi et compte rejoindre
Bob aux galeries Lafayette. Elle passe d’abord par le magasin du Printemps, et se
retrouve avec tous ceux qui sont présents autour de ce dernier (UPBS). Grâce à son
agenda, l’UABS déclare automatiquement que l’activité d’Alice est l’achat du cadeau.
Donc elle rejoint la communauté des consommateurs (Communauté 1) pour recevoir les
bonnes informations. Des bons de réduction électronique Printemps sont
automatiquement envoyés par SE5 selon les préférences qu’Alice a indiqué dans son
profil d’utilisateur. Les conseilleurs qui offrent les bons de réduction sont ceux qui sont
retrouvés (UDBS) autour d’Alice et qui sont réunis dans la Communauté 2. Quand elle
arrive près des galeries Lafayette, les informations de Lafayette sont diffusées par SE6 et
sont aussi reçues par Alice car grâce à la localisation (ULBS), Alice est ainsi incluse dans
la communauté 3 de ‘Lafayette’. Bob est supposé arriver un peu plus tard qu’Alice, il sera
alors inclus dans la communauté 3 de ‘Lafayette’, Il lance alors UDBS pour trouver Alice.
70 / 80
Figure 52: Exemple de la gestion de la communauté des utilisateurs
Notre approche facilite les diffusions et le partage d’information grâce à cette construction
dynamique de communautés d’utilisateur. Ce genre des communautés a pour objectif de
réunir les utilisateurs ayant les mêmes caractéristiques, ce qui intéresse les fournisseurs
de contenu. Aujourd’hui, les caractéristiques de l’utilisateur sont enregistrées dans la base
de données du côté l’opérateur, le diffuseur de l’information peut la consulter avant
d’envoyer les publications. L’objectif est de permettre aux diffuseurs d'informations
d'envoyer des informations sans connaître spécifiquement chaque user et d’augmenter
leurs chances de toucher plus de personne et d’avoir l’effet « longue traîne ».
Avec les services génériques proposés avant, nous avons ici la gestion de la communauté
des utilisateurs comme suit (Figure 53) :
Figure 53: Gestion de la communauté des utilisateurs
Gestion de communautés des équipements
La gestion de cette communauté peut supporter deux types de mobilité : la mobilité de
terminal et la mobilité de l’utilisateur. Nous regardons d’abord la mobilité de terminal.
Un utilisateur souhaite connaître les terminaux utilisables dans un contexte mobile,
dynamique et en temps réel. Terminaux autour d’un utilisateur sont organisés de manière
autonome, un nouveau PAN doit être prêt dès l’arrivée de l'utilisateur a un endroit donné.
Aujourd’hui, un utilisateur possède plusieurs terminaux hétérogènes. C’est l’opérateur qui
conserve l’information de ces terminaux concernant un utilisateur. Une base de donnée
centralisée et statique est employée.
Supposant que (Figure 54) Alice est localisée dans son bureau (DLBS) grâce à son
terminal (portable), le service de base de DPBS l’aide de savoir tous les équipements
autour quand elle est dans son bureau. De plus, la fonction DDBS avec sa propre droit
d’accès organise les terminaux utilisables qui lui appartenant pour construire son PAN
(PC, Phone et PDA).les ressources fonctionnellement équivalents sont ainsi réunies par le
DPBS dans leurs communautés pour les différentes activités (scanner ou imprimer). Ces
71 / 80
communautés des équipements préparent des ressources pour une utilisation sans
coupure et fiable en temps réel.
Quand elle se déplace dans une salle de réunion (DLBS), à travers du service de base de
DABS, son activité de conférence sur son agenda lui permet de joindre la communauté de
la conférence, là où se présentent (DPBS) les équipements des autres utilisateurs, les
équipements sur place (IP phone et projecteur). Supposant que en cours de réunion, les
deux participants ont allumé leur projecteurs apportés, ceux deux nouveaux membres
sont alors découvertes (DDBS par la fonction « projeter ») et regroupés avec le projecteur
actuel utilisé dans la communauté de projecteur.
Figure 54: Exemple de la gestion de la communauté des équipements 1
Notre approche est « User centric ». Selon cette vue, tous les équipements doivent
être organisés autour de l’utilisateur. De plus, ils concernent un utilisateur dédié.
Communauté de équipements gère, dynamiquement et automatiquement, les
terminaux autour d’un utilisateur pour que l’utilisateur puisse toujours avoir une bonne
sélection de terminal répondant différents services. Dans cette vision, la mobilité de
l’utilisateur peut aussi être supportée.
Figure 55: Exemple de la gestion de la communauté des équipements 2
Alice est en train (Figure 55) de regarder une vidéo dans son PDA. L’ordinateur fixe, IP
phone, PDA et le portable sont dans la communauté des équipements domicile (DLBS,
DABS et DPBS). D’après sa préférence, un écran plus grand est préféré pour ce type de
service grâce à la communauté des équipements fonctionnellement équivalents
(SE31=SE32= service d’affichage), selon le DDBS, SE32 installé sur son portable est
trouvé comme celui ayant la meilleure QoS par rapport au SE31 installé dans le PDA. Le
transport est alors changé à travers AN2. Tous ces traitements sont transparents à
72 / 80
l’utilisateur grâce à l’autogestion de la communauté des équipements Fonctionnellement
équivalents (service affichage).
En conclusion, cette communauté s’auto gère grâce aux fonctions qui sont des services
de base :
• Location est pour identifier où se trouve le terminal;
• Découverte est pour avoir des terminaux disponibles selon un critère sélecté.
• Activité est pour donner les contraintes et les possibilités pendant la construction
d’une communauté avec les préférences de l’utilisateur.
des équipements comme suit (Figure 56) :
Figure 56: Gestion de la communauté des équipements
Gestion de communautés des services
Cette fois-ci, la problématique est de comment assurer une session service de bout en
bout dans une manière sans coupure et sans couture quand le terminal se déplace. De
plus, l’utilisateur n'a pas conscience des traitements.
La session de service ne doit pas être coupée quand un meilleur composant de service
est trouvé et remplacé automatiquement. Aujourd’hui, l’utilisateur est obligé de couper la
session pour choisir un fournisseur qui offre cette fonction avec la QoS souhaitée. Dans
notre approche, les éléments des services sont organisés dans une communauté de
service fonctionnellement et QoS équivalents. L’autogestion des communautés de service
va assurer la mobilité de service.
Alice se déplace (Figure 57) avec son PDA tout en regardant un film fournit par SE22 et
synchronisé par SE11. Après son arrive à AN 1’, la QoS de service offerte par SE22 se
dégrade, grâce à l’autogestion de la communauté de service SE2x (SLBS, SPBS, SDBS),
SE21 est automatiquement sélecté pour une session de service sans coupure.
Figure 57: Exemple de la gestion de la communauté des services
des services comme suit (Figure 58) :
73 / 80
Figure 58: Gestion de la communauté de services
5.4. Sessionware : Continuité de service intégrée
Pour assurer la continuité de service de bout en bout, nous proposons d’abord une
session mobile et unique orientée utilisateur (§4.2). A travers cette session, les gestions
de différentes mobilités peuvent être prises en compte par agrégation.
Les fonctions dans le «NGN Sessionware» (Figure 59) sont donc identifiées:
• Service agrégation
Au delà du réseau de service overlay. L’agrégation de service est la mise en relation
dynamique de tous les services offerts par les composants de niveau différent
(service, réseau, et équipement).
• Continuous service delivery
Cette fonction responsable de la fourniture des services pour l’application demandée
par l’utilisateur.
• E2E QoS management
Cette fonction nous permet d’avoir une continuité de QoS de bout en bout.
• Authorization
• Charging aggregation
• Billing (one bill)
Ces trois fonctions nous permettent d’enchaîner tous les composants de chaque visibilité
et d’offrir à l’utilisateur un charging global et une seule facture.
Figure 59 : « NGN Sessionware »
5.5. « Seamless Userware »
Le dernier bloc fonctionnel est le « Seamless Userware » (Figure 60) avec l’utilisateur
pour interférer. Les préférences sont mises en fonction de la localisation des ressources,
74 / 80
et/ou suivant son activité à un instant donné. Nous devons traduire les préférences en
fonction de sa location et son activité temporelle. Le filtrage par les préférences nous
permet de déterminer la rentabilité des ressources ambiantes. La priorité de l'utilisation de
chaque ressource ambiante peut être déterminé se basant sur un mécanisme de calcul de
base sur les poids. Après l’application des préférences d'utilisateur, l'information sur des
ressources disponibles (« Real Time Profile » dans l’Infoware) pour la maintenance de la
session est accessible.
Figure 60 : « Seamless Userware »
5.6. Synthèse
Une analyse plus en détaillée nous permet d’identifier les interfaces qui existent entre les
blocs fonctionnels dans une carte fonctionnelle (
Figure 61).
75 / 80
Figure 61 : Carte fonctionnelle
Les besoins de la gestion en temps réel et ceux de faire coopérer les « communautés »
nous imposent une autogestion en fonction de mobilités. Finalement, les handovers
horizontaux et les handovers verticaux qui existent dans le réseau de transport nous
demandent un « offreur de connectivité » selon la meilleure connectivité.
Pour répondre à ces besoins, nous identifions respectivement les usecases suivants :
« seamless userware », « service session provider » et « connectivity provider », pour
offrir la mobilité de session et la gestion de la QoS de bout en bout.
Pour la composition de service qui intègre le SOA pour avoir une architecture horizontale
de service du type réseau overlay. La seconde est pour un enchaînement dynamique et
flexible des composants dans un VPSN.
Nous rappelons que toutes les entités dans notre architecture sont mutualisables et
partageables. Les blocs fonctionnels sont tous du type EDA, ce qui rendre la flexibilité au
système.
Dans le « Serviceware » proposé, la gestion se fait dans deux parties : une partie est la
gestion de la composition de service dans une architecture horizontale pour offrir un
réseau de services. Une autre partie est la gestion de la logique de service pour une
session de services.
Nous reviendrons ensuite sur la QoS, les entités ont leurs propres gestions de
performance pour contrôler et optimiser leur comportement. Cette gestion locale est faite
par le monitoring de leurs caractéristiques non fonctionnelles, c'est-à-dire, leur QoS.
En effet, durant l’exploitation du service, sa QoS reflétera si ce composant fonctionne
conformément au SLA ou pas. Une QoS de bout en bout est souhaité quand nous
considérons une vraie application de services. Assurer les applications globales à travers
la construction d’une session virtuelle et crosslayer est notre but final. Donc les aspects
QoS doivent être intégrées dès le début de la phase conception.
76 / 80
Pour avoir une vision plus claire de toutes nos propositions, nous proposons de les mettre
dans un scénario final (Figure 62).
Figure 62: Scénario final
Un utilisateur emploie son ordinateur portable quand elle est dans son bureau, le SE4 qui
est en fait un composant applicatif, par exemple l’affichage, du côté terminal est en train
de fonctionner. Supposant qu’elle souhaite également recevoir les emails (SE2bis) et SMS
(SE2) à travers un même terminal, la première application « User-Centric » est alors
construite par une logique de service (0) :
LS0= SE1 (authorization) +SE2+SE2bis1+SE4.
(0)
Dans son bureau, le PAN (1) d’Alice représente tous les équipements qui lui
appartiennent :
PANBureau = {laptop, PDA}
(1)
Il est 18H00, elle est supposée sortir du bureau. Mais suivant son agenda, elle attend
toujours un dernier email de confirmation de son client (UABS). Car il n’est pas pratique
d’utiliser l’ordinateur portable pendant la route, Grâce à sa communauté des équipements
PAN au bureau, son PDA est trouvé (DABS, DPBS) disponible pour l’activité de « travail »
pour avoir tous les services. Avec la logique de service (0), SE4 est identifié comme la
fonction souhaitée. Le composant de service SE5 est trouvé (DDBS) équivalent de SE4,
donc le PDA est choisi (DSelecting) pour continuer la session d’application d’Alice. La
session répond à la mobilité de l’utilisateur et un changement de SE4 à SE5 peut se faire,
une LS1 (Figure 62 - 1) est l’application actuelle (2) :
LS2= SE1+SE2+SE2bis1+SE5.
77 / 80
(2)
Alice se déplace dans sa voiture, un deuxième PAN (3) est alors automatiquement
construit.
PANvoiture = {PDA}
(3)
Puisqu’elle n’a plus de choix de terminal, elle reste donc avec le PDA. Grâce à son
agenda, nous pouvons prévoir son trajet de 18H10- 19H30 avec sa voiture (UABS), elle
ne peut pas voir ses email pendant son trajet en voiture, une modification sur la logique de
service (LS3) (Figure 62 - 2) est souhaitée par les préférences de l’utilisateur : elle
souhaite recevoir ses SMS en vocal. La session actuelle inclut automatiquement le SE3
qui est SMS vocal. Puisque pendant le déplacement d’Alice, le fournisseur de réseaux
mobiles est plus capable d’offrir le service email à travers la 3G (AN2) grâce à sa
couverture plus fine que le WiFi, la communauté de service (4) remplace
automatiquement SE2bis1 avec SE2bis2.
Communauté de Service (email)= {SE2bis1, SE2bis2 }
(4)
Le changement de la composition de service notifie dynamique à VPSN. Le réseau
support (VPCN) s’autogère au niveau du fournisseur des réseaux mobiles pour offrir une
meilleure connectivité. Grâce au « NGN Sessionware », la session des services est
toujours sans couture avec la logique de service (5) :
LS3= SE1+SE2+SE2bis2 +SE3+SE5.
(5)
Quand Alice arrive chez elle, son PAN (6) indique qu’elle a son ordinateur fixe disponible.
Grâce à la connexion ADSL (AN3), le fournisseur de ce type de réseau permet
l’utilisateur d’avoir plus de possibilité au niveau d’un service dédié sur les différentes
plates-formes. Les communautés de services sont donc automatiquement et
dynamiquement construites :
PANMaison = {PDA, Ordinateur fixe}.
(6)
Communauté de Service (email)= {SE2bis1, SE2bis2, SE2bi3}
(7)
Communauté de Service (SMS)= {SE21, SE22,}
L’arrivée à la maison notifie également un changement au niveau de la Logique de
Service, Alice n’a plus besoin du service de SMS
Vocal car elle peut voir les messages
elle-même maintenant. Grâce à son PAN(6), l’ordinateur fixe est choisi car il a une
meilleure qualité d’affichage (SE6), découverte par le DDBS. La modification se fait non
seulement au niveau du terminal mais aussi au niveau du transport et du service car les
anciens composants ne conviennent plus pour la QoS de bout en bout demandé par la
session « User Centric ». Le Binding se fait par le « NGN Sessionware » et nous obtenons
la session actuelle (Figure 62 - 3) :
LS4= SE1+SE22+ SE2bis3+SE6.
(8)
Dans ce scénario, nous nous apercevons que la communauté des équipements est mise
à jour en fonction de la localisation et de l’activité (1)(3)(6). Les communautés de services
(4) (7) s’auto gèrent également pour soutenir leur propre VPXN. La fourniture de service
est toujours garantie d’être délivrée en continue grâce au « NGN Sessionware ».
78 / 80
6. Conclusion
Du point de vue de l’architecture nous pouvons conclure que l’utilisateur aura accès à un
catalogue qui contiendra les services exposables pour qu’il puisse faire sa propre
composition. L’interconnexion de l’ensemble de ses services repose sur la composition de
service (VPSN) et sur l’agrégation de service (session). L’ensemble des concepts UBIS
sont supportés par ce que nous dénommons des services de bases. La Figure 63 montre
le schéma générique de middleware que nous utilisons dans notre étude. Ce schéma
différencie les services de base (en dessous du support d’interconnexion), des services
exposables (applicatifs) (au-dessus du support d’interconnexion).
Figure 63 : Schéma générique d'un middleware
Pour bien comprendre le fonctionnement du middleware UBIS (Figure 64), il faut définir
chacune des trois parties. On commence par le support d’interconnexion, appelé encore
« le courtier (ESIB : Service Elements Interconnection Bus)». C’est le composant
indispensable qui supporte la mise en relation des éléments distribués (VPSN et Session).
Ensuite, il y a les services de base qui sont nécessaires à la définition et la distribution des
composants (service de politique, nommage, services de localisation, sécurité, …). Ces
services fournissent les fonctionnalités UBIS afin de permettre la distribution et la gestion
des composants. Finalement, on a les services applicatifs qui sont exposables proposés
aux utilisateurs UBIS et qui s’appuient sur les services de bases pour offrir un service
global spécifique (une application).
79 / 80
Figure 64 : Architecture du middleware UBIS
UBIS propose cette architecture de service (Figure 64) prenant en compte la
communication et à la mise en relation des composants distribués. Cette structure
d’ensemble est un ensemble de concepts, de règles, de guides et de recettes permettant
de structurer les services, leur contrôle et leur gestion et qui prend en compte au-delà de
l’ouverture, la mobilité, la portabilité et la personnalisation des applications.
Du point de vue de l’utilisateur, l’accès aux services souscrits doit être possible en utilisant
n’importe quel type de terminal et à travers n’importe quel type de réseau et ceci où qu’il
soit localisé et quelque soit le moment de la demande (anytime, anywhere, anyhow).
80 / 80

UBIS SP2 - Lot2.1 Défintion et spécification de l`architecture

Transcription

Documents pareils

Engagement - Service public

Transmetteur d`images sans fil AUDIO-VIDEO

Entrée en 4ème, lectures conseillées

Votre atout sous-traitance

Référence annonce : 1028671

Canon Fax L380s

Etoile Quercynoise - FFCT LOT

Lot n° 1 : Façade ALLIANCE ECOCONSTRUCTION 8, rue Emile

Ingénierie des besoins