JBoss5 Clustering Guide (第三部分)

Chapter 2. Clustered JNDI Services
(HA-JNDI服务也是个cluster的服务, 就像其它服务一样, 并且是其他服务的注册表)
JNDI是应用服务器中最重要的服务(就像手机中的sim卡). JBoss HA-JNDI(High Availability JNDI)服务功能如下:
* 透明的失败转移. 如果一个naming context连接的服务失效或者停机, 自动转移到另外一个AS 实例上
* 负载均衡. naming context自动的负载均衡到cluster中的所有server上.
* 自动发现 HA-JNDI服务器, 利用广播.(现在的网络情况下能行?)
* 统一的JNDI树形结构. 连上一个node就能知道其他node上的服务. 通过以下两种机制实现:
1. cluster内lookup. 客户端lookup, 服务端HA-JNDI服务能发现绑定在node上的普通JNDI
2. cluster范围内的复制context tree. 绑定到HA-JNDI上面的对象可以在cluster内复制, 副本会出现在cluster中每个node的vm内.

JNDI是其他基于拦截器cluster服务关键: 那些服务注册到JNDI所以客户端能够lookup到他们的proxy, 从而调用他们. HA-JDNI通过HA的方式查找服务. 但是, 要记住, HA-JNDI对找到的服务能否提供cluster服务没有作用:
* 如果EJB不是配置为cluster, 仅从HA-JNDI lookup到的EJB不能得到cluster的好处(load balance/失败转移/状态传播)
* 如果EJB配置为cluster, 通过普通的JDNI去lookup不会让EJB cluster的特点消失.
(这个鸟东西写的特别晦涩, 貌似注册表同步缓存到每个节点上. EJB的cluster服务必须跟他狼狈为奸才最好用, 但不是必须的.)
(另外这玩意应该是基于缓存服务的, 能否就把它当singleton使?)

2.1 HA-JNDI是怎样工作的
JBoss客户端HA-JNDI命名Context基于客户端拦截器.
客户端拿到一个HA-JNDI proxy对象(通过InitialContext对象), 通过proxy调用远程服务器上的JNDI lookup. 客户端通过配置InitialContext需要的properties来指定HA-JNDI proxy.

在服务器端, HA-JNDI服务维护一个cluster范围内的contex树. 只要cluster里面还有一个node, 这个树就存在. 每个Node还维护一个本地的JNDI Context树. 这个节点上的HA-JNDI服务就能找到本地树JNDI树上绑定的对象. 一个应用把可以把对象绑定在哪里都可以. 理由如下:
* 避免了迁移问题. 仅仅通过配置文件就能让cluster实现.
* 在一个homogeneous cluster,这种配置减少了网络通讯. homogenous cluster是说在不同node上, 同类对象用相同的名字去绑定. (有反例吗?)
* HA-JNDI变成可选服务. 因为代码里面仅仅new InitialContext()来查找和绑定.

服务器端, 通过new InitialContext()来绑定是本机的, 不是cluster范围内的(这是基本的JNDI). 所以, 所有的EJB home等等都不会绑定到cluster级别的JNDI上, 仅仅是绑定到本地JNDI

当一个远程客户端通过HA-JNDI来lookup的时候, HA-JNDI在cluster范围内找不到时会代理本地到Context. 规则如下:
* Cluster范围JNDI优先
* 尝试本地JNDI
* 去其他node的本地JNDI找(没有隐私了?)
* throw new NameNotFoundException()

在实战中, 应该尽量不要绑定对象到Cluster级别的JNDI树上去, 应该绑定到本地. 比如EJB, 应该绑定到本地JNDI, 而不是HA-JNDI. 所以, 客户端通过HA-JNDI是通过代理到本地JNDI上的.

(就是说, 把cluster这种事情让框架去操心, 尽管按照最简单的本地方式去lookup, 减肥是EJB的近期发展方向)







这里有三段重复,貌似作者喝高了, 略

这是翻译的吗? 请问原文在哪里?

基本上都是翻译，原文参见第一章