Présentation de JNDI, Partie 1: Une introduction aux services de dénomination

Ceux d'entre vous qui ont été dans une bibliothèque et qui se souviennent encore de l'expérience peuvent se rappeler le processus de localisation d'un livre de bibliothèque. Si vous n'êtes pas en contact avec votre côté antiquaire, cette situation vous semblera inconnue; mais de temps en temps, je me promène dans une bibliothèque locale à la recherche d'un livre authentique et hors ligne. Les bibliothèques sont remplies de milliers de choses - elles sont poussiéreuses et faites de pâte de bois et de peau de vache, mais elles sont fascinantes à leur manière. Dans tous les cas, lorsque la contrainte de trouver un certain me frappe, j'évite le cours naïf de marcher dans les allées de la bibliothèque à sa recherche et je me tourne plutôt vers le catalogue sur fiches.

TEXTBOX: TEXTBOX_HEAD: Aperçu JNDI: Lisez toute la série!

  • Partie 1. Une introduction aux services de dénomination
  • Partie 2. Utilisez les services d'annuaire JNDI pour mieux gérer vos applications distribuées

  • Partie 3. Utilisez JNDI pour stocker les objets de votre application distribuée

  • Partie 4. Rassemblez ce que vous avez appris avec une application compatible JNDI: END_TEXTBOX

Un catalogue sur fiches, pour les non-initiés, fait correspondre les noms des livres à leur emplacement dans la bibliothèque. En accédant d'abord au catalogue sur fiches et en recherchant l'emplacement du livre, je m'économise beaucoup de marche. (Soit dit en passant, j'ai entendu dire que certaines bibliothèques permettent en fait aux utilisateurs d'utiliser des ordinateurs au lieu du catalogue sur fiches. Ils en ont la moitié - maintenant s'ils veulent simplement mettre les informations contenues dans les livres dans l'ordinateur auquel elles appartiennent. ..)

Aussi surprenant que cela puisse paraître, la notion de catalogue sur fiches est également très pratique dans le monde de l'informatique. En informatique, nous l'appelons un service de dénomination, qui associe les noms aux emplacements des services et aux informations. Il fournit aux programmes informatiques un emplacement unique où ils peuvent trouver les ressources dont ils ont besoin. En passant, les programmes ne perdent pas de temps en effectuant l'équivalent électronique de marcher dans les allées et n'exigent pas non plus que les emplacements soient codés en dur dans leur logique.

La recherche de ressources est particulièrement importante dans les environnements d'entreprise à grande échelle, où les applications que vous créez peuvent dépendre des services fournis par des applications écrites par d'autres groupes dans d'autres départements. Une infrastructure de dénomination bien conçue rend de tels projets possibles - et son absence les rend impossibles. En fait, de nombreux efforts de réingénierie des processus métier commencent par la conception et la mise en œuvre d'une infrastructure de dénomination et d'annuaire robuste à l'échelle de l'entreprise.

Ce mois-ci, je présente l'interface de nommage et d'annuaire Java (JNDI). JNDI fournit une interface de dénominateur commun à de nombreux services de dénomination existants. En tant que tel, JNDI n'a pas été conçu pour remplacer la technologie existante; à la place, il fournit une interface commune aux services de dénomination existants. Commençons par jeter un œil à certains de ces services.

Une introduction aux services de nommage

La figure ci-dessous illustre l'organisation d'un service de dénomination générique.

Un service de dénomination gère un ensemble de liaisons. Les liaisons relient les noms aux objets. Tous les objets d'un système de dénomination sont nommés de la même manière (c'est-à-dire qu'ils souscrivent à la même convention de dénomination ). Les clients utilisent le service de dénomination pour localiser les objets par nom.

Il existe un certain nombre de services de dénomination existants, dont quelques-uns seront décrits ci-dessous. Ils suivent chacun le modèle ci-dessus, mais diffèrent dans les détails.

  • Dénomination COS (Common Object Services): le service de dénomination des applications CORBA; permet aux applications de stocker et d'accéder aux références aux objets CORBA.

  • DNS (Domain Name System): le service de nommage d'Internet; mappe les noms conviviaux (tels que www.etcee.com) en adresses IP (Internet Protocol) conviviales pour les ordinateurs en notation quadrillée (207.69.175.36). Fait intéressant, DNS est un service de dénomination distribué , ce qui signifie que le service et sa base de données sous-jacente sont répartis sur de nombreux hôtes sur Internet.

  • LDAP (Lightweight Directory Access Protocol): Développé par l'Université du Michigan; comme son nom l'indique, il s'agit d'une version allégée de DAP (Directory Access Protocol), qui à son tour fait partie de X.500, une norme pour les services d'annuaire réseau. Actuellement, plus de 40 entreprises approuvent LDAP.

  • NIS (Network Information System) et NIS +: services de nommage de réseau développés par Sun Microsystems. Les deux permettent aux utilisateurs d'accéder aux fichiers et aux applications sur n'importe quel hôte avec un seul ID et mot de passe.

