Vue logique d'un espace de nom

L'espace de nom pour la cellule toute entière est fédéré pour tous les serveurs de la cellule. Chaque processus serveur contient un serveur de noms. Tous les serveurs de noms fournissent la même vue logique de l'espace de nom de la cellule.

Les diverses racines de serveur et partitions persistantes de l'espace de nom sont interconnectées au moyen d'un espace de nom système. Vous pouvez utiliser la structure de l'espace de nom système pour passer à l'un des contextes de l'espace de nom d'une cellule.

Le diagramme ci-dessous montre une vue logique de l'espace de nom d'une installation comportant plusieurs serveurs.

Table de la vue logique de l'espace de nom

Dans le diagramme ci-dessus, les liaisons sont représentées par des flèches solides, libellées en gras, et par des flèches tiretées, libellées en gris. Les flèches solides représentent les liaisons principales. Une liaison principale est créée lorsque le sous-contexte associé est créé. Les flèches tiretées indiquent les liaisons liées. Une liaison liée est formée lorsqu'un contexte existant est lié sous un nom additionnel. Les liaisons liées sont ajoutées pour des raisons de commodité ou d'interopérabilité avec les versions précédentes de WebSphere Application Server.

Un espace de nom de cellule est composé de contextes qui résident dans tous les serveurs de la cellule. Tous les serveurs de noms de la cellule fournissent la même vue logique de l'espace de nom de la cellule. Un serveur de noms construit cette vue au démarrage en lisant les informations de configuration. Chaque serveur de noms comporte sa propre copie en mémoire locale de l'espace de nom ; son fonctionnement ne dépend donc pas de l'exécution d'un autre serveur. Il existe cependant quelques exceptions. Les racines de serveurs pour d'autres serveurs ne sont pas répliquées sur tous les serveurs. Le serveur correspondant à une racine de serveur doit être en cours d'exécution pour qu'il soit possible d'accéder au contexte racine de ce serveur.

Dans les cellules WebSphere Application Server Network Deployment, les zones persistantes de cellule et de noeud peuvent être lues même si le gestionnaire de déploiement et l'agent de noeud respectifs ne sont pas en cours de fonctionnement. Cependant, le gestionnaire de déploiement doit être en cours de fonctionnement pour la mise à jour du segment persistant de la cellule et un agent de noeud doit être en cours de fonctionnement pour que son segment persistant soit mis à jour.

Partitions d'espaces de nom

Il existe cinq partitions principales dans l'espace de nom d'une cellule :

Partition de l'espace de nom système
L'espace de nom système contient une structure de contextes basée sur la topologie de la cellule. La structure système prend en charge le balayage de toutes les parties de l'espace de nom d'une cellule et de la racine d'autres cellules configurées en tant que cellules étrangères. La racine de cette structure est la racine de cellule. Outre la racine de cellule, la structure système contient une racine de noeud pour chaque noeud de la cellule. Vous pouvez accéder à d'autres contextes intéressants, spécifiques au noeud à partir de la racine du noeud, telle que la racine du noeud persistant et les racines de serveurs configurés dans ce noeud.

Tous les contextes de l'espace de nom système sont en lecture seule. Vous ne pouvez ajouter, mettre à jour ou supprimer aucune liaison.

Partition de racines de serveurs
Chaque serveur d'une cellule a un contexte de racine de serveur. Une racine de serveur est spécifique à un serveur particulier. Vous pouvez considérer les racines de tous les serveurs d'une cellule comme si elles se trouvaient dans une partition en lecture/écriture transitoire de l'espace de nom de la cellule. Les objets système, tels que les foyers de beans enterprise (EJB), pour les applications de serveur et les ressources, sont liés sous le contexte racine de serveur du serveur associé. Une application serveur peut également ajouter des liaisons sous sa racine de serveur. Ces liaisons sont transitoires. C'est pourquoi, l'application serveur crée toutes les liaisons requises au démarrage de l'application afin qu'elles existent lors de l'exécution de l'application.

Un cluster de serveurs est composé de nombreux serveurs qui sont logiquement équivalents. Chaque membre du cluster a sa propre racine de serveur. Ces racines de serveur ne sont pas répliquées sur l'ensemble du cluster. En d'autres termes, l'ajout d'une liaison à la racine de serveur d'un membre ne sera pas répercuté sur les racines de serveur des autres membres du cluster. Pour maintenir la même vue sur l'ensemble du cluster, toutes les liaisons utilisateur sous la racine de serveur doivent être créées par l'application serveur au démarrage de l'application afin que les liaisons soient présentes sous la racine de serveur de chaque membre du cluster. En raison du comportement de la gestion de la charge de travail (WLM), un client JNDI situé en dehors d'un cluster ne peut pas déterminer le contexte racine de serveur du membre de cluster qui sera la cible d'une opération JNDI. Par conséquent, vous ne devez exécuter les opérations de liaison vers la racine de serveur d'un membre du cluster qu'à partir du processus de ce membre de cluster.

Les liaisons de noms configurés au niveau du serveur dépendent de la racine de serveur d'un serveur.

Le nom d'un membre de cluster doit être unique au sein d'une cellule et doit être différent du nom de cette dernière.

