Jini

Jini est sorti en 1999, et à l’époque, il devançait son temps. Mais il connaît actuellement un regain d’intérêt à cause de la mode du SOA.Jini est en gros un système de mise-à-disposition et de découverte dynamique de services, fortement axé sur la mobilité. Son objectif est de permettre de coordonner facilement fournisseurs et consommateurs des à travers un réseau qui n’est pas toujours fiable, pas toujours rapide, pas toujours sécurisé, et dont les différents noeuds sont susceptibles de devenir indisponibles d’un moment à un autre.[Suite:]La structure est la suivante: il y a sur le réseau un ou plusieurs services de recherche (LookupServices), qui s’occupent de répertorier les services. Quand un nouveau service devient disponible, il commence par faire un broadcast UDP pour trouver un Lookup. S’il en trouve un, il s’y enregistre, en lui passant un petit objet Java (appelé un proxy) qui devra être exécuté côté client pour effectuer le service. Il indique également la durée de son « contrat » (Lease) auprès du Lookup, ce qui permet au Lookup de nettoyer sa liste de services dès que l’un d’eux ne renouvelle pas son contrat dans le délai convenu.Lorsqu’un client se connecte au réseau, il fait également un broadcast UDP, et s’il trouve un Lookup, il peut récupérer la liste de services que celui-ci propose. Ensuite, il télécharge l’objet proxy du service, et il l’instancie (ce qui pose naturellement bon nombre de problème du point de vue de la sécurité, que l’on doit résoudre en utilisant un SecurityManager, etc). C’est cette instance de l’objet proxy du service qui s’occupe de faire le travail d’interaction avec le service, sans que le client ait à se soucier du détail d’implémentation de celui-ci, ni même de protocole utilisé.Que tirer de cette session pour nous? Eh bien, Jini semble être très bien conçu, mais son architecture ne semble pas adaptée au genre d’utilisation que nous pourrions être susceptibles d’en faire à notre échelle. Comme bon nombre d’autres frameworks, il semble être conçu pour résoudre des problèmes qui ne se posent vraiment de très sérieusement quand on n’a qu’une dixaine ou une vingtaine de postes. Il me semble que Jini ajoute une complexité épouvantable au monde des WebServices et des appels de procédure distant. Pour de très grands systèmes, cette structuration serait sans-doute bienvenue, puisqu’elle permettrait une plus grande flexibilité, mais pour des projets plus modestes, elle risquerait fort d’être étouffante. Autrement dit, s’il est facile de faire des choses avancées, il faut s’attendre à ce qu’il soit pénible et lourd de faire des choses simples…Pour information, une référence intéressante de Jini est la compagnie de voyages Orbitz, qui utilise Jini pour coordonner quelque 10000 serveurs Linux, et proposer à leurs partenaires / fournisseurs / clients des services évoluant sans cesse. Jini leur permet de centraliser toute la gestion de leurs services, tout en offrant, en fonction du besoin, la couche basse en WS, CORBA, SOAP, etc.Jini va bientôt être (ou peut-être l’est-il déjà) open-sourcé selon une licence Apache, et donné à la fondation Apache. Il se trouve actuellement ici: http://www.jini.org http://jini.dev.java.netOn peut également accéder au site de l’intervenant qui a présent cette session ici:http://jan.netcomp.monash.edu.au/