SP3 COMPOSANTS DE SERVICES Lot 3.1 Spécifications des composants fonctionnelles de la session UBIS

Transcription

1 Projet ANR-Verso 2008 UBIS «User centric»: ubiquité et Intégration de Services SP3 COMPOSANTS DE SERVICES Lot 3.1 Spécifications des composants fonctionnelles de la session UBIS Auteurs : Participants : Version : 2.0 Gladys Diaz Netzahualcoyotl Ornelas Ken Chen Tuo Song Marouane Raji Philippe Coudé Date : 07/05/ / 48

2 Historique du Document Version Date Modifications /11/2009 Création du document /12/2009 Modification suite à groupe de travail /01/2010 Rédaction 1 ère Partie /01/2010 Rédaction Globale /02/2010 Relecture /02/ ère Relecture partenaires /04/2010 Modification rédaction partie 5 suite aux réunions des 22 et 23 mars /04/ ème Relecture partenaires /05/2010 Relecture Final ABSTRACT: Mots clés : Service, Composant, Composition de service, User Centric, Service Exposable, VPSN, SAO. 2 / 48

3 Table des matières MOTS CLES : INTRODUCTION : OBJECTIFS DU LOT : 3.1 : ETAT DE L ART DES COMPOSANTS DE SERVICES (QUOI?) Service web Web 2.0/ SOA (Service Oriented Architecture) SCA (Service Component Architecture) SaaS (Software as a service) Conclusion CONVERGENCE DE SERVICES Pourquoi tend- on vers la convergence de services? Approche UBIS Proposition de création des communautés Qualité de service Infosphère Approche proposée pour une composition dynamique PROPOSITION FONCTIONNELLE DES COMPOSANTS DE SERVICES Définition d un composant de service Caractéristiques et opérations du composant de service Plans et interfaces Conception d un ES à base d opérations Modèle du composant de service Automate SPECIFICATION FONCTIONNELLE DES COMPOSANTS «EXPOSABLES» DE LA SESSION Contexte Spécification des composants Services de base Localisation Présence Découverte Autres Services Exposables Géolocalisation Sélecteur de zone Voisinage Annuaire RichMédia Authentification / 48

4 Caddy et Espace privée CONCLUSION REFERENCES / 48

5 Table des Illustrations Figure 1: Positionnement des livrables du SP Figure 2 : Exemple d invocation des Web Services... 8 Figure 3 : Acteurs de l architecture de service SOA... 9 Figure 4 : Exemple d un Service web... 9 Figure 5: Pile des standards des Web Services Figure 6 : Services Web: (a) Orchestration (b) Choréographie Figure 7 : Technologies pour la composition dans les Web services standards industriels Figure 8 : Technologies pour la composition dans les Web services standards W3C Figure 9 : Web Figure 10 : Web 3.0 [24] Figure 11 : Les concepts de SOA Figure 12 : Exemple d une architecture orientée services Figure 13 : SOA : annuaire et contrat de services Figure 14 : Les couches dans l architecture SOA Figure 15 : La notion de composant dans SCA Figure 16 : La notion de composé dans SCA Figure 17 : L Architecture SCA et ses concepts Figure 18 : Exemple d implémentation avec le modèle SaaS Figure 19 : Evolutions des technologies Figure 20 : Les quatre niveau de visibilité de l architecture et le modèle <N,L,R> Figure 21 : La notion de VSC pour les VPxN Figure 22: Les Profils dans l Infosphère Figure 23:La composition de services proposée par UBIS Figure 24 : Diagramme du Modèle de Processus Business (BPM) d un ES Figure 25 : Mutualisation des ESs Figure 26 : Le modèle «Black-box» avec les 3 plans Figure 27 : Convergence des Plans et Interfaces Figure 28 : Elément de Service - Modélisation de l opération : Figure 29 : Automate d'un Elément de Service Figure 30 : Etat Activé d un SE Figure 31 : Position du SP 3.1 dans l architecture UBIS Figure 32 : Services Exposables bancaires (&SP1.3) Figure 33 : Services Exposables Télécom (&SP1.3) Figure 34 : Modélisation du SE I/O Figure 35 : Modélisation du SE Opérations Figure 36 : Service Localisation I/O Figure 37 : Service Localisation Exemple d implémentation EJB Figure 38 : Modélisation UML - Service Localisation Figure 39 : Service Présence - I/O Figure 40 : Service Présence Exemple d implémentation EJB Figure 41 : Service Découverte I/O Figure 42 : Service Découverte - Opérations Figure 43 : Service Découverte Exemple d implémentation EJB Figure 44 : Service Géolocalisation I/O Figure 45 : Service Géolocalisation Opérations Figure 46 : Service Sélecteur de zone - I/O Figure 47 : Service Sélecteur de zone - Opérations Figure 48 : Service Voisinage I/O Figure 49 : Service Voisinage - Opérations Figure 50 : Composant Annuaire I/O Figure 51 : Composant RichMédia I/O Figure 52 : Composant RichMédia- opérations Figure 53 : Composant Authentification Figure 54 : Composant Authentification opérations Figure 55 : Description fonctionnelle du service Authentification à base d opérations selon (a) des mécanismes symétriques ou (b) des mécanismes asymétriques / 48

