Automates des composants de services

Dans cette sous-section, nous représentons sous forme d'automate chacun de nos ser- vices de gestion de mobilité : le VSCU Attachment (voir Figure 11.5), le VSCU Creation (voir Figure 11.6), l'Internal VSCU Maintenance (voir Figure 11.7), l'External VSCU Maintenance (voir Figure 11.8), le SHD (voir Figure 11.9), l'Intra-SP SHS (voir Figure 11.10), l'Inter-SP SHS (voir Figure 11.11) et le VPSN Maintenance (voir Figure 11.12). Chacun de nos services de gestion et de nos services exposables agit sur trois plans : le plan d'usage, le plan de gestion et le plan de contrôle. Le plan d'usage regroupe les fonctions principales réalisées par le composant pour rendre son service. Le plan

VSCU Attachement! Plan d’usage! Reçoit l’évènement Service Deployment Déclenche Timer 1! "#$%&! Compare (F,QoS) Service/Inner VSC-U&Ls Compare (F,QoS) Service/ VSCU&Ps Compare (F,QoS) Service/ VSCU&Ps '! (! '! (! (! Envoie l’évènement Attach Inner

VSC-U&L Service à l’Infoware!

Arrête Timer 1! Arrête Timer 1!

Envoie l’évènement Create

VSC-U&L au VSCU Creation!

Envoie l’évènement Attach

VSC-U&P Service à l’Infoware!

Récupère la Fonctionnalité et la QoS du Service, et de toutes les Inner VSC-U&Ls et VSC-U&Ps!

Envoie l’évènement Create

VSC-U&P à l’Infoware!

Envoie l’évènement Create

VSC-U&L au VSCU Creation!

Fig. 11.5: Automate du VSCU Attachment.

de contrôle inclut les procédures de signalisation relatives à l'activation/désactivation du composant, provisionnement du composant et exécution ou interruption de son fonctionnement. Le plan de gestion regroupe les fonctions d'autogestion eectuées par l'agent de QoS qui est associé au composant de service. Parmi ces fonctions de gestion, il y a la vérication de la QoS courante, les échanges des IN-Contracts et OUT-Contracts qui se produisent entre les composants de services appartenant à une même commu- nauté pour la gestion du VPSN au bout d'un OUT-Contract et pour la gestion de cette communauté au bout de trois OUT-Contracts consécutifs.

Dans les automates de nos services de gestion, nous nous focalisons seulement sur le plan d'usage ; les autres plans ne rentrent pas dans le cadre de cette thèse. Comme nous le montrons dans ces diérents automates, le plan d'usage commence par un déclenchement d'un Timer 1. Ce dernier représente le temps nécessaire pour chaque service pour nir le traitement de chaque requête reçue. Si ce Timer 1 expire, l'agent de QoS de ce service intervient au niveau du plan de gestion an d'envoyer un OUT- Contract qui déclenche le processus de maintenance du VPSN. De plus, un Timer 2 apparaît aussi dans les plans d'usage des services VSCU Creation et External VSCU Maintenance. Ce Timer 2 est déclenché lorsque ces services font appel au service de découverte DBS. S'il expire, les agents de QoS associés aux services VSCU Creation et VSCU Maintenance doivent intervenir an de trouver un autre service DBS qui peut répondre aux requêtes, sûrement avant l'expiration du Timer 1.

VSCU Creation Plan d’usage Reçoit l’évènement Create VSC-U&L Déclenche Timer 1
 n < m ? m : nbr. minimal de

services dans une VSC-U&L i = 2 ?   Arrête Timer 1 Envoie Req. au DBS Reçoit la Réponse de DBS n < M ? n : nbr. des services découverts M : nbr. maximale de

services dans une VSC-U&L Choisit arbitrairement (M-1) Services  i = i+1   RS= 2 * RS  i = 0 RS= RS (initial)

Envoie l’évènement Deploy

Services ((m-n)-1) à l’Events Manager

Envoie l’évènement Inner

VSC-U&L Creation à l’Infoware

Déclenche Timer 2 Arrête Timer 2 Récupère la Fonctionnalité, la QoS et la Localisation Géographique du Service Sélectionne tous les n Services

Fig. 11.6: Automate du VSCU Creation.

Plan d’usage! Reçoit l’évènement Internal VSCU Degradation

Déclenche Timer 1!

"#$%&!

'!

Envoie l’évènement Delete Inner VSC-U&L à l’Infoware! Envoie l’évènement Remove Inner

VSC-U&L Service à l’Infoware!

