Anwendungen entwickeln, die JNDI verwenden
Referenzen auf EJB-Home-Verzeichnisse und andere Artefakte, z. B. Datenquellen, werden an den Namespace von WebSphere Application Server gebunden. Diese Objekte können über Java™ Naming and Directory Interface (JNDI) abgerufen werden. Bevor Sie JNDI-Operationen ausführen können, benötigen Sie einen Ausgangskontext. Sie können den Ausgangskontext verwenden, um Objekte zu suchen, die an den Namespace gebunden sind.
Informationen zu diesem Vorgang
In diesen Beispielen wird das Standardverhalten der speziellen Features für die JNDI-Kontextimplementierung von WebSphere Application Server verwendet.
Die JNDI-Kontextimplementierung von WebSphere Application Server enthält spezielle Features. Mit dem JNDI-Caching wird der Durchsatz bei wiederholten Lookup-Operationen für Objekte verbessert. Es stehen mehrere Optionen für die Namenssyntax bereit, eine optimierte Option für typische JNDI-Clients sowie eine optimierte Option für die Interoperabilität mit CosNaming-Anwendungen. In den meisten Fällen entspricht das Standardverhalten dieser Features dem gewünschten Verhalten. Es gibt aber auch Situationen, in denen ein anderes Verhalten angezeigt ist.
Das JNDI-Caching und die Optionen für die Namenssyntax sind einer javax.naming.InitialContext-Instanz zugeordnet. Zum Auswählen von Optionen für diese Features definieren Sie Eigenschaften, die von der Ausgangskontextfactory von WebSphere Application Server erkannt werden. Gehen Sie wie folgt vor, um die Eigenschaften für das JNDI-Caching und die JNDI-Namenssyntax festzulegen, die für die Ausgangskontextfactory sichtbar sind:
Vorgehensweise
- Optional: JNDI-Caches konfigurieren
Mit dem JNDI-Caching kann der Durchsatz von JNDI-Suchoperationen spürbar verbessert werden. Das JNDI-Caching ist standardmäßig aktiviert. In den meisten Situationen ist dieses Standardverhalten gewünscht. In bestimmten Situationen sollten jedoch andere JNDI-Cacheoptionen verwendet werden.
Gefundene Objekte werden lokal zwischengespeichert. Nachfolgende Lookup-Operationen für zwischengespeicherte Objekte werden lokal aufgelöst. Der Cacheinhalt kann jedoch veralten. Dies ist normalerweise kein Problem, da sich die meisten Objekte, nach denen gesucht wird, nicht oft ändern. Falls Sie nach Objekten suchen müssen, die relativ häufig geändert werden, modifizieren Sie Ihre JNDI-Cacheeinstellungen.
JNDI-Clients können mehrere Eigenschaften zum Steuern des Cacheverhaltens verwenden.
Sie können Eigenschaften wie folgt festlegen:- Über die Befehlszeile durch Eingabe des tatsächlichen Zeichenfolgewertes. Beispiele:
java -Dcom.ibm.websphere.naming.jndicache.maxentrylife=1440
- In einer Datei jndi.properties. Erstellen Sie dazu die Textdatei jndi.properties mit
den gewünschten Eigenschaftseinstellungen. Beispiel:
... com.ibm.websphere.naming.jndicache.cacheobject=none ...
Wenn Sie dieses Verfahren verwenden, beachten Sie, dass im Klassenpfad möglicherweise andere Instanzen der Datei jndi.properties vorhanden sind mit Eigenschaftseinstellungen, die Konflikte auslösen können. Eigenschaftseinstellungen werden bestimmt durch die Reihenfolge, in der der Klassenlader die Dateien jndi.properties berücksichtigt. Die Reihenfolge, in der der Klassenlader Dateien im Klassenpfad lokalisiert, kann nicht festgelegt werden. WebSphere Application Server enthält oder erstellt standardmäßig keine Dateien jndi.properties, die die Eigenschaft com.ibm.websphere.naming.jndicache.cacheobject definieren.
- Mit einem Java-Programm. Verwenden Sie dazu die in der Datei com.ibm.websphere.naming.PROPS
definierten Java-Konstanten vom Typ PROPS.JNDI_CACHE*. Hier sehen Sie die Konstantendefinitionen:
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;
Wenn Sie die vorherigen Eigenschaften in einem Java-Programm verwenden möchten, fügen Sie die Eigenschaftseinstellung zu einer Hash-Tabelle hinzu und übergeben Sie sie wie folgt an den InitialContext-Konstruktor:
java.util.Hashtable env = new java.util.Hashtable(); ... // Caching inaktivieren env.put(PROPS.JNDI_CACHE_OBJECT, PROPS.JNDI_CACHE_OBJECT_NONE); ... javax.naming.Context initialContext = new javax.naming.InitialContext(env);
Es folgen Beispiele, die veranschaulichen, wie Sie Eigenschaften des JNDI-Caches verwenden können, um das gewünschte Cacheverhalten zu erzielen. Cacheeigenschaften werden bei der Erstellung eines InitialContext-Objekts wirksam.
Beispiel: Verhalten des JNDI-Cache über ein Programm steuern
import java.util.Hashtable; import javax.naming.InitialContext; import javax.naming.Context; import com.ibm.websphere.naming.PROPS; /***** Das in diesem Abschnitt erläuterte Caching gehört zur Ausgangskontextfactory von WebSphere Application Server. Gehen Sie davon aus, dass die Eigenschaft "java.naming.factory.initial" als java.lang.System-Eigenschaft auf "com.ibm.websphere.naming.WsnInitialContextFactory" gesetzt ist. *****/ Hashtable env; Context ctx; // Cache löschen: env = new Hashtable(); env.put(PROPS.JNDI_CACHE_OBJECT, PROPS.JNDI_CACHE_OBJECT_CLEARED); ctx = new InitialContext(env); // Die maximale Lebensdauer eines Cache auf 60 Minuten begrenzen: env = new Hashtable(); env.put(PROPS.JNDI_CACHE_MAX_LIFE, "60"); ctx = new InitialContext(env); // Das Caching inaktivieren: env = new Hashtable(); env.put(PROPS.JNDI_CACHE_OBJECT, PROPS.JNDI_CACHE_OBJECT_NONE); ctx = new InitialContext(env); // Mit und ohne Caching arbeiten: 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; // Caching zum Lokalisieren des Home verwenden, da das Home nur selten geändert wird. o = ctx.lookup("com/mycom/MyEJBHome"); // Narrow, etc. ... // Cache nicht für flüchtige Daten verwenden. o = noCacheCtx.lookup("com/mycom/VolatileObject"); // ...
Beispiel: JavaMail-Sitzung mit JNDI suchen
Das nachfolgende Beispiel zeigt die Lookup-Operation für eine JavaMail-Ressource:
// Ausgangskontext wie zuvor dargestellt abrufen ... Session session = (Session) initialContext.lookup("java:comp/env/mail/MailSession");
- Über die Befehlszeile durch Eingabe des tatsächlichen Zeichenfolgewertes. Beispiele:
- Optional: Namenssyntax angeben
Die INS-Syntax ist für JNDI-Clients bestimmt, die mit CORBA-Anwendungen zusammenarbeiten müssen. Diese Syntax ermöglicht einem JNDI-Client, die CORBA-Namen richtig zuzuordnen. Die INS-Syntax weicht nur geringfügig von der JNDI-Syntax ab und enthält das zusätzliche Zeichen Punkt (.). Der Punkt wird zum Trennen der Felder "id" und "kind" in einer Namenskomponente verwendet. Ein Punkt wird als solcher interpretiert, wenn ihm ein Escapezeichen vorangestellt ist. In Namenskomponenten sind nur Punkte ohne vorangestelltes Escapezeichen zulässig. Eine Namenskomponente mit einem ausgefüllten Feld "id" und einem leeren Feld "kind" wird nur mit dem Wert des Feldes "id" dargestellt und darf nicht mit einem Punkt ohne vorangestelltes Escapezeichen enden. Eine leere Namenskomponente (leeres Feld "id" und leeres Feld "kind") wird durch einen einzelnen Punkt ohne vorangestelltes Escapezeichen dargestellt. Eine leere Zeichenfolge ist keine gültige Darstellung für eine Namenskomponente.
Die JNDI-Namenssyntax ist die Standardsyntax und eignet sich für typische JNDI-Clients. Diese Syntax umfasst folgende Sonderzeichen: Schrägstrich (/) und Backslash (\). Komponenten in einem Namen werden durch einen Schrägstrich getrennt. Der Backslash dient als Escapezeichen. Ein Schrägstrich wird als solcher interpretiert, wenn er mit einem Escapezeichen versehen ist, d. h. wenn ihm ein Backslash vorangestellt ist. Entsprechend wird ein Backslash als solcher interpretiert, wenn er mit einem Escapezeichen versehen ist.
Die meisten WebSphere-Anwendungen verwenden JNDI für die Suche nach EJB-Objekten und müssen nicht nach Objekten suchen, die durch CORBA-Anwendungen gebunden sind. Die Standardsyntax für JNDI-Namen ist deshalb sehr komfortabel. Wenn Ihre Anwendung nach Objekten suchen muss, die durch CORBA-Anwendungen gebunden sind, müssen Sie unter Umständen die Namenssyntax so ändern, dass alle CORBA-CosNaming-Namen dargestellt werden können.
JNDI-Clients können die Namenssyntax über eine Eigenschaft festlegen. Die Eigenschaftseinstellung wird von der Ausgangskontextfactory angewendet, wenn Sie ein neues java.naming.InitialContext-Objekt instanziieren. In JNDI-Operationen für den Ausgangskontext angegebene Namen werden entsprechend der angegebenen Namenssyntax analysiert.
Sie können die Eigenschaft wie folgt festlegen:
- Geben Sie in einer Befehlszeile den tatsächlichen Zeichenfolgewert ein.
Beispiel:
java -Dcom.ibm.websphere.naming.name.syntax=ins
- Erstellen Sie eine Datei mit dem Namen jndi.properties als Textdatei mit den gewünschten Eigenschaftseinstellungen.
Beispiel:
... com.ibm.websphere.naming.name.syntax=ins ...
Wenn Sie dieses Verfahren verwenden, beachten Sie, dass im Klassenpfad möglicherweise andere Instanzen der Datei jndi.properties vorhanden sind mit Eigenschaftseinstellungen, die Konflikte auslösen können. Eigenschaftseinstellungen werden bestimmt durch die Reihenfolge, in der der Klassenlader die Dateien jndi.properties berücksichtigt. Die Reihenfolge, in der der Klassenlader Dateien im Klassenpfad lokalisiert, kann nicht festgelegt werden. WebSphere Application Server enthält oder erstellt standardmäßig keine Dateien jndi.properties, die die Eigenschaft com.ibm.websphere.naming.name.syntax definieren.
- Verwenden Sie die Java-Konstanten PROPS.NAME_SYNTAX*, die in der Datei com.ibm.websphere.naming.PROPS definiert sind, in einem Java-Programm.
Hier sehen Sie die Konstantendefinitionen:
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";
Wenn Sie die vorherigen Eigenschaften in einem Java-Programm verwenden möchten, fügen Sie die Eigenschaftseinstellung zu einer Hash-Tabelle hinzu und übergeben Sie sie wie folgt an den InitialContext-Konstruktor:
java.util.Hashtable env = new java.util.Hashtable(); ... env.put(PROPS.NAME_SYNTAX, PROPS.NAME_SYNTAX_INS); // Namenssyntax auf INS setzen ... javax.naming.Context initialContext = new javax.naming.InitialContext(env);
Beispiel: Syntax für die Analyse von Namenszeichenfolgen festlegen
Die Eigenschaft der Namenssyntax kann an den InitialContext-Konstruktor über den entsprechenden Parameter in den Systemeigenschaften oder in einer Datei jndi.properties übergeben werden. Der Ausgangskontext und alle Kontexte, die über diesen Ausgangskontext lokalisiert werden, führen eine Syntaxanalyse von Namenszeichenfolgen, die auf der angegebenen Syntax basieren, durch.
Das folgende Beispiel zeigt, wie Sie die Namenssyntax definieren, damit der Ausgangskontext Namenszeichenfolgen gemäß INS-Syntax analysiert.
... import java.util.Hashtable; import javax.naming.Context; import javax.naming.InitialContext; import com.ibm.websphere.naming.PROPS; // WebSphere-Naming-Konstanten ... 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); // Der folgende Name wird einer CORBA-Namenskomponente wie folgt zugeordnet: // id = "a.name", kind = "in.INS.format" // Der Punkt ohne Escape-Zeichen wird als Begrenzer verwendet. // Punkte mit vorangestelltem Escape-Zeichen werden als Punkte interpretiert. java.lang.Object o = initialContext.lookup("a\\.name.in\\.INS\\.format"); ...
Die INS-Namenssyntax erfordert, dass eingebetteten Punkten (.) in einem Namen, wie z. B. in.INS.format, ein Backslash (\) als Escape-Zeichen vorangestellt wird. In einem Java-Zeichenfolgeliteral muss dem Backslash (\) ein weiterer Backslash als Escape-Zeichen vorangestellt werden.
- Geben Sie in einer Befehlszeile den tatsächlichen Zeichenfolgewert ein.
Beispiel:
- Optional: Normalisierung von Hostnamen inaktivieren
Verweise auf Hostnamen, IP-Adressen und localhost in Provider-URLs werden im Allgemeinen normalisiert. Das Format eines normalisierten Hostnamens ist das vollständig qualifizierte Format des Hostnamens. Die Normalisierung des Hostnamens verbessert die Systemeffizienz, weil sie die Verwendung des JNDI-Cache für einen bestimmten Bootstrap-Host ermöglicht, unabhängig vom Format des Verweises im Provider-URL. Wird die Normalisierung des Hostnamens durchgeführt, kann beispielsweise für die Verweise myhost, myhost.mydomain.com und localhost ein einziger JNDI-Cache verwendet werden, wenn alle Verweise sich auf denselben Host beziehen.
Die normalisierten Hostnamen werden zwischengespeichert, daher werden nachfolgende Normalisierungen schneller durchgeführt. In manchen Netzumgebungen werden die Daten für die Domänennamenssuche dynamisch geändert, was dazu führt, dass die zwischengespeicherten Daten für die Normalisierung des Hostnamens nicht mehr aktuell sind. Möglichweise müssen Sie in manchen Umgebungen die Normalisierung des Hostnamens inaktivieren. Wenn Sie die Normalisierung des Hostnamens inaktivieren, werden der Hostname und die IP-Adressen unverändert verwendet. Verweise auf localhost werden normalerweise zur Loopback-Adresse 127.0.0.1 aufgelöst.
JNDI-Clients können die Namenssyntax über eine Eigenschaft festlegen. Die Eigenschaftseinstellung wird von der Ausgangskontextfactory angewendet, wenn Sie ein neues java.naming.InitialContext-Objekt instanziieren.
Verwenden Sie eines der folgenden Verfahren, um diese Eigenschaft zu definieren:- Geben Sie in einer Befehlszeile den tatsächlichen Zeichenfolgewert ein.
Beispiel:
java -Dcom.ibm.websphere.naming.hostname.normalizer=...none...
- Erstellen Sie eine Datei mit dem Namen jndi.properties als Textdatei mit den gewünschten Eigenschaftseinstellungen.
Beispiel:
... com.ibm.websphere.naming.hostname.normalizer=...none... ...
Wenn Sie dieses Verfahren verwenden, beachten Sie, dass im Klassenpfad möglicherweise andere Instanzen der Datei jndi.properties vorhanden sind mit Eigenschaftseinstellungen, die Konflikte auslösen können. Eigenschaftseinstellungen werden bestimmt durch die Reihenfolge, in der der Klassenlader die Dateien jndi.properties berücksichtigt. Die Reihenfolge, in der der Klassenlader Dateien im Klassenpfad lokalisiert, kann nicht festgelegt werden. WebSphere Application Server enthält oder erstellt standardmäßig keine Dateien jndi.properties, die die Eigenschaft com.ibm.websphere.naming.hostname.normalizer definieren.
- Sie können die Java-Konstanten PROPS.HOSTNAME_NORMALIZER* in einem Java-Programm verwenden. Diese Java-Konstanten
werden in der Datei com.ibm.websphere.naming.PROPS definiert. Die folgenden Konstantendefinitionen werden verwendet, um anzugeben,
ob Sie dieses Verfahren verwenden:
public static final String HOSTNAME_NORMALIZER = "com.ibm.websphere.naming.hostname.normalizer"; public static final String HOSTNAME_NORMALIZER_NONE = "...none...;
Wenn Sie diese Definitionen in einem Java-Programm verwenden möchten, fügen Sie die Eigenschaftseinstellung zu einer Hash-Tabelle hinzu, und übergeben Sie sie wie folgt an den InitialContext-Konstruktor:
java.util.Hashtable env = new java.util.Hashtable(); ... env.put(PROPS.HOSTNAME_NORMALIZER, PROPS.HOSTNAME_NORMALIZER_NONE); // Normalisierung des Hostnamens inaktivieren ... javax.naming.Context initialContext = new javax.naming.InitialContext(env);
Beispiel: Normalisierung des Hostnamens inaktivieren
Die Eigenschaft der Normalisierungsfunktion kann an den InitialContext-Konstruktor über den entsprechenden Parameter in den Systemeigenschaften oder in einer Datei jndi.properties übergeben werden. Der Ausgangskontext und alle Kontexte, die über diesen Ausgangskontext lokalisiert werden, verwenden diese Eigenschaftseinstellung.
Das folgende Beispiel zeigt, wie Sie die Normalisierung des Hostnamens inaktivieren:
... import java.util.Hashtable; import javax.naming.Context; import javax.naming.InitialContext; import com.ibm.websphere.naming.PROPS; // WebSphere-Naming-Konstanten ... 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(...); ...
- Geben Sie in einer Befehlszeile den tatsächlichen Zeichenfolgewert ein.
Beispiel:
Unterartikel
Beispiel: Standardausgangskontext abrufen
Ein Programm hat verschiedene Möglichkeiten, den Standardausgangskontext abzurufen.Beispiel: Ausgangskontext durch Definieren der Eigenschaft "Provider-URL" abrufen
Im Allgemeinen müssen JNDI-Clients (Java Naming and Directory Interface) voraussetzen können, dass die richtige Umgebung bereits konfiguriert wurde und Eigenschaftswerte nicht mehr explizit konfiguriert und an den InitialContext-Konstruktor übergeben werden müssen. Ein JNDI-Client muss jedoch auf einen anderen als den in seiner Umgebung definierten Namespace zugreifen. In diesem Fall ist es erforderlich, die vom Konstruktor InitialContext verwendete Eigenschaft "java.naming.provider.url" (Provider-URL) explizit zu konfigurieren. Ein Provider-URL enthält Daten des Bootstrap-Servers, die die Ausgangskontextfactory verwenden kann, um einen Ausgangskontext abzurufen. Alle Eigenschaftswerte, die direkt an den InitialContext-Konstruktor übergeben wurden, haben eine höhere Priorität als die gleichen, in der Umgebung ermittelten Einstellungen.Beispiel: Eigenschaft für Provider-URL zur Auswahl eines vom Ausgangskontext abweichenden Stammkontextes definieren
Jeder Server enthält einen eigenen Stammkontext, und beim Booten eines Servers ist der Serverstamm der standardmäßig verwendete JNDI-Ausgangskontext. Meist ist diese Standardeinstellung der gewünschte Ausgangskontext, da Systemartefakte, wie z. B. EJB-Homes, dort gebunden werden. Es sind jedoch andere Stammkontexte vorhanden, die interessante Bindungen enthalten können. Es besteht die Möglichkeit, einen Provider-URL für die Auswahl anderer Stammkontexte anzugeben.Beispiel: EJB-Home- oder -Geschäftsschnittstelle mit JNDI suchen
Die meisten Anwendungen, die Java Naming and Directory Interface (JNDI) verwenden, werden in einem Container ausgeführt. Bei manchen Anwendungen ist das nicht der Fall. Welcher Name zum Lokalisieren eines Objekts verwendet wird, hängt davon ab, ob die Anwendung in einem Container ausgeführt wird. Manchmal ist es für eine Anwendung besser, einen corbaname-URL als Lookup-Namen zu verwenden. Containerstützte JNDI-Clients und Thin-Java-Clients können einen corbaname-URL verwenden.Interoperabilitätsprobleme bei JNDI
Sie müssen zusätzliche Schritte ausführen, wenn Ihre Programme mit produktfremden JNDI-Clients interagieren und MQSeries-Ressourcen an einen Namespace gebunden werden sollen.JNDI-Caching
Um die Leistung der JNDI-Verarbeitung (Java Naming and Directory Interface) zu verbessern, nutzt die JNDI-Implementierung des Produkts die Caching-Technologie, um die Anzahl der fernen Aufrufe an den Namensserver für Lookup-Operationen zu vermindern. Verwenden Sie in den meisten Fällen die Cachestandardeinstellung.JNDI-Cacheeinstellungen
Im Folgenden werden Einstellungen für verschiedene JNDI-Cacheeigenschaften (Java Naming and Directory Interface) beschrieben. Vergewissern Sie sich, dass alle Eigenschaftswerte Zeichenfolgewerte sind.Hinweise zur JNDI-CORBA-Namenszuordnung
Namensserver von WebSphere Application Server sind eine Implementierung der CORBA-Schnittstelle "CosNaming". Das Produkt stellt eine JNDI-Implementierung (Java Naming and Directory Interface) bereit, die Sie für den Zugriff auf CosNaming-Namensserver über die JNDI-Schnittstelle verwenden können. Bei der Zuordnung von JNDI-Namen zu CORBA-Namen (und umgekehrt) sind verschiedene Aspekte zu beachten.


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