深入解析 EJB 遠程調用原理與 WebLogic 實作機制

EJB 遠程調用的核心架構

Enterprise JavaBeans (EJB) 作為 J2EE 平台的核心組件，其遠程調用機制建立在 RMI (Remote Method Invocation) 之上，但比標準 RMI 更為複雜。一個典型的遠程物件至少需要 4 個類別檔案：遠程物件本身、遠程介面、Stub (客戶端代理) 和 Skeleton (伺服器端代理)。然而在 EJB 架構中，這一數字增長到至少 10 個類別，反映了 EJB 容器為管理生命週期、事務、安全等企業級服務所引入的額外層次。

EJB 的 10 個核心類別

這 10 個類別分為兩大類：

• Bean 相關 (5 個)：Bean 類別、應用伺服器特定的 Bean 實作類別、Remote 介面、應用伺服器特定的 Remote 實作類別、以及該實作類別的 Stub 和 Skeleton
• Home 相關 (5 個)：Home 介面、應用伺服器特定的 Home 實作類別、以及該實作類別的 Stub 和 Skeleton

開發人員實際只需編寫 3 個類別：Bean 類別、Remote 介面和 Home 介面。其餘 7 個類別由 EJB 容器工具 (如 WebLogic 的 ejbc) 自動生成，具體生成方式和打包位置因應用伺服器而異。

WebLogic 的具體實作機制

以 WebLogic 為例：

• 編譯期生成 (ejbc 階段)：Bean 實作類別、Home 實作類別、Remote 實作類別被打包進 EJB JAR 檔中，可見於檔案系統
• 部署期動態生成：Home 和 Remote 實作類別的 Stub 和 Skeleton 由 WebLogic 在部署時動態生成位元碼，不產生實體 .class 檔案

完整的遠程調用流程解析

一次客戶端對 EJB 的遠程調用，實際經歷了 兩次完整的 RMI 循環：

第一次 RMI 循環：獲取 Home Stub

1. 客戶端透過 JNDI 查找 Home 介面 (如 ctx.lookup("Hello"))
2. 伺服器端 JNDI 樹綁定的是 HelloBean_HomeImpl_WLStub 實例
3. 伺服器建立該 Stub 實例，序列化傳送給客戶端 (關鍵差異：普通 RMI 需客戶端預先有 Stub 類別，EJB 由伺服器動態下發)
4. 客戶端獲得 HelloHome 介面引用，實際指向 HelloBean_HomeImpl_WLStub@18c458

第二次 RMI 循環：創建 EJB 實例並獲取 Remote Stub

1. 客戶端呼叫 home.create()，實際觸發 Stub 的 create() 方法
2. 訊息經網路傳送至伺服器端 HelloBean_HomeImpl_WLSkeleton
3. Skeleton 呼叫 HelloBean_HomeImpl.create()
4. Home 實作類別呼叫 HelloBean_Impl.ejbCreate() 創建/分配 Bean 實例
5. 建立 HelloBean_EOImpl_WLStub 實例，序列化返回客戶端
6. 客戶端獲得 Hello 介面引用，實際指向 HelloBean_EOImpl_WLStub@8fa0d1

業務方法調用：第三次 RMI 循環

後續對 Remote 介面方法的調用 (如 h.helloWorld()) 將觸發第三次 RMI 循環：

1. 客戶端呼叫 HelloBean_EOImpl_WLStub.helloWorld()
2. 訊息傳送至伺服器端 HelloBean_EOImpl_WLSkeleton
3. Skeleton 呼叫 HelloBean_EOImpl.helloWorld()
4. EOImpl 實作類別委派給 HelloBean_Impl.helloWorld()
5. 最終執行開發者編寫的 HelloBean.helloWorld() 業務邏輯

關鍵設計洞察

EJB 容器引入的多層代理模式 (Home/Remote 各有 Stub/Skeleton) 實現了：

• 位置透明性：客戶端無需知道 Bean 實際部署位置
• 容器服務攔截：事務、安全、持久化等服務在 Skeleton/實作層透明織入
• 介面導向編程：客戶端僅依賴 Home/Remote 介面類別 (HelloHome.class, Hello.class)，Stub 由伺服器動態下發，解決了傳統 RMI 的類別分發難題

這種設計雖增加了調用開銷，但為分散式企業應用提供了強大的中間件支撐。