6 1. Introduction : Objectifs du lot : 3.1 : Le Sous-Projet 3.1 vise à fournir une description des composants de services selon le point de vue UBIS. Pour ce faire nous nous concentrerons sur les aspects des usages et besoins tels que définis dans le SP1 et sur l architecture fonctionnelle d UBIS définie dans le SP2.1. Les composants de services Ubis se situant à différents niveaux de l architecture UBIS, nous présenterons la description des composants de services (services exposables, et services de base) à travers les différents livrables du SP 3 (SP3.1, SP 3.2 et SP 3.3). La Figure 1 montre le positionnement des différents livrables concernant le SP3. Le document se focalisera sur la description des composants de services dits exposables tels que définis dans les cas d usage CAsa et SFR. Au niveau architectural, notre travail se situe dans la couche service de l architecture UBIS. Selon la définition donnée par SP1.3, les «services exposables» représentent les services que l utilisateur trouvera dans son catalogue de services. Ces services peuvent être de toute nature multifournisseur (télécom, web, entreprise, etc.) sachant que l architecture UBIS est de type transorganisationnelle aussi bien niveau réseaux que services. Nous présentons dans ce document la modélisation de ces composants de services exposables. La description des composants UBIS afin de permettre la mise en place d une session UBIS, sera complétée par la suite avec le livrable SP3.2 (qui traitera de la gestion dynamique des communautés d intérêt et de la Qualité de service) et le livrable SP3.3 (qui présentera la composition et l agrégation de services en vue de la session). Figure 1: Positionnement des livrables du SP 3 Ce document présente dans un premier temps un état de l art concernant la notion de composant ( 2). Il nous permettra de souligner les nouveaux besoins (mobilité, hétérogénéité, ubiquité, etc.), afin de nous amener vers une nouvelle façon de définir les services ( 3). Pour prendre en considération tous ces nouveaux besoins, nous définissons les propriétés des nouveaux services ( 4), ainsi qu un nouveau modèle pour spécifier et définir les services selon UBIS. Nous reprendrons ensuite un cas d utilisation présenté dans le SP1.3 (le scénario d usages des services bancaires et télécoms) pour modéliser selon les concepts UBIS, certains services exposables présentés dans ces cas d usage. 6 / 48

7 2. Etat de l art des composants de services (Quoi?) Le projet UBIS est basé sur l approche «User-Centric» dans un contexte NGN. Cette approche implique que c est l utilisateur qui décide la façon d accéder à ses services, c est lui qui conditionne le fonctionnement à travers une personnalisation de ses services. L ensemble de ces composants forme la session utilisateur qui est le résultat d une composition personnalisée de services. Pour prendre en considération tous les besoins liés à la mobilité (user, terminal, réseau, et service), à l hétérogénéité (terminal, réseau, service) et à la continuité de la session, il nous faut une nouvelle façon de concevoir les services. Ces services doivent être capables d affronter ce nouveau contexte où on peut s adapter aux besoins et préférences de l utilisateur lors d une session. Cette adaptation pourra être mise en place grâce à des mécanismes de composition de services dynamiques. Une évolution de la notion de composants de services, et de la composition en ellemême, est donc nécessaire pour prendre en considération les aspects impliqués dans le paradigme «User-Centric». Ceci implique une nouvelle manière de concevoir les services avec des nouvelles propriétés (par exemple l ubiquité). Cette évolution nous conduit vers la définition des services plus attractifs permettant de prendre en compte (à travers la composition des composants de services adaptés) le contexte de l utilisateur et ses préférences. La motivation d avoir un ROI 1 maximum et un TTM 2 minimum avec une vision «User- Centric» a dirigé notre recherche sur une nouvelle conception de service et de la composition de services. Plusieurs tendances existent sur le marché actuellement. Ces tendances présentent quelques unes des propriétés à considérer dans les services de demain : Service Web ( 2.1) pour la simplification et la réutilisation de service, Web 2.0 et Web 3.0 ( 2.2) pour une «partageabilité» de contenu et de l application, SOA (Service Oriented Architecture) ( 2.3) pour le couplage lâche, SCA (Service Componant Architecture) ( 2.4) qui insiste sur une séparation forte entre l implémentation des services et leur assemblage et SaaS (Software as a Service) ( 2.5) pour gérer les composants de service ubiquitaires. Ces principales tendances actuelles sont basées sur les concepts proposés par l approche SOA, dont la notion de service est le centre des préoccupations Service web Depuis ces dernières années, l'utilisation de Services Web a connu une popularité grandissante auprès des développeurs Web. Cette tendance est due aux techniques de «mash up» où plusieurs services Web sont combinés «élégamment», en utilisant un langage de programmation au niveau du serveur. Un exemple est donné dans la figure 2. Le service Web est défini par l organisme W3C 3 [1] comme "un système logiciel pour supporter les interactions de machine à machine au dessus d un réseau." 1 Return On Investment 2 Time To Market 3 World Wide Consortium 7 / 48

8 Figure 2 : Exemple d invocation des Web Services Les services web peuvent être définis de plusieurs points de vue : d'un point de vue business : un service web décrit les fonctionnalités exposables par une entreprise sur l'internet, permettant d'utiliser ces services à distance. Par exemple, une agence de voyages qui met à disposition un Web Service pour la réservation de voyages. d'un point de vue technique : les services Web permettent de créer des applications modulaires, faiblement couplées qui s'exécutent à travers l'infrastructure Web et qui peuvent être : décrites, publiées en utilisant un annuaire, invoquées par des applications clientes, et orchestrées avec d'autres services. L'architecture des services web repose sur le modèle SOA (Service-Oriented Architecture). Dans l approche service web tout devient «service». Lorsque l'architecture SOA s'appuie sur des services web, on parle alors de WSOA (pour Web Services Oriented Architecture). Grâce aux services web, les applications peuvent être vues comme un ensemble de services métiers, structurés et correctement décrits, dialoguant selon un standard international plutôt qu'un ensemble d'objets et de méthodes entremêlés. L'architecture SOA fait intervenir trois acteurs ( Figure 3) : le service provider : il fournit des services et les expose aux utilisateurs en les publiant, le service broker : il joue le rôle d'annuaire en ajoutant deux fonctionnalités : la publication et la recherche de services, le service Consumer/requestor : il représente un client. Il interroge le service broker pour trouver un service, puis invoque ce service en se liant au service provider. 8 / 48