Partition persistante de cellule
Le contexte de racine de la partition persistante de cellule est la racine persistante de cellule. Une liaison créée sous la racine persistante de la cellule est enregistrée dans la configuration de la cellule et continue à exister jusqu'à sa suppression explicite. Les applications qui ont besoin de créer des liaisons persistantes additionnelles pour des objets généralement associés à la cellule peuvent lier ces objets sous la racine persistante de la cellule.

Il est important de noter que la zone persistante de cellule n'est pas conçue pour les liaisons transitoires, à changement rapide. Les liaisons sont de nature plus statique, elles font partie par exemple de l'installation ou de la configuration d'une application ; elles ne sont pas créées à l'exécution.

La zone de persistance de cellule peut être lue même si le gestionnaire de déploiement n'est pas en cours d'exécution. Toutefois, il faut que le gestionnaire de déploiement s'exécute pour qu'il soit possible de mettre à jour le segment persistant de la cellule. Du fait que chaque serveur contient sa propre copie de la partition persistante de la cellule, n'importe quel serveur peut rechercher localement des objets liés dans la partition persistante de la cellule.

Les liaisons de noms configurés au niveau de la cellule dépendent de la racine persistance de cellule de la cellule.

Partition persistante de noeud
La partition persistante de noeud diffère de la partition de cellule en ce sens que chaque noeud a sa propre racine persistante de noeud. Une liaison créée sous une racine persistante de noeud est enregistrée dans la configuration de ce noeud et continue à exister jusqu'à sa suppression explicite.

Les applications qui ont besoin de créer des liaisons persistantes additionnelles pour des objets associés à un noeud spécifique peuvent lier ces objets sous la racine persistante de noeud de ce noeud particulier. Comme pour la zone persistante de cellule, il est important de noter que la zone persistante de noeud n'est pas conçue pour les liaisons transitoires, à changement rapide. Ces liaisons sont de nature plus statique, elles font partie par exemple de l'installation ou de la configuration d'une application ; elles ne sont pas créées à l'exécution.

La zone persistante de noeud d'un noeud peut être lue à partir de n'importe quel serveur du noeud même si l'agent de noeud correspondant n'est pas en cours d'exécution. Cependant, l'agent de noeud doit être en cours d'exécution pour qu'il soit possible de mettre à jour la zone persistante de noeud ou pour que tout serveur extérieur au noeud puisse lire des données à partir de la partition persistante de ce noeud. Du fait que chaque serveur d'un noeud contient sa propre copie de la partition persistante de noeud de ce noeud, n'importe quel serveur du noeud peut rechercher localement des objets liés dans la partition persistante de ce noeud.

Les liaisons de noms configurés au niveau du noeud sont liées à la racine persistante de noeud du noeud.

Partition applications
La spécification Java EE 6 introduit trois nouveaux espaces de noms : module, application (app) et global. Les noms JNDI sous forme d'URL Java commençant par java:module, java:app et java:global permettent d'accéder aux espaces de noms correspondants. Dans certains cas, ces espaces de noms ne sont accessibles que localement ; dans d'autres, ils sont accessibles à distance.

La partition applications contient des espaces de noms qui sont accessibles à distance. La racine de l'espace de noms java:global est le contexte racine des applications. Les racines des autres espaces de noms sont dans le sous-contexte com.ibm.ws.AppNameSpaces. Par exemple, le contexte racine java:app de l'application MonApp est lié avec le nom MonApp/root relativement à com.ibm.ws.AppNameSpaces. Les espaces de noms module et composant (comp) ne sont accessibles à distance que lorsqu'il s'agit d'un module client déployé sur le serveur ou en mode fédéré. Par exemple, le contexte racine java:module du module client MonModuleClient déployé sur le serveur, dans l'application MonApp, est lié avec le nom MonApp/MonModuleClient/root relativement à com.ibm.ws.AppNameSpaces. L'espace de noms des composants, qui contient les liaisons comp/env de ce même module, est lié sous MonApp/MonModuleClient/ComposantClient/root relativement à com.ibm.ws.AppNameSpaces.

Les ressources d'application telles que les références d'EJB, les références de ressource et les entrées d'environnement avec des noms java:global sont liées dans l'espace de noms java:global lorsque l'application qui les définit est installée. Il n'est pas nécessaire que cette application soit en cours d'exécution pour que ces liaisons de nom soient accessibles aux autres applications.

Les ressources définies dans les applications avec des noms java:global sont liées dans la partition applications de tous les serveurs de la cellule, lorsque les données sont distribuées à leurs noeuds respectifs. Les applications peuvent rechercher ces objets depuis n'importe quel serveur dans la cellule. Les objets home EJB sont aussi liés dans l'espace de noms java:global avec des noms de la forme java:global/nomApp/nomModule/nomBean, mais uniquement dans les serveurs où les beans enterprise correspondants sont exécutés. Toutefois, les recherches java:global portant sur un EJB peuvent être résolues à partir de n'importe quel serveur de la cellule.


Icône indiquant le type de rubrique Rubrique de concept



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=cnam_name_space_partitions
Nom du fichier : cnam_name_space_partitions.html