Rapport d’activités surSmartTools en 2008-2009
par Baptiste Boussemart
INRIA Sophia Antipolis 2004 route des Lucioles - BP 93 - 06902 Sophia Antipolis Cedex [email protected] http://www-sop.inria.fr/teams/lognet/pon
A propos de ce rapport 2009d’activités sur SmartTools
Ce rapport a pour but de rendre compte du travail apporté à SmartTools pour l’ouvrir au monde du
réparti, avec une manière pair-à-pair sur un Overlay Network.
Le rapport est organisé en deux parties : la mission et le projet, et puis une annexe technique.
Dans un premier temps, les objectifs, la méthodologie et les modifications sont présentés dans la par-
tie appelée “La mission et le projet”.
Dans une seconde partie, les aspects techniques développés durant cette mission sont présentés dans la partie appelée “Annexes”.
Enfin, les documents produits durant mes deux années à l’INRIA sont mis en Références.
La mission et le projet
I. Objectifs de la missionL’objectif de la mission a été la mise en œuvre du prototype “Programmable Overlay Network” (PON).
Ce prototype est composé de l’Architecture Orientée Service (SOA) de SmartTools et d’une implé-
mentation open-source d’une table de hachage distribuée (DHT) Open-Chord, qui permet le partage
par la publication et la recherche de ressources identifiées par une clé. Dans notre cadre, une res-
source représente un composant disponible sur le réseau.
Une phase d'étude des nombreuses technologies issues de la nouvelle vague SOA a été nécessaire
pour mieux comprendre l’intégration et l’articulation de nos futurs travaux de recherche pour les no-
tions de “Programmable Overlay Network” (PON). En particulier, nous avons étudié les technologies
liées aux différents protocoles de communication et de support, par exemple JXTA (Framework pair à pair de Sun Microsystems) ou la plateforme SCA (Service Component Architecture). Nous avons aussi
utilisé les nouvelles interfaces web dynamiques avec Google Web Toolkit (GWT) et Google Map API.
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 1
II. Contexte de la missionIl a fallu faire évoluer de l’architecture Orientée Service (SOA) issue de notre outil SmartTools dans le
cadre de la création de la nouvelle équipe LogNet. SmartTools a été modifié pour accepter une orga-
nisation virtuelle de postes (réseau virtuel d’ordinateurs) interconnectés en pair-à-pair, une organisa-tion virtuelle issue du domaine des Overlay Networks.
Ces deux approches s’articulent autour d’une notion d’organisation virtuelle analogue : une colonie
d’agents (composants) supervisée par un leader (le gestionnaire de composants dans le cadre de
SmartTools et le “broker” dans le cadre overlay network).
L’approche SOA et Overlay Network ont en commun la notion de clé (publish/subscribe) de publica-
tion et de recherche de ressources/composants.
III. MéthodologieNous avons appliqué une méthode incrémentale de développement et procédé en quatre étapes.
La première étape consistait à établir une connexion réseau point à point entre plusieurs plateformes.
Pour cela, nous avons mis en place des interconnexions entre JVMs (Java Virtual Machine), donc plu-
sieurs plateformes SOA de SmartTools. Nous avons proposé des modifications de SmartTools étape
par étape pour l’ouvrir à des protocoles de communication simple entre plateformes de composants avec les protocoles UDP et TCP. (section III.2) La SOA de SmartTools a été enrichie par des modules
de composants qui ont en charge la publication, la recherche et la communication vers des compo-
sants répartis.
Dans l’étape suivante, nous avons modifié les premiers modules de composants répartis avec une
gestion de plusieurs communications par connexion TCP (tuyaux virtuels) à la JXTA. (section III.3)
Ensuite, nous avons modifié les premiers modules de composants répartis avec une table de ha-
chage distribuée PiNet. (section III.4)
Pour la dernière étape, nous avons additionné les deux dernières étapes. Cela a consisté à créer un
module de composants PON, qui a pour principe de publier et de rechercher les composants dans
un Overlay Network, tel que Open-Chord, et de déléguer la communication à VirtPipes, des tuyaux virtuels. (section III.5)
Mais avant d’expliquer les différents protocoles, nous expliquons comment SmartTools a été ouvert
au réparti, avec les changements apportés au gestionnaire de composants. (section suivante, III.1)
1. Ouverture de SmartTools avec les modules de composants
La première étape du travail a été de refactoriser SmartTools afin d’ouvrir la plateforme SOA à plu-
sieurs méthodes de distribution (communication) des composants sur le réseau. En effet, sachant que
nous allions enrichir notre SOA de plusieurs types de protocoles indépendants, il était important que
notre gestionnaire de composants (CM), qui a la charge d’établir la connexion entre nos composants,
soit modulable et extensible. De nombreux protocoles ont été réalisés et testés. Pour chaque type de
protocole, un module de composants répartis a été réalisé. Ainsi, nous pouvons dynamiquement ad-
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 2
joindre au CM différents modules de composants répartis. Dans l’ordre de réalisation, les modules de
composants sont : SimpleUDP, SimpleTCP, VirtualPipes, PiNet et PON. PON est le module de com-posants le plus abouti, qui utilise à la fois un Overlay Network (Open-Chord) et une abstraction de tuyaux à
la JXTA.
Du point de vue technique, le CM possédait des tables de composants locaux et répartis (dans le
contexte de la première expérience en réparti utilisant la bibliothèque R-OSGi1). Ces tables sont main-
tenant gérées par les modules de composants, dont l’indispensable module de composants locaux
au CM pour une exécution locale. Les autres modules de composants sont optionnels et mettent en
œuvre des moyens d’accéder à des composants répartis (distants). Ils peuvent même être brancha-
bles et débranchables à chaud. Il a été apporté au CM une technique de choix de ces modules de
composants, en fonction de plusieurs facteurs : les arguments de l’ordre de connexion (l’opération
connectTo), de la présence ou non d’un type ou d’une instance de composant spécifiée dans les modules de composants. Pour plus de détails, l’annexe VIII présente précisément comment fonc-
tionne cette stratégie de choix du module de composants.
2. SimpleUDP & SimpleTCP
La motivation de cette première étape était de faire les premiers modules de composants basés sur
des protocoles simples, afin de maîtriser la communication des composants en réparti au sein de
SmartTools. Cela a permis de refactoriser la plateforme SmartTools, plus spécialement le gestionnaire
de composants (CM), pour que les modules de composants répartis puissent être interchangeables
et donc de proposer par la suite des modules de composants répartis de plus en plus complexes.
SimpleUDP et SimpleTCP sont des modules de composants répartis “simples” qui interconnectent
les JVMs point à point, respectivement en UDP et TCP. Ces modules de composants échangent la liste des composants de chaque machine, grâce à des messages de services spécifiques. De fait,
chaque module de composants SimpleUDP et SimpleTCP connait l’ensemble des composants ac-
cessibles sur le réseau, ce qui à large échelle n’est pas envisageable (explosions des tables). De plus,
la connexion entre les JVMs doit être effectuée préalablement, ou par un autre mécanisme à définir. Il
n’y a pas de mécanisme d’inscription au réseau pris en compte par ces modules de composants, à la
différence de PiNet et PON.
L’un des objectifs de cette première étape était de comprendre quel est le type de proxy (l’objet qui
joue le rôle du composant réparti) dont nous avions besoin. En effet, notre SOA est basé sur un
échange de messages asynchrones, réalisé par deux méthodes très génériques (send et receive,
pour l’envoi et la réception de messages). Cette première expérience a montré que notre forme de proxy est très simple et ne dépend uniquement que du type du protocole. En effet, le proxy doit sa-
voir comment et où envoyer son message, et dépend uniquement de son protocole. Donc chaque
module de composants répartis doit offrir une implémentation d’un proxy en fonction du protocole.
A l’inverse de RMI (Remote Method Invokation) ou de R-OSGi, qui génèrent des proxies en fonction
de l’interface des objets, SmartTools a besoin simplement d’utiliser une seule méthode de réception
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 3
1 http://r-osgi.sourceforge.net
des messages (receive), et la description du composant (nom + services). La méthode de réception
est invoquée par la méthode d’envoi (send) du conteneur qui invoque le service. La réception d’un message revient à faire l’appel de la méthode dans le code métier du composant (façade).
Pour la connexion entre deux composants, il est nécessaire d’accéder à la description des compo-
sants. Ainsi lors de la création d’un proxy, le fichier de description doit être fourni par la plateforme
SOA à distance.
Il y a donc une phase de publication et de recherche des références aux composants et une dernière
phase de communication, proprement dite, entre les composants. Ces deux modules (SimpleUDP et
SimpleTCP) réalisent ces trois phases : la publication, la recherche, et la communication point à point.
Aucune abstraction n’a été faite. Ces trois phases ont été mieux séparées et abstraites dans le mo-
dule de composants répartis PON, décrit par la suite.
Communication entre composants
Lorqu’un composant envoie un message à un proxy, ce dernier va écrire le message dans le tuyau de communication (connexion UDP ou TCP) qui atteindra la plateforme SOA qui contient le composant
distant (final).
Pour cela, le proxy spécifie le destinataire dans le message envoyé pour que le module de compo-
sants distant puisse savoir à quel composant il doit transmettre le message. Ensuite, le proxy envoie
le message sous forme sérialisée. A la réception du message, SimpleUDP ou SimpleTCP désérialise
le message. Le nom du destinataire contenu dans le message permet à Simple UDP ou SimpleTCP
de retrouver le composant final et de lui transmettre. Ceci est une première façon de faire du multi-
plexage à partir du nom du composant destinataire dans le message. Nous verrons dans les sous-
sections suivantes comment avec la notion de tuyau virtuel il est possible d’abstraire ce multiplexage,
avec le module de composants VirtualPipes et PON avec VirtPipes. La figure 1 résume le mécanisme de communication entre deux composants.
fig. 1 : Deux plateformes SOA connectées. Seuls la communication et le rôle du proxy sont représentés.“Sortie” et “entrée” représentent soit TCP ou UDP
Component Proxy
Module de composantsrépartis
protocolecomm.
(TCP/UDP)distributeur
CDML + nom du composant
Réseauprotocole
comm.(TCP/UDP)
distributeur
Module de composantsrépartis
0011100101110110
110110111101
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 4
Dans le cas du protocole UDP, une seule communication UDP pour toutes les JVMs connectées.
Alors que le protocole TCP établit autant de tuyaux de communication (sockets) que de plateformes SOA interconnectées. UDP se trouve donc plus simple que TCP dans ce cas, mais n’offre pas les
avantages de TCP sur la qualité de la transmission, l’ordre d’envoi des messages, le découpage des
messages longs et leurs reconstitutions.
3. VirtualPipes
VirtualPipes est un module de composants qui ressemble au SimpleTCP dans la publication et la re-
cherche, mais où l’émission des messages aux composants est déchargée à un module de tuyaux
de communication abstraits, que nous dénommons “tuyaux virtuels”. La distribution des messages
n’est plus gérée par SimpleUDP ou SimpleTCP, mais par un module chargé de construire un tuyau
virtuel associé au proxy. Ce tuyau envoie les messages directement vers le vrai composant final (le
destinataire).
Ce module VirtualPipes nous a permis d’expérimenter la notion de tuyaux virtuels entre 2 JVMs, et de
proposer une version améliorée de ces tuyaux virtuels dans PON avec VirtPipes, dans le cadre d’un
Overlay Network.
Toutefois, ce module était purement expérimental et présentait des limitations. Premièrement, il était
basé sur le framework des entrées/sorties standard de Java (java.io), qui sont bloquantes. A cause de
cela, chaque connexion TCP et chaque tuyau virtuel nécessitaient la gestion d’un Thread (processus
léger Java). Enfin, pour chaque connexion TCP et chaque composant local, un tuyau virtuel était créé,
ce qui n’était pas efficace du tout en terme de Threads ouverts.
Tout de même, cette expérimentation a montré la possibilité de connecter les proxies directement aux
vrais composants, en abstrayant la distribution de messages du module de composants dans un framework générique. Ce travail a débouché sur VirtPipes, qui apporte beaucoup plus de possibilités
et d’efficacité, grâce notamment à une DHT (Open-Chord) et le framework des entrées/sorties non-
bloquantes de Java NIO (java.nio). Java NIO (New Input/Output) permet de rendre TCP plus simple à
la programmation (gestion des threads) et plus performant à l’utilisation, ce qui a été utilisé dans le
cadre de VirtPipes et donc de PON.
4. PiNet
PiNet est un module de composants ressemblant à SimpleUDP dans la communication, mais où la
publication et la recherche des composants sont décentralisées dans une table de hachage distri-
buée (DHT) PiNet, réalisé par Bernard Serpette. L’utilisation de la DHT supprime les messages de ser-
vices entre les modules de composants répartis, car seuls les messages de communication entre les composants sont transmis durant la phase de communication.
Cette première expérience de notre SOA sur un Overlay Network nous a permis de voir l’utilité de la
DHT pour publier et rechercher nos composants de chaque JVM.
Ce module de composants PiNet a apporté la possibilité de découverte des plateformes SOA, donc
des autres modules de composants PiNet. Contrairement aux modules SimpleUDP, SimpleTCP et
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 5
VirtualPipes, il n’est pas nécessaire d’interconnecter tous les modules de composants entre eux pour
constituer une liste exhaustive des composants disponibles, puisque la gestion de la table des com-posants est déléguée à l’Overlay Network. L’overlay joue le rôle d’une table globale des composants
disponibles sur le réseau. La DHT apporte la fonctionnalité de connecter les plateformes SOA auto-
matiquement et dynamiquement à la demande.
5. PON (Open-Chord + VirtPipes)
PON est un module de composants alliant l’abstraction de tuyaux virtuels VirtPipes et une table dé-
centralisée OpenChord. Dans ce contexte, le module de composants délègue la gestion des tables
de composants à l’Overlay Network et la gestion de la communication à VirtPipes. Ceci rend ce mo-
dule de composants répartis plus modulaire et plus simple que les autres modules de composants,
car il utilise deux abstractions des deux phases : la publication et recherche (avec OpenChord), puis la
communication (avec VirtPipes).
Le travail a consisté à produire la glue entre ce module de composants PON et les deux abstractions
VirtPipes et OpenChord. La figure 2 représente la communication et le schéma de l’architecture.
Ce module de composants ne gère plus directement un protocole de communication, la distribution
des messages, ni des messages de service pour échanger les tables de composants, mais orchestre
plutôt les deux abstractions vues dans PiNet et VirtualPipes avec des technologies similaires, respec-
tivement Open-Chord et VirtPipes.
Fig.2 : Orchestration de PON avec VirtPipes et la DHT : Chaque composant possède un tuyau d’entrée,et chaque proxy possède un tuyau de sortie pointant vers le tuyau d’entrée du composant final
Component A Proxy B Component B Proxy A
Module de composantsrépartis
VirtPipes
DHT (Open-Chord) DHT (Open-Chord)
VirtPipes
VirtPipes Service
CDML + nom du composant
Réseau
Module de composantsrépartis
0011100101110110
0011100101110110
0011100101110110
110110111101
110110111101
110110111101
GLUE- Créé les tuyaux virtuels- Enregistre les référencesdans la DHT
A AB B
Lecture,désérialisationet transmission
Java NIO TCP
VirtPipes Service
Java NIO TCP
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 6
PON est expliqué plus en détail dans la section suivante (IV).
IV. PON : Programmable Overlay NetworkLa principale motivation de réaliser PON est de proposer la plateforme SOA de SmartTools en pair-à-
pair (P2P), afin d’éviter d’avoir un annuaire central de services (composants). Un serveur central est difficile à héberger et à configurer pour le commun des mortels. On veut favoriser plutôt la connexion
de multiples microsystèmes SOA en P2P. L’avantage est que nous évitons une configuration statique
et difficile à maintenir et à étendre.
Toutes les expériences acquises avec les modules de composants répartis, ont permis de construire
un overlay network programmable, que nous avons nommé PON (Programme Overlay Network).
PON s’organise en trois couches : SmartTools, VirtPipes et Open-Chord. Voir figure 3.
Fig. 3 : Architecture logique de PON en trois couches,avec les modules de composants pour SmartTools et les modules d’informations pour VirtPipes
SmartTools est la plateforme SOA qui apporte la capacité de programmer et d’exécuter des services.
VirtPipes permet de connecter les services entre eux suivant un modèle dynamique de connexions. Enfin, Open-Chord est une implémentation d’une table de hachage distribuée, un Overlay Network,
qui nous permet d’avoir une communauté d’utilisateurs qui échangent leurs services.
Cette section est organisée en deux sous-sections. La première section est consacrée à son utilisa-
tion dans SmartTools avec le module de composants PON. La seconde section est une introduction à
l’abstraction de communication VirtPipes.
1. Utilisation de VirtPipes dans SmartTools, avec le module de composants PON
A chaque composant publié par le module de composants PON, PON ouvre un tuyau virtuel d’entrée
et l’enregistre dans l’Overlay Network. Si un composant veut se connecter à un composant distant
géré par PON, le module de composants PON cherche dans la DHT le tuyau d’entrée du composant
distant, son type afin de produire le proxy du composant distant. PON associe ce tuyau virtuel au
SmartTools
VirtPipes
DHT (Open-Chord)
Modules decomposants
local
Modulesd’information
DHT
PON ...
...
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 7
composant dans l’Overlay Network, afin de permettre aux autres modules de composants PON de
retrouver à quel tuyau les proxies doivent transmettre les messages. Enfin PON créé un objet d’inter-position de lecture du tuyau, qui a pour rôle d’être notifié de l’arrivée d’un message, de le désérialiser
et de le transmettre au composant final.
A partir de là, j’ai proposé un autre modèle de connexions de sortie pour prendre en compte l’invoca-
tion d’un service sur un ensemble de composants répartis de manière plus efficace. Pour invoquer un
service sur un groupe de N composants, N appels aux proxies des composants sont réalisés, et par
conséquent N envois de messages sur le réseau étaient effectués. Cela n’est pas efficace et j’ai pro-
posé de faire une distinction entre l’envoi unicast et l’envoi multicast en réalisant deux modèles de
connexion. En fait, peu de choses ont changé. La modification a été de déléguer l’envoi multicast aux
modules de composants répartis. Pour plus de détails, voyez la section IX.3 en annexe.
2. VirtPipes
La couche de communication VirtPipes utilise Open-Chord pour le partage et la recherche d’informa-
tions sur les tuyaux. VirtPipes est modularisé, comme SmartTools, avec des modules d’information.
Ces modules permettent de proposer différentes façons, additionnables, de résoudre la connectivité
des tuyaux virtuels. Un module d’information permet de lier VirtPipes à Open-Chord, et d’autres pour-
raient lier VirtPipes à un annuaire centralisé ou à de la découverte de service telle que Bonjour.
VirtPipes permet de faire passer plusieurs tuyaux de communication à travers une seule connexion
TCP, et donc de limiter le nombre de connexions TCP à une connexion par couple de plateformes
SOA (JVM) connectée. L’implémentation des communications TCP utilise Java NIO pour plus d’effi-
cacité, car un seul Thread permet de gérer plusieurs communications TCP avec les entrées/sorties
non bloquantes de Java NIO.
VirtPipes définit le concept de tuyau identifié par un numéro unique UUID de 128 bits. Java fournit
une API pour créer de tel numéro unique (la classe java.util.UUID). L’identifiant est associé à la ma-
chine virtuelle identifiée elle-même par un numéro unique. Cette association (clé, valeur) est enregis-
trée dans l’Overlay Network pour que les VirtPipes de chaque SOA puissent retrouver cette informa-
tion.
L’identifiant de la JVM permet de retrouver l’adresse IP et le port du serveur ouvert par la JVM, et
cette association est aussi enregistré dans les modules d’informations pour VirtPipes. Cela permet
d’établir une connexion TCP si cela n’a pas déjà été fait, ou de rétablir une connexion TCP coupée.
(UUID de la JVM -> Adresses IP + port du ServerSocket)
V. ExemplesAfin de tester et d’utiliser PON, plusieurs exemples ont été réalisés.
Le premier exemple présenté est celui du chat, qui en terme de composant est très simple. Les com-posants Chat en connexion s’échangent des messages textuels écrits par des chatteurs.
Ensuite l’exemple du transport est présenté. Cet exemple montre la possibilité d’ajouter dynamique-
ment une connexion directe entre le client et le service (grâce à un échange de méta-informations).
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 8
1. Chat
Chat est un exemple de composants simples où l’interface utilisateur permet au composant associé de se connecter dynamiquement à un autre composant publié dans l’Overlay Network. Une instance
de Chat représente un utilisateur, qui est publiée dans l’Overlay Network avec PON. Un autre utilisa-
teur peut se connecter à cet utilisateur, sans autre information plus technique que le nom de l’utilisa-
teur distant. PON résout la communication, l’initialisation de la connexion TCP.
Cet exemple simple nous a permis de tester les différents modules de composants développés au
cours de la mission, et de présenter un petit exemple concret sur le site web. Il permet de montrer les
avantages de PON avec la recherche de composants dans l’Overlay Network OpenChord et l’auto-
connexion des plateformes SOA, grâce aussi à l’Overlay Network OpenChord.
Deux types d’interfaces ont été implémentés : Swing et GWT, suivant les capacités de la machine.
Fig. 4 : Deux composants Chat (baptiste et didier) connectés avec PON (composants locaux en jaunes et proxies en blancs)
Pour plus de détails, vous pouvez vous référer à la partie Chat dans l’annexe (XIV.1).
2. Transport
Nous avons réalisé un exemple plus complexe dénommé Transport. Le principe de cette application
est de proposer aux usagers, en fonction de leur position géographique, les moyens de transport dis-
ponibles (ou services). Les moyens de transport sont définis simplement par une zone. Pour chaque
service, un composant est instancié (le nom du service géoréférencé).
Grâce à PON, nous utilisons une table décentralisée pour enregistrer les composants distribués sur le
réseau. Le composant lui-même peut utiliser cette table pour enrichir les informations. Dans cet
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 9
exemple de Transport, les composants savent utiliser l’Overlay Network OpenChord pour ajouter des
méta-informations sur les composants, dont la zone géographique de service de chaque composant.
Les services de transport publient dans la table décentralisée sa zone géographique de service et un
composant utilisateur peut trouver les services proches de sa position géographique.
Fig. 5 : Les trois composants de l’exemple Transport,de gauche à droite : le gestionnaire qui créé des services géoréférencés,
les services géoréférencés et l’utilisateur qui recherche les services en fonction de sa position
Pour plus de détails, vous pouvez vous référer à la partie Transport dans l’annexe (XIV.3).
VI. ConclusionCe rapport a permis de présenter la manière dont SmartTools a été ouvert au monde réparti, les pos-
sibilités d’une architecture modulable du gestionnaire de composants de SmartTools. Cette architec-ture permet de brancher différents types de protocoles au cœur de SmartTools.
Afin de tester et valider le développement, nous avons développé des exemples nous permettant de
maîtriser le développement général, ainsi que d’identifier les besoins. La méthode est très incrémen-
tale, proche des méthodes agiles avec des petites itérations, plutôt qu’un cycle en V lourd et long.
Ce travail m’a permis de mettre en pratique des technologies SOA et P2P en Java et OSGi, aussi que
des interfaces Swing et GWT.
VII. Idées futures
1. Cluster
Nous avons pensé à développer un moyen d’installer et d’instancier des composants à distance,
pour montrer les capacités dynamiques de SmartTools au-dessus de OSGi.
OSGi offre la possibilité d’ajouter dynamiquement de types de composants avec l’installation dynami-
que de JAR (Bundle). SmartTools offre la possibilité de démarrer dynamiquement des instances de composants en fonction des types de composants installés sur la plateforme OSGi locale.
J’ai proposé un type de composant “Servant” permettant de donner le contrôle à distance à un com-
posant “Gestionnaire” des possibilités de OSGi et de SmartTools.
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 10
Un prototype a montré la faisabilité de cette idée, mais il reste à l’utiliser. Cela peut être utile pour faire
des études de l’architecture de PON à plus grande échelle, par exemple des tests avec GRID5000. Nous ne sommes pas allés jusque-là.
Pour plus de détails, vous pouvez vous référer à la section XV en annexe.
2. META-PON
PON est une première réalisation d’une architecture orientée service sur un réseau virtuel, où
SmartTools utilise VirtPipes et Open-Chord, et où VirtPipes utilise Open-Chord pour résoudre la con-
nectivité des tuyaux virtuels.
Du fait que l’architecture est modulaire, nous pouvons proposer un PON avec d’autres technologies
ayant le même savoir-faire. On peut même additionner les différentes manières de faire. Par exemple,
on peut utiliser SimpleUDP et PON dans SmartTools sans effort. Ou encore, allier la DHT et la décou-
verte Bonjour pour VirtPipes.
On pourrait instancier et configurer deux ou plusieurs modules de composants PON différents. Cha-
que PON configuré différemment pour que l’un s’occupe d’un groupe de poste spécifique, et que
l’autre s’occupe d’un autre groupe plus large n’incluant pas le premier. Ce projet reste à être réalisé et
testé.
On peut aussi penser à ajouter de la sécurité pour la communication et l’authentification des plate-
formes SOA, ou d’aller plus finement au niveau des composants.
En résumé, l’architecture est suffisamment modulable pour qu’elle soit composable à souhait.
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 11
Annexes
Refactorisation
Un ensemble de refactorisations a été effectué tout au long de cette mission. Ces modifications sont
nombreuses et portent sur des parties qui ne concernent pas seulement les modules de composants. Le refactoring est le fait d’améliorer la structure d’un programme sans changer la fonctionnalité, afin
de préparer une extension du logiciel ou accroître la maintenance de celui-ci.
VIII.Refactorisation du ComponentsManagerLe ComponentsManager a été modularisé pour accepter des modules de composants répartis, sans
que la façon de connecter les composants change. Plusieurs modules de composants ont été pré-
sentés dans ce rapport (section III.2 à III.5).
1. Stratégie de choix du module de composants
Dans cette sous-section, nous présentons le principe de la stratégie de choix du module de compo-
sants qui effectuera la connexion entre un composant local et un autre composant (local ou réparti). Il
pourrait y avoir plusieurs types de stratégies. Voici celle qui nous semble la plus simple. Il y a deux
phases dans cette stratégie, présentées sur deux schémas.
La première phase consiste à déterminer le type de commande de connexion connectTo (connect-ToOne, connectToFirst ou connectToAll). Suivant le type de commande, la stratégie change. Con-
nectToOne permet de connecter une instance de composant à une autre instance de composant
spécifiée. ConnectToFirst permet de connecter une instance de composant à une instance de com-
posant répondant au type de composant demandé. ConnectToAll permet de connecter une instance
de composant à toutes les instances de composant répondant au type de composant demandé.
Dans le cas du connectToOne, on va interroger les modules de composants pour savoir qui possède
l’instance de composant en question. La suite est présentée dans la phase 2.
Dans le cas du connectToFirst, on va interroger les modules de composants pour savoir s’ils peuvent
fournir une instance de composant du type demandé. La suite est présentée dans la phase 2.
Et dans le cas du connectToAll, on délègue la connexion du composant source à toutes les instan-ces de composants du type donné. Les demandes de connectToAll sont gardés en mémoire dans le
CM, pour notifier les nouveaux modules de composants qui pourraient arriver ultérieurement qu’ils
doivent se charger de connecter les composants sources à tous les composants de type demandés.
La stratégie est finie pour connectToAll.
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 12
Phase 1 de la stratégie
Dans les cas connectToOne et connectToFirst, les modules de composants vont chercher à répon-
dre à la question. Une fois que tous les modules de composants ont répondu au CM, le CM va com-pléter la demande de connexion en cours.
Dans le cas de connectToOne, la priorité est donnée au module de composants locaux pour réaliser
la connexion. Si celui-ci ne possède pas l’instance de composant, alors on regarde si un module de
composants répartis possède l’instance du composant à distance. Si plusieurs ont répondu positive-
ment, nous prenons arbitrairement le premier de la liste. Dans le cas contraire, et dans le cas où la
fonction auto-start n’est pas désactivée, on regarde si le module de composants locaux possède le
type de ce composant, et on demande de démarrer l’instance de composant et on demande à ce
module d’effectuer la connexion.
Dans le cas de connectToFirst, on donne aussi la priorité au module de composants locaux, puis la
possibilité aux modules de composants répartis de faire la connexion. Cette commande effectue une seule connexion à une instance de composant que nous ne connaissons pas, mais qui est du type
demandé.
Si une connexion a été effectuée dans un module de composants, alors la stratégie se finit et est dé-
truite. Par contre, dans le cas où aucune connexion n’ait été effectuée, la commande est gardée dans
le CM et sera rejouée lors d’un événement notifiant qu’une instance de composants est fraîchement
arrivée, de la part des modules de composants.
connectTo service
ComponentsManager
ComponentsManager
stratégie de connexionmodules de composantsconnectToCommands
connectTo(arguments)réponse(...)
ConnectToCommandFactory ConnectToCommand
DefaultConnectToCommand
execute()
ConnectToOneCommand
execute()
execute()
execute()
ConnectToFirstCommand
ConnectToAllCommand
créé et ajoute au CM
créé en fonction des arguments
appel
Module de composants
répartis
Module de composants
répartis
Module de composants
répartis
Module de composants
répartis
*
cherche un composant
délègue la connexion à tous lescomposants du type donné
cherche le 1er composant du type donné
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 13
Phase 2 de la stratégie
2. Interfaces
Le gestionnaire de composants (CM) définit les interfaces du module de composants locaux (Lo-calDS) et des modules de composants répartis (RemoteDS). Cela permet au CM d’interagir avec eux
alors qu’il ne peut pas dépendre d’eux directement (dépendances Java/OSGi). Par contre, les modu-
les dépendent du CM, d’une part pour implanter les interfaces et d’autre part pour répondre au CM à
ses demandes.
L’interface LocalDS contient un ensemble de méthodes qui était dans le CM avant la refactorisation
des modules de composants. L’implémentation de ces méthodes a été déplacée dans le module de
composants locaux.
L’interface RemoteDS contient les méthodes nécessaires pour répondre aux demandes de la straté-
gie de connexion et à la demande de connexion de composants.
Un RemoteDS peut dépendre de LocalDS pour avoir accès aux composants locaux.
connectTo service
ComponentsManager
ComponentsManager
stratégie de connexionmodules de composantsconnectToCommands
connectTo(arguments)réponse(...)
ConnectToCommand
DefaultConnectToCommand
execute()
ConnectToOneCommand
execute()
execute()
ConnectToFirstCommand
complète et continue la commande liée
Module de composants
répartis
Module de composants
répartis
Module de composants
répartis
Module de composants
répartis
*
réponse à la requète
complète et continue
Module de composantsrépartis
choisi le module composant qui va réaliser la connexion
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 14
Interface du module de composants locaux (LocalDS)(vus par le gestionnaire de composants (CM) et les modules de composants répartis)
Interface des modules de composants répartis (RemoteDS)(vue par le gestionnaire de composants (CM))
3. ConnectTo First et ConnectTo All
Dans la manière de connecter les composants, nous avons identifié trois façons de réaliser une con-nexion entre des composants. La connexion d’un composant à un composant, que nous savons faire
depuis le début dans SmartTools (que j’appelle ConnectToOne). Mais aussi deux autres manières de
connecter les composants, le connectToFirst et le connectToAll, qui n’ont pas besoin de savoir à
quelle instance de composant on cherche à se connecter, mais plutôt le type du composant.
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 15
Suivant les arguments dans la requête de connexion connectTo, nous pouvons faire deux types de
connexion d’un composant à un type de composant. Nous pouvons faire en sorte que le composant se connecte au premier composant du type donné, c’est le connectToFirst. Ou que le composant se
connecte à toutes les instances du type donné, c’est le connectToAll.
Chaque module de composants devrait être capable de traiter ces façons de connecter les compo-
sants : connectToOne, connectToFirst et connectToAll. Le connectToOne est obligatoire.
IX. Refactorisation du conteneur des composants
1. Structure du conteneur de composants
Un proxy de composant a la même fonctionnalité que conteneur du composant.
Cette propriété était mal modélisée dans les premières versions de SmartTools. Le conteneur modéli-
sait les relations avec les autres composants via l’interface ContainerProxy, donc le proxy. Or, le con-
teneur n’implémentait pas cette interface. Pour cela, lors de la création d’un composant, le conteneur
était encapsulé dans un objet de ContainerProxyImpl. Cela semblait inutile.
Structure originale posant un problème où Proxy est dissocié de conteneur
Le conteneur a donc été refactorisé pour que le conteneur implémente l’interface proxy, et SmartTools
n’a plus besoin d’encapsuler le conteneur dans un proxy.
De plus, ContainerProxy offrait toutes les fonctionnalités de Container, là où seulement le nom d’ins-
tance, la description du composant, et les méthodes de connexion et de déconnexion sont nécessai-
res. Mais ces besoins ont été identifiés lors de cette mission.
Container<<Interface>>
ContainerProxy<<Interface>>
ContainerContainerProxyImpl
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 16
Nouvelle structure où Container implémente Proxy
Dans la nouvelle structure, il n’est plus besoin de créer un objet proxy, car le conteneur joue ce rôle.
Cela ne change pas le modèle de connexion, qui modélise le fait qu’un composant est connecté à des proxies.
En plus, cela permet de faire une distinction entre un composant local avec un test, instance de Con-
tainer implémentant ContainerProxy, d’un composant réparti, implémentant ContainerProxy seule-
ment. Cette distinction a permis d’identifier les composants locaux pour l’envoi multicast.
ContainerProxy aComponent = ...;
if (aComponent instanceof Container) // alors c’est un composant local
La nouvelle interface ContainerProxy offre des méthodes pour avoir le nom du composant, sa des-
cription, la méthode de réception, la méthode de connexion et la méthode de déconnexion.
Container spécifie les autres méthodes qui décrivent la structure d’un vrai composant local.
2. Thread
La structure du conteneur commun (AbstractContainer) a été modifiée pour prendre en compte la
gestion du Thread en interne et de l’état du composant. Le Thread était lancé par le module de com-
posants locaux, et la référence vers celui-ci était perdue après le lancement du composant. Le fait de
donner la gestion de ce thread dans le conteneur de composant est plus propre.
3. Modèles de connexion
Le modèle de connexion a changé pour distinguer un envoi multicast (à tous les composants connec-
tés à un service de sortie) d'un envoi unicast (à un composant destinataire spécifié dans le message).
Le choix du mode se fait dans le message qui comporte un champ destinataire : s'il est non nul, le
mode unicast est choisi ; s'il est nul, le mode multicast est choisi.
Container<<Interface>>
ContainerProxy<<Interface>>
Container
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 17
Dans le cas unicast, on cherche à envoyer un message à un composant spécifié. Pour cela, le mo-
dèle connecte l'entrée d'un composant destinataire à la sortie de notre composant.
Dans le cas multicast, on cherche à envoyer un message à un ensemble de composants implémen-
tant le service spécifié (nom du message). Pour cela, le modèle connecte les services d'entrées d'un
composant aux services de sorties de notre composant. Il y a un seul appel d'envoi de message par
module de composants répartis et pour chaque service de sortie, plus les envois de messages pour
les composants locaux. Le but est de faire un seul appel d’envoi pour optimiser l'envoi de messages
sur le réseau.
1. Unicast
Le modèle de connexion unicast est géré par le conteneur. La méthode connect du conteneur per-
met la mise en place de cette connexion dans le modèle.
On cherche à connecter un composant à un autre composant, grâce à une Map<NomDuCompo-sant, ContainerProxy>.
2. Multicast
Le modèle de connexion multicast est modélisé dans le conteneur, pour les composants locaux, et
dans les modules de composants répartis (RemoteDS). Le conteneur modélise ces associations avec
une table de hachage Map<NomDuService, List<ContainerProxyLocal>> et une liste List<Remo-
teDS>.
Multicast en réparti
Lorsqu'un composant local s'exporte à travers un module de composants répartis alors le module de
composants s'ajoute dans la liste List<RemoteDS> du composant.
Lors d'un envoi multicast, tous les RemoteDS de cette liste se chargeront d'envoyer le message aux
composants connectés au service de sortie du composant source. Aux modules de composants de gérer la façon de connecter ce service.
Multicast en local
La méthode connect et disconnect fait la distinction d'un composant réparti et local grâce à "instan-
ceof Container" (Refactoring de la structure du conteneur, section IV.1). Dans le cas où le composant
est local, il fait un recoupement des services compatibles avec la table de hachage Map<NomDuSer-
vice, List<ContainerProxyLocal>>.
Ce modèle est celui utilisé dans la version 1.5.3 et avant. Il sera restreint seulement aux composants
locaux et au multicast.
En plus de la délégation d'envoi aux modules de composants répartis, le conteneur envoie le mes-
sage aux différents composants locaux connectés au service du message.
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 18
X. VirtPipesLes tuyaux virtuels sont des tuyaux de communication qui font abstraction de comment ils sont con-
nectés et comment sont envoyés les messages. Dans les tuyaux de communication, on peut distin-
guer classiquement les IPC (inter-process communication) et les RPC (remote-call procedure). Les IPC permettent des communications entre les processus (threads). Les RPC permettent des invoca-
tions de méthodes distantes. Nos tuyaux virtuels unifient ces deux concepts de manière uniforme.
Un tuyau est identifié par un numéro unique (UUID, 128 bits). La règle est que tous les tuyaux de
communication de sorties sont connectés virtuellement à tous les tuyaux d’entrées ayant le même
numéro unique. Les transmissions sont donc unicast par messages.
L’utilisation de cette abstraction par SmartTools est que chaque composant ouvre un tuyau unique
d’entrée et que tous les composants connectés en réparti à ce composant récupère le numéro du
tuyau d’entrée du composant et en créée un proxy.
Pour l’envoi de messages groupés (multicast), un tuyau virtuel de sortie est créé pour chaque service
de sortie du composant. Plusieurs tuyaux virtuels d’entrée iront écouter les messages multicast pro-venant d’un service spécifique (opération réalisée lors de la connexion répartie PON).
1. Concept des tuyaux virtuels
Le concept est similaire aux tuyaux de JXTA. Globalement, les tuyaux sont virtuellement connectés
par le framework, bien que rien ne laisse supposer qu'ils le sont réellement. Il n'y a aucune garantie
que le message atteigne sa (ses) destination(s), surtout dans le cas multicast, dans le cas en routage
et dans le cas où le tuyau ait été fermé avant ou pendant la transmission. Quelques travaux seraient
nécessaires pour pallier à ces problèmes, mais ma vision est que nous pouvons construire un frame-
work au-dessus de celui des tuyaux virtuels apportant cette fiabilité.
La propriété la plus importante est qu'il y a seulement une connexion TCP entre A et B et plusieurs
tuyaux tuyaux virtuels passent à travers ce tuyau de communication TCP entre la machine A et B.
2. Tests intensifs de Java NIO
Afin de montrer l’avantage de Java NIO, nous avons voulu vérifier qu’avec 1 seul Thread, Java NIO
est capable de gérer la communication d’un grand nombre de sockets TCP en charge de communi-
cation, grâce à un sélecteur, principe venant du système UNIX.
Nous avons tracé un graphe de l’état des tuyaux qui montre que Java NIO réparti bien la charge des
tuyaux. Dans cette expérimentation, nous ouvrons 1500 sockets (axe Y) TCP et envoyons dans cha-
que socket des messages le plus rapidement possible dans le temps (axe X). Un point rouge repré-
sentant un envoi et un point bleu représentant la réception, le tracé graphique de tous les points per-
met de se rendre compte que Java NIO distribue la charge imposée correctement.
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 19
Tracé des envois (rouges) et réceptions (bleus) en réseau local EthernetConclusion : distribution équilibrée des points et chaque tuyau communique
3. Utilisation de VirtPipes par SmartTools
Le principe est lors de la création d'un composant A, un tuyau virtuel est créé, qui permet de lire les messages adressés à ce composant. Plus précisément, pour les services en entrée de ce compo-
sant, les messages arriveront sur ce tuyau. Le nom du tuyau, un numéro unique, est publié sur un
overlay (DHT) avec le principe décrit dans VirtPipes.
Afin de retrouver ce numéro unique, j'associe le nom du composant avec le numéro du tuyau.
[Clé -> Valeur] : nom du composant -> UUID du tuyau virtuel
Lorsqu’un composant B est connecté à ce composant A, un proxy de B est créé sur la machine A.
Le module de composants répartis de A recherche le tuyau virtuel d'entrée de B avec le nom du composant. Le proxy va pouvoir écrire dans ce tuyau. Pour les services de sortie de A avec l'équiva-
lent en service d’entrée pour B, le proxy va écrire les messages (de sortie de A) pour être lu par B
avec ce tuyau virtuel.
Puis surtout, entre deux framework OSGi (machines), une seule connexion TCP est ouverte. Cette
connexion TCP va pouvoir supporter plusieurs communications (tuyau virtuel) entre les différents
composants des deux machines. Le proxy écrit dans un tuyau virtuel préalablement créé par le vrai
composant distant. Le module de composants PON crée pour chaque composant local un objet rea-
der qui lit les infos du VirtPipeInput. Comme expliqués après (Scénario), les tuyaux sont enregistrés
dans une DHT, et un composant distant est capable de récupérer les références de ce tuyau pour en
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 20
créer un proxy du composant. Pour faire une communication bidirectionnelle, l'opération de con-
nexion est effectuée dans les deux sens, comme SmartTools le fait déjà en local.
4. Utilisation des VirtPipes
Le VirtPipes module OSGi qui offre une abstraction de tuyaux de communication. Ce bundle dépend
de Open-Chord (une DHT) et doit être lancé au début.
La communication est basée sur Java NIO et TCP. Pour la couche utilisatrice de VirtPipes, 3 classes
sont importantes : VirtPipeInput, VirtPipeOutput et VirtPipesService.
Une instance de VirtPipesService est créée lors du lancement du bundle et est publiée en tant que
service OSGi. Ce service OSGi est utile pour enregistrer des VirtPipesInput.
Une instance de VirtPipeInput enregistré dans VirtPipesService, aura comme effet une écoute de
messages dans le tuyau identifié par virtPipeInput.getId().
Une instance de VirtPipeOutput doit avoir comme attribut VirtPipesService pour envoyer des mes-sages dans le tuyau virtuel identifié par virtPipeOutput.getId().
Voici un exemple pour un VirtPipeInput :
public class Activator implements BundleActivator {
public void start(BundleContext context) throws Exception { final ServiceReference ref = context.getServiceReference(VirtPipesService.class.getName()); VirtPipesService vps = (VirtPipesService) context.getService(ref); if (vps != null) { vps.registerVirtPipe(new VirtPipeInput() {
private UUID id = UUID.randomUUID();
public UUID getId() { return id; }
public void read(final ByteBuffer buffer) { System.out.println(new String(buffer.array())); } }}
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 21
Voici une exemple pour un VirtPipeOutput :
5. Structure
VirtPipeOutput est basé sur une mécanique uniforme Channels, qui propose de faire tourner l'en-
semble des SelectableChannels avec un thread. Cela est rendu possible grâce à Java NIO. Chan-nelsPool doit être le plus générique possible, et agnostique des frameworks qui l'utilisent. Pour cela
un pattern stratégie est utilisé. Deux stratégies abstraites sont proposées ServerSocketStrategy, qui
ne fait qu'accepter des clients, et SocketStrategy qui ne fait qu’envoyer et recevoir des données, fi-
naliser la connexion. Ces stratégies doivent être implémentées par les frameworks clients, tels que
VirtPipe.
VirtPipe est essentiellement constitué de VirtPipesService (VPS), qui a pour rôle de gérer les tuyaux
d'entrée, les connexions TCP vers les autres VPS, les données en attentes d'envoi ou de réception,
de dispatcher ou router les informations.
VirtPipeInput est important, car il est nécessaire pour la couche supérieure, qui veut lire des données
(être notifié de la réception d'un message).
VirtPipeOutput est, quant à lui, utilisé, mais n'est pas fondamentalement nécessaire. On peut envoyer
les messages directement avec VirtPipesService. Toutefois, VirtPipeOutput permet de récupérer les
exceptions à la couche supérieure.
Deux autres classes, qui ne sont pas représentées ici, SelectableVirtPipeInput et SelectableVirtPi-
peOutput, permettent de rendre les tuyaux virtuels respectivement InputStream et OutputStream.
Pour cela, un Java NIO Pipe va réaliser la glue du framework VirtPipes vers la couche utilisatrice. Les
demi-pipes gérées par VirtPipesService tournent dans le thread ChannelsPool, alors que les demi-
pipes de la couche utilisatrice vont pouvoir utiliser leurs propres threads. Cela permet d'utiliser Objec-
tInputStream et ObjectOutputStream avec des tuyaux virtuels.
public class Activator implements BundleActivator {
public void start(BundleContext context) throws Exception { final ServiceReference ref = context.getServiceReference(VirtPipesService.class.getName()); VirtPipesService vps = (VirtPipesService) context.getService(ref); new VirtPipeOutput(vps, uuid /* some way to get an Id */) {
public void error(Exception e) { e.printStackTrace(); }
public void virtPipeClosed() {}
}.send(ByteBuffer.wrap("Hello World".getBytes())); }}
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 22
6. Scénario
Dans cette section, je décris un petit scénario introduisant la transmission d'un message dans un tuyau virtuel unicast.
Vous pouvez voir qu'il y a deux notes 1 et 2 marquant 2 phases dans la réalisation de la connexion et
de l'envoi du message.
Avant ces deux notes, c'est l'instanciation des clients et des frameworks VirtPipes et Channels.
Instanciation et initialisation
Dans cette instanciation, il est important de noter que les VirtPipesServices (VPS) enregistrent leurs
coordonnées dans la DHT. Les coordonnées sont l'ensemble des adresses IP et le port, que possède
la ServerSocket gérée par le VPS. Les coordonnées du VPS sont enregistrées dans la DHT, indexées
par "ips:UUID-VPS", où UUID-VPS est l'identifiant logique du VPS. Un préfix "ips:" est ajouté à l'iden-
tifiant UUID du VPS (UUID-VPS) afin de distinguer cet enregistrement avec l'enregistrement d'un
VirtPipeInput (voir paragraphe suivant). Cette entrée permet donc de connecter les VPS entre eux, car ils ont leurs adresses IP publiées dans la DHT.
A chaque VirtPipeInput (VPI) enregistré dans un VPS, le VPS ajoute le VPI dans sa table de VPIs lo-
caux et enregistre une entrée dans la DHT :
UUID du VPI -> UUID du VPS
Par exemple, quand B ouvre son tuyau virtuel d'entrée (VPI-B), son VPS-B va enregistrer dans la DHT
cette entrée "UUID-VPI-B"->"UUID-VPS-B". Cette entrée permet donc d'identifier sur quels VPSs on
doit envoyer la donnée, pour qu’elle soit dispatchée aux VPIs correspondant à la clé.
Envoi d’une donnée de A vers B
Le client A veut envoyer une donnée au tuyau virtuel UUID-VPI-B. Pour cela il a un objet VirtPipeOut-
put (VPO) qui encapsule l'ID "UUID-VPI-B" du VPI-B distant et son VPS-A. Cet objet fait simplement
VPS-A.send et peut recevoir des exceptions du VPS-A. Lorsque le VPS doit envoyer une donnée, il crée un VirtPipeMessage ayant l'ID (UUID-VPI-B) et la donnée sous forme de ByteBuffer. La forme
envoyée dans le réseau est la suivante :
1 byte (type) + 128 bytes (UUID) + 16 bytes (size of ByteBuffer) + SIZE bytes (the ByteBuffer data)
Comme nous utilisons TCP, la transmission est garantie sur nous avons une connexion TCP au bon
VPS. (ordre et intégrité des paquets)
phase 1
Dans la phase notée 1, le VPS de A (VPS-A) n'est pas connecté au VPS de B (VPS-B), alors une
connexion doit être réalisée. Pour cela, VPS-A interroge la DHT avec la clé "ips:UUID-VPS-B" et rapa-
trie la liste des IPs et le port du VPS-B.
ips:UUID-VPS -> {”192.168.0.1”,”12.3.44.200”, ...},8080 (liste des adresses IP + port)
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 23
Alors VPS A va tenter de se connecter avec chaque IP tant qu'il arrive enfin à avoir une connexion. Si
ce n'était pas le cas, il faut chercher un autre VPS qui se chargera de router les messages vers VPS B. (Cette mécanique n'a pas été réalisée.) La donnée est mise en attente dans une FIFO et on
rend la main au programme principal.
phase 2
ChannelsPool reprend la main lorsque la connexion est réalisée (phase 2).
Juste après l'établissement de la connexion les VPS s'échangent leur ID à l'aide d'un message VirtPi-
peMessage avec un type INIT. Tous les autres messages destinés à des VPI ont un type NORMAL.
Enfin, il est possible d'envoyer la donnée au VPS-B. VPS B recevant un message, il recrée VirtPipe-
Message, utilise l'identifiant du VPI (UUID-VPI-B), retrouve le VPI dans sa table locale, et dispatche
l'information.
Attention, lorsque VPI est invoqué, c'est toujours le thread de ChannelsPool-B qui joue. Il vaut mieux
redonner la main au ChannelsPool tout de suite, pour qu'il puisse traiter la réception et l'émission des nombreux channels dont il a la charge.
XI. Sites web
1. Mirage
Pour notre organisation et documentation interne, j’ai mis en place un système Trac sur notre serveur
mirage. Cela a permis de partager les connaissances au sein de l’équipe grandissante et de débuter
une documentation interne. Un gestionnaire de références bibliographiques a aussi été mis en place.
Lien intranet : http://mirage/
2. PON
Nous avons créé un site web pour le projet PON, en plus du site web de SmartTools Eclipse. Cela
permet de bien faire une distinction entre ces deux réalisations, bien qu’ils soient liés par le cœur de
SmartTools. (http://www-sop.inria.fr/teams/lognet/pon &
http://www-sop.inria.fr/teams/lognet/SmartTools/eclipse/)
XII.Embarqué avec le Nokia N800Le cœur de SmartTools avec les modules de composants SimpleUDP et SimpleTCP ont été testé sur une plateforme mobile Nokia N800, une tablette Internet tournant sur un Linux mobile.
Le résultat de l’exécution est toutefois plutôt lent. De plus, OpenChord s’avère être trop lourd pour ce
type d’appareil et pose un problème pour PON. Il faudrait une DHT plus simple ou des postes plus
puissants pour jouer le rôle de proxy d’OpenChord.
XIII.GWTPour pouvoir commander des composants à distance, comme pour le Nokia N800, nous avons utili-
sé des interfaces web dernières génération nommée AJAX. Pour générer ces interfaces, nous utili-
sons Google Web Toolkit (GWT), qui permet de coder ces interfaces en Java.
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 24
Dans l’exemple du transport, l’interface utilise Google Maps pour éditer la zone géographique du
composant démarré.
Le Nokia N800 ne sait pas exécuter des interfaces Swing. Nous avons opté pour des interfaces GWT,
qui sont un remplaçant intéressant, car les interfaces se codent de manière similaire à Swing.
1. détails
Google Web Toolkit est un outil capable de compiler du code Java en Javascript. GWT offre un mo-
dèle de programmation d'interfaces graphiques AJAX en Java (à la Swing), et son compilateur trans-
forme cette programmation Java en interface AJAX (donc avec du Javascript, publié dans un dossier
war/APPLICATION, au lieu de bin/). L’avantage de GWT pour le développeur est d’éviter d’écrire di-
rectement du JavaScript, parfois moins fiable et moins rapide. Pour faciliter la communication de l'in-
terface client légère avec le serveur, GWT offre un modèle de communication type RPC, qui gère la
synchronisation des interfaces de communication du client et du serveur et la sérialisation des objets.
GWT est modulaire et la description des modules et des dépendances se fait dans un fichier XML. Un
projet se structure avec un package client et server, et un dossier public pour tous les documents qui
simplement copié dans le côté client. Le fichier XML est placé au même niveau que ces trois dossiers
client, server et public.
2. Intégration avec les composants
Les composants peuvent avoir une interface GWT pour contrôler le code métier. L'interface doit être
alors intégrée dans la façade.
Dans l'exemple du transport ou dans le chat, l'interface est publiée lors de la création du composant,
donc dans la façade. L'interface peut interagir avec le composant et inversement, par le biais de la
Servlet (le code GWT côté serveur). Un serveur est instancié sur chaque JVM (Nokia). Il sert les pages des composants créés localement sur le Nokia.
Pour publier l'interface GWT, la façade doit demander à l'activateur le BundleContext pour aller cher-
cher le HttpService. Une fois le HttpService trouvé, il faut enregistrer le dossier GWT généré dans
une URL disponible, et instancier la Servlet dans le nom que l'interface est capable de trouver (Voir
classe utilitaire ServiceUsage dans le code GWT client).
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 25
3. Utilisation
Depuis GWT 1.6, Google offre enfin une intégration avec Eclipse.
http://code.google.com/eclipse/
Les composants sont des projets GWT, il suffit de cliquer sur la boîte à outils rouge (logo de GWT)
pour compiler le projet GWT. Faire un refresh après compilation, c'est toujours prudent. Le dossier
war doit être un dossier source, pour que ce qui est compilé soit présent dans le build du composant.
Autour de cette technologie GWT, il existe de nombreux tutoriaux, documentations et participations,
dont la principale liste est sur notre serveur Mirage.
XIV.Exemples détaillés
1. Chat
Le Chat est un composant qui se connecte vers des composants du même type, pour échanger des
messages.
Le chat offre une interface Swing ou GWT. Chaque instance de composant possède sa propre inter-face graphique pour invoquer au bout du compte les services de composants. Cette interface pro-
pose un champ permet de connecter à un autre composant chat interactivement, un historique des
communications et un champ pour envoyer un message aux composants chat connectés.
final ServiceReference svc = context.getServiceReference(HttpService.class.getName());if (svc != null) { httpService = (HttpService) context.getService(svc); if (httpService != null) { // Register servlet try { final Dictionary<String, String> initparams = new Hashtable<String, String>(); initparams.put("name", "TransportClientService"); httpService.registerResources( "/inria.lognet.transport.client.TransportClient", "/inria.lognet.transport.client.TransportClient", null); httpService.registerServlet( "/inria.lognet.transport.client.TransportClient/TransportClientService", Activator.gwtService, initparams, null); } catch (final Exception e) { e.printStackTrace(); } }}
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 26
Interface GWT de Chat, disponible aussi en Swing
2. Chimiste
L’application du Chimiste a été la toute première application qui mettait en relation la SOA et l’Overlay Network.
Le Chimiste est un composant qui se connecte vers des composants du même type, pour échanger
des molécules.
Le chimiste résout des formules chimiques et recherche sur le réseau les molécules nécessaires qu’il
n’a pas en possession. Il va donc aller négocier avec un autre chimiste la molécule dont il a besoin.
Il n’y a pas d’interfaces dans cet exemple, seuls des traces dans la console sont utilisées.
Pour cet exemple, le composant chimiste a besoin de PiNet pour fonctionner. Un prototype de méta-
informations publiées dans une DHT, mieux présentées avec Transport.
3. Transport
L’exemple du transport permet une recherche des services non pas par un nom, mais par une posi-tion géographique. Cet exemple présente donc des services géoréférencés.
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 27
Manager qui offre la possibilité de créer une zone et de démarrer un service associé
Provider qui est le service géo-référencé. Ici on peut saisir son état.
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 28
Client qui offre la possibilité de chercher les services qui opère à une position donnée.Le client trouvera la liste des services et a la possibilité de se connecter à un service et acquérir l’état de ce dernier
Ceci concerne les bundles inria.lognet.transport.client & inria.lognet.transport.manager.
Ce sont des applications GWT ayant besoin d'Internet pour accéder à Google Maps.
Il existe trois composants, donc trois types d’interfaces : le manager, le service provider, et le client.
Le manager enregistre des polygones, représentant des services qui opèrent dans ces zones, dans
open-chord. Le client recherche les polygones proches de sa position à partir d'open-chord.
Le manager va éditer un polygone et identifier les clés dans lesquelles il va entrer son polygone. Les
clés sont construites avec la latitude et la longitude, tronquées au dixième (0.1, 0.2, etc).
Ces zones seront publiées dans l’Overlay Network Open-Chord.
La va leur enreg ist rée dans chaque c lé est constru i te de la manière su ivante
serviceinfo,point,point,point,...,point, où chaque point représente latitude;longitude non tronquée.
Le client est capable de reconstruire le polygone, d'affiche le service correspondant, et savoir s'il est
bien dans le polygone en fonction de sa position.
clé : latitude au dixième,longitude au dixième -> valeur : nom-du-service,liste des points...
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 29
Ainsi, un client récupère la liste des services autour de lui en lançant une requête dans l’Overlay
Network Open-Chord. Il a ainsi découvert une liste de services qui lui être peut être inconnu proche de lui. L’Overlay Network Open Chord offre une solution complètement décentralisée.
4. Plane
L’exemple des avions présente un exemple de service très concret avec un service gestionnaire, un
service guichet et un service modèle (base de données). Nous sommes capables d’empaqueter le
tout dans une application Eclipse, et de la scinder en plusieurs applications réparties.
Cet exemple démontre la capacité de SmartTools à produire des RCPs Eclipse en modèle SOA, de
découper une RCP locale en plusieurs RCPs connectés en réparti.
XV.ClusterL’idée de Cluster est de pouvoir faire des études de l’architecture de PON à plus grande échelle, par
exemple des tests avec GRID5000. Pour cela nous souhaitons pouvoir déployer des types de com-
posants et démarrer des instances de ces composants à distance.
1. Phase 0 : manager
Il faut au moins un manager ouvert.
2. Phase 1 : boot
Le bundle inria.lognet.cluster.boot est chargé de télécharger un Bundle à l'adresse spécifié avec la
propriété système inria.lognet.cluster.boot=http://mirage/inria.lognet.cluster.launcher_1.0.0.jar par
exemp le . L ' ad resse donnée peu t -ê t re s t a t i que ou dynam ique p rovenan t du
inria.lognet.cluster.manager.
Le JAR inria.lognet.cluster.launcher_1.0.0.jar sera téléchargé, installé et démarré par le boot, et le
boot s'éteint en toute fin.
La phase 1 peut être sautée si launcher est déjà installé dans l'Equinox.
3. Phase 2 : launcher
Le but de ce bundle est d'installer une série de bundles embarqués dans son JAR (en ressources). Il
va installer inria.lognet.cluster.client et ses dépendances (inria.lognet.virtpipes, open-chord et gwt).
Dans le cas d'open-chord, une propriété système lui permet de booter, et c'est hard-codé dans laun-
cher.
La phase 2 peut-être sautée si l'équinox a le client statiquement installé.
4. Phase 3 : client
Le client ouvre un tuyau virtuel d'entrée pour recevoir des communications de managers. Le client
recherche dans open-chord les managers ouverts et lui communique son tuyau virtuel. Le manager
enregistre le fait qu'un nouveau client est découvert, et informe les interfaces graphiques.
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 30
L'utilisateur derrière le manager sélectionne un client à partir de l'interface GWT. Certaines comman-
des s'activent, comme la possibilité de visionner les bundles du clients et leurs états, ou encore d'ins-taller un bundle à distance.
Toutes ces commandes offertes par le managers sont communiquées par le tuyau virtuel du client,
qui se charge de les exécuter.
A partir de là, il est possible de déployer et commande n'importe quelle architecture logicielle à dis-
tance.
Références
2 Rapports
• D-SOA (Hal INRIA) : rapport technique expliquant en détail le fonctionnement de SmartTools, les
modules de composants, la stratégie de choix dans le gestionnaire de composant, et les proxies
dans les modules de composants répartis.
• Rapport de travail de la première année (2007-2008) : intégration de SmartTools au-dessus d’Eclipse, découpage de SmartTools pour produire une version légère fonctionnant sur OSGi (sans
le support d’Eclipse)
2 Site Web
• http://www-sop.inria.fr/teams/lognet/pon
• http://www-sop.inria.fr/teams/lognet/SmartTools/eclipse/
INRIA Sophia Antipolis
Rapport d’activités sur SmartTools en 2008-2009 par Baptiste Boussemart 31
Top Related