• Aucun résultat trouvé

Fig. 2.4 – Le probl`eme de la s´election vu depuis la superstructure GGM

2.2.3 Analyse

Le probl`eme de la s´election est en ´etroite liaison avec celui du d´eploiement. Il est ´egalement crucial pour les performances de la plateforme : rien ne sert de d´eployer de fa¸con optimale une ressource, si au moment de l’utilisation un mauvais r´eplica est syst´ematiquement s´electionn´e. Par exemple, si le d´eploiement vise `a optimiser les temps d’ex´ecution en couvrant l’ensemble du r´eseau, mais que les clients ne s´electionnent pas leur r´eplica le plus proche, alors les performances seront sub-optimales et les charges augment´ees et mal ´equilibr´ees.

De mˆeme que pour le d´eploiement, le probl`eme de la s´election d´epend de trois param`etres : – l’emplacement du client et des diff´erentes instances de la ressource

– les caract´eristiques de la ressource

– les caract´eristiques de la portion d’infrastructure mat´erielle concern´ee – le ou les aspects `a optimiser

En effet, on pourra d´ecider de privil´egier les hˆotes les moins charg´es afin d’assurer un ´equilibrage des charges, ou bien de s´electionner les hˆotes permettant d’assurer le plus court temps d’ex´ecution, ceux-ci n’´etant pas n´ecessairement les mˆemes. De plus, on pourra vouloir prendre ´egalement en compte d’autres aspects tels que le coˆut financier, ou des aspects plus s´emantiques tels que la fraˆıcheur ou l’exactitude. Ainsi, le probl`eme de la s´election est ´egalement extrˆemement complexe.

2.3 Probl`eme g´en´erique de la composition de ressources

On a pu constater avec l’av`enement des architectures orient´ees services que la plupart des tˆaches relevaient en fait de la composition de plusieurs ressources. En effet, un service ´etant une application logicielle en charge d’une tˆache souvent bien pr´ecise et unitaire, les tˆaches utilisateur correspondent bien souvent `a l’utilisation successive de plusieurs ressources assurant chacune des sous-tˆaches n´ e-cessaires. Cela est commun´ement appel´e la composition de ressources. Cet aspect a fait l’objet de la th`ese de Girma Berhe [Berhe 06] soutenue dans notre ´equipe.

Le probl`eme de la composition correspond en r´ealit´e `a deux probl`emes. Le premier, appel´e ordon-nancement, consiste `a choisir dans quel ordre les ressources doivent ˆetre utilis´ees lorsque des

sous-tˆaches sont interchangeables. Le second consiste `a s´electionner pour chaque ressource quelle instance doit ˆetre utilis´ee. Dans certains cas, il est possible de r´esoudre ces deux probl`emes ind´ependamment : on commence par ordonnancer les tˆaches en fonction d’un graphe s´emantique de composition, puis on s´electionne les ressources en fonction de cet ordonnancement. Mais cette approche n’est pas toujours optimale, comme nous allons le voir ci-apr`es.

2.3.1 Pr´esentation du point de vue s´emantique

Fig. 2.5 – Exemple de chemins logiques d’adaptation de contenus multim´edia.

Fig.2.6 – Le probl`eme de la s´election du point de vue s´emantique

La Figure 2.6 montre un exemple de composition de services permettant l’adaptation d’un contenu multim´edia vid´eo qui doit ˆetre chang´e de taille, de format et ˆetre sous-titr´e grˆace `a l’extraction du flux audio, sa transcription en texte, sa traduction puis son incrustation dans le flux vid´eo. On parle ici de chemin logique d’adaptation, car on d´ecrit les op´erations devant ˆetre appliqu´ees au contenu ainsi que leur ordre, sans prendre en compte les services physiques devant ˆetre effectivement invoqu´es pour effectuer ces op´erations.

La description des diff´erents services impliqu´es est :

Fournisseur fournit le contenu vid´eo initial

Convertisseur de taille change la taille du contenu vid´eo re¸cu en entr´ee

Convertisseur de format change le format du contenu vid´eo re¸cu en entr´ee

DeMux extrait le son du contenu vid´eo re¸cu en entr´ee

Extracteur de voix extrait les voix du contenu audio re¸cu en entr´ee

Transcripteur de voix produit un fichier texte synchronis´e transcrivant le contenu audio re¸cu en

