EJB 調用原理深度解析（一）：類結構與 RMI 基礎模型

普通 RMI 的四大核心類

一次遠程調用至少涉及 4 個 class 文件：

1. 遠程對象實現類 (Remote Object Implementation)
2. 遠程接口 (Remote Interface)
3. Stub 類 (Client-side Proxy)
4. Skeleton 類 (Server-side Dispatcher，Java 1.2+ 可選)

Stub 與遠程對象同時實現同一接口。客戶端代碼面向接口編程，實際操作 Stub 實例：

Hello h = new Hello_Stub();  // 實際類型為 Stub
h.getString();               // 委派給 Stub 發起網絡調用

客戶端需備有 Hello.class、Hello_Stub.class。

EJB 的十類文件結構

EJB 在 RMI 基礎上引入 Home/Remote 雙接口機制，至少包含 10 個 class：

用戶僅編寫 3 個文件 (Bean、Remote、Home)，其餘 7 個由容器工具生成。生成時機、打包方式因 App Server 而異。

WebLogic 具體生成策略

• EJBC 階段：生成 Bean_Impl、HomeImpl、EOImpl，打包進 EJB JAR，可見 class 文件。
• 部署階段：容器動態生成 4 個 Stub/Skeleton 字節碼 (_WLStub, _WLSkeleton)，不產生物理 class 文件，直接在內存中定義類。

客戶端調用 EJB 的兩次 RMI 循環

第一階段：JNDI 查找 Home → 獲取 Home Stub

1. 客戶端 ctx.lookup("Hello")
2. 服務端 JNDI 綁定的是 HelloBean_HomeImpl_WLStub 類
3. 服務端實例化該 Stub，序列化傳回客戶端
4. 客戶端反序列化得到 Home Stub 實例（表面為 HelloHome 接口）
5. 關鍵差異：普通 RMI 需客戶端預置 Stub 類；EJB 由服務端動態下發 Stub 實例，客戶端無需 Stub class 文件。

第二階段：Home Stub.create() → 獲取 Remote Stub

1. 客戶端調用 home.create() (實際調用 Home Stub create())
2. Stub 發送調用 → 服務端 Home Skeleton 接收 → 調用 HomeImpl.create()
3. 第一次 RMI 循環完成 (遠程對象：HomeImpl)
4. HomeImpl.create() 內部調用 Bean_Impl.ejbCreate() 創建 Bean 實例
5. 構造 Remote Stub (EOImpl_WLStub) 序列化返回客戶端

第三階段：業務方法調用

1. 客戶端調用 remote.method() (實際調用 Remote Stub)
2. Stub 發送 → 服務端 Remote Skeleton → 調用 EOImpl.method()
3. 第二次 RMI 循環完成 (遠程對象：EOImpl)
4. EOImpl.method() 委派給 Bean_Impl.method() (用戶業務代碼)

核心類職責速查

• Bean_Impl：核心邏輯載體，繼承用戶 Bean，實現 ejbCreate、業務方法
• HomeImpl：工廠職責，負責創建/查找 Bean，返回 Remote Stub
• EOImpl：Remote 接口實現，充當 Bean_Impl 的遠程代理，轉發業務調用
• Stub：客戶端代理，封裝網絡通訊細節 (序列化參數、發送請求、接收結果)
• Skeleton：服務端分發器，反序列化請求、路由到 Impl、序列化返回值

為什麼 EJB 不需要客戶端預置 Stub？

因為 Stub 類在部署時由容器動態生成並隨 Home/Remote Stub 實例一同序列化傳遞給客戶端。客戶端類加載器動態定義 Stub 類，實現零部署客戶端。