揭開J2EE集群的神秘面紗（六）

EJB是J2EE技術中重要的部分，並且EJB集群是實現J2EE集群最大的挑戰。

EJB技術是為分散式計算而生。它們可以在獨立的伺服器中運行。Web伺服器組件或富客戶端可以從其他的機器通過標準協議（RMI/IIOP）來訪問EJB。你可以象調用你本地Java對象的方法一樣調用遠程EJB的方法。實際上，RMI/IIOP完全掩蓋了你正在調用的對象是本地的還是遠程的，這被稱作本地/遠程透明性。

圖16EJB調用機制

上圖顯示了遠程EJB的調用機制。當客戶端想使用EJB，它不能直接調用，相反，客戶端只能調用一個被稱為「stub」的本地對象，它扮演了到遠程對象代理的角色，並且有遠程對象相同的介面。這個對象負責接受本地方法調用，並且這些調用通過網路代理到遠程EJB。這些對象在客戶JVM中運行，並且知道如何通過RMI/IIOP跨過網路查找真正的對象。要了解有關EJB更多的信息，請參考http://java.sun.com/products/ejb/

為解釋EJB集群的實現，我們先看看在J2EE代碼中如何使用EJB的。為了調用EJB，我們需要

l在JNDI伺服器中查找EJBHomestub

l使用EJBHomestub查找或創建EJB對象，這樣獲得一個EJBObjectstub

l在EJBObjectstub上調用方法

負載均衡和失效轉移可以在JNDI查找時發生，這我們已在上面闡述了。在EJBstub（包括EJBHome和EJBObject）的方法調用時，供應商採用以下三種方式實現EJB負載均衡和失效轉移。

正如我們所知，客戶端可以通過存根對象（stub）來訪門遠程的EJB，這個對象可以通過JNDI樹獲取，甚至客戶端可能透明地從WEB伺服器上下載存根類文件。

這樣存根就可以在運行期動態地用程序生成，而其類文件也不必在客戶端環境的classpath或庫中。（因為它是可以被下載的）

圖17智能存根

如圖17所示，BEAWebLogic和Jboss通過在存根代碼中組合幾種行為來實現EJB集群，而這些都是在客戶端透明運行的（客戶端不需要了解這些代碼）。這種技術叫做智能存根。

智能存根確實很聰明，它包含一組它可以訪問的目標實例，可以檢測這些實例的任何失效，它也包含了複雜的負載均衡和失效轉移的邏輯，用來分發請求到目標實例。而且，如果集群拓樸改變了的話（比如新增或刪除了伺服器實例），存根可以更新它的目標實例清單來反映新的拓樸，而不需要手工重新配置。

使用智能存根實現集群有以下優點：

l因為EJB存根運行在客戶端，所以它可以節省許多伺服器資源。

l負載均衡是在客戶端代碼中，並且與客戶端的生命周期相關。這樣就消除了負載均衡器的單點失效。如果負載均衡器失效了，就意味著客戶端也失效了，這種情況是能接受的。

l存根可動態的自動下載更新，這意味著零維護。

SunJESApplicationServer使用了另一種方法實現EJB集群。負載均衡和失效轉移邏輯是在IIOP運行庫中實現的。比如，JES修改了「ORBSocketFactory」的實現，使它能支持集群。如圖18所示。

圖18IIOP運行期

「ORBSocketFactory」的修改版有實現負載均衡和失效轉移的所有邏輯和演算法，這樣就保持了存根乾淨和小。因為是在運行庫中實現的，這樣就比存根的方式更容易獲得系統資源。但這種方式需要在客戶端運行一個特殊的運行庫，這樣就給與其他J2EE產品進行互操作時帶來了麻煩。

攔截器代理

IBMWebshpere採用了定位服務精靈（LocationServiceDaemon-LSD）,它對EJB客戶端扮演了攔截器代理的角色，如圖19所示。

圖19攔截器代理

在這種方式中，客戶端通過JNDI查找獲取存根，這個存根將信息路由到LSD，而不是運行了EJB的應用程序伺服器。這樣LSD接收到所有進來的請求，根據負載均衡和失效轉移的策略來判斷應該將它發送到哪個伺服器實例。這種方式增加的安裝和維護集群的額外的管理工作。

要調用EJB的方法，要涉及到兩種存根對象，一是EJBHome介面，另一個是EJBObject介面。這意味著EJB潛在的需要在兩層上實現在負載均衡和失效轉移。

l當客戶端使用EJBHome存根創建或查找EJB對象時

l當客戶端調用EJB對象上的方法時。

EJBHome存根支持集群

EJBHome介面用於在EJB容器中創建和查找EJB實例，而EJBHome存根是EJBHome介面的客戶端代理。EJBHome介面不需維持任何客戶端的狀態信息。這樣，來自不同EJB容器中的相同EJBHome介面對於客戶端來說是一致的。當客戶端執行create()或find()調用的時候，home存根根據負載均衡和失效轉移演算法從多個相同的伺服器實例中選擇一個，並將調用發送到該伺服器的home介面上。

EJBObject存根支持集群

當EJBHome介面創建一個EJB實例，它將返回EJBObject的存根給客戶端，並讓用戶調用EJB的業務方法。集群中已有一組可用的伺服器實例，並在上面的部署了bean，但是不能將EJBObject存根對象向EJBObject介面發出調用轉發到任意一個伺服器實例上，這取決於EJB的類型。

無狀態會話Bean是最簡單的情況，因為不涉及到狀態，所有的實例都可以認為是一樣的，這樣對EJBObject的方法調用可負載均衡和失效轉移到任意一個伺服器實例上。

集群的有狀態會話Bean與無狀態會話Bean有一點不同，正如我們所知，有狀態會話Bean對於客戶端連續的請求會持有狀態信息。從技術上來說，集群有狀態會話Bean與集群HTTPSession是一樣的。在常規時間，EJBObject存根將不會把請求負載均衡到不同的伺服器實例。相反，它將膠粘到最初創建的伺服器實例上，我們稱這個實例為「主實例」。在執行過程中，會話狀態會從主實例備份到其他服務上去。如果主實例失效了，備份伺服器將接管它。

實體Bean本質上是無狀態的，儘管它可以處理有狀態的請求。所有的信息都將通過實體Bean本身的機製備份到資料庫中。這樣看起來實體Bean可以象無狀態會話Bean一樣很容易獲取負載均衡和失效轉移。但實際，實體Bean多數情況下是不負載均衡和失效轉移的。根據設計模式的建議，實體Bean被會話外觀包裝。這樣，多數對實體Bean的訪問都是進程內會話Bean通過本地介面完成的，而不是遠程客戶端。這使得負載均衡和失效轉移沒有意義。

除JSP，Servlet，JNDI和EJB之外，在J2EE中還有其他的分散式對象。這些對象在集群的實現中可能支持，可能不支持。

當前，一些資料庫產品，如OracleRAC，支持集群環境並可以部署到多複製，同步的資料庫實例中。然而，JDBC是一個高度狀態化的協議並且它的事務狀態直接與客戶端和伺服器的Socket連接綁定，所以很難獲取集群能力。如果一個JDBC連接失效了，與該失效連接相關的所有JDBC對象也就失效了。客戶端代碼需要進行重連的動作。BEAWebLogic使用JDBC多池（multipool）技術來簡化這種重連過程。

JMS被多數J2EE伺服器所支持，但支持得並不完全，負載均衡和失效轉移僅僅被JMS代理所實現，很少有產品在JMSDestination中的消息有失效轉移的功能。