Attachement aux VSCUs

Lors du déploiement d'un nouveau service dans une des plates-formes d'un four- nisseur donné, le service VSCU Attachment de cette plate-forme essaye d'attacher le service déployé à une des VSC-U&Ps relatives à ce fournisseur et à une des Inner VSC- U&Ls relatives à cette plate-forme. En eet, l'intérêt de cet attachement est d'éviter, si possible, la création de nouvelles VSCUs pour chaque déploiement d'un nouveau service.

Pour pouvoir lancer ce processus d'attachement, l'évènement de déploiement d'un nouveau service dans une plate-forme doit être détecté. Pour cette raison, nous as- socions le déploiement du service à la création d'un Service Prole dans l'Infoware relatif à cette plate-forme. Ce Service Prole contient les champs suivants {Service ID, Functionality, QoS criteria, Provider ID, SIP URI, Longitude, latitude, VSC-U&P, Inner VSC-U&L, Outer VSC-U&Ls}, ainsi que le rayon Rc qui délimite la zone de

couverture de ce service et qui sera utilisé dans la partie de handover sémantique. Pour l'instant, les champs {VSC-U&P, Inner VSC-U&L, Outer VSC-U&Ls} restent vides. Par conséquent, suite à la création de ce Service Prole, l'Infoware détecte l'évènement de déploiement du nouveau service dans la plate-forme, et notie l'Events Manager relatif à cette dernière en envoyant une Service Deployment Notication contenant le Service ID. Ainsi, l'Events Manager associe cet évènement à l'action de notier le service VSCU Attachment abonné à ce type d'évènement.

Comme le montre la Figure 8.4, le processus fonctionnel du service VSCU Attach- ment correspond à la séquence suivante d'opérations :

 Opération 1 : Le VSCU Attachment envoie une requête à l'Infoware pour récu- pérer, d'une part la liste {Functionality, QoS criteria} relative au service déployé tout en s'appuyant sur son Service Prole, et d'autre part les listes {Functiona- lity, QoS criteria, QoS margins} relatives aux diérentes VSC-U&Ps et Inner VSC-U&Ls tout en s'appuyant sur leurs prols. Il faut noter que dans les prols des communautés virtuelles, nous associons aux quatre critères de QoS quatre marges de QoS, car ces communautés combinent des services ayant des valeurs de QoS qui ne sont pas forcément identiques, mais plutôt équivalentes.

 Opération 2 : Le VSCU Attachment compare la fonctionnalité et les valeurs de QoS relatives au service déployé à celles des VSC-U&Ps et des Inner VSC-U&Ls. Ainsi, trois cas sont possibles. Le premier cas se produit quand les caractéristiques du service déployé vérient celles d'une Inner VSC-U&L et d'une VSC-U&P. Le deuxième cas se produit quand les caractéristiques du service déployé ne vérient celles d'aucune Inner VSC-U&L, mais elles vérient celles d'une VSC-U&P. Le troisième cas se produit quand les caractéristiques du service déployé ne vérient celles d'aucune Inner VSC-U&L ni celles d'aucune VSC-U&P. Il faut noter qu'un quatrième cas, qui consiste à avoir un service déployé dont la fonctionnalité et les valeurs de QoS vérient celles d'une Inner VSC-U&L mais ne vérient celles d'aucune VSC-U&P, ne se produira jamais. En eet, le fait que les caractéristiques du service déployé vérient celles d'une Inner VSC-U&L implique qu'il y a déjà dans cette même plate-forme un service ubiquitaire qui a été déjà déployé et qui a causé la création de cette Inner VSC-U&L et qui ensuite a sûrement causé la création d'une certaine VSC-U&P.

 Opération 3 : Pour le premier cas, le VSCU Attachment envoie les notica- tions suivantes {Attach Inner VSCU&L Service, Attach VSC-U&P Service} à l'Infoware tout en précisant les identiants du service déployé, de l'Inner VSC- U&L et de la VSC-U&P. Ainsi, l'Infoware eectue l'attachement du service dé- ployé à l'Inner VSC-U&L et à la VSC-U&P. Pour le deuxième cas, le VSCU At- tachment envoie une première notication, Attach VSC-U&P Service, à l'Infoware tout en précisant les identiants du service déployé et de la VSC-U&P. Ainsi, l'Infoware eectue l'attachement du service déployé à la VSC-U&P. De plus, il envoie une deuxième notication, Create VSC-U&L, au service VSCU Creation de la même plate-forme tout en précisant l'identiant du service déployé. Ainsi, le service VSCU Creation crée selon son propre processus fonctionnel l'Inner VSC- U&L correspondant à ce nouveau service déployé. Enn, pour le troisième cas, le VSCU Attachment envoie une notication, Create VSC-U&L, au service VSCU Creation comme dans le deuxième cas, an que ce dernier crée selon son proces- sus l'Inner VSC-U&L correspondante. De plus, le VSCU Attachment envoie une notication, Create VSC-U&P, directement à l'Infoware an que ce dernier crée la VSC-U&P relative au service déployé. Il faut noter que pour la création d'une VSC-U&P, nous n'avons pas besoin de passer par le service VSCU Creation, car l'Infoware possède toutes les informations nécessaires pour créer par inférence