Caractéristiques communes

Comme je l'ai mentionné plus tôt, la fonction principale d'un système de dénomination est de lier les noms à des objets (ou, dans certains cas, à des références à des objets - plus sur lesquels dans un instant). Pour être un service de nommage, un service doit au minimum fournir la possibilité de lier des noms à des objets et de rechercher des objets par nom.

De nombreux systèmes de dénomination ne stockent pas directement les objets. Au lieu de cela, ils stockent des références aux objets. À titre d'illustration, considérons DNS. L'adresse 207.69.175.36 est une référence à l'emplacement d'un ordinateur sur Internet, et non à l'ordinateur lui-même.

JNDI fournit une interface qui prend en charge toutes ces fonctionnalités communes. Je présenterai cette interface plus loin dans cet article.

Leurs différences

Il est également important de comprendre en quoi les services de dénomination existants diffèrent, car JNDI doit fournir une abstraction réalisable qui contourne ces différences.

Outre les différences fonctionnelles, la différence la plus notable est la façon dont chaque service de dénomination requiert la spécification des noms - sa convention de dénomination. Quelques exemples devraient illustrer le problème.

Dans DNS, les noms sont construits à partir de composants séparés par des points ("."). Ils lisent de droite à gauche. Le nom «www.etcee.com» désigne une machine appelée «www» dans le domaine «etcee.com». De même, le nom «etcee.com» nomme le domaine «etcee» dans le domaine de premier niveau «com».

En LDAP, la situation est légèrement plus compliquée. Les noms sont construits à partir de composants séparés par des virgules (","). Comme les noms DNS, ils lisent de droite à gauche. Cependant, les composants d'un nom LDAP doivent être spécifiés sous forme de paires nom / valeur. Le nom "cn = Todd Sundsted, o = ComFrame, c = US" désigne la personne "cn = Todd Sundsted" dans l'organisation "o = ComFrame, c = US". De même, le nom «o = ComFrame, c = US» nomme l'organisation «o = ComFrame» dans le pays «c = US».

Comme l'illustrent les exemples ci-dessus, la convention de dénomination d'un service de dénomination à elle seule a le potentiel d'introduire une part importante de la saveur du service de dénomination sous-jacent dans JNDI. Ce n'est pas une fonctionnalité qu'une interface indépendante de l'implémentation devrait avoir.

JNDI résout ce problème avec la Nameclasse et ses sous-classes et classes d'assistance. La Nameclasse représente un nom composé de séquences ordonnées de sous-noms et fournit des méthodes pour travailler avec des noms indépendants du service de dénomination sous-jacent.

Un regard sur la dénomination JNDI

