Réalisé par Rémi Julien et
Mathieu Weill
- 0 Index
- 1 Introduction
- 2 L'infrastructure d'un système Jini
- 3 Le modèle de programmation Jini
- 4 Architecture matérielle
- 4.1 Principe
L’infrastructure Jini est centrée sur le modèle de clients requérant des
services. La notion de services englobe l’accès à certaines ressources
logicielles et matérielles, et plus généralement tout moyen permettant à un
utilisateur d’atteindre un certain but.
Au sein d’une fédération Jini, un service est représenté par différentes
instances d’objets, dans le service de recherche (lookup) par
exemple. La communication entre ces objets et le service proprement dit (son
implémentation matérielle), et donc l’intégration du service à une
fédération Jini (aussi appelée un djinn) implique l’existence d’une
machine virtuelle Java (JVM) à l’interface entre service et réseau.
Différentes architectures permettant l’intégration de dispositifs matériels
sont proposées par les spécifications de Sun Microsystems.
Dans la suite de l’exposé, à titre d’exemple, nous allons considérer
l’intégration d’une cafetière " nouvelle génération " à une
fédération Jini.
- 4.2 Machine virtuelle Java individuelle
La méthode la plus directe pour intégrer simplement une cafetière au
djinn est de la doter d’un microprocesseur, de mémoire vive, de
capacité de stockage, bref d’une machine virtuelle Java. Il n’est bien sûr
pas nécessaire que cette JVM soit complète : la cafetière se passera
très bien des classes graphiques... Les fonctionnalités requises d’une telle
JVM " allégée " sont la capacité de télécharger du code (en fait
tout ce qui a trait aux fonctions réseau et sécurité) et de traiter les
classes des packages spécifiques à Jini. Le contenu exact d’une JVM
light n’a pas été spécifié par les concepteurs de Jini.
Cette approche présente, malgré ou en raison de sa simplicité, un défaut
majeur : le coût de la cafetière est largement accru par l’addition de
la machine virtuelle Java, même dans sa version allégée. En revanche, la
flexibilité offerte par la machine virtuelle permet une évolution très
simple des fonctionnalités offertes par le service : il suffit au
constructeur de fournir une nouvelle version du code Java représentant le
service, sans avoir besoin de recourir à une modification matérielle plus
coûteuse.
- 4.3 Machine virtuelle spécialisée
Notre cafetière peut voir son coût de production baisser si son
constructeur renonce à la doter d’une véritable JVM ou d’une JVM allégée, et
en remplaçant celle-ci par une machine virtuelle spécialisée qui implémente
de façon propriétaire les interfaces avec les services constitutifs Jini
(lookup, discovery/join, etc.). En échange de cette réduction
des coûts, on perd un peu de la flexibilité offerte par la solution
" 100% pur Java " précédente : une évolution du service
offert par la cafetière (par exemple un cappuccino) implique de concevoir
une nouvelle machine spécialisée, plutôt qu’une classe Java
Cappucino, qui hérite de la classe BoissonChaude.
- 4.4 Machine virtuelle Java partagée
Toujours dans une optique de réduction des coûts, on peut mettre en place
une machine virtuelle Java complète, partagée entre un ensemble de
dispositifs. La communication entre les dispositifs et la JVM est laissée à
la discrétion du constructeur (protocoles propriétaires). Dans notre cas, la
cafetière pourrait partager avec le four à micro-ondes, le lave-vaisselle et
le mixer une JVM " de cuisine ", faisant office de proxy au sein
de la fédération Jini.
La baisse de coût induite est notable, mais implique une plus grande
complexité de la gestion des communications entre le proxy et les appareils.
Le protocole doit être défini à l’avance et ne peut guère évoluer avec
autant de souplesse que dans les solutions précédentes.
- 4.5 Jini et Internet Inter-Operability Protocol
Jini peut intégrer des services fondés sur une architecture CORBA à l’aide
du protocole IIOP, implémenté dans le package Java RMI (Remote Method
Invocation).
Si la cafetière contient un ORB (Object Request Broker) CORBA, elle
peut directement interagir avec le service de recherche Jini, via le protocole
IIOP. Le fait que le service de recherche génère ses flux IIOP via RMI est
transparent pour le service, et réciproquement le fait que le service
n’implémente pas RMI (par exemple pour les questions de leasing) l’est
pour le service de recherche.
La cafetière peut également ne pas intégrer d’ORB, mais interpréter
directement le flux IIOP et tenter d’interagir avec le service de recherche.
Dans ce cas, l’implémentation réside de manière très étroite sur la
spécification, et sa compatibilité avec les versions futures de Jini n’est pas
garantie, notamment en ce qui concerne le service d’allocation de ressources
(leasing).
- 5 Forces et faiblesses de Jini
|
