• Les classes Java RMI (Remote Method Invocation), qui permet à deux classes localisées dans des entités physiques différentes de communiquer, et qui permet aussi d'assurer la sécurité de l'environnement distribué Jini.
• Le protocole de découverte (discovery process) et d'adhésion (join process) qui permet aux services de se faire connaître, de découvrir d'autres services et de créer des fédérations.
• Enfin le service de recherche (lookup service), qui est le recueil des services existants. Les nouveaux services s'enregistrent auprès du service de recherche. De même ils sont consultés lorsqu'un client recherche un service. Ils forment donc le mécanisme central de l'environnement Jini.

Ces trois formes sont combinées lors des trois processus majeurs de Jini: la découverte, l'adhésion, et la recherche.

• 2.1 Les principes de Java RMI
  Java Remote Method Invocation est à la base de la technologie Jini puisque c'est la brique logicielle permettant aux entités Java distantes de communiquer entre elles. C'est un mécanisme du type RPC (Remote Procedure Call), permettant de faire appel à une méthode d'une entité distante à travers une interface. Cependant Java RMI a l'avantage de fonctionner de Java à Java, ce qui permet de s'affranchir de certaines limites dues à la neutralité des RPC vis-à-vis du langage de programmation.
  
  

  Ainsi Java RMI permet de passer en arguments des objets entiers et non plus uniquement des types de donnée prédéfinis. RMI peut aussi fournir des fonctions de sécurité, comme des sockets cryptées par exemple. Le mode de fonctionnement est très simple : le fournisseur de service exporte un type de référence. Lorsque le client reçoit cette référence, RMI charge un stub qui transcrit les appels à cette référence en un appel au fournisseur. Ce processus de marshalling utilise la mise en série (serialization) des objets. Du côté du serveur, un squelette (skeleton) effectue l'unmarshalling et invoque la méthode adéquate du serveur (voir Figure 1).
  Ce type de comportement est tout à fait similaire à celui des environnements CORBA.

  Figure 1 : Rôles des stubs et des squelettes
  
  
• 2.2 Le processus de découverte (discovery process)
  Ce processus fonctionne d'une façon assez simple : lorsqu'un périphérique ou un quelconque fournisseur de service se connecte au réseau, il diffuse une "annonce de présence" (presence announcement) en envoyant un paquet multicast sur un port dont le numéro est convenu préalablement et connu de tous. Il s'agit du port 4160 qui, pour la petite histoire, correspond à la valeur décimale de la soustraction en hexadécimal de CAFE par BABE: CAFE-BABE=0x1040.
  A l'intérieur de ce paquet, on trouve:
  • L'adresse IP et le numéro de port où l’on peut joindre le périphérique
  • Une liste de noms de groupes auquel le périphérique souhaite adhérer.

  Les services de recherche (lookup service) surveillent ce numéro de port dans l'attente d'éventuels "annonces de présence". Lorsqu'ils reçoivent de tels messages, ils inspectent la liste des noms de groupe. Dans le cas où le service maintient un des groupes cités, il contacte l'expéditeur du paquet directement en utilisant son adresse IP et le numéro de port déclaré. Il lui envoie alors un stub RMI qui permettra au périphérique d'interagir avec le service de recherche. Ainsi à travers cette interface, le périphérique peut s'enregistrer auprès du service grâce au processus d'adhésion.

  Figure 2 : le processus de découverte
  
  
• 2.3 Le processus d'adhésion (join process)
  Une fois que le périphérique a découvert un service de recherche, il peut enregistrer ses propres services à travers le processus d'adhésion. En utilisant le stub RMI reçu lors de la découverte, le périphérique envoie des informations sur le service qu'il propose au service de recherche. Celui-ci enregistre ces informations et inscrit le service dans le groupe demandé. Le service a alors adhéré au groupe sur le service de recherche considéré. Un service donné peut ainsi adhérer à des groupes tenus par des services de recherche différents.

  L'information envoyée au service de recherche comprend :

  • Une instance d'une classe qui implémente l'interface du service, qui permet d'utiliser les services proposés. Ceci inclut notamment les déclarations des méthodes pouvant être utilisées.
  • De façon optionnelle, des attributs du service peuvent aussi être envoyés. Cela peut prendre la forme, par exemple, d'une applet permettant d'interagir directement avec le service à travers une interface graphique.
  Figure 3: processus d'adhésion

  Le service est alors prêt à être recherché et utilisé par un client. Il faut noter que le service est identifié par le type de cette interface. Le service de recherche repère les services grâce au type de cette interface. Les clients interagissent avec le service en invoquant les méthodes déclarées. C'est donc une pièce extrêmement importante du système Jini.

  
  
• 2.4 Le processus de recherche de service (lookup process)
  Une fois que le service a adhéré à au moins un groupe, il est disponible et les clients qui en font la requête auprès du service de recherche peuvent l'utiliser. C'est la grande innovation proclamée par Sun du " Plug and Play universel ". Pour construire une fédération de services qui travailleront ensemble à une tâche donnée, le client doit localiser et engager chaque service individuellement. Le processus de découverte est ainsi utilisé par le client pour trouver un service.

  Au début de ce processus, le client contacte le service de recherche en utilisant une méthode du stub RMI reçu lors du processus de découverte et requiert des services d'un type donné. Le type est en fait une interface Java qui définit la façon d'interagir avec service. Cela correspond donc à l'interface de service enregistrée lors du processus d'adhésion. Le service de recherche retourne (en fait en valeur de retour de la méthode invoquée) alors de zéro à plusieurs objets qui correspondent au type demandé. Grâce à ces objets, qui sont en fait une instance de l'interface du service, le client peut interagir directement avec le fournisseur de service. Ceci peut se faire en invoquant les méthodes déclarées dans l'interface.

  Figure 4: Processus de recherche
  
  
• 2.5 L'interaction client service
  L'interface du service peut donner accès au service de plusieurs façons : ainsi, l'interface peut représenter le service entièrement, et dans ce cas, le service lui-même est transmis au client lors du processus de recherche et est ensuite exécuté en local par le client. Cette option est assimilable à un téléchargement du service et n'est donc pas un excellent exemple d'environnement distribué.

  Mais l'interface peut aussi n'être qu'un recueil de déclarations de méthodes, ce qui fait que l'interface se comporte comme un proxy. Lorsque le client invoque une méthode, l'interface fait suivre la demande par marshalling / unmarshalling et le fournisseur du service exécute l'instruction. Cette approche est beaucoup plus proche de l'esprit des systèmes distribués et correspond à la méthode utilisée dans CORBA par exemple.

  Enfin il existe une approche intermédiaire. Elle consiste à faire exécuter une partie du service en local et une partie par le fournisseur. Les proxies qui utilisent cette approche sont appelés des proxy intelligents (smart proxy).

  Il faut noter que le protocole utilisé entre le proxy et le service distant ne doit pas nécessairement pouvoir être compris par le client. C'est le service qui décide de ce protocole et la communication est possible car le service a placé dans le proxy une partie de son propre code. Cette partie de code peut être un stub RMI, ce qui est l'approche recommandée par Jini, ou alors ce code peut adopter des protocoles CORBA, IIOP par exemple. L'important en fait est que cet aspect reste totalement transparent pour le client.