Conception et réalisation d'un syst`eme d'instrumentation ... - CoDE

2.2. ARCHITECTURE
Nous verrons que ceci n’est pas du tout le cas de RMI, et donc de Jini, car un mécanisme
supplémentaire, appelé code mobile, permet la mise en commun des classes entre le client
et le serveur, y compris celles qui ne sont connus que par un de deux protagonistes. Dans
ce cas, l’envoi d’une sous-classe permettra de récupérer un membre de cette sous-classe en
bout de marshallisation même si à l’origine seule la super-classe est connue du serveur.
2.2.4 Les Objets standards
L’OMG a spécifié un ensemble d’objets standardisés à même d’être déployés sur le bus
CORBA de manière à offrir des services spécifiques à de nombreux scénarios d’utilisation.
Il s’agit d’abstractions aux fonctions systèmes de base, telles que la dénomination (Naming
Service), la persistance des objets, le cycle de vie, la sécurité, la gestion des licences d’utilisation
des objets,les événements, etc. L’ensemble formé de ces services ne sont pas toujours
implémentes de manière complète par les ORB disponibles actuellement. Dans le cadre de
la réalisation de réseaux de terrains et d’instrumentation distribuée, seuls trois services importants
sont à même de remplir des fonctionnalités clés dans les processus d’interaction
et de coopération intervenant entre les appareils d’une part et les clients logiciels d’autre
part. Il s’agit des Naming Service, Trader Service et Event Service.
Le Naming Service
Ce service fournit un système de désignation permettant d’obtenir les références des
objets répondant à un nom d’enregistrement donné. Les noms sont structurés selon un
graphe de contextes de dénominations interconnectées, permettant ainsi la création d’un
espace de nom réparti et éventuellement fort vaste. A l’intérieur de chaque contexte, chaque
nom symbolique doit être unique, mais un même objet peut utiliser plusieurs noms. Ceci
permet aux objets de s’enregistrer multiplement : sur base de noms différents ou dans des
contextes différents. Ce mécanisme est en réalité assez pauvre dans un cadre dynamique,
car un nom seul ne peut refléter les capacités des objets et rien ne précise si un objet se
présentant sous un nom donné est susceptible d’implanter une interface recherchée.
Le Trader Service
Le Trader Service présente un mécanisme plus puissant et plus exploitable que le Naming
Service. Les serveurs s’y enregistrent en détaillant l’ensemble des propriétés qui les
caractérisent, sous forme d’un ensemble d’associations clef-valeur, ainsi qu’en fournissant
l’interface IDL qu’ils implantent. Les clients utilisent ce service en indiquant le type d’interface
recherchée et des critères annexes : type des objets arguments, nombre d’arguments,etc.
Le Trader Service résout les requêtes en parcourant l’ensemble du référentiel
des enregistrements qu’il a collectés. Le client ayant obtenu ainsi l’ensemble des références
des objets qu’il désire utiliser, la transaction peut commencer avec le serveur, par exemple
en exploitant la Dynamic Invocation Interface.
27