Développement d'applications utilisant JNDI
Les références aux foyers Enterprise JavaBeans (EJB) et à d'autres artefacts tels que les sources de données sont liées à l'espace de nom WebSphere Application Server. Ces objets peuvent être obtenus via l'interface JNDIJava™ Naming and Directory Interface). Avant de pouvoir exécuter une quelconque opération JNDI, vous devez obtenir un contexte initial. Vous pouvez utiliser ce contexte initial pour rechercher des objets liés à l'espace de nom.
Pourquoi et quand exécuter cette tâche
Ces exemples utilisent le comportement par défaut des fonctions spécifiques à la mise en oeuvre du contexte JNDI WebSphere Application Server.
La mise en oeuvre du contexte JNDI de WebSphere Application Server comporte des caractéristiques particulières. La mise en cache JNDI améliore les performances des opérations répétitives de recherche sur un même objet. Les options de syntaxe de nom offrent un choix de syntaxes de nom : l'une est optimisée pour les clients JNDI types et l'autre pour l'interopérabilité avec les applications CosNaming. Le comportement par défaut de ces fonctionnalités est généralement le mieux adapté. Toutefois, dans certaines situations, vous devrez modifier ce comportement.
Les options de mise en cache JNDI et de syntaxe de nom sont associées à une instance javax.naming.InitialContext. Pour sélectionner les options de ces fonctions, définissez des propriétés reconnues par la fabrique de contexte initial de WebSphere Application Server. Pour définir des propriétés de mise en cache JNDI ou de syntaxe de nom qui seront visibles pour la fabrique de contexte initial, suivez les étapes ci-dessous :
Procédure
- Facultatif : Configurez les caches JNDI.
La mise en cache JNDI peut fortement augmenter les performances des opérations de recherche JNDI. Par défaut, la mise en cache JNDI est activée. En règle générale, il s'agit du comportement souhaité. Toutefois, dans des situations spécifiques, utilisez les autres options de cache JNDI.
Les objets sont mis en cache localement lorsqu'ils sont recherchés. Les recherches suivantes sur les objets mis en cache sont résolues localement. Toutefois, le contenu du cache peut devenir obsolète. Ce qui n'engendre généralement aucun problème étant donné que la plupart des objets recherchés ne sont pas modifiés fréquemment. Si vous devez rechercher des objets qui sont modifiés relativement souvent, modifiez vos options de cache JNDI.
Les clients JNDI peuvent utiliser plusieurs propriétés pour contrôler le comportement du cache.
Vous pouvez définir les propriétés :- A partir de la ligne de commande, en entrant la valeur de chaîne réelle. Par
exemple :
java -Dcom.ibm.websphere.naming.jndicache.maxentrylife=1440
- Dans un fichier jndi.properties, en créant un fichier nommé jndi.properties en tant que fichier texte aux paramètres de propriétés souhaités. Exemple :
... com.ibm.websphere.naming.jndicache.cacheobject=none ...
Si vous utilisez cette technique, vous devez savoir que d'autres instances du fichier jndi.properties peuvent exister dans le chemin d'accès aux classes et contenir des paramètres de propriété en conflit. Les paramètres de propriété sont déterminés par l'ordre dans lequel le chargeur de classe prélève les fichiers jndi.properties. Il n'existe pas de moyen de contrôler l'ordre dans lequel le chargeur de classe localise les fichiers dans le chemin d'accès aux classes. Au départ, WebSphere Application Server ne contient pas ni ne crée de fichier jndi.properties qui définisse la propriété com.ibm.websphere.naming.jndicache.cacheobject.
- Dans un programme Java, en utilisant les constantes Java PROPS.JNDI_CACHE* définies dans le fichier com.ibm.websphere.naming.PROPS.
Voici les définitions des constantes :
public static final String JNDI_CACHE_OBJECT = "com.ibm.websphere.naming.jndicache.cacheobject"; public static final String JNDI_CACHE_OBJECT_NONE = "none"; public static final String JNDI_CACHE_OBJECT_POPULATED = "populated"; public static final String JNDI_CACHE_OBJECT_CLEARED = "cleared"; public static final String JNDI_CACHE_OBJECT_DEFAULT = JNDI_CACHE_OBJECT_POPULATED; public static final String JNDI_CACHE_NAME = "com.ibm.websphere.naming.jndicache.cachename"; public static final String JNDI_CACHE_NAME_DEFAULT = "providerURL"; public static final String JNDI_CACHE_MAX_LIFE = "com.ibm.websphere.naming.jndicache.maxcachelife"; public static final int JNDI_CACHE_MAX_LIFE_DEFAULT = 0; public static final String JNDI_CACHE_MAX_ENTRY_LIFE = "com.ibm.websphere.naming.jndicache.maxentrylife"; public static final int JNDI_CACHE_MAX_ENTRY_LIFE_DEFAULT = 0;
Pour utiliser les propriétés précédentes dans un programme Java, ajoutez le paramètre de propriétés dans une table de hachage et transmettez cette dernière au constructeur InitialContext de la manière suivante :
java.util.Hashtable env = new java.util.Hashtable(); ... // Disable caching env.put(PROPS.JNDI_CACHE_OBJECT, PROPS.JNDI_CACHE_OBJECT_NONE); ... javax.naming.Context initialContext = new javax.naming.InitialContext(env);
Vous trouverez ci-dessous des exemples qui illustrent l'utilisation des propriétés de cache JNDI afin d'obtenir le comportement de cache souhaité. Les propriétés de cache prennent effet lorsqu'un objet InitialContext est généré.
Exemple : contrôle du comportement du cache JNDI à partir d'un programme
import java.util.Hashtable; import javax.naming.InitialContext; import javax.naming.Context; import com.ibm.websphere.naming.PROPS; /***** Caching discussed in this section pertains to the WebSphere Application Server initial context factory. Assume the property, java.naming.factory.initial, is set to "com.ibm.websphere.naming.WsnInitialContextFactory" as a java.lang.System property. *****/ Hashtable env; Context ctx; // To clear a cache: env = new Hashtable(); env.put(PROPS.JNDI_CACHE_OBJECT, PROPS.JNDI_CACHE_OBJECT_CLEARED); ctx = new InitialContext(env); // To set a cache's maximum cache lifetime to 60 minutes: env = new Hashtable(); env.put(PROPS.JNDI_CACHE_MAX_LIFE, "60"); ctx = new InitialContext(env); // To turn caching off: env = new Hashtable(); env.put(PROPS.JNDI_CACHE_OBJECT, PROPS.JNDI_CACHE_OBJECT_NONE); ctx = new InitialContext(env); // To use caching and no caching: env = new Hashtable(); env.put(PROPS.JNDI_CACHE_OBJECT, PROPS.JNDI_CACHE_OBJECT_POPULATED); ctx = new InitialContext(env); env.put(PROPS.JNDI_CACHE_OBJECT, PROPS.JNDI_CACHE_OBJECT_NONE); Context noCacheCtx = new InitialContext(env); Object o; // Use caching to look up home, since the home should rarely change. o = ctx.lookup("com/mycom/MyEJBHome"); // Narrow, etc. ... // Do not use cache if data is volatile. o = noCacheCtx.lookup("com/mycom/VolatileObject"); // ...
Exemple : recherche d'une session JavaMail avec JNDI
L'exemple ci-dessous illustre la recherche d'une ressource JavaMail :
// Get the initial context as shown previously ... Session session = (Session) initialContext.lookup("java:comp/env/mail/MailSession");
- A partir de la ligne de commande, en entrant la valeur de chaîne réelle. Par
exemple :
- Facultatif : Spécifiez la syntaxe de nom.
La syntaxe INS est conçue pour les clients JNDI ayant besoin d'interopérer avec les applications CORBA. Elle permet à un client JNDI d'effectuer le mappage approprié de et vers un nom CORBA. La syntaxe INS est très similaire à la syntaxe JNDI ; elle s'en différencie par l'utilisation du caractère spécial point (.). Les points sont utilisés pour délimiter les zones ID et Type dans un composant de nom. Lorsqu'il est utilisé avec un caractère d'échappement, un point est interprété littéralement. Seul un point dépourvu de caractère d'échappement est autorisé dans un composant de nom. Un composant de nom dont la zone ID n'est pas vide et dont la zone Type est vide est représenté avec uniquement la valeur de la zone ID et ne doit pas se terminer par un point avec un caractère d'échappement. Un composant de nom vide (zones ID et Type vides) est représenté par un point unique, sans caractère d'échappement. Une chaîne vide n'est pas une représentation de composant de nom valide.
La syntaxe des noms JNDI est la syntaxe par défaut ; elle est appropriée pour les clients JNDI typiques. Elle inclut les caractères spéciaux suivants : barre oblique (/) et barre oblique inversée (\). Les composants d'un nom sont délimités par une barre oblique. La barre oblique inversée est utilisé comme caractère d'échappement. Une barre oblique est interprétée littéralement si elle est accompagnée d'un caractère d'échappement, c'est-à-dire précédée d'une barre oblique inversée. De même, une barre oblique inversée est interprétée littéralement si elle est précédée d'un caractère d'échappement.
La plupart des applications WebSphere utilisent JNDI pour rechercher des objets EJB et n'ont pas besoin de rechercher des objets liés par des applications CORBA. Par conséquent, la syntaxe de nom par défaut utilisée pour les noms JNDI est la plus pratique. Si votre application a besoin de rechercher des objets liés par des applications CORBA, vous pouvez avoir besoin de modifier votre syntaxe de nom afin que tous les noms CosNaming CORBA puissent être représentés.
Les clients JNDI peuvent définir la syntaxe de nom en définissant une propriété. Le paramètre de propriété est appliqué par la fabrique de contexte initial lorsque vous instanciez un nouvel objet java.naming.InitialContext. Les noms spécifiés dans des opérations JNDI sur le contexte initial sont analysés en fonction de la syntaxe de nom spécifiée.
Vous pouvez définir la propriété :
- A partir d'une ligne de commande, entrez la valeur réelle de la chaîne. Exemple :
java -Dcom.ibm.websphere.naming.name.syntax=ins
- Créez un fichier appelé jndi.properties comme fichier texte avec les paramètres de propriété de votre choix. Exemple :
... com.ibm.websphere.naming.name.syntax=ins ...
Si vous utilisez cette technique, vous devez savoir que d'autres instances du fichier jndi.properties peuvent exister dans le chemin d'accès aux classes et contenir des paramètres de propriété en conflit. Les paramètres de propriété sont déterminés par l'ordre dans lequel le chargeur de classe prélève les fichiers jndi.properties. Il n'existe pas de moyen de contrôler l'ordre dans lequel le chargeur de classe localise les fichiers dans le chemin d'accès aux classes. Au départ, WebSphere Application Server ne contient pas ni ne crée de fichier jndi.properties qui définisse la propriété com.ibm.websphere.naming.name.syntax.
- Utilisez les constantes Java PROPS.NAME_SYNTAX* définies dans le fichier com.ibm.websphere.naming.PROPS, dans un programme Java. Voici les définitions des constantes :
public static final String NAME_SYNTAX = "com.ibm.websphere.naming.name.syntax"; public static final String NAME_SYNTAX_JNDI = "jndi"; public static final String NAME_SYNTAX_INS = "ins";
Pour utiliser les propriétés précédentes dans un programme Java, ajoutez le paramètre de propriétés dans une table de hachage et transmettez cette dernière au constructeur InitialContext de la manière suivante :
java.util.Hashtable env = new java.util.Hashtable(); ... env.put(PROPS.NAME_SYNTAX, PROPS.NAME_SYNTAX_INS); // Set name syntax to INS ... javax.naming.Context initialContext = new javax.naming.InitialContext(env);
Exemple : définition de la syntaxe utilisée pour analyser les chaînes de nom
La propriété de syntaxe de nom peut être transmise vers le constructeur InitialContext via son paramètre, dans les propriétés système ou dans un fichier jndi.properties. Le contexte initial et tous les contextes recherchés à partir de ce contexte initial vont analyser les chaînes de nom en fonction de la syntaxe spécifiée.
L'exemple suivant montre comment définir la syntaxe de nom de sorte que le contexte initial analyse les chaînes de nom en fonction de la syntaxe INS.
... import java.util.Hashtable; import javax.naming.Context; import javax.naming.InitialContext; import com.ibm.websphere.naming.PROPS; // WebSphere naming constants ... Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory"); env.put(Context.PROVIDER_URL, ...); env.put(PROPS.NAME_SYNTAX, PROPS.NAME_SYNTAX_INS); Context initialContext = new InitialContext(env); // The following name maps to a CORBA name component as follows: // id = "a.name", kind = "in.INS.format" // The unescaped dot is used as the delimiter. // Escaped dots are interpreted literally. java.lang.Object o = initialContext.lookup("a\\.name.in\\.INS\\.format"); ...
La syntaxe de nom INS nécessite que les points intercalaires (.) dans un nom tel que in.INS.format soient accompagnés d'une barre oblique inversée (\) comme caractère d'échappement. Dans un littéral chaîne Java, une barre oblique inversée (\) doit être accompagnée d'une autre barre oblique inversée comme caractère d'échappement (\\).
- A partir d'une ligne de commande, entrez la valeur réelle de la chaîne. Exemple :
- Facultatif : Désactivez la normalisation des noms d'hôte
Les références aux noms d'hôte, aux adresse IP et à localhost dans les URL fournisseur sont habituellement normalisées. Le format d'un nom d'hôte normalisé est sa forme complète. La normalisation des noms d'hôte améliore l'efficacité du système, car elle permet l'utilisation du même cache JNDI pour un hôte d'amorçage donné, quel que soit le format de la référence dans l'URL fournisseur. Par exemple, la normalisation du nom d'hôte permet d'utiliser le même cache JNDI pour les références myhost, myhost.mydomain.com et localhost si toutes ces références se rapportent au même hôte.
Les noms d'hôte normalisés étant mis en mémoire cache, les normalisations suivantes sont plus rapides. Dans certains environnements réseau, les données de recherche des nom de domaine change de façon dynamique, et les noms d'hôte normalisés du cache se périment. Dans ce type d'environnement, il peut être nécessaire de désactiver la normalisation des noms d'hôte. Lorsque celle-ci est désactivée, les noms d'hôte et les adresses IP sont utilisés tels quels. Les références à localhost sont habituellement résolues par l'adresse de bouclage 127.0.0.1.
Pour les clients JNDI, la normalisation des noms d'hôte peut être désactivée à l'aide d'une propriété. Le paramètre de propriété est appliqué par la fabrique de contexte initial lorsque vous instanciez un nouvel objet java.naming.InitialContext.
Utilisez l'une des techniques suivantes pour définir cette propriété :- A partir d'une ligne de commande, entrez la valeur réelle de la chaîne. Exemple :
java -Dcom.ibm.websphere.naming.hostname.normalizer=...none...
- Vous pouvez créer un fichier appelé jndi.properties comme fichier texte avec les paramètres de propriété de votre choix. Exemple :
... com.ibm.websphere.naming.hostname.normalizer=...none... ...
Si vous utilisez cette technique, vous devez savoir que d'autres instances du fichier jndi.properties peuvent exister dans le chemin d'accès aux classes et contenir des paramètres de propriété en conflit. Les paramètres de propriété sont déterminés par l'ordre dans lequel le chargeur de classe prélève les fichiers jndi.properties. Il n'existe pas de moyen de contrôler l'ordre dans lequel le chargeur de classe localise les fichiers dans le chemin d'accès aux classes. Au départ, WebSphere Application Server ne contient pas ni ne crée de fichier jndi.properties qui définisse la propriété com.ibm.websphere.naming.hostname.normalizer.
- Vous pouvez utiliser la constante Java PROPS.HOSTNAME_NORMALIZER* dans un programme Java. Ces constantes Java sont définies dans le fichier com.ibm.websphere.naming.PROPS. Les définitions de constante à utiliser si vous choisissez cette technique sont les suivantes :
public static final String HOSTNAME_NORMALIZER = "com.ibm.websphere.naming.hostname.normalizer"; public static final String HOSTNAME_NORMALIZER_NONE = "...none...;
Pour utiliser ces définitions dans un programme Java, ajoutez le paramètre de propriétés dans une table de hachage et transmettez cette dernière au constructeur InitialContext :
java.util.Hashtable env = new java.util.Hashtable(); ... env.put(PROPS.HOSTNAME_NORMALIZER, PROPS.HOSTNAME_NORMALIZER_NONE); // Disable hostname normalization ... javax.naming.Context initialContext = new javax.naming.InitialContext(env);
Exemple : Désactivation de la normalisation des noms d'hôte
La propriété de normalisation des noms d'hôte peut être transmise au constructeur InitialContext via son paramètre, dans le fichier des propriétés système ou dans un fichier jndi.properties. Le contexte initial et tous les contextes futurs recherchés à partir de ce contexte initial utiliseront cette propriété.
L'exemple suivant montre comment désactiver la normalisation des noms d'hôte.
... import java.util.Hashtable; import javax.naming.Context; import javax.naming.InitialContext; import com.ibm.websphere.naming.PROPS; // WebSphere naming constants ... Hashtable env = new Hashtable(); env.put(Context.INITIAL_CONTEXT_FACTORY, "com.ibm.websphere.naming.WsnInitialContextFactory"); env.put(Context.PROVIDER_URL, ...); env.put(PROPS.HOSTNAME_NORMALIZER, PROPS.HOSTNAME_NORMALIZER_NONE); Context initialContext = new InitialContext(env); java.lang.Object o = initialContext.lookup(...); ...
- A partir d'une ligne de commande, entrez la valeur réelle de la chaîne. Exemple :
Sous-rubriques
Exemple : Obtention du contexte initial par défaut
Il existe plusieurs façons pour un programme d'obtenir le contexte initial par défaut.Exemple : Obtention d'un contexte initial en définissant la propriété d'URL du fournisseur
En général, les clients JNDI (Java Naming and Directory Interface) doivent considérer que l'environnement correct est déjà configuré, de sorte qu'il n'est pas nécessaire de définir explicitement les valeurs des propriétés JNDI et de les transmettre au constructeur InitialContext. Cependant, un client JNDI peut avoir besoin d'accéder à un autre espace de nom que celui identifié dans son environnement. Dans ce cas, il est nécessaire de définir explicitement la propriété java.naming.provider.url (URL de fournisseur) utilisée par le constructeur InitialContext. Une URL de fournisseur contient des informations sur le serveur d'amorce que la fabrique de contextes initiaux peut utiliser pour obtenir un contexte initial. Toute valeur de propriété transmise directement au constructeur InitialContext est prioritaire sur les paramètres de ces mêmes propriétés trouvées ailleurs dans l'environnement.Exemple : Définition de la propriété d'URL du fournisseur pour sélectionner un autre contexte racine en tant que contexte initial
Chaque serveur contient son propre contexte racine de serveur et lors de l'amorçage vers un serveur, la racine de serveur est le contexte JNDI initial par défaut. La plupart du temps, il s'agit du contexte initial souhaité dans la mesure où les objets système, tels que les interfaces home d'EJB, sont liés à cet endroit. Il existe cependant d'autres contextes racines qui peuvent contenir des liaisons intéressantes. Il est possible de spécifier une URL fournisseur pour sélectionner d'autres contextes de racine.Exemple : recherche d'une interface home ou métier d'EJB avec JNDI
La plupart des applications qui utilisent Java Naming and Directory Interface (JNDI) s'excutent dans un conteneur. Ce n'est pas le cas de toutes les applications utilisant JNDI. Le nom utilisé pour rechercher un objet est différent selon que l'application s'exécute ou non dans un conteneur. Il est parfois préférable qu'une application utilise une URL corbaname comme nom de recherche. Les clients JNDI fondés sur conteneur et les clients partiels Java peuvent utiliser une URL corbaname.Remarques sur l'interopérabilité JNDI
Vous devez accomplir des étapes supplémentaires pour permettre une interopérabilité entre vos programmes et des clients JNDI autres que ceux du produit et pour lier les ressources de MQSeries à un espace de nom.Mise en cache JNDI
Afin d'accroître les performances des opérations JNDI (Java Naming and Directory Interface), l'implémentation JNDI du produit utilise la mise en cache de manière à réduire le nombre d'appels au serveur de noms pour des opérations de recherche. Dans la plupart des cas, conservez les réglages de mise en cache par défaut.Paramètres de cache JNDI
Voici différents paramètres de cache Java Naming and Directory Interface (JNDI). Assurez-vous que toutes les valeurs de propriété sont des chaînes.Remarques sur le mappage des noms JNDI vers CORBA
Les serveurs de noms WebSphere Application Server sont une mise en oeuvre de l'interface CORBA CosNaming. Le produit fournit une mise en oeuvre JNDI (Java Naming and Directory Interface) que vous pouvez utiliser pour accéder aux serveurs de noms CosNaming via l'interface JNDI. Le mappage de chaînes de noms JNDI de et vers les noms CORBA peut poser certains problèmes.


http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=tnam_develop_naming
Nom du fichier : tnam_develop_naming.html