深度解析 EJB 程式設計限制：安全策略與合規測試指南（下）

Java 2 平台安全策略與 EJB 容器執行

上篇列舉的程式限制，實為 Java 語言與 J2SE 強大特性的子集。EJB 容器雖允許在 J2SE 層面使用受限特性，但 EJB 元件本身必須透過 Java 2 安全機制間接存取，而非直接呼叫 API。Java 2 為 EJB 1.1 定義了許可權集（如 FilePermission、NetPermission、ReflectPermission、SecurityPermission），以強化前述限制。

合規現狀與風險

眾多容器未強制執行這些限制，寄望開發者自律。違規元件或過度依賴非標準權限，或權限不足，極難在多容器間移植，且隱藏難以預測的運行時缺陷。關鍵在於：違規程式碼編譯期無法偵測，因皆為標準 Java 功能。

適用範圍與封裝規範

• 限制同樣適用於輔助/存取類別（Helper/Access Classes）。
• J2EE 應用以 .ear (Enterprise Archive) 封裝，含一或多個 .ejb-jar 及相依庫。
• EAR 內所有程式碼需遵守程式限制與許可權集。

未來規範或允許透過部署工具自訂安全許可，現有容器提供的額外權限屬非標準行為。

容器管理機制深度理解

EJB 容器是元件的受管執行環境，提供：

• 交易管理、安全、持久化、資源存取、客戶連線服務
• 元件完整生命週期、擴展性、並發管理
• 透過 Remote/Home 介面攔截所有方法呼叫
• 透明注入部署描述檔定義的服務（交易、安全、持久化、狀態管理）

資源與連接架構

資源封裝資源管理器存取（如 JDBC Connection），資源工廠建構資源（如 DataSource）。J2EE Connector Architecture (JCA) 正標準化資源適配器與連接/交易/安全契約，讓應用伺服器以統一方式整合 ERP、大型主機、資料庫等企業系統。

限制背後的設計哲學

因容器全權負責生命週期、並發、資源、安全，故須消除與容器鎖定/並發管理衝突的可能，並堵塞安全漏洞。同時，EJB 元件應專注商業邏輯，依賴容器服務而非自行解決系統層問題。

移植性常見陷阱與測試建議

1. 依賴特定容器未強制的受限特性
2. 依賴容器提供的非標準服務

最佳實務：使用符合 Java 2 安全策略、且強制執行程式限制的容器進行測試，確保可移植性與一致行為。

總結

EJB 開發者必須知悉、理解並嚴守編程限制。這些限制雖阻擋標準 Java 特性使用，違反者編譯期不報錯，容器亦不強制執行，但它們已成為元件契約條款，是構建可靠、可移植元件的基石。請謹慎遵循。