Exemple : Obtention du contexte initial par défaut

Il existe plusieurs façons pour un programme d'obtenir le contexte initial par défaut.

L'exemple suivant illustre le contexte initial par défaut. Il convient de noter qu'aucune URL URL n'est transmise au constructeur javax.naming.InitialContext.

...
import javax.naming.Context;
import javax.naming.InitialContext;
...
Context initialContext = new InitialContext();
...

Le contexte initial par défaut dépend de l'environnement d'exécution du client JNDI (Java™ Naming and Directory Interface). Voici les contextes initiaux renvoyés dans les divers environnements :

Client léger
Le contexte initial est le contexte racine du serveur exécuté sur l'hôte local, port 2809.
Client pur
Le contexte initial est le contexte spécifié par la propriété java.naming.provider.url transmise à la commande launchClient avec le paramètre de ligne de commande -CCD. Il s'agit généralement du contexte racine du serveur situé à l'adresse spécifiée dans l'URL, bien qu'il soit possible de générer une URL corbaname ou corbaloc résolue en un autre contexte.

Si aucune adresse URL de fournisseur n'a été spécifiée, il s'agit du contexte racine du serveur exécuté sur l'hôte et le port spécifiés par les paramètres de ligne de commande -CCproviderURL ou-CCBootstrapHost et les paramètres de ligne de commande -CCBootstrapPort. L'hôte par défaut est l'hôte local et le port par défaut est 2809.

Processus serveur
Le contexte initial est le contexte racine du serveur pour ce processus.

Bien qu'aucune URL de fournisseur ne soit explicitement spécifiée dans l'exemple précédent, le constructeur InitialContext peut trouver une URL de fournisseur définie dans d'autres endroits qu'il explore à la recherche de paramètres de propriété.

Les utilisateurs de propriétés qui affectent l'initialisation de l'ORB doivent lire la suite de cette section pour avoir une connaissance plus approfondie de la façon dont les contextes initiaux sont obtenus.

Détermination du serveur utilisé pour obtenir le contexte initial

Les serveurs de noms WebSphere Application Server sont des serveurs CORBA CosNaming et le produit fournit une implémentation de module d'extension JNDI CosNaming pour les clients JNDI afin de permettre l'exécution d'opérations de nommage sur les espaces de nom du produit. L'implémentation du module d'extension CosNaming est sélectionnée à l'aide d'une propriété JNDI transmise au constructeur InitialContext. Cette propriété, java.naming.factory.initial, spécifie l'implémentation de fabrique de contexte initial à utiliser pour obtenir un contexte initial. La fabrique renvoie une instance javax.naming.Context qui fait partie de son implémentation.

