JBoss企業級應用服務平台群集指南(五)

Session EJBs 提供遠端的調用服務。它們按照用戶端攔截器架構（client-side interceptor architecture）組成群集系統。群集的 session bean 的客戶應用程式和非群集的版本是一模一樣的，除了對啟用 HA-JNDI 查找的java.naming.provider.url系統屬性的少許改動。對于用戶端來說，不需要任何的源碼改動或重新編譯。現在，讓我們看看怎麼分别在 EJB 2.x 和 EJB 3.0 伺服器應用程式裡配置群集的 session beans。

群集的 stateless session beans 有可能是最簡單的：因為不涉及到狀态，調用可以在群集裡的任何節點（部署有這個 bean 的節點）上進行負載平衡。要群集一個 bean，你需要修改它的 jboss.xml 描述符，使它包含一個 <clustered> 标簽。

在bean配置裡，隻有 <clustered> 元素是強制性的. 它表明bean在叢集裡工作。The <cluster-config> 是可選的，以上的執行個體配置裡面是它的屬性的預設值。下面是<cluster-config>元素的屬性描述：

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.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 配置的一個示例。

既然 JBoss 需要管理狀态資訊，群集 stateful session beans 就比群集 stateles ssession beans 更為複雜。當 stateful session beans 的狀态改變時，所有狀态在群集中複制和同步。JBoss AS 使用HASessionState MBean 來為群集的 EJB 2.x stateful session beans 管理分布式的會話狀态。在這部分内容裡，我們将介紹 session bean 的配置和HASessionState MBean 的配置。

在 EJB 應用程式裡，你需要為每個 stateful session bean 修改jboss.xml描述符檔案并加入<clustered>标簽。

在 bean 的配置檔案裡，隻有<clustered>标簽是強制的，它指出 bean 處在群集系統裡。<cluster-config>元素是可選的，我們在上面的配置檔案樣本裡指出了它的預設屬性值。

<session-state-manager-jndi-name>标簽用來說明這個 bean 所用的HASessionState服務的JNDI名字.

餘下的标簽的描述和 stateless session bean 的描述是一樣的。群集的 stateful session bean 的主接口上的動作預設是基于 round-robin 負載平衡政策的。一旦 bean 的 remote stub 對于客戶可用時，調用将不會再進行負載平衡而"粘"（sticky）在清單裡的第一個節點上。

因為複制過程是很消耗資源的，為了優化這個過程，你可以選擇性地在你的 bean 類裡實作有下面的簽名的方法：

在複制你的 bean 之前，容器（container）将檢測 bean 是否實作了這個方法。如果是，容器會調用 isModified()方法并隻在方法傳回 true 時複制這個 bean。如果 bean 還沒被更改(或者還不夠來請求複制，這取決于你的喜好，你可以傳回 false，這樣複制就不會發生。

這個特性僅僅在JBoss AS 3.0.1+上是可用的。

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 分鐘）。

要在 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 實作的例子。

為了在 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 配置。

本文轉自xudayu 51CTO部落格，原文連結：http://blog.51cto.com/xudayu/66655，如需轉載請自行聯系原作者