Logische Ansicht des Namespace
Der Namespace für die gesamte Zelle wird auf alle Server in der Zelle verteilt. Jeder Serverprozess enthält einen Namensserver. Alle Namensserver stellen dieselbe logische Sicht des Zellen-Namespace bereit.
Die verschiedenen Serverstämme und persistenten Partitionen des Namespace sind über einen System-Namespace miteinander verbunden. Die Struktur des System-Namespace kann dazu verwendet werden, zu jedem Kontext in einem Zellen-Namespace zu wechseln.
Das folgende Diagramm zeigt eine logische Sicht des Namespace in einer Installation mit mehreren Servern.

Die Bindungen im vorherigen Diagramm sind mit durchgezogenen Pfeilen, Beschriftungen in Fettschrift und gestrichelten Pfeilen mit grauen Beschriftungen. Durchgezogene Pfeile stehen für primäre Bindungen. Eine primäre Bindung entsteht, wenn der zugeordnete Subkontext erstellt wird. Gestrichelte Pfeile stehen für verknüpfte Bindungen. Eine verknüpfte Bindung entsteht, wenn ein bestehender Kontext unter einem weiteren Namen gebunden wird. Verknüpfte Bindungen werden zur Vereinfachung oder zwecks Interoperabilität mit früheren Versionen von WebSphere Application Server hinzugefügt.
Ein Namespace einer Zelle besteht aus Kontexten, die sich auf Servern überall in der Zelle befinden. Alle Namensserver der Zelle bieten dieselbe logische Sicht auf den Zellen-Namespace. Ein Namensserver konstruiert diese Ansicht beim Neustart, indem er die Konfigurationsdaten liest. Jeder Namensserver besitzt eine eigene lokale speicherresidente Kopie des Namespace und benötigt keinen weiteren aktiven Server. Es gibt jedoch einige Ausnahmen. Serverstämme für andere Server werden nicht unter allen Servern repliziert. Der entsprechende Server für einen Serverstamm muss aktiv sein, damit der Zugriff auf den Serverstammkontext möglich ist.
In Zellen mit WebSphere Application Server Network Deployment können die zellen- und knotenpersistenten Bereiche gelesen werden, auch wenn der Deployment Manager und der zugehörige Node Agent nicht aktiv sind. Allerdings muss der Deployment Manager aktiv sein, damit das zellenpersistente Segment aktualisiert werden kann, und ein Node Agent muss aktiv sein, damit das zugehörige knotenpersistente Segment aktualisiert werden kann.
Namespacepartitionen
Es gibt fünf Hauptpartitionen im Namespace einer Zelle:
- Systemnamespacepartition
- Partition für Serverstämme
- Zellenpersistente Partition
- Knotenpersistente Partition
- Anwendungspartition
- Systemnamespacepartition
- Der
System-Namespace enthält eine Struktur von Kontexten, die auf der Zellentopologie basiert. Die Systemstruktur ermöglicht Querverweise zu allen Teilen des Namespace der Zelle und zum
Zellenstamm anderer Zellen, die als fremde Zellen konfiguriert sind. Der Stamm dieser Struktur ist der Zellenstamm. Zusätzlich zum Zellenstamm enthält die Systemstruktur ein
Knotenstamm für jeden Knoten in der Zelle.
Vom Knotenstamm aus kann auf andere Kontexte zugegriffen werden, die für den Knoten von
spezieller Bedeutung sind, wie der knotenpersistente Stamm und die Serverstämme für Server, die
in diesem Knoten konfiguriert sind.
Alle Kontexte im System-Namespace sind schreibgeschützt, d. h., es können keine Bindungen hinzugefügt, aktualisiert oder entfernt werden.
- Partition für Serverstämme
- Jeder Server in einer Zelle
hat einen Serverstammkontext. Der Serverstamm eines Servers gehört allein zu diesem jeweiligen Server. Die Serverstämme aller Server in einer Zelle können als zugehörig zu einer temporären Schreib-/Lesepartition
des Namespace der Zelle angesehen werden.
Systemartefakte für Serveranwendungen und Ressourcen, wie EJB-Homes (Enterprise JavaBeans), werden unter dem
Serverstammkontext des zugeordneten Servers gebunden. Eine Serveranwendung kann auch unter ihrem Serverstamm Bindungen hinzufügen. Diese Bindungen sind
temporär. Deshalb erzeugt die Serveranwendung alle erforderlichen Bindungen beim Anwendungsstart, sodass sie immer existieren, wenn die Anwendung aktiv ist.
Ein Server-Cluster besteht aus vielen Servern, die logisch äquivalent sind. Jedes Member des Cluster hat seinen eigenen Serverstamm. Diese Serverstämme werden im Cluster nicht repliziert. Wenn der Serverstamm eines Member eine Bindung hinzugefügt wird, wird dies also nicht an die Serverstämme der anderen Cluster-Member weitergegeben. Um im ganzen Cluster dieselbe Sicht zu haben, sollten alle Benutzerbindungen unter dem Serverstamm durch die Serveranwendung beim Anwendungsstart erzeugt werden, sodass die Bindungen unter dem Serverstamm jedes Cluster-Member vorliegen. Aufgrund des WLM-Verhaltens hat ein JNDI-Client außerhalb eines Cluster keine Kontrolle darüber, der Serverstammkontext welches Cluster-Member das Ziel der JNDI-Operation wird. Deshalb sollten Sie Bindungsoperationen an den Serverstamm eines Cluster-Member nur von innerhalb dieses Cluster-Member-Prozesses ausführen.
Namensbindungen im Geltungsbereich des Servers beziehen sich auf den Serverstamm eines Servers.
Die Namen der Cluster-Member müssen innerhalb einer Zelle eindeutig sein und sich vom Zellennamen unterscheiden.
- Zellenpersistente Partition
- Der Stammkontext
der zellenpersistenten Partition ist der zellenpersistente Stamm. Eine Bindung, die unter dem
zellenpersistenten Stamm erstellt wurde, wird als Teil der Zellenkonfiguration gespeichert und
existiert weiter, bis sie explizit entfernt wird.
Anwendungen, die zusätzliche persistente Bindungen von Objekten erstellen müssen, die allgemein der
Zelle zugeordnet sind, können diese Objekte unter dem zellenpersistenten Stamm.
Wichtig ist hierbei, dass der zellenpersistente Bereich nicht für temporäre, schnell veränderliche Bindungen gedacht ist. Vielmehr sollten die Bindungen statistischer Art sein, wie z. B. Teil einer Anwendungskonfiguration, und sollten nicht zur Laufzeit erzeugt werden.
Der zellenpersistente Bereich kann auch dann gelesen werden, wenn der Deployment Manager nicht aktiv ist. Der Deployment Manager muss jedoch aktiv sein, wenn Sie das zellenpersistente Segment aktualisieren möchten. Da jeder Server eine eigene Kopie der zellenpersistenten Partition besitzt, hat jeder Server die Möglichkeit, Objekte, die an die zellenpersistente Partition gebunden sind, lokal zu suchen.
Namensbindungen im Geltungsbereich der Zelle beziehen sich auf den zellenpersistenten Stamm einer Zelle.
- Knotenpersistente Partition
- Die knotenpersistente Partition
gleicht der Zellenpartition, außer dass jeder Knoten seinen eigenen knotenpersistente Stamm hat. Eine
Bindung, die unter dem knotenpersistenten Stamm erstellt wurde, wird als Teil der Konfiguration dieses
Knotens gespeichert und existiert weiter, bis sie explizit entfernt wird.
Anwendungen, die zusätzliche persistente Bindungen von Objekten erstellen müssen, die einem speziellen Knoten zugeordnet sind, können diese Objekte unter dem knotenpersistenten Stamm dieses Knotens binden. Wie beim zellenpersistenten Bereich ist es wichtig, dass der knotenpersistente Bereich nicht für temporäre, schnell veränderliche Bindungen gedacht ist. Vielmehr sollten die Bindungen statistischer Art sein, wie z. B. Teil einer Anwendungskonfiguration, und sollten nicht zur Laufzeit erzeugt werden.
Der knotenpersistente Bereich für einen Knoten kann von jedem Server des Knotens gelesen werden, sofern der entsprechende Node Agent nicht aktiv ist. Der Node Agent muss jedoch aktiv sein, wenn Sie den knotenpersistenten Bereich aktualisieren möchten oder wenn ein Server außerhalb des Knotens Daten von dieser knotenpersistenten Partition lesen möchte. Da jeder Server eines Knotens eine eigene Kopie der knotenpersistenten Partition für seinen Knoten besitzt, hat jeder Server die Möglichkeit, Objekte, die an diese knotenpersistente Partition gebunden sind, lokal zu suchen.
Knotenbezogene Namensbindungen beziehen sich auf den knotenpersistenten Stamm eines Knotens.
- Anwendungspartition
- Die Spezifikation Java EE 6 führt Modul-, Anwendungs- und globale Namespaces ein. JNDI-Namen von Java-URLs mit Präfixen wie
java:module, java:app und java:global können auf die jeweiligen Namenspaces zugreifen. In manchen Fällen
ist der Zugriff auf die Namespaces nur lokal möglich, in anderen erfolgt Fernzugriff.
Die Anwendungspartition enthält Namespaces, auf die über ein fernes System zugegriffen werden kann. Das Stammverzeichnis des Namespace java:global ist der Anwendungsstammkontext. Die Stammverzeichnisse anderer Namespaces befinden sich im Subkontext "com.ibm.ws.AppNameSpaces". Beispielsweise wird der Stammkontext java:app für die Anwendung MyApp mit dem Namen MyApp/root relativ zu com.ibm.ws.AppNameSpaces gebunden. Modul- und Komponenten-Namespaces sind nur über Fernzugriff verfügbar, wenn das Modul ein Clientmodul in einem Modus für Serverimplementierung oder in einem eingebundenen Modus ist. Beispielsweise ist der Stammkontext java:module für das von einem Server implementierte Clientmodul MyClientModule in der Anwendung MyApp an den Namen MyApp/MyClientModule/root relativ zu com.ibm.ws.AppNameSpaces gebunden. Der Komponenten-Namespace, der comp/env-Bindungen enthält, wird für dasselbe Modul unter MyApp/MyClientModule/ClientComponent/root relativ zu com.ibm.ws.AppNameSpaces gebunden.
Anwendungsressourcen, wie z. B. EJB-Referenzen, Ressourcenreferenzen und Umgebungseinträge mit java:global-Namen werden bei der Installation der definierenden Anwendung an den Namespace java:global gebunden. Die Anwendung muss nicht aktiv sein, damit diese Namensbindungen für andere Anwendungen verfügbar sind.
Ressourcen, die in Anwendungen mit java:global-Namen definiert sind, werden in der Anwendungspartition für alle Server in der Zelle gebunden, wenn die Daten an die entsprechenden Knoten verteilt werden. Anwendungen können diese Objekte von jedem Server in der Zelle erkennen. EJB-Homes werden auch im Namespace java:global mit Namen im Format java:global/Anwendungsname/Modulname/Bean-Name gebunden, jedoch nur in Servern, in denen die Enterprise-Beans ausgeführt werden. java:global-Lookups, die sich auf eine EJB beziehen, können auf jedem Server in der Zelle aufgelöst werden.