Comme je l'ai mentionné ci-dessus, il est important de se rappeler que JNDI est une interface plutôt qu'une implémentation. Ce fait présente certains inconvénients - vous devez accéder à un service de dénomination existant (tel qu'un service LDAP) et vous devez comprendre quelque chose sur son fonctionnement pour pouvoir jouer avec JNDI. D'un autre côté, cela permet à JNDI de s'intégrer de manière transparente dans un environnement informatique existant où un service de dénomination établi domine.

La dénomination JNDI s'articule autour d'un petit ensemble de classes et d'une poignée d'opérations. Jetons un coup d'œil à eux.

Contexte et InitialContext

L' Contextinterface joue un rôle central dans JNDI. Un contexte représente un ensemble de liaisons au sein d'un service de dénomination qui partagent toutes la même convention de dénomination. Un Contextobjet fournit les méthodes pour lier les noms aux objets et dissocier les noms des objets, pour renommer les objets et pour répertorier les liaisons.

Certains services de dénomination fournissent également des fonctionnalités de sous-contexte. Tout comme un répertoire dans un système de fichiers, un sous-contexte est un contexte dans un contexte. Cette structure hiérarchique permet une meilleure organisation des informations. Pour les services de dénomination prenant en charge les sous-contextes, la Contextclasse fournit également des méthodes de création et de destruction de sous-contextes.

JNDI effectue toutes les opérations de dénomination relatives à un contexte. Pour vous aider à trouver un point de départ, la spécification JNDI définit une InitialContextclasse. Cette classe est instanciée avec des propriétés qui définissent le type de service de dénomination utilisé et, pour les services de dénomination assurant la sécurité, l'ID et le mot de passe à utiliser lors de la connexion.

Pour ceux d'entre vous familiarisés avec la Namingclasse RMI , la plupart des méthodes fournies par l' Contextinterface décrite ci-dessous vous sembleront familières. Jetons un coup d'œil aux Contextméthodes de:

  • void bind(String stringName, Object object): Lie un nom à un objet. Le nom ne doit pas être lié à un autre objet. Tous les contextes intermédiaires doivent déjà exister.

  • void rebind(String stringName, Object object): Lie un nom à un objet. Tous les contextes intermédiaires doivent déjà exister.

  • Object lookup(String stringName): Renvoie l'objet spécifié.

  • void unbind(String stringName): Annule la liaison de l'objet spécifié.

L' Contextinterface fournit également des méthodes pour renommer et répertorier les liaisons.

  • void rename(String stringOldName, String stringNewName): Modifie le nom auquel un objet est lié.
  • NamingEnumeration listBindings(String stringName): Renvoie une énumération contenant les noms liés au contexte spécifié, ainsi que les objets et les noms de classe des objets qui leur sont liés.

  • NamingEnumeration list(String stringName): Renvoie une énumération contenant les noms liés au contexte spécifié, ainsi que les noms de classe des objets qui leur sont liés.

Chacune de ces méthodes a un frère qui prend un Nameobjet au lieu d'un Stringobjet. Un Nameobjet représente un nom générique. La Nameclasse permet à un programme de manipuler les noms sans avoir à en savoir autant sur le service de dénomination spécifique utilisé.

L'exemple

L'exemple ci-dessous illustre comment se connecter à un service de nommage, répertorier toutes les liaisons ou répertorier une liaison spécifique. Il utilise le fournisseur de services de système de fichiers, qui est l'une des implémentations de fournisseur de services JNDI de référence fournies par Sun. Le fournisseur de service du système de fichiers fait ressembler le système de fichiers à un service de dénomination (ce qu'il est, à bien des égards - les noms de fichiers tels que des /foo/bar/baznoms et sont liés à des objets tels que des fichiers et des répertoires). Je l'ai sélectionné parce que tout le monde a accès à un système de fichiers (par opposition, par exemple, à un serveur LDAP).

import javax.naming.Context; import javax.naming.InitialContext; import javax.naming.Binding; import javax.naming.NamingEnumeration; import javax.naming.NamingException; import java.util.Hashtable; public class Main { public static void main(String [] rgstring) { try { // Create the initial context. The environment // information specifies the JNDI provider to use // and the initial URL to use (in our case, a // directory in URL form -- file:///...). Hashtable hashtableEnvironment = new Hashtable(); hashtableEnvironment.put( Context.INITIAL_CONTEXT_FACTORY, "com.sun.jndi.fscontext.RefFSContextFactory" ); hashtableEnvironment.put( Context.PROVIDER_URL, rgstring[0] ); Context context = new InitialContext(hashtableEnvironment); // If you provide no other command line arguments, // list all of the names in the specified context and // the objects they are bound to. if (rgstring.length == 1) { NamingEnumeration namingenumeration = context.listBindings(""); while (namingenumeration.hasMore()) { Binding binding = (Binding)namingenumeration.next(); System.out.println( binding.getName() + " " + binding.getObject() ); } } // Otherwise, list the names and bindings for the // specified arguments. else { for (int i = 1; i < rgstring.length; i++) { Object object = context.lookup(rgstring[i]); System.out.println( rgstring[i] + " " + object ); } } context.close(); } catch (NamingException namingexception) { namingexception.printStackTrace(); } } } 

The program in the listing above first creates an initial context from the specified JNDI provider (in this case, Sun's filesystem provider) and a URL specifying a local directory. If no additional command-line arguments are specified, the program lists the objects and names of every entity in the specified directory. Otherwise, it lists the objects and names of only those items specified on the command line.

Conclusion

You should now have both an understanding of and an appreciation for naming services in general and JNDI in particular. In distributed environments, they are valuable tools for locating information and resources. JNDI makes it possible to work with a variety of naming services without having to master a multitude of APIs. Next month, we'll take a look at the other half of JNDI -- its directory functions.

Todd Sundsted a écrit des programmes depuis que les ordinateurs sont devenus disponibles dans des modèles de bureau pratiques. Bien qu'à l'origine intéressé par la création d'applications distribuées en C ++, Todd est passé au langage de programmation Java quand il est devenu le choix évident pour ce genre de chose. En plus de l'écriture, Todd travaille également en tant qu'architecte Java avec ComFrame Software.

En savoir plus sur ce sujet

  • Téléchargez le code source complet de cet article, au format zip

    //images.techhive.com/downloads/idge/imported/article/jvw/2000/01/jw-01-howto.zip

  • Toutes choses JNDI

    //java.sun.com/products/jndi/

  • Documentation JNDI

    //java.sun.com/products/jndi/docs.html

  • Fournisseurs de services actuellement disponibles

    //java.sun.com/products/jndi/serviceproviders.html

  • Liste complète des colonnes Java How-To précédentes

    //www.javaworld.com/javaworld/topicalindex/jw-ti-howto.html

Cette histoire, "Vue d'ensemble de JNDI, Partie 1: Une introduction aux services de nommage" a été initialement publiée par JavaWorld.