2.3 Probl`eme g´en´erique de la composition de ressources 25 Traducteur traduit un fichier texte re¸cu en entr´ee

Incrusteur de sous-titres incruste un fichier texte synchronis´e dans un contenu vid´eo re¸cus en

entr´ee

client consomme l’adaptation finale du contenu

Les diff´erents contenus ´echang´es lors de cette composition sont les suivants :

V : Le contenu vid´eo initial

Vf : Le contenu vid´eo apr`es conversion de format

Vt : Le contenu vid´eo apr`es changement de taille

S : Le flux audio du contenu vid´eo

S’ : Le contenu audio des voix du flux audio S” : Les sous-titres dans la langue initiale s : Les sous-titres dans la langue cible Vs : Le contenu vid´eo sous-titr´e

Nous notons les diff´erents contenus comme des combinaisons des diff´erentes adaptations et les op´ e-rations not´ees entre crochet sont optionnelles. Par exemple Vfts repr´esente le contenu vid´eo retaill´e, convertit et sous-titr´e, alors que V[f]s repr´esente deux contenus : soit le contenu vid´eo sous-titr´e et converti, soit le contenu vid´eo seulement sous-titr´e.

2.3.2 Pr´esentation du point de vue l’infrastructure

La Figure 2.7 illustre le probl`eme de la composition de ressource vu depuis l’infrastructure ma-t´erielle. Les diff´erents services devant ˆetre invoqu´es entre le fournisseur et le client sont distribu´es et r´epliqu´es sur plusieurs hˆotes. Il faut donc prendre en compte cette distribution afin de s´electionner chacun des r´eplicas en fonction de leur place dans le graphe s´emantique.

2.3.3 Pr´esentation du point de vue de la superstructure GGM

La Figure 2.8 illustre le probl`eme de la composition de ressource vu depuis la superstructure GGM : (1) un client, qui peut ˆetre un utilisateur ou un autre composant logiciel de la superstructure, ´emet une demande pour un contenu adapt´e au service de caches collaboratifs ; (2) ce dernier ´evalue les diff´erentes solutions d’adaptation en construisant le graphe s´emantique d’adaptation et en le confrontant aux services index´es sur la grille ; (4) puis il invoque chacun des services d’adaptation n´ecessaires en fonction de la solution retenue, soit en connectant directement les services successifs, soit en stockant les r´esultats interm´ediaires selon sa propre strat´egie ; (4) le cache stocke le r´esultat final et en fournit son identifiant physique au client ; (5) le client acc`ede enfin au contenu adapt´e demand´e.

Fig.2.8 – Le probl`eme de la composition vu depuis la superstructure GGM

2.3.4 Analyse

Une premi`ere remarque concerne la parall´elisation de la tˆache de cr´eation des sous-titres qui est possible `a trois niveaux diff´erents : parall´elisation au plus tˆot (le contenu vid´eo est envoy´e simultan´ e-ment au service DeMux et aux convertisseurs), parall´elisation `a moiti´e (le contenu vid´eo est envoy´e au service DeMux apr`es ˆetre pass´e par un des convertisseurs) ou pas de parall´elisation (le contenu vid´eo est envoy´e au service DeMux apr`es ˆetre pass´e par les deux convertisseurs). Pour chacun de ces trois cas, les deux convertisseurs de taille et de format sont interchangeables.

On peut donc compter six chemins possibles entre le fournisseur et le consommateur. On peut intuitivement penser que la parall´elisation est souhaitable pour am´eliorer les performances. En r´ealit´e, la distribution des ressources rend les choses plus complexes. En effet, si les conversions de tailles et de formats produisent des contenus de plus faibles tailles, et si l’infrastructure mat´erielle dispose de faibles capacit´es de communication ou bien que ces communications sont coˆuteuses (financi`erement ou en cas d’utilisation intensive), alors il peut ˆetre plus judicieux de commencer par convertir le contenu original avant d’entreprendre son sous-titrage, afin de limiter les coˆuts de communication.

On peut ´egalement remarquer qu’une adaptation paraissant anodine, par exemple l’extraction du flux audio face aux processus de transcription et de traduction, peut en r´ealit´e s’av´erer ˆetre une op´eration critique si elle est h´eberg´ee uniquement sur un hˆote pr´esentant des performances tr`es basses.