J2EE规范要求所有的J2EE容器必须提供JNDI规范的实现。JNDI在J2EE应用程序中的主要角色是用来提供一个间接层，这样资源可以很容易被找到，而不用关心细节。这使得J2EE组件更加可复用。
拥用全特性的集群的JNDI对于J2EE集群是非常重要的。所有的EJB调用都开始于在JNDI树上查找它的Home接口，J2EE供应商根据他们的集群结构采用不同的方式实现JNDI集群。
共享全局JNDI树WebLogic和Jboss都有一个全局的，共享的，集群范围的JNDI Context供客户端查找和绑定对象，绑定的全局JNDI Context中对象将通过IP广播的方式在集群中复制，这样当一台服务器实例停机后，被绑定的对象仍然可供查找。
图 14 共享的全局JNDI
如图14所示，共享的全局JNDI树实际包括了所有本地JNDI结点上绑定的对象。集群上每个结点都拥有自己的名称服务器，它们与集群中其他服务器相互复制所有的东西。这样每个名称服务器上都拥有其他名称服务器对象树的拷贝。这种冗余结构使得全局JNDI树高可用。
实 际上，集群的JNDI树可以被用做两个目的。可以被管理员用来部署对象和服务。在一台服务中部署完EJB模块或JDBC&JMS服务后，JNDI 树上的所有对象都将复制到其他服务器实例中。在运行期，程序可以JNDI API访问JNDI树存储或者获取对象，这些对象也将被全局复制。
独立JNDIJboss 和WebLogic都采用了共享全局JNDI树的方式，Sun JES和IBM WebSphere等采用了每个服务器都拥有独立的JNDI树的方式。在 使用独立JNDI树的集群中，成员服务器不必知道或关心集群中其他服务器。这是否意味着不想把JNDI集群呢？所有EJB访问都开始于在JNDI树上查找 它们的Home接口，如果没有可集群的JNDI树，集群就根本无用。
实际上，如果J2EE应用程序是相似的，独立的JNDI树仍然可以获得高可用性。当集群中所有实例都有相同的设置以及都部署相同的应用程序集，我们说集群是“相似的”，这种情况下，一种被称为代理的特殊管理工具可以帮助我们获取高可用性，如图15所示：
图 15 独立JNDI
不管是Sun JES还是WebSphere都在集群的实例上安装了结点代理，当部署EJB模块或绑定其他JNDI服务，管理控制员可以向所有的代理发出命令，以此实现与共享全局JNDI相同的效果。
但 是独立JNDI的方案不能支持复制在运行期绑定或获取的对象。有以下几个原因：JNDI在J2EE应用程序中的主要角色是用来提供管理外部资源的间接层， 并不是用来做数据存储。如果有这样的需求，可以采用具有HA（高可用性）特性的独立的LDAP服务器或数据库。Sun和IBM自己都有这样拥有集群特性的 独立的LDAP服务器产品。
中心JNDI少数J2EE产品使用了中心JNDI方案，这种方案中名称服务器驻留在单一服务器中，所有的服务器实例都注册它们相同的EJB组件和管理对象到单一的服务器中。
名称服务器实现了高可用性，这对客户端是透明的。所有的客户端都在这台服务器中查找EJB组件，但是这种结构意味着复杂的安装和管理，慢慢被多数供应商抛弃。
初始化访问JNDI服务器当然客户端要访问JNDI服务器的时候，它们需要知道远程JNDI服务器的主机名/IP地址和端口，在全局或是独立JNDI树的方案中，有多个JNDI服务器。客户端第一次访问时应该连接哪个呢？如何获得负载均衡和失效转移呢？
从技术上说，一个软件或硬件负载均衡器可以设在远程客户端和所有的JNDI服务器之间执行负载均和失效转移。但是，很少有供应商实现这种方式，这里有些简单的方案：
l Sun JES 和Jboss 实现JNDI集群是在“java.naming.provider.url”属性中设置一列用逗号分隔的URL，如 java.naming.provider.url=server1:1100,server2:1100:server3.1100:server4.1100 客户端将挨个联系列表中的服务器，一旦其中一个响应了便中止。
l Jboss同时也实现了自动发现的特性，当设置属性串“java.naming.provider.url”为空时，客户端将试图通过网络广播来发现在一个JNDI服务器。
