Rapport d’activités sur SmartTools en 2008-2009 par

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

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-



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



1 http://r-osgi.sourceforge.net

http://r-osgi.sourceforge.net

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


0011100101110110

110110111101



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



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


VirtPipes

DHT (Open-Chord) DHT (Open-Chord)

VirtPipes

VirtPipes Service

CDML + nom du composant

Réseau


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



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 ...

...



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).



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



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.



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.



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.



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


répartis


répartis


répartis

*

cherche un composant

délègue la connexion à tous lescomposants du type donné

cherche le 1er composant du type donné



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


répartis


répartis


répartis


répartis

*

réponse à la requète

complète et continue


choisi le module composant qui va réaliser la connexion



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.



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



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



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.



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.



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



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())); } }}



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())); }}



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)



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.





http://www-sop.inria.fr/teams/lognet/SmartTools/eclipse/


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).



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(); } }}





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.



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.



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...



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.



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/







Documents

Rapport d’activités sur SmartTools en 2008-2009 par