SP2 Architecture UBIS Lot 2.1 Définition et spécification de l architecture

Transcription

1 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/ / 80

2 Historique du Document Version Date Modifications V0 9/2009 N. SIMONI V1 11/2009 N. Simoni V2 1/2010 N. SIMONI 2 / 80

3 Table des matières 1. INTRODUCTION Contexte NGN Les éléments d évolution Evolution du contexte Evolution des Télécoms Evolution des architectures Evolution de la conception Evolution de la convergence LE QUOI La nouvelle vision : Définition d une architecture L ingénierie des architectures Les architectures de service : analyse de l existant Les architectures Telco Les architectures Web Les architectures IT : SOA LE POURQUOI : Les défis La continuité de service LE COMMENT : LA NATURE DES REPONSES UBIS Architecture de service UBIS La session de bout en bout UBIS DE L ARCHITECTURE AUX BLOCS FONCTIONNELS Topologie fonctionnelle «Serviceware» et le VPSN Gestion des mobilités Dysfonctionnements de la QoS du composant Des acteurs Concept de communauté d intérêt Autogestion de communautés Sessionware : Continuité de service intégrée «Seamless Userware» Synthèse CONCLUSION / 80

4 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 Figure 6 : L architecture de la norme de Figure 7 : PS Handover : Phase de Préparation Figure 8: Mobilité de l utilisateur Figure 9: mobilité de l utilisateur supporté par SIP Figure 10: mobilité de service Figure 11 : Définition de sessions dans TINA Figure 12 : Session service Figure 13: System Centric Figure 14: Application Centric Figure 15: Network Centric Figure 16: User Centric Figure 17: Evolution des Télécoms Figure 18: Evolution des architectures Figure 19: Evolution de la conception Figure 20: Evolution des convergences Figure 21: Le quoi : Contexte et Périmètre Figure 22: Nouvelle Vision Figure 23: Modèle générique au niveau d un nœud de l architecture Figure 24 : Architecture fonctionnelle du réseau intelligent Figure 25 : Modèle organisationnel du Parlay/OSA Figure 26 : Architecture du Parlay/OSA Figure 27: Le framework Parlay Figure 28 : Le modèle métier de l'abonnement Parlay Figure 29 : Architecture Parlay X Figure 30: Architecture OSE Figure 31: Architecture IMS SCIM Figure 32 : Cadre architectural des services Web Figure 33 : Structure d'ensemble SOA des services Web Figure 34 : Web Figure 35 : exemple de la plate-forme de SaaS Figure 36 : Modèle SOA Figure 37 : composition de service exemple Figure 38 : composition de service exemple Figure 39 : Architecture de SOA Figure 40 : architecture de la Plate-forme Fiorano SOA Figure 41 : Modèle vertical des architectures de services Figure 42 : Le Pourquoi : la continuité de service Figure 43: La plateforme NGN Middleware proposée Figure 44 : Sessions Multiples vs. Session Unique Figure 45:Concept de la session «User Centric» Figure 46 : Topologie fonctionnelle Figure 47: Mutualisation d un ES pour différente Composition de Service Figure 48: Scénario de la mutualisation d un ES et Composition de Service Figure 49: Serviceware Figure 50: les cas d utilisation de la gestion de mobilité Figure 51: Création de communauté Figure 52: Exemple de la gestion de la communauté des utilisateurs Figure 53: Gestion de la communauté des utilisateurs Figure 54: Exemple de la gestion de la communauté des équipements Figure 55: Exemple de la gestion de la communauté des équipements Figure 56: Gestion de la communauté des équipements Figure 57: Exemple de la gestion de la communauté des services Figure 58: Gestion de la communauté de services Figure 59 : «NGN Sessionware» Figure 60 : «Seamless Userware» Figure 61 : Carte fonctionnelle Figure 62: Scénario final Figure 63 : Schéma générique d'un middleware Figure 64 : Architecture du middleware UBIS / 80

5 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) 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

6 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. Mobilité de terminal Figure 2: Les mobilités 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

7 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

8 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' (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

9 Dans l environnement hétérogène, nous avons étudié la technologie de l UMA (Unlicensed Access mobile) et la norme de IEEE 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 (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

10 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 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 / 80

11 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

12 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

13 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 adresses logiques de et 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

14 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

15 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

16 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 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

17 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 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

18 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 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

19 1.2.3 Evolution des architectures Figure 17: Evolution des Télécoms 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

20 Figure 18: Evolution des architectures 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) 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

21 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 . 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

22 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

23 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) 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

24 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 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

25 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

26 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 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 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 ( ), de Parlay/OSA ( ), de Parlay X ( ), d OMA ( ) et la dernière en date IMS ( ) 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

27 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

28 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

29 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

30 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

31 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

32 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

33 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

34 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 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

35 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 Description Utilisation Parlay/OSA Un ensemble de riches APIs - Adéquate pour être utilisées par télécom, utilisées dans les développeurs professionnels de différents environnements logiciels. (Corba (C, C++), Java, ) - Adéquate pour développer une application prépayée Parlay X Un ensemble de haut niveau APIs télécom, simples à être utilisées dans des environnements services. Il y a 17 interfaces Web services (APIs Web services) Web - 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

36 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

37 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 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

38 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

39 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 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

40 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 Voic (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 / 80

41 Parlay/OSA SCIM Basée SIP - ++ Définition modulaire de services + + Adaptable pour IMS + ++ Sécurité + + Binding dynamique des services ++ A faire Indépendance du réseau ++ -(Spécifique à IMS) Communauté des développeurs IT SIP et Télécom Condition d invocation des services - ++ 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» 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 ( ) et de ses évolutions ( ). Puis on abordera le SaaS ( ) qui nous conduit vers une approche«tout service» 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

42 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

43 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 o celle-ci, le catalogue UDDI permet la réutilisation de logiciels en interne. "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

44 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

45 Figure 33 : Structure d'ensemble SOA des services Web 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

46 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

47 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 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

48 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 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

49 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

50 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

51 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

52 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

53 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 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

54 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 s 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 , 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é 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

55 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

56 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 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

57 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

58 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