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

最新推荐文章于 2023-09-27 07:32:07 发布

long13168

最新推荐文章于 2023-09-27 07:32:07 发布

阅读量770

点赞数

分类专栏：架构与设计模式文章标签：集群 java 服务器 websphere ejb jboss

架构与设计模式专栏收录该内容

14 篇文章 0 订阅

订阅专栏

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 服务器的初始访问