JBoss企业级应用服务平台群集指南(五)

1.3 群集Session EJBs

Session EJBs 提供远程的调用服务。它们按照客户端拦截器架构（client-side interceptor architecture）组成群集系统。群集的 session bean 的客户应用程序和非群集的版本是一模一样的，除了对启用 HA-JNDI 查找的java.naming.provider.url系统属性的少许改动。对于客户端来说，不需要任何的源码改动或重新编译。现在，让我们看看怎么分别在 EJB 2.x 和 EJB 3.0 服务器应用程序里配置群集的 session beans。

1.3.1     EJB 2.x里的Stateless Session Bean

群集的 stateless session beans 有可能是最简单的：因为不涉及到状态，调用可以在群集里的任何节点（部署有这个 bean 的节点）上进行负载平衡。要群集一个 bean，你需要修改它的 jboss.xml 描述符，使它包含一个 标签。

 

在bean配置里，只有 元素是强制性的. 它表明bean在集群里工作。The 是可选的，以上的实例配置里面是它的属性的缺省值。下面是元素的属性描述：

 

u  partition-name  指明bean所加入的集群的名字。默认值是DefaultPartition. 缺省的分区名也可以用 jboss.partition.name 系统属性跨系统地被指定。

u  home-load-balance-policy 指出 home stub 所用来平衡节点上的调用的类。在缺省情况下，代理（proxy）会用 RoundRobin 方式平衡调用负载。你也可以实现自己的负载平衡策略类或持续使用所遇到的第一个可用节点直至其消亡的 FirstAvailable 类。

u  bean-load-balance-policy 指出 home stub 所使用的平衡节点上的调用的类。对于home-load-balance-policy属性的注释也同样适用。

 

在 JBoss 3.0.x 里，每个客户端 stub 都有自己的可用目标节点的列表。由此会产生某些副作用。例如，每次你需要进行一次调用时，你都为 stateless session bean（应用 Round-Robin 策略）缓存你的 home stub 并重新创建一个远程 stub，每次调用都会下载包含可用节点列表的新的远程 stub。因此，由于第一个目标节点总是列表里的第一项，而且不同的 stubs 之间并没有一个节点的使用记录，调用负载看起来并没有被平衡。在 JBoss 3.2+ 里，proxy families（也就是 "First AvailableIdenticalAllProxies" 负载平衡策略，见章节 1.3.2 , “JBoss AS 3.2+”） 消除了这个副作用，因为给定 EJB 的 home 和 remote stubs 分别在两个不同的族（familiy）里。

1.3.1.1 集群重启操作

我们已经在章节 1.2.1 , “Client-side interceptor”.介绍了 HA smart client architecture。缺省的 HA smart proxy client 只能在群集里一个节点故障时进行失效切换（failover）。如果整个群集都关闭了，代理（proxy）将失去所有群集里可用节点的信息。在这种情况下，代理没有什么办法来恢复系统。当节点重启时，需要在 JNDI/HAJNDI 之外查找代理。

 

3.2.7 +/4.0.2+ 版本包含了RetryInterceptor，它可以加入到代理客户端拦截器栈里，允许在这样的重启故障后进行透明恢复（transparent recovery）。为了启用这个机制，你可以设立包含RetryInterceptor 的invoker-proxy-binding。下面是jboss.xml 配置的一个示例。

 

1.3.2     EJB 2.x里的Stateful Session Bean

既然 JBoss 需要管理状态信息，群集 stateful session beans 就比群集 stateles ssession beans 更为复杂。当 stateful session beans 的状态改变时，所有状态在群集中复制和同步。JBoss AS 使用HASessionState MBean 来为群集的 EJB 2.x stateful session beans 管理分布式的会话状态。在这部分内容里，我们将介绍 session bean 的配置和HASessionState MBean 的配置。

1.3.2.1 配置EJB应用服务

在 EJB 应用程序里，你需要为每个 stateful session bean 修改jboss.xml描述符文件并加入标签。

在 bean 的配置文件里，只有标签是强制的，它指出 bean 处在群集系统里。元素是可选的，我们在上面的配置文件样本里指出了它的缺省属性值。

 

标签用来说明这个 bean 所用的HASessionState服务的JNDI名字.

 

余下的标签的描述和 stateless session bean 的描述是一样的。群集的 stateful session bean 的主接口上的动作缺省是基于 round-robin 负载平衡策略的。一旦 bean 的 remote stub 对于客户可用时，调用将不会再进行负载平衡而"粘"（sticky）在列表里的第一个节点上。

1.3.2.2 优化复制状态

因为复制过程是很消耗资源的，为了优化这个过程，你可以选择性地在你的 bean 类里实现有下面的签名的方法：

在复制你的 bean 之前，容器（container）将检测 bean 是否实现了这个方法。如果是，容器会调用 isModified() 方法并只在方法返回 true 时复制这个 bean。如果 bean 还没被更改(或者还不够来请求复制，这取决于你的喜好，你可以返回 false，这样复制就不会发生。

这个特性仅仅在JBoss AS 3.0.1 +上是可用的。

1.3.2.3 HASessionState 服务配置

all/deploy/cluster-service.xml 文件里定义了HASessionState服务 MBean。

HASessionState MBean 里的配置属性如下所示：

 

u  JndiName 是一个可选属性，它指定这个HASessionState服务被绑定的 JNDI 名。它的缺省值是 /HAPartition/Default.

u  PartitionName 是一个可选属性，它指定了当前HASessionState协议所服务的群集名称。它的缺省值是 DefaultPartition.

u  BeanCleaningDelay 是一个可选属性，它指定了一个状态在多久没有变化后HASessionState 服务就可以清除它，它的单位是毫秒。例如，如果拥有某一 bean 的节点崩溃了，它的兄弟节点将接管这个 bean。但是，这个兄弟节点的容器缓存并不会知道这个信息（因为之前并没有这个信息），也永远不会按照这个 bean 的清除设置来删除它。这就是为什么HASessionState服务需要来做这个清除工作。它的缺省值是 30*60*1000 毫秒（也就是 30 分钟）。

1.3.3     EJB 3.0里的Stateless Session Bean

要在 EJB 3.0 内群集一个 stateless session bean，你所需要做的就是用@Cluster注解来注解（annotate）bean 类。你可以把负载平衡策略（load balance policy）和群集分区名当作参数传入这个注解。缺省的负载平衡策略是org.jboss.ha.framework.interfaces.RandomRobin，缺省的群集是DefaultPartition。下面是@Cluster注解的定义。

这里是一个群集的 EJB 3.0 stateless session bean 实现的例子。

1.3.4     EJB 3.0里的Stateful Session Bean

为了在 EJB 3.0 里群集 stateful session beans，你需要用@Cluster注解来标记 bean 实现类，就和我们之前对 EJB 3.0 stateless session bean 做的一样。

JBoss Cache 为 EJB 3.0 stateful session beans 提供会话状态复制服务（session state replication service）。deploy 目录下ejb3-clustered-sfsbcache-service.xml文件定义了相关的 MBean 服务。文件的内容如下：

PassivationTreeCache MBean 里的配置属性基本上和在章节 2, JBossCache 和 JGroups 服务 里讨论的标准 JBoss Cache TreeCache MBean 一样。我们再一次忽略了 ClusterConfig 属性（详情请参考部分 1, “JGroups 配置” ）的 JGroups 配置。