Comme étudié dans le premier chapitre, les RS sont de plus en plus développés afin de couvrir les besoins des différents utilisateurs. Mais, ils présentent encore plusieurs lacunes au
Chapitre 2
niveau de l’architecture, la disponibilité des données, la livraison sans perte et l’expression des intentions des utilisateurs devant la grande quantité de données produites sur Internet. En effet, nous remarquons qu’un échange de données est souvent inutile ou se produit à des moments inadéquats pour l’utilisateur. Cet échange se fait souvent selon des liens d’amitiés (exemple Facebook, LinkedIn, Whatsapp, etc.). D’après notre étude bibliographique, nous avons constaté que la plupart des RS déjà déployé sur Internet utilisent une infrastructure centralisée formée par un nombre limité de serveurs sous le contrôle d’un fournisseur de services. Ce dernier soit exige des frais pour l’utilisation du RS, soit impose des contraintes telles que l’espace de stockage limité, les services offerts limités, les problèmes de sécurité et de confidentialité des données personnelles, etc. Ainsi, la déviation du centralisée à une infra-structure distribuée parait une solution prometteuse du point de vue performance, sécurité, tolérance aux pannes et scalabilité.
Un système publier/souscrire est un paradigme populaire dans lequel les utilisateurs peuvent souscrire ou publier des contenus sur la base de leurs intérêts. Ces deux phénomènes des RS émergents et des systèmes publier/souscrire nous ont motivés à présenter une propo-sition pour l’amélioration des RS par l’intégration d’un système publier/souscrire afin de les rendre à la fois plus souhaitables et captivant pour les utilisateurs. Après une étude détaillée des systèmes publier/souscrire ainsi que leurs architectures, nous avons choisi d’adopter ce type de systèmes dans l’approche que nous allons proposer dans ce qui suit. Dans cette thèse, nous voulons montrer comment les fonctionnalités d’un système publier/souscrire peuvent être adaptées dans les RS fondés sur l’intérêt de l’utilisateur dans l’abonnement et la publi-cation.
Nous expliquons dans cette section l’architecture de base que nous proposons ainsi qu’une décomposition de la problématique de cette thèse.
2.3.1 Présentation générale de la plateforme MULUS
Dans le premier chapitre, nous avons identifié principalement les défis à résoudre dans cette thèse : (i) le partage de contenus composites selon les intentions des utilisateurs (ii) la décentralisation des RS pour plus de sécurité et de scalabilité (iii) assurer la disponibilité de données ainsi que leur livraison sans perte.
Une solution qui peut faire face à ces défis est l’utilisation des systèmes publier/sous-crire. Notre approche consiste à concevoir et implémenter un RSD fondé sur un système
publier/souscrire sémantique, de topologie P2P structurée et supportant la composition d’évènements. Ce RSD, que nous avons appelé"MULUS", assure le partage de données, en particulier des contenusMULtimédias composites entre les clUSters des utilisateurs.
Figure 2.13 – Interaction avec MULUS pour le partage de données composites
La Figure 2.13 présente l’interaction avec la plateforme MULUS et les étapes
primor-diales pour la livraison souhaitée [11]. Après qu’un utilisateur exprime son besoin composite et lorsqu’un producteur fournit un ensemble de données (1), ces éléments seront décomposés au niveau du réseau intermédiaire. Ensuite, une composition d’éléments (2) et une sélection de clusters (3) se font selon les intérêts des utilisateurs pour que la composition soit ache-minée uniquement vers les souscrits. À l’arrivée au cluster d’un utilisateur, la sélection des équipements se fait selon la description des capacités et les préférences des utilisateurs (4). Nous finissons par la distribution des éléments sur les équipements sélectionnés au niveau du cluster.
Chapitre 2
2.3.2 Architecture de MULUS
Pour gérer la distribution correcte de données composites entre les utilisateurs, MULUS doit assurer le filtrage des données partagées sur le réseau. Pour ce faire, MULUS repose sur un système publier/souscrire de topologie P2P structurée qui communique les clusters des différents utilisateurs à travers une entité Home Box Entity (HBE) (voir Figure 2.14). Cette entité est déployée sur un dispositif sélectionné de chaque cluster jouant le rôle d’une gateway. Une fois le nouveau paquet délivré aux consommateurs des clusters correspondants, nous avons besoin de sélectionner les appareils du cluster capables de supporter les éléments reçus. Cette entité joue le rôle d’un serveur d’évènements une deuxième fois pour connecter les différents équipements au niveau local du cluster. L’architecture de cette entité sera dé-taillée dans le Chapitre3.
La mise à l’échelle de notre plateforme est garantie grâce à la topologie P2P structurée du système publier/souscrire reliant les différents clusters. Cette topologie utilise la DHT qui se caractérise aussi par l’auto-organisation des nœuds et l’équilibrage de charge (le load-balancing) entre les nœuds qui composent le service d’évènements du système publier/sous-crire. La DHT est connue aussi par le routage flexible entre les nœuds fondé sur le routage des pairs (clé, valeur) et par la scalabilité. Avec ce protocole, les DHT procurent aux déve-loppeurs un haut niveau d’abstraction pour implémenter un système de stockage persistant et à large échelle. Ils masquent la complexité de routage, de tolérance aux pannes et de réplication de données. Par conséquent, ils sont de plus en plus utilisés pour développer des applications dont la fiabilité est primordiale, telles que la gestion répartie de fichiers, les sys-tèmes de sauvegarde, ou les applications de distribution de données. Pour notre plateforme MULUS, nous choisissons le système Scribe que nous avons présenté dans la section2.2.3.5. Pour la diversité des intérêts des utilisateurs et l’hétérogénéité des données, notre plateforme a recours à la description sémantique pour permettre aux utilisateurs une meilleure précision lors de la description de leurs intentions. Vu la diversité de la description sémantique, nous utilisons une ontologie de domaine unifiée entre tous les utilisateurs de notre plateforme pour l’étendre à des individus exprimant leurs différents besoins. Nous expliquerons plus tard notre approche pour l’utilisation de l’ontologie sur le système Scribe.
Comme le montre la Figure 2.14, les serveurs d’évènements de notre système
publier/-souscrire sont des équipements choisis des différents clusters. Ce choix est justifié par les avantages identifiés dans la section précédente du modèle P2P de ces systèmes. Néanmoins,
ces équipements sont réellement trop dynamiques sur le réseau vu l’utilisation fréquente des équipements mobiles qui favorise la connexion/déconnexion répétée sur le réseau. En consé-quence, nous devons résoudre le problème de dynamisme fort des serveurs d’évènements d’un
système publier/souscrire P2P basé DHT. Nous traiterons ce problème dans le Chapitre5.
Figure 2.14 – Architecture de la plateforme MULUS [11]