cette VSC-U&P.

Dans le cas où l'Infoware crée la VSC-U&P relative au service déployé, il crée un VSC-U&P Prole dans lequel il met les informations suivantes {VSC-U&P ID, Func- tionality, QoS criteria, QoS margins, Provider ID}. Ces informations sont prises par inférence d'après le Service Prole du service déployé. Ce Service Prole change aussi par inférence en ajoutant l'identiant de la VSC-U&P. Il faut noter que la VSC-U&P dans ce cas contient seulement un seul service. Puisque la VSC-U&P créée concerne un fournisseur et non pas une plate-forme bien déterminée, l'Infoware envoie des noti- cations, VSC-U&P Creation, à tous les fragments d'Infoware relatifs aux diérentes plates-formes de ce fournisseur. Dans ces notications, l'Infoware précise toutes les informations qui concernent la VSC-U&P créée (le VSC-U&P Prole ainsi que l'iden- tiant du service déployé, son adresse logique et sa zone de couverture qui sera utilisée par les autres plates-formes pour le handover sémantique).

Dans le cas où l'Infoware exécute l'attachement du service déployé à la VSC-U&P, il ajoute dans le Service Prole l'identiant de la VSC-U&P. Ensuite, il envoie des notications de mise à jour, VSC-U&P Service Attachment, vers tous les fragments d'Infoware relatifs aux diérentes plates-formes de ce fournisseur. Cette mise à jour contient l'identiant de la VSC-U&P adaptée ainsi que l'identiant du service attaché, son adresse logique et sa zone de couverture.

Enn, dans le cas où l'Infoware exécute l'attachement du service déployé à l'Inner VSC-U&L, il ajoute le Service ID à l'Inner VSC-U&L Prole et l'Inner VSC-U&L ID au Service Prole. Ainsi, le service déployé considère la communauté virtuelle à laquelle il vient de s'attacher comme son Inner VSC-U&L. Or, cette dernière a été déjà créée suite au déploiement d'un autre service dans cette même plate-forme. Par conséquent, nous nous trouvons dans une situation où nous avons deux services d'une même plate-forme partageant la même Inner VSC-U&L. Nous diérencions ces deux services en considérant celui qui était à l'origine de cette Inner VSC-U&L, comme un responsable, quand au deuxième service, nous le considérons comme un Backup. Ainsi, les autres services qui appartiennent à cette communauté et qui la considère comme Outer VSC-U&L n'auront pas conscience de l'existence de ce Backup. Par contre, ils ont des informations sur le responsable de cette communauté et ils le contactent en cas de dégradation.