J2EE 技術選型指南：無狀態網路環境下的 Servlet vs 無狀態 Session Bean

Java 生態系指數級增長，面對眾多供應商、規範與元件類型，企業開發者、架構師如何抉擇？「J2EE 探險者」系列旨在為您闢出決策路徑。本文聚焦無狀態請求處理組件的兩大主流選擇：Servlet（含 JSP）與無狀態 Session Bean。

無狀態網路的本質

HTTP 是典型無狀態協定：每個請求獨立，伺服器不記住先前互動。為模擬有狀態會話，業界發展出表單隱藏欄位、Cookie、URL 重寫等技巧，由應用程式開發者負責管理客戶端狀態。

Servlet 架構：輕量、靈活、平台無關

核心優勢

• 元件模型：透過部署描述符（伺服器專屬 + 標準 web.xml）唯一配置
• 平台無關：JVM 跨 OS，J2EE 標準跨 Web 容器
• 協定無關：雖常處理 HTTP，但 Servlet 介面未綁定協定

MVC 中的角色定位

Servlet 天生適合 MVC：

• 控制器：處理請求路由、參數解析、安全檢查、視圖選擇
• 視圖：通常委派 JSP，純 Servlet 亦可輸出內容
• 模型：委派給 JavaBean/助手類處理業務邏輯與後端整合

線程模型與擴展性

單一 Servlet 實例以新線程處理每個請求，執行 service() → doGet()/doPost()。容器管理線程池，資源佔用極低，擴展平滑。

無狀態 Session Bean：健壯的企業級選擇

EJB 容器賦能

• 宣告式安全性與交易上下文
• 可配置的企業 Bean 關係
• 透過資源管理器工廠整合 JMS、JavaMail、JDBC 等 J2EE API

架構定位

Session Bean 可擔任視圖、控制器、模型，常實作 外觀模式或業務委派模式。可被 Servlet/JSP、JavaBean、Applet、Swing 應用、另一 EJB 呼叫。

實例管理與代價

EJB 容器佔用大量 CPU/記憶體，創建管理多物件實例。但換來的是：不犧牲太多回應時間與擴展性的前提下，獲得企業資源、交易、安全的有效管理。無狀態 Bean 可高效池化複用。

技術選型決策矩陣

應用程式客戶端

企業應用整合（EAI）

• Servlet 僅在「僅有 HTTP 通道」罕見情況下適用，否則帶來額外開銷
• 無狀態 Session Bean 為 EAI 設計：輕量、可池化、狀態管理由專用機制/J2EE 交易處理、支援 CORBA 互操作

豐富 GUI 客戶端

Web 應用程式（標準瀏覽器客戶端）

必須使用 Servlet（HTTP 需求）。是否引入 EJB 視企業服務需求而定。

多重客戶端類型共存

最佳實踐：業務邏輯置於無狀態 Session Bean，外部瀏覽器經 Servlet 層存取，內部應用直連 Bean。達成「表現與業務徹底分離、內部應用零抽象直達業務邏輯」。

結語

Servlet 擅長輕量 HTTP 互動與表現層；無狀態 Session Bean 擅長企業級資源、交易、安全管理。實務中常採「Servlet 表現層 + Session Bean 業務層」雙層架構。下集將探討有狀態網路環境下的狀態管理：HttpSession vs 有狀態 Session Bean——敬請期待！