Java EE集群技术初探——第六部分(JNDI集群的实现)

JNDI集群的实现

 

Java EE规范要求Java EE容易需要提供对JNDI规范的实现。在Java EE应用中，JNDI的主要角色就是提供了一个中间层，资源可通过较为透明的方式获得。这使Java EE组件提高了重用度。

 

具有完整功能的集群JNDI是Java EE集群的重要内容，因为几乎每个EJB组件都从查找(lookup)其JNDI树的home接口开始。各个厂商实现JNDI集群的方法不同，主要是根据其集群的结构而定。

 

全局共享JNDI树

WebLogic和JBoss都使用集群范围全局共享的JNDI上下文以便客户端能查找并绑定对象。绑定到全局JNDI上下文的内容将被基于IP的多播技术复制到整个集群中，这样当一个服务器实例宕机时，还能保证绑定对象可获得。

如上图所示，全局共享的JNDI树实际上包含了每个节点上所有本地的JNDI的集合。集群中的每个节点都有其自己的JNDI命名服务器，它将所有的信息复制到集群中其它所有的命名服务器中。这样，每个命名服务器的树中都有其他命名服务器的对象拷贝。这样的冗余结构使全局JNDI树实现了高可用。

 

实际上，集群的JNDI树有两个用途。管理员可以用它来进行部署任务。在一台服务器上部署了EJB模块或配置了JDBC/JMS服务后，所有的JNDI树都会被复制到其它服务器实例。在应用运行期间，程序用JNDI的API访问JNDI树来存储和检索对象，所以自定义的对象也被全局复制。

 

独立JNDI

虽然JBoss和WebLogic采用了全局共享JNDI，但SUN JES、IBM WebsPhere和其他一些服务器采用了独立JNDI树技术。在独立JNDI树集群环境下的成员服务器不知道或者并不关心集群中的其他服务器。那这样岂不是意味着不对JNDI进行集群？因为几乎每个EJB访问都从JNDI树中查找其home接口开始，所以如果不对JNDI树进行集群就会丧失集群的功能。

 

实际上，独立JNDI树依然能实现高可用，只要Java EE的应用都是同构的。我们将其称为同构集群，因为所有的实例配置相同，部署了同样的应用。在这样的条件下，一个叫“代理”的特殊管理工具可用来实现高可用，如下图：

 

SUN JES和IBM WebSphere都将代理安装在集群的每个实例上。当部署EJB模块并绑定其他JNDI服务时，管理终端通过对所有代理发送命令来达到与全局共享JNDI树同样的效果。

 

但是独立JNDI解决方案将不支持复制由运行的应用绑定和检索的判定对象。原因如下：在Java EE应用中，JNDI扮演的角色是对管理外部资源提供中间层，而不是运行时数据的存储。如果有需要的话，各自的LDAP服务器或有HA功能的数据库能够实现。Sun和IBM都有它们的LDAP服务器产品，而且都已经随着集群特性分发。

 

 

集中式JNDI

一些Java EE产品使用集中式的JNDI树，命名服务器驻留在一台服务器上，所有服务器实例将EJB组件和其他管理对象注册至命名服务器中。

 

命名服务器本身实现了高可用，对客户端透明。所有客户端通过单独的命名服务器查找EJB组件。这种结构加大了安装和管理的复杂度，所以不为大多数厂商采用。

 

对JNDI服务器的初始访问

当客户端访问JNDI服务器时，需要知道hostname/IP地址和远程JNDI服务器端口号。在全局共享与独立JNDI树解决方案中，均有多个JNDI服务器。那么客户端会先连接哪台JNDI服务器呢？如何实现负载均衡和失败转移呢？

 

通常，软件或硬件负载均衡器可在远程客户端和所有的JNDI服务器之间执行负载均衡和失败转移的任务。但是几乎没有厂商采用这样的办法，而使用一些简单的解决方案。

• Sun JES和JBoss通过“java.naming.provider.url”让JNDI设置接收由逗号分离的URL列表来实现集群。例如，java.naming.provider.url=server1:1100,server2:1100,server3:1100,server4:1100

客户端将尝试逐个与列表中的每台服务器，一旦连接上之后就停止尝试。

• JBoss也实现了自动恢复的功能。当属性字符串“java.naming.providing.url”为空时，客户端将尝试通过网络多播调用恢复引导JNDI服务器。

Java EE集群技术参考文档下载http://www.betteryou.com.cn/downloads/docs.jsp