NaradaBrokering est une technologie qui utilise les avantages de deux systèmes d’applications réparties : le système pair-à-pair et le système de type grille de calcul. Ces deux systèmes ont des avantages complémentaires.
Cette technologie peut s'interfacer avec un réseau peer-to-peer JXTA.
Les systèmes pair-à-pair ont une architecture très flexible reliant des pairs volontaires se trouvant à la bordure des réseaux. Les pairs sont alors reliés dans des réseaux correspondant plutôt à des réseaux ad hoc, c’est-à-dire tolérant aux déconnexions et aussi aux fautes. Ces systèmes sont davantage orientés vers le partage de fichiers et permettent aux pairs de rejoindre des groupes, émettre des requêtes, découvrir des ressources et signaler leurs intérêts particuliers pour certaines ressources.
Les systèmes de grille sont eux davantage orientés vers le partage de temps de travail. Ces réseaux sont en général robustes car fixes. Ils passent donc plutôt bien à l’échelle. En outre ces réseaux sont généralement soumis à de fortes contraintes de sécurité puisqu’ils travaillent souvent pour de projets industriels et/ou sensibles. En revanche le modèle de grille, même s’il est tolérant aux fautes, s’appuie davantage sur une certaine stabilité du réseau, une absence de nœuds opportunistes (leechers) et plus généralement, on peut dire que dans ce modèle, la volonté des nœuds et leur singularité ne sont pas vraiment des éléments clés.
La grande idée du NaradaBrokering va donc être de réunir les avantages de ces deux systèmes pour offrir aux utilisateurs un réseau de grande qualité. Pour intégrer le meilleur de ces deux modèles, le NaradaBrokering utilise des techniques tirées des objets distribués, des services web et, ce qui nous intéresse tout particulièrement ici, des intergiciels orientés message.
L’architecture utilisée ici est une architecture de réseaux locaux de pairs organisés à grande échelle par un réseau cœur. Pour l’accès aux services on introduit alors des « brokers ». C’est sur cette partie du réseau que vont principalement être utilisés les intergiciels orientés message. Ces brokers sont envisagés comme étant le plus petit élément de ce réseau. Ils ont pour mission de traiter et router intelligemment les messages. Plus particulièrement, voici les points clés de leur rôle :
Le réseau lié au NaradaBrokering est considéré comme étant constitué de brokers coopérants les un avec les autres, que ceux-ci soient situés sur des machines qui sont aussi de simples clients ou non.
Pour éviter d’avoir un réseau de brokers disparate et mal connecté, NaradaBrokering intègre un protocole de communication entre brokers chargé de gérer les liaisons entre brokers et de gérer l’ajout (ou le retrait) de brokers au réseau. L’organisation de ce réseau est faite de façon hiérarchique, chaque broker faisant partie d’un sous-ensemble, regroupé avec d’autres sous-ensembles en un autre ensemble, etc. Ces premiers sous-ensembles possèdent des brokers fortement interconnectés avec les autres sous-ensembles afin de garantir une liaison même en cas de panne. On a ainsi de petits réseaux connectés les uns aux autres. Ceci fait que lorsqu’on augmente la taille du réseau, le trafic augment de façon logarithmique et non exponentielle comme dans le cas des réseaux mal organisés ou désorganisés. NaradaBrokering introduit d’ailleurs des Brokers Network Maps (BNM) permettant d’assurer le routage intelligent évoqué plus haut.
JXTA est un projet Open Source dont le but est de proposer un ensemble de protocoles standards pour le modèle de communication pair-à-pair.
Le NaradaBrokering supporte les interactions avec le pair-à-pair, en fixant deux contraintes principales :
L’intégration de JXTA repose sur un modèle de proxy, ce dernier pouvant être vu comme une passerelle entre le système NaradaBrokering et JXTA, jouant en même temps le rôle d’un pair rendez-vous (sorte de super-pair), et un client NaradaBrokering. Du point de vue JXTA, NaradaBrokering peut être considéré comme un service, dont la découverte est automatique, grâce à l’intégration dans la couche rendez-vous. Du point de vue des pairs, l’interaction avec un proxy Narada-JXTA ou un pair rendez-vous est totalement invisible.
Le modèle d’interaction gravite donc autour de la couche rendez-vous : celle-ci traite les interactions placées en queue. Dans le cas de requêtes de recherche/découverte, ou de communication au sein d’un groupe de pairs, les interactions seront traitées à la fois par les pairs de rendez-vous JXTA, et les proxies Narada-JXTA. Lors de son initialisation en tant que client Narada, chaque proxy se voit assigner un identifiant unique. Il souscrit ensuite à un sujet l’identifiant comme proxy Narada-JXTA, ce qui permet au système de connaître tous les différents proxies présents.
D’autre part, en tant que pair rendez-vous, le proxy récupère certaines informations des interactions JXTA, telles que par exemple :
Puis un événement correspondant aux informations récupérées est créé, ciblant des sujets spécifiques, pour un routage plus efficace.
Etant donné que les messages au sein d’un système NaradaBrokering peuvent traverser des nœuds plus ou moins sécurisés, il est nécessaire de mettre en place une infrastructure reposant sur des niveaux de sécurité pour les messages. La gestion de la sécurité dans NaradaBrokering a pour intention de garantir ou permettre :
Ainsi, NaradaBrokering est une infrastructure reposant sur l’échange de messages, qui paraît appropriée aux Grilles pair-à-pair. Comme il existe de plus de nombreux matching engines, cela favorise les interactions possibles, et enrichit les mécanismes de découvertes. C’est notamment le cas avec un moteur supportant le XML. L’objectif est également à terme de supporter les bases de données Native XML (Xindice et eXist). Un travail en collaboration avec Gnutella est également en cours, dans le cadre d’une fédération de systèmes pair-à-pair, et de standardisation des mécanismes de recherche, requêtes, et réponses.