1.2 群集的JNDI服务
JNDI 是应用服务器提供的最重要的服务之一。JBoss 的群集 JNDI 服务基于客户端拦截器架构。客户必须获得一个 JNDI 占位对象（stub object）（通过InitialContext对象）和通过 stub 在远程服务器上调用 JNDI 查找服务。而且，JNDI 是许多其他基于拦截器的群集服务的基础：这些服务在 JNDI 上注册，客户就可以查找它们的 stubs 并使用它们的服务。
1.2.1 工作方式
JBoss HA-JNDI （高可用性 JNDI）服务维护了一个跨群集的上下文树（context tree）。只要群集里有一个节点，这个树就会存在。群集里的每个 JNDI 节点也维护子集的本地 JNDI 上下文。服务器端的应用程序可以把它的对象绑定在两者中的任意一个上。在本部分内容里，你将学习怎样区分这两种树和在应用部署时的最佳做法。这个架构的合理设计如下：
u
我们不希望在本地实现 JNDI 的应用程序有任何的移植问题。我们希望通过简单的配置群集系统就可以正常工作。
u
我们需要清晰地区分本地绑定的对象和跨群集的对象。
u
在同样的群集里，这个配置实际上降低了网络的负载。
u
既然所有下面的群集节点都使用一个新的 InitialContext() 来查找或创建绑定，用这个方法来设计可以使 HA-JNDI服务成为一种可选的服务。
在服务器端，new InitialContext() 将会绑定到一个仅用于本地的，非跨群集的 JNDI 上下文（实际上是基本JNDI）。因此，所有 EJB 主接口（homes）都不会绑定到跨群集的 JNDI 上下文。但是，每个主接口都会绑定到本地JNDI 上。当远程的客户通过 HA-JNDI 发起一个查找，HA-JNDI 在全局跨群集上下文找不到这个对象时会委托给本地JNDI 上下文。详细的查找规则如下所示。
u
如果这个绑定在跨群集的 JNDI 树（JNDI tree）里可用。
u
如果这个绑定不在跨群集的树里，它会把查找请求委托给本地 JNDI 服务并返回可用的结果。
u
如果没有可用的结果，HA-JNDI 服务会查找其他群集里的节点，如果它们的本地 JNDI 服务拥有这样的绑定，就会返回相应的结果。
u
如果没有任何本地 JNDI 服务有这样的一个绑定，最后会产生 NameNotFoundException 异常。
所以，当 EJB home 通过 HA-JNDI 查找，总会委托给本地 JNDI 实例。如果不同的 beans（即使是相同的类型,但在不同的群集里）使用同一个 JNDI 名称，这意味着每个 JNDI 服务器将会有一个不同的 "target" 绑定（节点 1 上的 JNDI 将有一个用于 bean A的绑定,节点 2 会有一个用于 bean B 的相同名字的绑定）。因此，如果客户为这个名字执行 HA-JNDI 查询，这个查询会在群集里的任何 JNDI 服务器上调用并返回本地绑定的 stub。而且，它未必是客户所希望的正确的 stub!
如果你想从服务器端访问HA-JNDI，你必须通过JNDI的属性文件明确的得到一个InitialContext。下面的代码讲述了怎么访问HA-JNDI。
Context.PROVIDER_URL
属性指向HANamingService MBean中配置的HA-JNDI服务(见2.3, “JBoss 配置”)。
1.2.2 客户端配置
JNDI
客户需要意识到 HA-JNDI 的群集方式。你可以把 JNDI 服务器的列表（HA-JNDI群集里的节点）写入到 jndi.properties 文件里的 java.naming.provider.url 设置里。每个服务器节点都用它的 IP 地址和 JNDI 端口号码来识别。服务器节点用逗号来隔开(见 2.3, “JBoss 配置” 关于如何配置服务器和端口)。
初始化时，JNP 客户代码会试图连接列表里的每个服务器，一个接一个，只要连接到一个服务器它就会停止尝试。然后它将从这个节点下载 HA-JNDI stub。
下载的 smart stub 包含了必要时失效切换（fail-over）至另一节点的逻辑和更新的当前运行节点的列表。而且，每次对服务器执行 JNDI 调用后，stub interceptor 里的目标节点列表都会被更新（只有在上次调用后又有修改的情况下）。
如果属性字符串java.naming.provider.url是空或者它标明的所有服务器是不可到达的，JNP client 会试图通过网络上的多点传送（multicast）调用来恢复 HA-JNDI 服务器。见 2.3, “JBoss 配置” 关于怎么在JNDI服务器节点上配置自动回复(auto-discovery)。通过自动恢复，客户端不需要任何配置就可以获得一个有效的 HA-JNDI 服务器节点。当然，为了自动恢复能够工作，客户应用程序必须和服务器节点（使用 EJB 服务器的 web servlets）在同一局域网里。局域网和广域网也必须配置成可以传送这样的多点传送数据包。
除 java.naming.provier.url 属性以外，你还可以指定一系列其他属性。下面的列表展示了当建立一个新的 InitialContext 时，你可以指定的所有客户端属性。
u
java.naming.provider.url:
提供群集里 HA-JNDI 提供者节点的 IP 地址和端口号的列表。客户端会尝试这些提供者并使用第一个响应的服务器。
u
jnp.disableDiscovery:
当设置为 true 时，这个属性关闭了自动恢复（automatic discovery）特征。默认值是false。
u
jnp.partitionName:
在有多个绑定在不同的群集系统的 HA-JNDI 服务的环境里，这个属性允许你配置当使用自动恢复（automatic discovery）特征时广播至哪个群集。如果你没有使用自动恢复特征（就是说你可在以在 java.naming.provider.url 里显性地提供有效的 JNDI 节点的列表），这个属性就不会被使用。在缺省情况下，这个属性不会被设置，自动恢复选择第一个响应的 HA-JNDI 服务器，而不管在哪个群集系统里。
u
jnp.discoveryTimeout:
决定上下文（context）等待对它的自动恢复数据包应答的的时间，它的缺省值是 5000 毫秒。
u
jnp.discoveryGroup:
决定用于自动恢复的多点传送组地址。它的缺省值是 230.0.0.4。
u
jnp.discoveryPort:
决定用于自动恢复的多点传送组端口。它的缺省值是 1102。
u
jnp.discoveryTTL -- The time-to-live for multicast discovery packets
1.2.3 JBoss 配置
all/deploy
文件夹下的cluster-service.xml 文件，包括了下列启用 HA-JNDI 服务的 MBean。
你可以看到这个 MBean 依赖于在它之上定义的 DefaultPartition MBean（在本章之前的部分曾讨论过）。在其他配置里，你可以把那个元素（element）放在 jboss-services.xml 或者 /deploy 目录下的其他 JBoss 配置文件里来启用 HA-JNDI 服务。这个MBean 的可用属性如下所示：
u
PartitionName
是一个可选的属性，它指定与 HA-JNDI 服务通讯的不同节点的群集的名字。默认值是 DefaultPartition.
u
BindAddress
是一个可选属性，它指定 HA-JNDI 服务器绑定的等待 JNP 客户连接的地址。它只对多宿主主机（multi-homed computers）有用。
u
Port
是一个可选属性，它指定 HA-JNDI 服务器等待 JNP 客户连接所绑定的端口。它的缺省值是 1100。
u
Backlog
是一个可选属性，它指定 TCP 服务器套接字等待 JNP 客户所使用的 backlog 值。它的缺省值是 50。
u
RmiPort
决定服务器应与下载的 stub 通信所用的端口。这个属性是可选的。如果它没有设置，服务器会自动分配一个 RMI 端口。
u
AutoDiscoveryAddress
是一个可选属性，它指定侦听的用于 JNDI 自动恢复的多点传送地址。它的缺省值是 230.0.0.4。
u
AutoDiscoveryGroup
是一个可选属性，它指定侦听的用于 JNDI 自动恢复的多点传送组。它的缺省值是 1102。
u
LookupPool
指定用于控制引导程序和自动恢复查找的线程池服务。
u
DiscoveryDisabled
是一个布尔值标记，它可用来取消自动恢复多点传送侦听者（multicast listener）的配置。
u
AutoDiscoveryBindAddress
设置自动恢复引导程序绑定的地址。如果这个属性没有指定而设置了 BindAddress，BindAddress 将被使用。
u
AutoDiscoveryTTL
为用于自动恢复的 IP 多点传送数据包指定 TTL （time-to-live）。
HANamingService MBean
完整的默认配置如下：
HA-JNDI
本文转自xudayu 51CTO博客，原文链接：http://blog.51cto.com/xudayu/66164，如需转载请自行联系原作者