9 Figure 3 : Acteurs de l architecture de service SOA Les Services Web sont souvent utilisés comme des APIs Web qui peuvent être accédés à travers un réseau et exécutés dans un système distant hébergeant les services demandés. Le Service broker ( Figure 4) est l interface entre les demandeurs et les fournisseurs de services. Service Web est en fait un premier dénominateur commun pour la création de service. Figure 4 : Exemple d un Service web Deux approches ont forgées la direction des services web (& Figure 5) : Une approche de modèle process business avec sa logique de s inspirer des processus business pour modéliser un service et une activité en général et la décrire sous forme de workflow. Une approche sémantique basant les fonctionnalités sur des mots clefs et guidées par une ontologie de service (un modèle pour conceptualiser les connaissances, les méthodes et les interactions). 9 / 48

10 Figure 5: Pile des standards des Web Services Les services web peuvent être définis à travers quelques caractéristiques de base : Application fournissant des traitements et des données à d autres applications déployées sur le Web, et vues à travers une interface Protocole SOAP au dessus de http Données codées en XML Répertoire de services : UDDI Langage WSDL pour décrire le service 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 [2] [3] [4] : la chorégraphie ou l orchestration ( Figures 6). Figure 6 : Services Web: (a) Orchestration (b) Choréographie Une orchestration comprend un élément central responsable de la composition dans son ensemble. Le processus devient alors la somme de ses sous processus et l entité responsable de la composition, appelée «orchestrateur qui peut aussi être un service Web», gère seule les échanges de messages. Les services Web n ont pas de connaissance (et n ont pas besoin de l avoir) de la composition pour faire partie d un processus métier, seulement le coordinateur de l orchestration a besoin de cette connaissance. 10 / 48

11 Une chorégraphie contrairement à l orchestration, n a pas un coordinateur central. Elle décrit le flux de messages échangé par un service Web lors de son interaction avec d autres services. Il s agit donc d une manière décentralisée de gérer une composition puisque chaque service Web, acteur, est responsable d une partie du workflow. En particulier, la norme WSCI 4 permet de spécifier le comportement du service Web par rapport au reste de la composition [5]. Figure 7 : Technologies pour la composition dans les Web services standards industriels Figure 8 : Technologies pour la composition dans les Web services standards W3C La composition d un processus d'affaire (bussines process) hors la définition du service lui-même s'appelle l «orchestration». Dans le cadre où de multiples processus agissent les uns avec les autres, l orchestration décrit le point de vue d'un processus simple seulement. Contrairement aux orchestrations, les chorégraphies décrivent l'effet entre les processus d'une perspective globale. Tandis que des orchestrations sont bien comprises, actuellement les chorégraphies constituent un champ de recherche ouvert. Basé sur des expériences de l Internet, Service Web est considéré comme une des solutions possibles pour fournir les services demandés par l utilisateur à travers un réseau télécom. Principalement, les Services Web sont exécutés dans un serveur et les fonctions proposées sont du côté réseau. 4 Web Service Choreography Interface 11 / 48

12 Une application du concept «Service Web» est IMS 5 [6]. Il est proposé comme une technologie motrice qui permet la convergence des services de l Internet et du réseau cellulaire. Il doit supporter les services traditionnels de Télécom, ainsi que des services multimédias comme la vidéo conférence. En effet, les Services Web permettent la création de services demandés par l utilisateur grâce à des composants proposés à travers le Web. Mais il a ses limites, par exemple : il est difficile d ajouter ou de modifier, dynamiquement, un composant de service. Le Service broker reste une application client-serveur peu flexible. La question est : est ce suffisant pour les besoins de mobilité et d application du client dans un contexte NGN? 2.2. Web 2.0/3.0 Le Web 2.0 [7] [8] 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éfini 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 ( Figure 9). C est le Web participatif, social [9]. Figure 9 : Web 2.0 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-standards 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. A la différence du web 1.0 dont les contenus étaient fournis par les professionnels de l Internet (fournisseurs d accès, annonceurs, marques, etc.), le web 2.0 se caractérise par la prise de pouvoir des utilisateurs. Grâce à de nouvelles plates-formes de diffusion, de 5 IP Multimedia Subsystem 12 / 48

