Beispiel: Standardausgangskontext abrufen
Ein Programm hat verschiedene Möglichkeiten, den Standardausgangskontext abzurufen.
Im folgenden Beispiel wird der Standardausgangskontext abgerufen. Beachten Sie, dass kein Provider-URL an den Konstruktor javax.naming.InitialContext übergeben wird.
...
import javax.naming.Context;
import javax.naming.InitialContext;
...
Context initialContext = new InitialContext();
...
Der Standardausgangskontext, der zurückgegeben wird, hängt von der Laufzeitumgebung des JNDI-Clients (Java™ Naming and Directory Interface) ab. Die folgenden Ausgangskontexte werden in den verschiedenen Umgebungen zurückgegeben:
- Thin Client
- Der Ausgangskontext ist der Serverstammkontext des Servers, der auf dem lokalen Host an Port 2809 ausgeführt wird.
- Reiner Client
- Der Ausgangskontext ist der Kontext, der von der
Eigenschaft "java.naming.provider.url" angegeben und an den Befehl "launchClient" mit dem Befehlszeilenparameter
"-CCD" übergeben wird. Der Kontext ist normalerweise der Serverstammkontext des Servers an der im URL angegebenen Adresse, obwohl es möglich ist, einen corbaname- oder corbaloc-URL zu erstellen, der in einen anderen Kontext aufgelöst wird.
Wenn kein Provider-URL angegeben ist, ist der Ausgangskontext der Stammkontext des Servers, der auf dem mit den Befehlszeilenparametern -CCproviderURL bzw. -CCBootstrapHost und -CCBootstrapPort angegebenen Host ausgeführt wird. Der Standardhost ist der lokale Host, der Standardport ist 2809.
- Serverprozess
- Der Ausgangskontext ist der Serverstammkontext für diesen Prozess.
Obwohl im obigen Beispiel kein Provider-URL explizit angegeben ist, kann InitialContext einen in anderen Positionen definierten Provider-URL lokalisieren. Dazu werden diese Positionen nach Eigenschaftseinstellungen durchsucht.
Die Benutzer von Eigenschaften, die die ORB-Initialisierung beeinträchtigen, müssen den Rest dieses Abschnitts lesen, um genauer verstehen zu können, wie Ausgangskontexte abgerufen werden.
Server zum Abrufen des Ausgangskontexts bestimmen
Die Namensserver von WebSphere Application Server sind CORBA-CosNaming-Namensserver, und das Produkt stellt die Implementierung eines CosNaming-JNDI-Plug-ins für JNDI-Clients bereit, um Naming-Operationen für Produkt-Namespaces auszuführen. Die Implementierung des CosNaming-Plug-ins wird über eine JNDI-Eigenschaft ausgewählt, die an den InitialContext-Konstruktor übergeben wird. Diese Eigenschaft ist java.naming.factory.initial, und sie gibt die Implementierung der Ausgangskontextfactory an, die zum Abrufen eines Ausgangskontexts verwendet werden soll. Die Factory gibt eine javax.naming.Context-Instanz zurück, die Teil der Implementierung ist.
Die Ausgangskontextfactory com.ibm.websphere.naming.WsnInitialContextFactory wird gewöhnlich von Anwendungen für die Ausführung von JNDI-Operationen verwendet. Die Laufzeitumgebung von WebSphere Application Server ist so definiert, dass diese Ausgangskontextfactory verwendet wird, wenn der JNDI-Client keine Factory explizit angibt. Wenn die Ausgangskontextfactory aufgerufen wird, wird ein Ausgangskontext abgerufen. In den folgenden Abschnitten wird erläutert, wie die Ausgangskontextfactory den Ausgangskontext in Client- und Serverumgebungen abruft.
- Ausgangsreferenzen in Serverprozessen registrieren
Jeder WebSphere Application Server hat einen ORB, den er verwendet, um Aufrufe von Objekten, die auf diesem Server ausgeführt werden, zu empfangen und zuzuteilen. Services, die im Serverprozess ausgeführt werden, können Ausgangsreferenzen am ORB registrieren. Jede Ausgangsreferenz wird unter einem Schlüssel registriert, der ein Zeichenfolgenschlüssel ist. Jedes CORBA-Objekt kann eine Ausgangsreferenz sein. Namensserver von WebSphere Application Server registrieren verschiedene Ausgangskontexte als Ausgangsreferenzen unter vordefinierten Schlüsseln. Jede Ausgangsreferenz eines Namensservers ist eine Instanz der Schnitttstelle org.omg.CosNaming.NamingContext.
- Ausgangsreferenzen in reinen Clientprozessen abrufen
Reine JNDI-Clients, d. h., JNDI-Clients, die nicht in einem Prozess von WebSphere Application Server ausgeführt werden, haben ebenfalls eine ORB-Instanz. Diese Client-ORB-Instanz kann an den InitialContext-Konstruktor übergeben werden, aber normalerweise erstellt und initialisiert die Ausgangskontextfactory die Client-ORB-Instanz sichtbar. Ein Client-ORB kann mit Ausgangsreferenzen initialisiert werden, aber die Ausgangsreferenzen werden wahrscheinlich in Objekte aufgelöst, die auf einem Server ausgeführt werden. Die Ausgangskontextfactory definiert bei der ORB-Initialisierung keine Standardausgangsreferenzen. Wenn die Methode resolve_initial_references auf dem Client-ORB aufgerufen wird und keine Ausgangsreferenzen konfiguriert wurden, schlägt der Methodenaufruf fehl. Diese Bedingung ist für reine Clientprozesse typisch. Wenn Sie eine NamingContext-Ausgangsreferenz abrufen möchten, muss die Ausgangskontextfactory string_to_object mit einem CORBA-Objekt-URL des Typs IIOP, wie z. B. corbaloc:iiop:myhost:2809, aufrufen. Der URL gibt die Adresse des Servers an, von dem der Ausgangskontext abgerufen werden soll. Die Host- und Portangabe wird vom Provider-URL, der an den InitialContext-Konstruktor übergeben wird, extrahiert.
Ist kein Provider-URL definiert, verwendet die Ausgangskontextfactory von WebSphere Application Server den Standard-Provider-URL, corbaloc:iiop:localhost:2809.
Ist kein Provider-URL definiert, verwendet die Ausgangskontextfactory von WebSphere Application Server den Standard-Provider-URL corbaloc:iiop:Name.Ihres.Servers:2809.
Die ORB-Methode string_to_object löst den URL auf und kommuniziert mit dem Zielserver-ORB, um die Ausgangsreferenz abzurufen.
- Ausgangsreferenzen in Serverprozessen abrufen
Wenn der JNDI-Client in einem Prozess von WebSphere Application Server ausgeführt wird, ruft die Ausgangskontextfactory eine Referenz auf die Server-ORB-Instanz ab, vorausgesetzt, der JNDI-Client stellt keine ORB-Instanz bereit. Normalerweise verwenden JNDI-Clients, die in Serverprozessen ausgeführt werden, die Server-ORB-Instanz, d. h., sie übergeben eine ORB-Instanz nicht an den InitialContext-Konstruktor. Der Namensserver, der im Serverprozess ausgeführt wird, definiert einen Provider-URL als Eigenschaft "java.lang.System", die als Standard-Provider-URL für alle JNDI-Clients im Prozess verwendet werden soll. Dieser Standard-Provider-URL ist corbaloc:rir:/NameServiceServerRoot. Dieser URL wird in den Serverstammkontext für diesen Server aufgelöst. (Der URL entspricht dem Aufrufen von resolve_initial_references auf dem ORB mit dem Schlüssel NameServiceServerRoot. Der Namensserver registriert den Serverstammkontext als Ausgangsreferenz unter diesem Schlüssel.)
- Das traditionelle ORB-Protokoll
In den Versionen vor WebSphere Application Server Version 5.x wird eine andere ORB-Implementierung verwendet. Diese ORB-Implementierung verwendete ein traditionelles Protokoll und nicht das INS-Protokoll (Interoperable Name Service), das jetzt verwendet wird. Diese Änderung hat sich auf die Implementierung der Ausgangskontextfactory ausgewirkt. Im Vergleich zu früheren Releases von WebSphere Application Server verhalten bestimmte Typen reiner Clients sich anders, wenn sie JNDI-Ausgangskontexte abrufen. Nachfolgend wird dieses Verhalten ausführlich beschrieben.
Die folgenden ORB-Eigenschaften werden mit dem traditionellen ORB-Protokoll für die ORB-Initialisierung verwendet und sind jetzt veraltet:
- com.ibm.CORBA.BootstrapHost
- com.ibm.CORBA.BootstrapPort
Der neue INS-ORB unterscheidet sich wesentlich dadurch, dass er kein Standardverhalten bereitstellt, wenn keine Ausgangsreferenzen definiert sind.
Im traditionellen ORB waren die Standardwerte für den Bootstrap-Host und den Bootstrap-Port localhost und 900.
Im traditionellen ORB waren die Standardwerte für den Bootstrap-Host und den Bootstrap-Port Name.Ihres.Servers und 900.
Alle Ausgangsreferenzen wurden von dem Server abgerufen, der auf dem Bootstrap-Host und über den Bootstrap-Port ausgeführt wurde. Wenn der ORB-Benutzer keinen Bootstrap-Host und Bootstrap-Port bereitstellt, werden alle Ausgangsreferenzen von dem Server aufgelöst, der am lokalen Host und an Port 900 ausgeführt wird. Der INS-ORB verwendet kein Konzept, das auf einem Bootstrap-Host oder Bootstrap-Port basiert. Alle Ausgangsreferenzen werden unabhängig voneinander definiert. Das bedeutet, andere Ausgangsreferenzen werden in andere Server aufgelöst. Wenn ORB.resolve_initial_references mit einem Schlüssel aufgerufen wird und der ORB nicht mit einer Ausgangsreferenz, die diesen Schlüssel besitzt, initialisiert wird, schlägt der Aufruf fehl.
In den Releases vor Version 5 ruft die Ausgangskontextfactory resolve_initial_references im ORB ohne Provider-URL auf. Diese Aktion konnte ausgeführt werden, wenn ein Namensserver auf dem Standard-Bootstrap-Host und am Standard-Bootstrap-Port ausgeführt wurde. Im aktuellen Release, mit dem INS-ORB, würde diese Operation fehlschlagen. (Tatsächlich würde der ORB in der Übergangsphase wieder zum traditionellen Protokoll wechseln, wenn das traditionelle Protokoll jedoch nicht mehr unterstützt wird, würde die Operation fehlschlagen.)
Die Ausgangskontextfactory verwendet jetzt den Standard-Provider-URL, corbaloc:iiop:localhost:2809, und ruft string_to_object mit dem Provider-URL auf.
Die Ausgangskontextfactory verwendet jetzt den Standard-Provider-URL, corbaloc:iiop:Name.Ihres.Servers:2809, und ruft string_to_object mit dem Provider-URL auf.
Bei dieser Operation wird das Verhalten reiner Clients, die in älteren Releases keine ORB-Bootstrapeigenschaften oder keinen Provider-URL angaben, beibehalten. Diese andere Implementierung der Ausgangskontextfactory ändert das Verhalten bestimmter traditioneller reiner Clients, die keinen Provider-URL angeben:
- Clients, die beim Abrufen des Ausgangskontexts die oben aufgelisteten ORB-Bootstrapeigenschaften definieren.
- Clients, die ihre eigene ORB-Instanz dem InitialContext-Konstruktur bereitstellen.
Es gibt zwei Möglichkeiten, diese Verhaltensänderung zu umgehen:
- Geben Sie immer einen IIOP-Provider-URL an. Diese Methode ist nicht von den Eigenschaften des Bootstrap-Hosts und des Bootstrap-Ports abhängig und kann weiterverwendet werden, wenn die Unterstützung der Eigenschaften des Bootstrap-Hosts und des Bootstrap-Ports entfernt wird. Sie können beispielsweise die Werte meinHost und 2809 für die Eigenschaften "Bootstrap-Host" und "Boostrap-Port" auch in Form von corbaloc:iiop:meinHost:2809 ausdrücken.
- Verwenden Sie einen Provider-URL des Typs "rir":
- Geben Sie corbaloc:rir:/NameServiceServerRoot an, wenn der ORB so initialisiert wird, dass ein Server der Version 5 als Bootstrap-Server verwendet werden soll.
- Geben Sie corbaname:rir:/NameService#domain/legacyRoot an, wenn der ORB so initialisiert wird, dass ein Server der Version 4.0.x als Bootstrap-Server verwendet werden soll.
- Geben Sie corbaloc:rir:/NameService an, wenn der ORB so initialisiert wird, dass ein anderer Server als ein Server der Version 4.0.x oder 5 als Bootstrap-Server verwendet werden soll.
URLs dieses Typs entsprechen dem Aufrufen von resolve_initial_references auf dem ORB mit dem angegebenen Schlüssel. Wenn die Eigenschaften des Bootstrap-Hosts und des Bootstrap-Ports zur Initialisierung des ORB verwendet werden, funktioniert diese Methode nur so lange, wie diese Eigenschaften unterstützt werden.
- Die Suchreihenfolge des InitialContext-Konstruktors bei der Suche nach JNDI-Eigenschaften
Wenn der am Anfang dieses Abschnitts gezeigte Codeauszug von einer Anwendung ausgeführt wird, ist der Bootstrap-Server von dem Wert der Eigenschaft "java.naming.provider.url" abhängig.
Wird die Eigenschaft nicht definiert (in Serverprozessen wird der Standardwert als Systemeigenschaft definiert), werden der Standardhost localhost und der Standardport 2809 als Adresse des Servers, von dem der Ausgangskontext abgerufen werden soll, verwendet.
Wird die Eigenschaft nicht definiert (in Serverprozessen wird der Standardwert als Systemeigenschaft definiert), werden der Standardhost Name.Ihres.Servers und der Standardport 2809 als Adresse des Servers, von dem der Ausgangskontext abgerufen werden soll, verwendet.
Die JNDI-Spezifikation beschreibt, an welcher Position der InitialContext-Konstruktor die Einstellungen der Eigenschaft "java.naming.provider.url" sucht. Die Eigenschaft wird in der angezeigten Reihenfolge an folgenden Positionen ausgewählt:
- InitialContext-Konstruktor
- Das gilt nicht für das obige Beispiel, da das Beispiel den leeren InitalContext-Konstruktor verwendet.
- Systemumgebung
- Sie können JNDI-Eigenschaften zur Systemumgebung hinzufügen, indem Sie beim Aufruf des Java-Befehls eine entsprechende Option angeben oder indem Sie Programmcode verwenden. Die empfohlene Vorgehensweise, den Provider-URL in der Systemumgebung zu definieren, besteht darin, eine Option für den Aufruf des Java-Befehls anzugeben. Die Definition des Provider-URL ist nicht zeitabhängig, daher erhalten Sie beim Abrufen eines Standardausgangskontexts immer dasselbe Ergebnis. Allgemein wird empfohlen, zum Definieren der Eigenschaft "Provider-URL" keinen Programmcode zu verwenden, da dies möglicherweise anderen, nicht zugehörigen Code, der an anderer Stelle im Prozess ausgeführt wird, nachteilig beeinflusst.
- Datei jndi.properties
- Es gibt viele jndi.properties-Dateien, die im Bereich des aktiven Klassenladers wirksam sind. Alle jndi.properties-Dateien werden zum Definieren von JNDI-Eigenschaften verwendet, aber die Einstellung des Provider-URL wird von der ersten Datei jndi.properties, die vom Klassenlader zurückgegeben wird, bestimmt.