(! _{n : nbr. de services} n = 0 ?

de Backup Récupère l’ID de la VSC-U&P et de l’Inner VSC-U&L, ainsi que le nombre ‘n’ de services de Backup de cette Inner VSC-U&L !

Envoie l’évènement Remove VSC-U&P Service à l’Infoware! Internal VSCU Maintenance!

Arrête Timer 1! Envoie l’évènement Update Service QoS à l’Infoware!

External VSCU Maintenance

Plan d’usage

Reçoit l’évènement External VSCU Degradation

Déclenche Timer 1
 i = 2 ? Arrête Timer 1 Reçoit la Réponse de DBS   RS= 2 * RS  i = 0 RS= RS (initial)

Envoie l’évènement Deploy Services (1) à l’Events Manager Envoie l’évènement Add Inner

VSC-U&L Service à l’Infoware

 n = 0 ? n : nbr. des services découverts i = i+1 Choisit arbitrairement Un service Arrête Timer 1 Récupère l’ID de l’Inner VSC-U&L

Envoie Req. au DBS

Déclenche Timer 2 Envoie l’évènement Remove Inner VSC-U&L Service à l’Infoware Récupère la Fonctionnalité, la QoS et la Localisation Géographique du Service

Arrête Timer 2

Fig. 11.8: Automate de l'External VSCU Maintenance.

SHD! Plan d’usage! Reçoit Spatial Mobility Notification Déclenche Timer 1! "#$%&! '! Envoie l’évènement Semantic Handover Initiation à l’Intra-SP SHS! (! (L,l) ! CZi ? i=i+1! Récupère les IDs et les Zones de Couverture de tous les Controlled User VPSN’s Services.

(N : nbr. de ces services)!

Ajoute SEi à la liste des

Intiated-SH Services ! i = N+1 ? (! '! i = 0 Nbr. des Initiated- SH Services = 0 ? '! Arrête Timer 1! (! Fig. 11.9: Automate du SHD.

Intra-SP SHS Plan d’usage Déclenche Timer 1
    Envoie l’évènement Intra-SP Semantic Handover Decision au VPSN Maintenance  (L,l) CZi,j ? j=j+1

Ajoute SEij à la liste des Counterpart Services de cet “i” Initiated-SH Service i = N’+1 ?   i = 0     j = Mi+1 ? j = 0 Nbr. des Counterpart Services = 0 ?  i=i+1 

Ajoute le “i” Initiated-SH Service à la liste des Inter-SP Possible-Handover Services Choisit arbitrairement

un Counterpart Service

Ajoute le service choisi à la liste des Intra-SP Handover Counterpart Services

Ajoute le “i” Initiated-SH Service à la liste des Intra-SP Handover-Enabled Services Envoie l’évènement No Intra-SP Semantic Handover Notification à l’Inter-SP SHS Reçoit l’événement

Semantic Handover Initiation

Récupère pour chaque Initiated-SH Service, les IDs et les Zones de Couvertures de tous ses Intra-SP Ubiquitous Services. (N’ : nbr. des Initiated-SH Services) (Mi: nbr. des Intra-SP Ubiquitous Services pour chaque “i” Initiated-SH Service)

Nbr. des Intra-SP Handover Counterpart Services

= 0 ?

Arrête Timer 1

Fig. 11.10: Automate de l'Intra-SP SHS.

Inter-SP SHS Plan d’usage Déclenche Timer 1
  Envoie l’évènement Inter-SP Semantic Handover Decision au VPSN Maintenance  (L,l) CZi,j ? j=j+1

Ajoute SEij à la liste des Counterpart Services de cet “i” Inter-SP Possible Handover Service i = N’’+1 ?   i = 0  Arrête Timer 1    j = Mi+1 ? j = 0 Nbr. des Counterpart Services = 0 ?  i=i+1  Choisit arbitrairement un Counterpart Service Ajoute le service choisi à la liste des Inter-SP Handover Counterpart Services

Ajoute le “i” Inter-SP Possible Handover Service à la liste des Inter-SP Handover-Enabled Services

Reçoit l’événement No Intra-SP

Semantic Handover Notification

Récupère pour chaque Inter-SP Possible-Handover Service, , les IDs et les Zones de Couvertures de tous ses Inter-SP Ubiquitous Services. (N’’ : nbr. des Inter-SP Possible-Handover Services) (Mi: nbr. des Inter-SP Ubiquitous Services pour chaque “i” Inter-SP Possible-Handover Service)

Nbr. des Inter-SP Handover Counterpart Services

= 0 ?

VPSN Maintenance!

Plan d’usage!

Reçoit l’évènement Intra-SP

Semantic Handover Decision

Déclenche Timer 1!

"#$%&!

Reçoit l’évènement Inter-SP

Semantic Handover Decision

Récupère les Adresses Logiques de tous les Intra-SP Handover Counterpart Services et Inter-SP Handover Counterpart Services!

Envoie l’évènement

Update VPSN à l’Infoware!

Arrête Timer 1!

Fig. 11.12: Automate du VPSN Maintenance.

Pour conclure, ces services de gestion de mobilité, qui sont représentés dans ces automates, sont déployés sous forme d'EJBs de base dans le démonstrateur. De plus, les services exposables qui sont utilisés dans le scénario applicatif seront eux aussi déployés dans le démonstrateur sous forme d'EJBs applicatifs. La Figure 11.13 représente les deux conteneurs qui contiennent les services exposables et les services de gestion de mobilité. Ce démonstrateur permettra ainsi de mettre en ÷uvre le scénario applicatif et de valider nos propositions.

Conteneur EJB (SEs de Gestion) Conteneur EJB (SEs Exposables)

VSCU Attachment SHD VSCU Creation External VSCU Maintenance Internal VSCU Maintenance Intra-SP SHS Inter-SP SHS VPSN Maintenance Home Announcement (STG) Voice (SFR) Contact (STG) Gallery (Flickr) Map (Mappy) Video (SFR) Video (Orange) Google Maps (Google)

Cette thèse avait pour objectif de concevoir une architecture convergente pour la per- sonnalisation et la continuité de services, dans un contexte NGN/NGS mobile et user- centric. Dans ce dernier chapitre, nous concluons en synthétisant l'ensemble de nos contributions (voir Section 12.1), et ensuite, nous formulons nos perspectives (voir Sec- tion 12.2).

12.1 Conclusions

Avec l'émergence du contexte NGN/NGS et de l'approche user-centric mobile, de nou- veaux besoins régissent la relation entre les fournisseurs de services et les utilisateurs. D'après notre analyse, nous avons identié les dés suivants : la personnalisation de services selon les besoins et les préférences de l'utilisateur, la convergence des services appartenant à diérents domaines (Telco, Web et IT), l'intégration verticale entre les couches NGS et NGN tout en tenant compte des dés d'hétérogénéité et de mobilité qui régissent la convergence réseau, et enn, la maintenance d'une session de services unique et continue, qui tient compte des préférences fonctionnelles et non-fonctionnelles (QoS demandée) de l'utilisateur, ainsi que de son contexte ambiant. An de lever ces diérents dés, nous avons eectué une réingénierie au niveau du modèle de services et au niveau de l'architecture qui les structure. Nous avons proposé, aux niveaux ar- chitectural et fonctionnel, plusieurs solutions innovantes qui font partie d'un nouveau écosystème de services.

Nous avons commencé par trouver des solutions pour la convergence et la person- nalisation de services, tout en tenant compte des problèmes de exibilité des architec- tures verticales en silos et des problèmes de couplage fort des approches distribuées orientées objet. Pour ce faire, nous avons proposé un nouveau modèle architectural qui suit une approche évènementielle, orientée service, horizontale, distribuée et trans- organisationnelle. En eet, l'approche SOA améliorée s'appuie sur un nouveau modèle de services, qui consiste à avoir des composants de services qui sont non seulement réutilisables, interopérables et autonomes, mais aussi mutualisables, Stateless, autogé- rés à l'aide d'un agent de QoS et interconnectés par des liens génériques à couplages

lâches. De plus, ce modèle s'applique sur des éléments de services appartenant à dié- rents domaines (Telco, Web et IT). Par conséquent, grâce à ce modèle architectural et à ce modèle de services, nous avons permis à tout utilisateur de composer d'une manière personnalisée et horizontale sa propre session de services, tout en faisant converger des services multi-domaines et trans-organisationnels. En outre, suite à notre approche EDA et grâce aux liens lâches qui relient les diérents composants, la session de services créée est adaptée d'une manière dynamique et transparente à toute modication dans les préférences de l'utilisateur, à tout changement dans son contexte ambiant et à toute dégradation au niveau du fonctionnement ou de la QoS d'un des éléments de services demandés.

An de supporter cette nouvelle vision de services (NGS) et an de garantir la cohabitation avec le contexte NGN sous-jacent, nous avons proposé une architecture de services, nommée NGN/NGS Middleware, qui introduit un ensemble de concept et de services structurer en trois partie : les services exposables, le SEIB et les services de base. En eet, les services exposables sont ceux exposés dans les catalogues des four- nisseurs. Le SEIB est un bus d'interconnexion qui ajoute aux fonctionnalités de base d'un ESB, une nouvelle fonctionnalité d'interconnexion virtuelle. Cette dernière est soit horizontale, d'où la notion du VPSN, soit verticale, d'où la notion de l'agrégation de services. Le VPSN supporte la personnalisation de services en pré-provisionnant les éléments de services qui répondent aux préférences d'un utilisateur donné. L'agrégation de services supporte la cohabitation entre la couche service et les couches NGN sous- jacents en pré-provisionnant de bout-en-bout toutes les ressources (services, réseaux et équipements) qui vérient les préférences d'un utilisateur donné. La dernière partie de notre NGN/NGS Middleware est celle des services de base. Ces derniers permettent d'une part de composer la logique de services demandée par l'utilisateur et d'autre part de rendre transparent le réseau NGN sous-jacent en tenant compte des dés d'hétéro- généité et de mobilité qui le régissent. Pour la gestion de l'hétérogénéité, nous avons introduit un nouveau modèle de QoS, à quatre critères (Disponibilité, Fiabilité, Ca- pacité et Délai), qui s'applique sur toutes les ressources hétérogènes de bout-en-bout an de les rendre homogènes. Pour la gestion de la mobilité, nous avons proposé deux solutions innovantes : les communautés virtuelles et le handover sémantique. En eet, ces deux solutions interviennent au niveau du Service Delivery an de compléter la gestion de la mobilité qui est eectuée par les solutions existantes au niveau du Media Delivery. An de mettre en ÷uvre nos solutions proposées, diérents services de base de gestion ont été conçus.

Grâce à la solution des communautés virtuelles, nous avons pu maintenir la conti- nuité de services tout en tenant compte des préférences fonctionnelles de l'utilisateur ainsi que de ses préférences non fonctionnelles, c.à.d. sa QoS demandée. Pour ce faire, nous avons proposé d'anticiper toute coupure de la session de services de l'utilisateur en remplaçant tout service dégradé par un service ubiquitaire, ayant la même fonc- tionnalité et une QoS équivalente. An de supporter cette approche, des communautés virtuelles sont créées pour combiner les services ubiquitaires, et des agents de QoS sont intégrés dans ces diérents services pour détecter toute dégradation de la QoS ou du fonctionnement de chaque service. Autres que l'ubiquité, d'autres intérêts sont

aussi pris en considération an de concevoir d'autres types de communautés virtuelles. Nous avons conçu des VSC-U&Ps qui combinent des services ubiquitaires appartenant à un même fournisseur, des VSC-U&Ls qui combinent des services ubiquitaires qui sont dans la même zone d'entourage, et enn, nous avons combiné ces deux types de com- munautés pour avoir les VSCU-L&Ps. En outre, nous avons aussi favorisé dans notre approche une gestion distribuée où chaque plate-forme est responsable de ses propres communautés. Pour ce faire, nous avons diérencié les notions d'Inner VSC-U&L et d'Outer VSC-U&L.

Grâce à la solution du handover sémantique, nous avons pu maintenir la continuité de services, améliorer la QoE de l'utilisateur et diminuer le temps de latence, tout en tenant compte du nouveau contexte ambiant de cet utilisateur. Pour ce faire, nous avons proposé de remplacer un service pré-provisionné dans le VPSN par un autre service ubiquitaire appartenant à la nouvelle zone ambiante de l'utilisateur. An de supporter cette approche, chaque fournisseur distribue ses services ubiquitaires dans des zones géographiques à grande échelle et il associe à chaque service une zone de couverture. Ainsi, lors d'une mobilité spatiale (mobilité du terminal ou mobilité de l'utilisateur), et lorsque l'utilisateur sort de la zone de couverture relative à l'un de ses services pré- provisionnés et passe vers la zone de couverture d'un nouveau service, la plate-forme du service pré-provisionné intervient pour exécuter un processus de handover sémantique. Ainsi, nous diérencions deux types de handover sémantique possibles : un handover sémantique intra-fournisseur dans le cas où les deux services appartiennent au même fournisseur, et un handover sémantique inter-fournisseurs dans le cas opposé.

Au delà de ce contexte fort prometteur où l'utilisateur est au centre de l'architecture, où la composition de service répond aux besoins de personnalisation, et où nous rendons possible la convergence de services, nous pensons apporter une réponse au monde du cloud computing en intégrant nos solutions pour gérer les utilisateurs du cloud.

Ensuite, nous avons présenté un scénario qui montre l'intérêt qu'apportent nos deux solutions de gestion de la mobilité et qui vérie la complémentarité de ces solutions. Ce scénario est mis en ÷uvre suite à l'intégration des services de gestion de mobilité et des services exposables dans des conteneurs EJB dans un serveur GlassFish. Ce dernier fait partie d'un démonstrateur qui intervient de bout-en-bout pour valider la faisabilité de nos travaux user-centric.