13 nouveaux outils, et une accessibilité plus grande des technologies web, les utilisateurs produisent eux-mêmes leurs propres contenus et les diffusent sur l Internet [9]. Web 3.0 désigne l adaptation des services web aux supports mobiles convergents, ordinateurs portables, PDAs et téléphones mobiles 3G. 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 plate-forme. Par rapport à Web2.0, Web 3.0 [10] voudrait donner plus de personnalisation et rechercher plus efficacement les données Web. La définition précise d'une application Web 3.0 est encore très débattue. Cependant, il est généralement admis qu'une solution Web 3.0 doit montrer certaines caractéristiques [23]: on ne se réfère plus uniquement à un site Web ((X)HTML). Ce peut être aussi une solution Web SaaS (application: (X)HTML + base de données relationnelles (SQLServer, Oracle, MySQL ) ou XML (la base de données open source Existdb, Oracle g11,...)) ; mobilité, elle doit être indépendante de tout type de support (taille d'écran, sortie imprimante, etc.) ; universalité, elle doit être indépendante de tout système d'exploitation, et de tout matériel (fabricant, marque, logiciel, ou de plugin) ; accessibilité, strictement en conformité avec le W3C, ce qui permet de rendre d'autres logiciels accessibles à l'aide de Microformat et ouverts aux bases de données diverses. Alors que le Web 2.0 se caractérise surtout par sa volonté de lier les utilisateurs et de créer une intelligence collective, le Web 3.0 devrait avoir des objectifs tout autres et adopter un nom, un concept : «le Web sémantique» [24]. Figure 10 : Web 3.0 [24] Le Web 3.0 intègre l approche SOA, basé sur une infrastructure autour des standards SOAP, WSDL, UDDI. Cette approche est suffisante pour mettre en place des composants interopérables et intégrables mais insuffisante pour rendre automatique et efficace plusieurs tâches liées au cycle de vie des services web, par exemple : la composition et aussi la découverte des services requis [25]. Fonctionnellement les applications type web 2.0 et 3.0 restent basées sur une architecture de type client-serveur. Ces approches ne sont pas suffisantes pour faciliter la création de service orienté utilisateur SOA (Service Oriented Architecture) Mettre en place une Architecture Orientée Services consiste, à concevoir et construire un système d information et les applications qui la composent à partir d un ensemble de 13 / 48

14 services logiciels indépendants, mais capables de communiquer les uns avec les autres. La notion de «service», composant élémentaire, est relativement large : consulter un compte en banque en ligne, passer une commande de billet d avion, calcul d un crédit, intégration d un service (météo, jeux, suivi de livraison, ) dans un portail tiers L idée principale de SOA est de mettre en œuvre les services ou les applications sous forme des «composants logiciels». La notion de service est le point central d intérêt de cette approche ( Figure 11). Figure 11 : Les concepts de SOA SOA propose des services 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 [11] ( Figure 12). Figure 12 : Exemple d une architecture orientée services L interaction et la communication d une collection de services permettent 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êmes. 14 / 48

15 Au sein de l'architecture orientée services, on distingue les notions d'annuaire, de bus, de contrat et de service, ce dernier étant le noyau et le point central d'une architecture orientée services ( Figure 13). Le service est l'unité atomique d'une architecture SOA. Une application est un ensemble de services qui dialoguent entre eux par des messages. Le couplage entre services est un couplage lâche et les communications peuvent être synchrones ou asynchrones. Figure 13 : SOA : annuaire et contrat de services La notion de service avec SOA est associée à une fonction encapsulée dans un composant que l'on peut interroger à l'aide d'une requête. Idéalement chaque service doit être indépendant des autres afin de garantir sa réutilisabilité et son interopérabilité. Un service doit offrir un ensemble d'opérations dont les interfaces sont publiées. Il doit être autonome et respecter un ensemble de contrats (ou règles de fonctionnement). SOA c est avant tout une architecture applicative et une méthodologie de mise en œuvre. Cette méthodologie permet de déployer une architecture logiciel d entreprise orientée processus métiers et décomposée en fonction de base appelée «services». L architecture SOA se base sur des couches qui répondent à des fonctions ( Figure 14). Ce n est pas une révolution dans le monde de l informatique mais la généralisation de ce concept permet la construction de bases solides pour les développements futurs des applications de l entreprise. Figure 14 : Les couches dans l architecture SOA 15 / 48

16 2.4. SCA (Service Component Architecture) SCA propose un modèle de programmation pour la construction d applications à base de composants suivant le paradigme SOA [13]. Les travaux de standardisation sont sous la responsabilité du groupe OASIS [14]. SCA est un ensemble de spécifications visant à simplifier la création et la composition de services (indépendamment de leur implémentation). Ce modèle se base notamment sur l idée qu un service de niveau N se construit par assemblage / agrégation / orchestration de services de niveau N-1 ou N (quelque soit la hiérarchisation choisie). Par exemple : Services organisationnels, Services métiers, Services techniques. SCA fournit deux niveaux de modèle : Un modèle d implémentation pour construire des composants qui fournissent et consomment des services ; Un modèle d assemblage pour permettre la construction des applications métier à forte valeur ajoutée en liant entre eux un ensemble de composants. SCA insiste sur une séparation forte entre l implémentation des services et leur assemblage. Il définit un modèle avec deux composants : Le composant Le composé L élément de base est «le composant» qui constitue l unité élémentaire de construction ( Figure 15). Un composant est une instance configurée d implémentation où une implémentation est un code source fournissant des fonctionnalités. Ces fonctionnalités sont exposées en tant que services en vue de leur utilisation par d autre composant. Les services sont décrits au travers d interfaces qui constituent le contrat de service. Ces contrats sont implémentés par le composant. Figure 15 : La notion de composant dans SCA L implémentation peut s appuyer sur des services fournis par d autres composants dont elle dépend. Ces dépendances sont appelées «références». Elles sont associées à des services qui peuvent être soit exposés par d autres composants SCA soit exposé par des systèmes tiers (Web services, connecteurs JCA, etc.). Le deuxième élément c est «le composé» qui est un assemblage de composants, services, références, propriétés et des liens qui existent entre ces éléments ( Figure 16). 16 / 48

17 Figure 16 : La notion de composé dans SCA Un composé est un composant de plus haut niveau que celui qui le compose (Il fournit des services, dépend de références et a des propriétés). Un composé peut donc à son tour être référencé par d autres composants et être utilisé au sein d autres composés. Au plus haut niveau, les composés sont déployés dans des domaines SCA qui regroupent l ensemble des services pour un système fonctionnel. La figure 17 montre l approche proposée par l architecture SCA. Figure 17 : L Architecture SCA et ses concepts SaaS (Software as a service) SaaS ou Software as a Service, c'est un nouveau modèle économique pour délivrer ses logiciels sous forme de services à travers Internet. SaaS renvoie à un modèle de logiciel commercialisé non pas sous la forme d'un produit (en licence définitive), que le client installerait en interne sur ses serveurs, mais en tant qu'application accessible à distance comme un service, par le biais d'internet et du Web. Cette tendance majeure dans l'industrie informatique concerne aussi bien les TPE que les grands comptes. C'est aussi une nouvelle approche technique, d'exposition, de composition et de consommation de ces services. Architecturalement, l application de SaaS [15] [16] est similaire aux autres applications qui suivent le concept de l orienté service. Tout comme l'asp 6 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 6 Application Service Provider 17 / 48

18 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. Le modèle SaaS permet aux consommateurs d'accéder à distance à un logiciel hébergé par une autre entreprise dans un domaine spécifique. Avec ce modèle, le fournisseur offre une solution complète pour un besoin logiciel particulier, ce qui permet au consommateur d'externaliser cette partie du système. Le fournisseur de services gère le logiciel dans le temps et facture le consommateur en fonction de son usage, ce qui signifie que le consommateur n'a plus à gérer ces services logiciels de façon locale. La figure 18 montre un exemple d implémentation en utilisant le modèle SaaS. [26] Figure 18 : Exemple d implémentation avec le modèle SaaS 2.6. Conclusion Les notions présentées dans cette section nous ont permis de conclure sur l évolution des approches informatiques/réseaux qui prennent en compte la notion de composant. La figure 19 montre un bilan sur l évolution des différentes technologies de traitement des notions telles que l objet, le composant, etc. Figure 19 : Evolutions des technologies Historiquement cette évolution se montre comme suit : Au début de ces approches se trouve la notion d objet. La logique de l objet n est pas loin de la notion de service, mais il reste encore des aspects tels que l héritage qui désigne encore un couplage fort entre les objets. 18 / 48

19 Ensuite sont apparus les composants. Les composants ont été crées pour aider au déploiement des objets et pour supporter les objets distribuables avec des éléments de gestion. Ensuite les composants ont été organisés conceptuellement en modules. L idée des modules était de faire une composition le plus indépendant possible des composants avec un raisonnement conceptuel. Actuellement ces notions et leur évolution ont donné naissance à la notion de service. Cette notion permet une jointure des approches informatique et réseaux. La notion de composant est encore l élément de base mais maintenant traitée avec une approche réseaux qui utilise la notion de protocole et qui propose un traitement dirigé par les événements (selon un modèle Event-Driven), avec une spécification du comportement des composants de services en utilisant des automates à état finis. L historique présenté sur ces approches montre également l évolution qui s est produite concernant le couplage entre les traitements et les données. Initialement dans toutes ces approches (objet, composant, module), existait un couplage fort entre les données et l applicatif (leurs transactions et traitements). Les données étaient très dépendantes de l application où elles étaient définies/utilisées. Les services Web actuels montrent une évolution sur ce besoin de séparer données et traitements, mais il reste encore conditionné par le réseau de traitement : Internet. Ainsi les Web services contribuent à la simplification et à la réutilisation de service, mais leur architecture reste encore orientée «client-serveur». Le Web 2.0 et Web 3.0 ont pour objectif la partageabilité de contenu et des applications sous la forme d option de service. SOA offre un couplage lâche mais la décomposition de service ne permet pas l accès au composant de service par plusieurs acteurs (user, le contrôle et le management) car il n est pas mutualisable. SaaS (Software as a Service) propose de gérer les composants de service ubiquitaires mais l architecture a un couplage fort car verticale. Dans les futurs services à concevoir, il faut que les traitements et les données soient indépendants de l application qui les utilise. Ceci nous amène à la conception des modèles informationnels pour le système de gestion qui ont un traitement à part du système de traitements, et dont il faut que les données soient à l extérieur. Il faut donc pouvoir faire évoluer les systèmes de gestion et les traitements indépendamment. Les données et traitements doivent donc être vues séparément de l applicatif. Dans le cadre du projet UBIS, nous travaillons séparément le modèle informationnel et le modèle fonctionnel, en évitant de structurer l information en fonction des applications. Il faut le faire en fonction de la sémantique des données représentant le monde réel. Il faut donc repenser les services, et considérer séparément les différents aspects du système : architecture, fonction, organisation, information et communication. Nous pensons que la notion de «service» elle-même doit être repensée. Elle doit permettre la conception et définition des services avec un modèle qui mettra en place un couplage souple entre leurs interfaces mais en même temps qui facilite l interconnexion et l interopérabilité des différents éléments de services constituant un service final exposable. Nous présentons dans ce document notre point de vue sur la notion de service, en proposant des nouvelles propriétés et modélisation. Dans le cadre du projet UBIS, nous nous sommes intéressés aux traitements des besoins d une session guidée par les préférences de l utilisateur (User-centric session), et donc nous cherchons à définir des composants autonomes, inter-fonctionnels et mutualisables. Nous nous intéressons également à la composition dynamique d éléments de services. Cette dynamicité dans l approche de composition devra permettre et faciliter l adaptation/remplacement des éléments de services qui devront être combinés pour fournir un service global à l utilisateur. La mise en place de cette dynamicité garantira la continuité de la 19 / 48

20 session de l utilisateur malgré les changements de contexte dus aux aspects de mobilité et hétérogénéité. Nous pensons que cette dynamicité doit être garanti par les éléments de services eux-mêmes, et dont l autonomie (et l auto-gestion) devient la propriété nécessaire à garantir. 3. Convergence de services Dans notre société informatisée d aujourd hui, les réseaux et les services offerts par les réseaux de communication prennent une place importante. Les opérateurs et fournisseurs de services télécom sont en constante évolution et concurrence, vis-à-vis les services fournis à leurs utilisateurs. Notre société d information évolue très rapidement, quant aux exigences des nouveaux services, et les conditions d accès aux services (avec la mobilité des clients et l Internet ambiant par exemple) mais aussi, quant aux exigences vis-à-vis des garanties de QoS et de la maitrise des nouvelles technologies. Les marchés télécoms d aujourd hui doivent donc s adapter et suivre toute cette évolution pour pouvoir rester concurrentiels au niveau du marché. Les télécoms cherchent ainsi à satisfaire les utilisateurs, en termes de ROI, d OPEX 7 et de TTM. 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é sur le marché avec un TTM minimum et un ROI le plus rapide. En considérant les services existants et les concurrences entre les différents opérateurs, la transorganisation devient un verrou à lever. Ce dernier introduit la notion de la «mobilité de service» [22]. Les solutions verticales actuellement proposées par les télécoms, en ce qui concerne la fourniture des services (chaque réseau propose ses services), ne sont plus adaptées aux nouvelles évolutions et exigences des services, surtout dans un contexte de mobilité, d ubiquité et de personnalisation des services. Les NGN et NGS cherchent du côté télécoms à faire évoluer la façon dont les services sont fournis aux clients, ils se dirigent vers une architecture de traitement horizontale. Le traitement de ces nouveaux besoins se traduisent par la mise en place des nouvelles architectures de services, et de gestion, qui permettent de garantir la continuité, l omniprésence, la QoS de bout-en-bout et la personnalisation des services. Ainsi actuellement l approche SOA, dont les Services Web constituent une des implémentations très répandues, cherchent la mise en place des nouvelles solutions vis-à-vis des architectures de services. Une des exigences importantes traitées par l approche SOA est celle d une composition flexible et dynamique des services. Les différentes techniques de composition existent de nos jours, elles permettent de mettre en place une composition avec un courtage et une liaison retardée, mais elles ne couvrent pas toutes les exigences vis-à-vis d'une composition dynamique. Par exemple elles ne permettent pas une recomposition dynamique, et sans coupure du service global, lors d un changement côté utilisateur ou côté du service lui-même. Une composition dynamique doit permettre la création de services exposables à l utilisateur, en combinant des éléments de services existants et permettant une recomposition et une adaptation du service suite à des changements du contexte d exécution. Pour implémenter une telle composition nous avons besoin d une nouvelle approche qui facilite par exemple le remplacement des éléments de services par d autres éléments de service équivalents. Les études actuelles menées pour mettre en place une composition dynamique et flexible des services suivent deux approches. La première approche consiste à se focaliser sur les liens entre les éléments de service, en cherchant d améliorer les méthodes de liaisons. La deuxième consiste à se concentrer sur l élément de service lui-même, en cherchant à le définir 7 Operating Expenses 20 / 48

21 à travers une vision différente de modélisation et de description améliorées. Nous allons focaliser notre étude sur ce deuxième point de vue. Les services du futur seront constitués d un enchaînement de services de base avec une logique de service personnalisée. Mais cette logique de service ne peut se faire que si nous avons des services de base composables. Il est donc important d avoir une bonne approche du service. Un service n est ni une application, ni une transaction et encore moins un système. L ISO [18] le définit comme «une prestation composable qui doit être source de valeur pour le consommateur et le fournisseur». Or pour faire cette composition dynamique, pour assurer toutes sortes de personnalisation, pour suivre la mobilité de l utilisateur, nous ne pouvons plus nous satisfaire d une architecture de service «client / serveur» avec des services à options. Il nous faut penser les services autrement. Avoir une architecture permettant à l utilisateur de faire sa propre composition de service, avec des changements dynamiques en fonction des propositions qui lui sont faites [22]. Après avoir expliqué le pourquoi de la convergence de services ( 3.1), nous allons présenter dans les paragraphes suivants notre approche pour une convergence des services ( 3.2). La gestion doit être faite de façon à garantir la fourniture du service de bout-en-bout, ce qui implique une composition dynamique aux différents niveaux de notre architecture ( 3.3). Nous allons nous intéresser par la suite au niveau service, et au comment garantir une QoS de bout-en-bout ( 3.4). Tous ces aspects de gestion dynamique devront permettre la mise en place d une session UBIS qui s appuie sur une base de connaissances ( 3.5), la composition et l agrégation des composants de services ( 3.6) Pourquoi tend t- on vers la convergence de services? Les composants existants dans les architectures de services actuelles ont été désignés pour un usage unique, et sans prendre en compte que ses services devront être capables de participer à des services globaux différents et à n importe quel moment. Une redéfinition de la notion de «service» est donc nécessaire pour prendre en considération des propriétés telles que l autonomie, la réutilisabilité, la mutualisation. L idée étant que ses nouveaux services puissent être flexibles vis-à-vis leur composition. UBIS cherche à supporter la Convergence du Réseau (NGN) avec tous ses scenarios et à lever tous les défis de Mobilité, Hétérogénéité et User-Centric, mais aussi garantir la Convergence de Service en introduisant une composition dynamique à couplage lâche de service, menant à ce qu on appelle le NGS (Nouvelle Génération de Services). Notre approche est User-Centric, cela veut dire que les services offerts à l utilisateur et supportés par notre architecture devront permettre une composition dynamique prenant en compte les préférences de l utilisateur. Pour la gestion des services on cherchera donc à gérer les différents aspects concernés par cette approche : la mobilité, l hétérogénéité, la continuité de service et la QoS Approche UBIS La mise en œuvre d une solution architecturale de services centrés sur l utilisateur comme expliqué dans le SP2.1 - architecture UBIS- nécessite une prise en compte de tous les niveaux de visibilité. Les niveaux de visibilité équipements, réseaux, services et utilisateurs y ont été établis. En appliquant le modèle <N, L, R> [20] (qui dit qu un réseau est un ensemble de nœuds et de liens de même nature) aux quatre niveaux de visibilités, nous sommes amenés à une modélisation permettant de représenter de manière simple et générique tous les éléments 8 Quality of Service 21 / 48

22 d un réseau de télécommunications. Ainsi, selon cette représentation, chaque visibilité constitue un réseau de nœuds et de liens de même nature sur un niveau horizontal comme l illustre la figure 20. Figure 20 : Les quatre niveau de visibilité de l architecture et le modèle <N,L,R> La mise en place des services avec UBIS suit une approche horizontale mais aussi verticale. L approche horizontale permet d organiser les ES (Eléments de Service) à chaque niveau de traitement de l architecture. Ces ESs forment ce que l on appelle les VPxNs (x = E: Equipement, R: Réseaux, S: Service et U: User) qui à chaque niveau seront choisis/gérés de façon dynamique et finalement participeront à la fourniture d un service global. L approche verticale consiste à mettre en place la session User-centric dynamique et à établir les liens entre les ESs choisis dans chaque niveau de visibilité. Les quatre niveaux de visibilité : Niveau équipements : Il est constitué de nœuds physiques (équipements hardware : PC, routeurs, serveurs, etc.) reliés entre eux par des média de connexion physiques (fibre, coaxial, onde, etc.) pour former le VPEN (Virtual Private Equipement Networks). Niveau réseaux : Il est constitué de nœuds logiques protocolaires de transports (partie fonctionnelle de routeurs et des switches) et qui sont reliés entre eux par des canaux logiques pour le transport (connexion TCP, lien UDP, ) pour former le VPCN (Virtual Private Core Network) qui constitue un réseau logique de transport. Niveau services : Il est constitué de composant de services se trouvant sur une plate-forme dédiée ou sur le terminal utilisateur. Ces éléments de services sont mis en relation entre eux par des liens logique de services dont les regroupements constituent les applications. Les entités de ce niveau rendent un service à valeur ajoutée, c'est-à-dire un service applicatif au delà du service de transport basic. Niveau utilisateurs : Il est constitué des utilisateurs, demandeurs ou fournisseurs reliés entre eux par des relations d intérêt business. Ils forment des réseaux de personnes pour le partage d informations ou de services Proposition de création des communautés Pour mettre en place une gestion autonome et une composition dynamique nos ESs doivent être autonomes et indépendants vis-à-vis de leur interfonctionnement. Fonctionnellement, un système auto-gérable doit assurer quatre automatismes à la fois : 22 / 48

23 Auto-réparation : capacité du système à détecter, diagnostiquer, et réparer automatiquement les anomalies. Auto-configuration : capacité du système à s adapter dynamiquement aux changements de l environnement. Auto-optimisation : ajuster automatiquement le système pour maximiser ses performances. Auto-protection : anticiper, identifier, et protéger le système de toute attaque. Fondé sur les quatre niveaux de visibilité et le modèle organisationnel proposé précédemment, pour anticiper tout impact de mobilité, nous créons des communautés virtuelles (CV) regroupant les composants fonctionnellement et QoS équivalents. Afin de mettre en œuvre ces automatismes d auto-gestion, nous introduisons la gestion des communautés dont l intérêt commun est la continuité de service (Nous trouverons plus de détails sur cette notion de gestion des communautés dans le prochain délivrable, D3.2). Ainsi le remplacement des composants n assurant plus leurs contrats se fait automatiquement et dynamiquement. Nous avons relié chacune des mobilités à un niveau de notre architecture (Utilisateur, Service, Réseau et Equipement), en leur associant une communauté virtuelle autogérée. Nous rappelons que les VPxN (x=equipement, Réseau, Service ou Utilisateur) sont préconisés par notre modélisation pour identifier les composants activables (cette notion sera expliquée dans la section suivante) pouvant coopérant pour fournir le service. Donc chaque niveau gèrera dynamiquement son réseau de composants coopérant en fonction des mobilités. Ainsi tout changement intervenant lors des différentes mobilités au cours de la session «User-Centric» sera pris en compte. Figure 21 : La notion de VSC pour les VPxN L autogestion des services est faite en temps réel sur la base de sa QoS. Pour atteindre cette autogestion l introduction d un gestionnaire de QoS dans chaque élément de service est nécessaire. 23 / 48

24 3.4. Qualité de service La QoS est la caractérisation d un service représentant sa partie non-fonctionnelle, c'està-dire elle représente son comportement ou encore tous les autres aspects non liés directement aux fonctions qu il doit fournir. La QoS en générale est définie selon quatre critères [22] : - Disponibilité: aptitude d'une entité à être présente et prête à remplir sa fonction à un instant donné, selon les exigences et conditions contractuelles. Elle peut être vue comme le taux de réussite suite à des sollicitations pour l accès à l entité. - Fiabilité: aptitude d'une entité à accomplir sa fonction sans détérioration de l'information traitée, en respectant les exigences et les conditions contractuelles. - Délai: temps mis par une entité pour accomplir une action, tout en respectant les conditions contractuelles. - Capacité: aptitude d une entité à avoir les moyens nécessaires pour réaliser les tâches requises selon les exigences et les conditions contractuelles. Ces quatre critères sont applicables à chaque service offert au niveau service de l architecture Ubis, mais aussi elles seront appliquées aux réseaux et aux équipements gérés chacun à leur niveau. La fonction principale d un SE est de fournir un service à l utilisateur. Ce service est une transaction réalisée entre un fournisseur et l utilisateur. La qualité de cette transaction sera exprimée par un contrat de QoS entre le fournisseur du service et l utilisateur du service. La gestion du VPxN doit être dynamique pour répondre aux besoins de mobilité et personnalisation de l utilisateur. Pour intégrer un ES dans sa composition, un utilisateur recherche l ES qui offre le service dont il a besoin avec la QoS qu il demande et établit avec cet ES le contrat de QoS. Une fois établi, les deux parties doivent surveiller de façon continue l exécution de ce contrat. Des points de mesure doivent être définis pour chaque composant pour pouvoir mesurer sa QoS et surveiller le non dépassement des valeurs seuils accordées. Pour ceci, la gestion doit être réalisée à tout moment pendant la phase d exploitation du service en ayant une interaction en temps réel avec le contrôle et l usage du service. Cette interaction permettra une réactivité lors d un évènement comme la dégradation de la qualité d un ou plusieurs ESs qui font partie du service global. La gestion de nos services doit donc être une «gestion Orientée événement» pour pouvoir faire face à ce contexte multidimensionnel. La gestion du service global de l utilisateur se fait à plusieurs niveaux. L autogestion des éléments de services est nécessaire pour gérer son fonctionnement, tandis que le choix et le changement des ES dans un VPxN lors d une dégradation de QoS sera prise en charge par la VSC à laquelle appartient l ES. Ceci permettra d avoir une gestion de la session de l utilisateur qui est transversale aux quatre couches du modèle. Nous proposons également de travailler avec un «User profil» ( 3.5) qui puisse être partagé par tous les ESs. Ce profil partagé permettra de prendre en considération les préférences mais aussi le contexte de l utilisateur Infosphère Pour fournir le service qui répond aux besoins de l utilisateur et s adapte à son contexte il est nécessaire d avoir une vision globale de tout son environnement. La connaissance des 24 / 48

25 préférences de l utilisateur ainsi que le comportement des différentes ressources (équipements, services, réseaux) de son système permet d avoir la bonne décision qui correspond aux exigences de l utilisateur. En effet, pour un utilisateur mobile voulant accéder à ses services à tout moment et en tout lieu on doit lui garantir une continuité de session avec une adaptation de son service selon les différents changements. Ces changements regroupent le changement de son réseau d accès, le changement du terminal utilisé, le changement du contexte utilisateur (localisation, activité, etc.) ainsi que le changement du comportement des services (disponibilité, dégradation de la qualité de service, etc.). Ainsi pour établir et maintenir un système d information pour l utilisateur dans un environnement caractérisé par l hétérogénéité et la mobilité, il faut considérer un modèle d information décisionnel (une base de connaissance) et définir les différentes actions à prendre en compte lorsqu un événement se produit (changement de la qualité de service d un composant de service, changement de contexte et préférences utilisateurs, etc.). Ceci garantit d avoir une représentation du monde réel de l utilisateur et de prendre une décision correcte et transparente pour l utilisateur. Nous avons besoin de représenter l image des composants en temps réel dans un SI (Système d Information) pour gérer le contexte et préférences d utilisateur lors la mise en place et pour la gestion de la continuité de sa session. Pour mettre en place nos solutions de gestion dynamique de bout-en-bout, nous devons définir la dimension Informationnelle. Pour ce faire, on propose ce que l on appelle, l Infosphère. L infosphère est une base de connaissances (collecte d information) inférante qui nous permet de compter avec l information adéquate au bon moment et au bon endroit afin de prendre des décisions. La structure informationnelle est composée de différents profils ( Figure 22): 1. le «Resource Profile» : c est le profil de base pour représenter toutes les ressources. Il est indépendant de l environnement d'exécution et est généré par le fournisseur de la ressource. Il décrit les comportements d'une ressource. Pour fournir une représentation homogène du comportement de toutes les ressources, nous croyons que le dénominateur commun le plus approprié est la QoS. Ainsi Le comportement des ressources (services, réseaux et terminaux) est décrit à travers leurs possibilités de QoS dénommées dans ce profil QoS Capabilities. Les valeurs des quatre critères de QoS sont celles de la conception, elles représentent le maximum qu une ressource peut fournir. 2. Le «Usage Profile» qui permet de tenir compte du contexte d utilisation de la ressource. Pour le comportement, nous aurons la QoS demandée et la QoS offerte, qui décrivent l ensemble des renseignements nécessaires pour déterminer comment une ressource peut être déployée et utilisée. Le Profil d'usage de Ressource est rattaché à l'environnement d'exécution d'une ressource. 3. Le «Active Profile» est l'image informationnelle (plan de gestion) des ressources utilisables avec leurs états en temps réel. Dans notre système, chaque ressource agit en tant que machine à état fini. Nous définissons quatre états distincts pour représenter le cycle de vie entier d'une ressource. Les quatre états possibles pour un composant sont : non disponible, disponible, activable et activé ( 4.3.1). Le profil actif contient les ressources qui se trouvent dans l'état "Activable" ou "activé". 4. Le «User Profile» fournit une interface commune par laquelle les utilisateurs peuvent, d'une part, indiquer leurs renseignements généraux (UserID, nom de famille, etc.); d'autre part, spécifier leurs préférences concernant les terminaux, les réseaux et les services. Et cela pour toutes leurs localisations et activités potentielles. 25 / 48