Quel est le but de JNDI

Comment pouvez-vous réaliser l'utilisation de JNDI, avec un exemple si possible?

JNDI est l'interface de nommage et d'annuaire Java. Il est utilisé pour séparer les préoccupations de l'application développeur et l'application deployer . Lorsque vous écrivez une application qui repose sur une base de données, vous ne devriez pas avoir à vous soucier du nom d'utilisateur ou du mot de passe pour vous connecter à cette base de données. JNDI permet au développeur de donner un nom à une base de données et de s'appuyer sur le déployeur pour mapper ce nom à une instance réelle de la base de données.

Par exemple, si vous écrivez du code qui s'exécute dans un conteneur Java EE, vous pouvez écrire ceci pour obtenir la source de données avec le nom JNDI "Database":

DataSource dataSource = null;
try
{
    Context context = new InitialContext();
    dataSource = (DataSource) context.lookup("Database");
}
catch (NamingException e)
{
    // Couldn't find the data source: give up
}

Notez qu'il n'y a rien ici sur le pilote de base de données, le nom d'utilisateur ou le mot de passe. Cela est configuré à l'intérieur du conteneur.

JNDI n'est pas limité aux bases de données (JDBC); toutes sortes de services peuvent être nommés. Pour plus de détails, vous devriez consulter le didacticiel d'Oracle .

JNDI est un mécanisme très puissant pour à la fois organiser les informations de configuration et découvrir et écouter les services en utilisant le EventContext. Dans JNDI, vous pouvez rechercher et écouter n'importe quel objet (pas seulement DataSources), en supposant que votre fournisseur de services JNDI le prenne en charge.

Bien sûr, le seul problème est d'avoir un fournisseur de services JNDI; ce qui est formidable, c'est qu'il est étonnamment facile de rouler le vôtre. Après tout, vous pouvez encoder n'importe quelle instance Java en XMLutilisant les JavaBeans XMLEncoderet XMLDecoder: vous n'avez pas besoin de vous reposer sur un serveur d'applications!

Alors, quelle est la différence entre cela et avoir des fichiers de configuration? Eh bien, cela peut être beaucoup plus propre car toutes vos applications peuvent obtenir leur configuration au même endroit . S'ils ont besoin de partager des informations de configuration (par exemple, des emplacements de base de données), cela peut être défini une fois dans JNDI . Supposons que vous ayez déplacé des serveurs de base de données: vous n'avez pas besoin de vous souvenir des fichiers de configuration de gazillion avec leur emplacement. Vous allez juste au seul endroit: JNDI.

JNDI est une API utilisée pour accéder à l'annuaire et aux services de nommage (c'est-à-dire les moyens par lesquels les noms sont associés aux objets). L'association d'un nom avec un objet s'appelle une liaison.

Un exemple de base de service de dénomination est le DNS qui mappe les noms de machine aux adresses IP.

À l'aide de JNDI, les applications peuvent stocker et récupérer des objets Java nommés de tout type.

Dans le contexte de java, cela peut être utilisé dans des fichiers de configuration où vous ne voulez pas coder en dur des variables spécifiques à l'environnement.

Exemple de printemps:

Fichier de contexte Spring

<bean id="WSClientConfig" class="com.example.BaseClientConfigImpl">
<property name="protocol">
    <jee:jndi-lookup jndi-name="java:comp/env/protocol" />
</property>
<property name="endpoint">
    <jee:jndi-lookup jndi-name="java:comp/env/endpoint" />
</property>
<property name="requestPath">
<jee:jndi-lookup jndi-name="java:comp/env/requestPath" />    
</property>

Fichier de contexte Tomcat

<Environment name="protocol" type="java.lang.String" value="https://"/>
<Environment name="endpoint" type="java.lang.String" value="172.0.0.1"/>
<Environment name="requestPath" type="java.lang.String" value="/path/to/service"/>

JNDI permet la simplification d'une construction de ressource en un simple nom . Donc, c'est beaucoup de détails regroupés en 1 pour plus de commodité / sécurité / etc. (aka couche d'abstraction)

à réaliser: configurez une liste de propriétés qui correspond aux champs prédéfinis dans l'interface de contexte Jndi. (ces propriétés spécifient les paramètres pour l'exécution jndi; mais * pas le nom de la recherche)

Properties props = new Properties();
//field Context.INITIAL_CONTEXT_FACTORY => property name java.naming.factory.initial
    //field Context.PROVIDER_URL => property name java.naming.provider.url
props.load(new FileInputStream("*properties file*")); //prop file in this case

Context ctx = new InitialContext(props);
    Object o = ctx.lookup("*name of resource*");

idéalement, une fonction spécialisée existerait pour maintenir un annuaire LDAP, un DNS, etc. dans votre organisation (donc un ensemble de mappage unique unifié dessert tous, réduisant les écarts)

Liste des fournisseurs de services JNDI: https://www.ibm.com/support/knowledgecenter/en/SSVSD8_8.4.1/com.ibm.websphere.dtx.adapjndi.doc/concepts/c_jndi_JNDI_Service_Providers_.htm