應用程式伺服器作為連結後端資料來源與前端用戶的中介層,構成了經典的「三層架構」。本文深入探討如何在基於 Sun Java Enterprise Edition (J2EE) 規範的應用程式伺服器中,建立並部署 IBM Cloudscape 或 Apache Derby 資料庫作為後端資源管理器。由於 Derby 引擎同樣以 Java 實現,具備「一次編寫,到處執行」的特性,能與 J2EE 伺服器無縫整合,無需修改即可在任何支援 J2EE 的環境中運行。
J2EE 應用程式伺服器可視為執行一或多個 Java 應用程式的中介軟體。它整合了支援應用程式運行及保障網路用戶安全存取所需的各項技術。伺服器管理中間層組件處理核心業務邏輯,用戶層通常透過瀏覽器與之互動,而受保護的後端業務系統(近年稱作 Enterprise Information System,EIS 層)則位於中間層之後。運行於伺服器上的應用程式可透過多種 API(如 J2SE 例程、JSP、Servlet)編寫,並統一存取為伺服器環境定義的資料庫。下圖展示了三層架構的簡化視圖:

大多數 J2EE 應用需持久化資料,採用符合 JDBC 規範的資料庫是主流做法。任何具備 JDBC 驅動介面的資料庫皆可整合為 J2EE 術語中的「Resource Manager (RM)」。Derby 引擎專為大型系統中的關聯式資料庫組件而設計,這正是「嵌入式資料庫」的含義。當嵌入 J2EE 伺服器時,它成為部署應用程式的專用工具。
J2EE 伺服器提供網路通訊與安全性支援,Derby 不實現這些功能,但樂於利用伺服器環境現有的服務。傳統資料庫二進位檔中龐大的程式碼多用於實現 J2EE 系統已內建的安全與網路功能,因此 Derby 僅佔用極少記憶體(約 2 MB),即可在 J2EE 伺服器中建立功能完整、符合 JDBC 的 Resource Manager。
J2SE 提供兩種存取 JDBC 相容資料庫的途徑:
DataSource 介面建立連線。這是 J2EE 應用的首選,因為它能使程式碼與資料庫完全解耦(驅動資訊、位置、參數由伺服器管理),支援連線共用(連線池)大幅提升效能與擴展性,並允許 EJB 利用資料庫實現業務邏輯。DriverManager:應用程式自行建立連線,適用於獨立應用,但無法享受伺服器提供的可攜性與擴展性優勢。J2EE 伺服器最大的優在在於簡化了 JDBC SPI 的使用,避免開發人員自行編寫資料源與連線池程式碼。
以下步驟示範如何透過 JDBC SPI 將 Derby 設定為 J2EE Resource Manager:
derby.jar 加入伺服器目錄),引擎隨 JDBC 驅動載入自動啟動,透過 SQL 指令檔(如使用 ij 工具)建立應用資料庫。derby.jar)、驅動類別名(org.apache.derby.jdbc.EmbeddedDriver)、資料庫連線 URL(如 jdbc:derby:Databases/JPetstoreDB)等資訊。伺服器將自動註冊 JNDI 名稱、建立連線池、啟動資料源。DataSource 介面建立連線(或採用容器管理持久性)。Gluecode 整合了 Apache Geronimo 並提供 GUI 管理主控台。以下為建立名為 JPetstoreDB 的 Derby 資料源步驟:
https://localhost:8080/console/login.html)。完成後,部署於伺服器的應用程式即可透過 JNDI 名稱存取資料庫,無需知悉底層 DBMS 細節。


Derby 作為嵌入式 Java 程式運行於應用程式伺服器 JVM 內部,而非獨立進程。這使其易受伺服器內部實作細節影響,特別是多重類別載入器機制。為隔離多應用程式,伺服器使用多層類別載入器;若 Derby 類別由單一應用專用的載入器載入,或跨越多個載入器,將導致引擎中止。因此,資料庫作為共享資源,應在較高層次的類別載入器載入。透過服務提供者介面 (SPI) 建立連線,可確保應用在不同伺服器環境間的可攜性,不受類別載入器層次結構差異影響。
若架構限制無法使用 SPI,或需將資料庫負載分散至其他機器,可搭配 Derby Network Server 使用,但會引入額外複雜度(獨立啟動、認證、安全策略、不同 JAR 與 URL 語法)。
市面上存在眾多 J2EE 應用程式伺服器,各自捆綁不同技術組合。大多數支援本文所述的資料源與連線池建立。掌握 J2EE 基礎架構,循序漸進熟悉其生態系,是應對龐雜技術棧的最佳策略。