La fabrique de contexte initial com.ibm.websphere.naming.WsnInitialContextFactory est généralement utilisée par les applications pour effectuer des opérations JNDI. L'environnement d'exécution de WebSphere Application Server est configuré pour utiliser cette fabrique de contexte initial lorsqu'aucune fabrique n'a été spécifiée explicitement par le client JNDI. Lorsque la fabrique de contexte initial est appelée, un contexte initial est obtenu. Les paragraphes suivants expliquent comment la fabrique de contexte initial obtient le contexte initial dans des environnements client/serveur.

  • Enregistrement des références initiales dans les processus serveur

    Chaque serveur WebSphere Application Server comporte un ORB utilisé pour recevoir et répartir les appels sur les objets exécutés dans ce serveur. Les services exécutés dans le processus serveur peuvent enregistrer des références initiales auprès de l'ORB. Chaque référence initiale est enregistrée sous une clé qui est une valeur de chaîne. Une référence initiale peut être n'importe quel objet CORBA. Les serveurs de noms WebSphere Application Server enregistrent plusieurs contextes initiaux en tant que références initiales sous des clés prédéfinies. Chaque référence initiale à un serveur de noms est une instance de l'interface org.omg.CosNaming.NamingContext.

  • Obtention de références initiales dans des processus client purs

    Les clients JNDI purs, c'est-à-dire ceux qui ne s'exécutent pas dans un processus WebSphere Application Server, ont également une instance ORB. Cette instance peut être transmise au constructeur InitialContext, mais généralement, la fabrique de contexte initial crée et initialise l'instance ORB client de façon transparente. Un ORB client peut être initialisé avec des références initiales, mais celles-ci sont généralement résolues en objets exécutés dans un serveur. La fabrique de contexte initial ne définit pas de références initiales par défaut lorsqu'elle initialise un ORB. Si la méthode resolve_initial_references est appelée sur l'ORB client alors qu'aucune référence initiale n'a été configurée, l'appel de la méthode échoue. Cette situation s'applique généralement aux processus client pur. Pour obtenir une référence NamingContext initiale, la fabrique de contexte initial doit appeler string_to_object avec une URL d'objet CORBA de type IIOP, telle que corbaloc:iiop:myhost:2809. L'URL spécifie l'adresse du serveur à partir duquel le contexte initial peut être obtenu. Les informations concernant l'hôte et le port sont extraites de l'URL de fournisseur et transmises au constructeur InitialContext.

    [AIX][HP-UX][Linux][Solaris][Windows][z/OS]Si aucune URL de fournisseur n'est définie, la fabrique de contexte initial WebSphere Application Server utilise l'URL de fournisseur par défaut corbaloc:iiop:localhost:2809.

    [IBM i]Si aucune URL de fournisseur n'est définie, la fabrique de contexte initial WebSphere Application Server utilise l'URL de fournisseur par défaut corbaloc:iiop:your.server.name:2809.

    La méthode ORB string_to_object résout l'URL et communique avec l'ORB de serveur cible afin d'obtenir la référence initiale.

  • Obtention de références initiales dans des processus serveur

    Si le client JNDI est exécuté dans un processus WebSphere Application Server, la fabrique de contexte initial obtient une référence à l'instance ORB du serveur si le client JNDI ne fournit pas d'instance ORB. Généralement, les clients JNDI exécutés dans des processus serveur utilisent l'instance ORB du serveur, c'est-à-dire qu'ils ne transmettent pas une instance ORB au constructeur InitialContext. Le serveur de noms exécuté dans le processus serveur définit une URL de fournisseur en tant que propriété java.lang.System qui servira d'URL de fournisseur par défaut pour tous les clients JNDI du processus. Cette URL de fournisseur par défaut est corbaloc:rir:/NameServiceServerRoot. Elle se résout en contexte racine de serveur pour ce serveur. (L'URL équivaut à l'appel de resolve_initial_references sur l'ORB avec une clé NameServiceServerRoot. Le serveur de noms enregistre le contexte racine de serveur en tant que référence initiale sous cette clé.)

  • Protocole ORB existant

    Les précédentes éditions de WebSphere Application Server version 5 utilisaient une implémentation ORB différente qui employait un protocole existant différent du protocole INS (Interoperable Name Service) utilisé actuellement. Ce changement a affecté l'implémentation de la fabrique de contexte initial. Il se peut que le comportement de certains types de clients purs soit différent lors du chargement des contextes JNDI initiaux par rapport aux versions antérieures de WebSphere Application Server. Ce comportement est détaillé ci-après.

    Les propriétés ORB suivantes sont utilisées avec le protocole ORB existant pour l'initialisation d'ORB, elles sont déconseillées :

    • com.ibm.CORBA.BootstrapHost
    • com.ibm.CORBA.BootstrapPort

    Le nouvel ORB INS présente une différence importante : il n'indique pas de comportement par défaut si aucune référence initiale n'est définie.

    [AIX][HP-UX][Linux][Solaris][Windows][z/OS]Dans l'ancien ORB, les valeurs d'hôte amorce et de port étaient par défaut l'hôte_local et 900.

    [IBM i]Dans l'ORB existant, les valeurs d'hôte amorce et de port étaient par défaut nom.du.serveur et 900.

    Toutes les références initiales ont été obtenues à partir du serveur exécuté sur l'hôte et le port d'amorce. Par conséquent, si l'utilisateur d'ORB n'a pas fourni d'hôte et de port d'amorce, toutes les références initiales sont résolues à partir du serveur exécuté sur l'hôte local, port 900. L'ORB INS n'est pas lié au concept d'hôte et de port d'amorce. Toutes les références initiales sont définies de façon indépendante. C'est-à-dire que des références initiales différentes peuvent être résolues en serveurs différents. Si ORB.resolve_initial_references est appelé avec une clé qui ne permet pas à l'ORB d'être initialisé si sa référence initiale comporte cette clé, l'appel échoue.

    Dans les versions antérieures à la version 5, la fabrique de contexte initial appelait resolve_initial_references sur l'ORB en l'absence d'URL fournisseur. Cette action aboutissait si un serveur de noms fonctionnait sur l'hôte et le port d'amorce par défaut. Actuellement, avec l'ORB INS, cette action échouerait. (En fait, l'ORB retournerait au protocole hérité au cours de la période de transition, mais lorsque ce protocole ne serait plus pris en charge, l'opération échouerait.)

    [AIX][HP-UX][Linux][Solaris][Windows][z/OS]La fabrique de contexte initial utilise désormais une URL de fournisseur par défaut corbaloc:iiop:localhost:2809, et appelle string_to_object avec cette URL.

    [IBM i]La fabrique de contexte initial utilise désormais une URL de fournisseur par défaut corbaloc:iiop:nom.du.serveur:2809 et invoque string_to_object avec cette URL.

    Cette opération maintient le comportement que les clients purs rencontraient dans les précédentes versions lorsqu'ils ne définissaient ni propriétés d'amorce ORB, ni URL de fournisseur. Toutefois, cette implémentation différente de fabrique de contexte initial modifie le comportement de certains clients purs existants qui n'indiquent pas d'URL de fournisseur :

    • Les clients qui définissent les propriétés d'amorce ORB répertoriées ci-dessus lors de l'obtention d'un contexte initial.
    • Les clients qui fournissent leur propre instance ORB au constructeur InitialContext.

    Il existe deux façons d'éviter ce changement de comportement :

    • Toujours spécifier une URL de fournisseur de type IIOP. Cette approche ne dépend pas des propriétés d'hôte et de port d'amorce, elle continue de fonctionner lorsque la prise en charge de ces propriétés est supprimée. Par exemple, vous pouvez exprimer des valeurs de propriétés d'hôte et de port d'amorce myHost et 2809, respectivement, sous la forme corbaloc:iiop:myHost:2809.
    • Utilisez une URL de fournisseur de type rir :
      • Spécifiez corbaloc:rir:/NameServiceServerRoot si l'ORB est initialisé pour utiliser un serveur de version 5 comme serveur d'amorce.
      • Spécifiez corbaname:rir:/NameService#domain/legacyRoot si l'ORB est initialisé pour utiliser un serveur de version 4.0.x comme serveur d'amorce.
      • Spécifiez corbaloc:rir:/NameService si l'ORB est initialisé pour utiliser un serveur d'une version autre que 5 ou 4.0.x comme serveur d'amorce.

      Les URL de ce type équivalent à l'appel de resolve_initial_references sur l'ORB avec la clé spécifiée. Si les propriétés d'hôte et de port d'amorce sont utilisées pour initialiser l'ORB, cette approche ne fonctionnera plus lorsque ces propriétés ne seront plus prises en charge.

  • Ordre de recherche des propriétés JNDI par le constructeur InitialContext

    Si le fragment de code indiqué précédemment est exécuté par une application, le serveur d'amorce dépend de la valeur de la propriété java.naming.provider.url.

    [AIX][HP-UX][Linux][Solaris][Windows][z/OS]Si la propriété n'est pas définie (dans les processus de serveur, la valeur par défaut est définie en tant que propriété système), l'hôte par défaut localhost et le port par défaut 2809 sont utilisés comme adresse du serveur à partir duquel vous obtiendrez le contexte initial.

    [IBM i]Si la propriété n'est pas définie (dans les processus de serveur, la valeur par défaut est définie en tant que propriété système), l'hôte par défaut nom.du.serveur et le port par défaut 2809 sont utilisés comme adresse du serveur à partir duquel vous obtiendrez le contexte initial.

    La spécification JNDI indique l'endroit où le constructeur InitialContext recherche les paramètres de la propriété java.naming.provider.url. Celle-ci est extraite des emplacements suivants, dans l'ordre indiqué :

    constructeur InitialContext
    Il ne s'applique pas à l'exemple précédent car ce dernier utilise le constructeur vide InitalContext.
    Environnement système
    Vous pouvez ajouter des propriétés JNDI à l'environnement système en tant qu'option de l'appel d'une commande Java ou par code de programme. La méthode recommandée pour définir l'URL de fournisseur dans l'environnement système consiste à spécifier cette URL en tant qu'option dans l'appel d'une commande Java. Définir l'URL fournisseur de cette façon n'est pas temporaire afin que le contexte initial par défaut donne toujours le même résultat. Il n'est généralement pas conseillé de définir la propriété URL dans l'environnement système avec le code programme car, à titre d'effet secondaire, cette approche peut affecter du code, peut être sans relation, s'exécutant ailleurs dans le même processus.
    Fichier jndi.properties
    Il peut exister de nombreux fichiers jndi.properties qui se situent dans la portée du chargeur de classe actif. Tous les fichiers jndi.properties sont utilisés pour définir des propriétés JNDI, mais le paramètre de l'URL de fournisseur est déterminé par le premier fichier jndi.properties renvoyé par le chargeur de classe.

Icône indiquant le type de rubrique Rubrique de référence



Icône d'horodatage Dernière mise à jour: last_date
http://www14.software.ibm.com/webapp/wsbroker/redirect?version=cord&product=was-nd-mp&topic=rnam_example_prop1
Nom du fichier : rnam_example_prop1.html