從 EJB 2 CMP 遷移至 pureQuery：IBM InfoSphere MDM Server 持久層現代化實戰 (上)

背景：MDM Server 持久層面臨的技術債

2007 年，IBM Master Data Management 團隊規劃 WebSphere Customer Center 重要新版（更名為 IBM InfoSphere Master Data Management Server），架構關鍵決策之一是如何處理基於 EJB 2 容器管理持久性（CMP）實體 Bean 與本地 JDBC 呼叫的現有持久機制——該機制正逐漸過時。本文為兩部分系列之首，闡述為何決定採用 pureQuery 技術、遷移規劃、以及驗證決策的效能與功能測試結果。

InfoSphere MDM Server 產品概覽

IBM InfoSphere MDM Server 管理驅動組織核心業務流程的主資料實體（客戶、帳戶、產品），提供全面 MDM 解決方案，具備服務所有主資料管理方法的高度開箱即用功能。使用 MDM Server，組織可將關鍵資料集中至單一受信來源——識別最高價值客戶、增加收入、降低成本、從既有系統獲取更大價值、提升客戶滿意度、快速發現新市場。

MDM 系統關鍵共同需求：統一多域主資料庫（知識層）、提供 SOA 業務服務操作查詢資料、管理資料品質正確性、提供智能前瞻業務邏輯參與資料生命週期、提供資料治理功能實現審計交易與資料存取安全。

實際上，MDM Server 為 SOA 應用，擁有豐富預定義業務服務維護資料庫主資料。接受 XML 格式更新請求 → 解析為物件 → 安全檢查 → 驗證標準化複寫 → 透過持久層套用變更。持久層為本文關注焦點。MDM Server 為 WebSphere Customer Center 繼任者，增強帳戶與產品主資料域。

Data Studio Developer 與 pureQuery 技術概覽

IBM Data Studio 產品組合提供整合、模組化資料管理環境，跨資料管理生命週期設計、開發、部署、管理資料與應用。本文聚焦 Data Studio Developer 與 Data Studio pureQuery Runtime 提供的 pureQuery 技術：構建於 JDBC 之上的高效能 Java 資料存取技術，簡化資料庫應用與服務開發部署。pureQuery 在 Java 與資料庫間搭建橋樑，解決連結兩領域的大量效能與生產力問題。

直接寫 JDBC 冗長乏味，且需精通 JDBC/SQL 才能確保高效。為獲最佳效能，開發者必須掌握 JDBC API、善用批次處理與結果優化等特性。ORM 框架雖減少初始工作，但診斷執行期效能問題時增加開銷與複雜度——開發者無法控制發送到資料庫的 SQL，難以修改 SQL 或確定發出應用。pureQuery 解決這些問題：

• 簡單直觀的 API，預覽針對 JDBC 標準化考慮的功能
• 在 Java 集合與資料庫快取中發揮 SQL 威力
• 工具簡化常見任務：儲存/檢索 Bean、資料庫雙向映射開箱即用
• SQL 完全可客製化、可擴展（可插入自訂結果處理模式）
• 擴充 Java 編輯器含整合 SQL 編輯器，提供代碼完成、驗證、執行輔助
• 關鍵標誌：單一 API 程式設計、靜態/動態 SQL 執行部署能力（靜態 SQL 公認提升效能、穩定性、安全性）
• 未來版本將追蹤 SQL 回初始應用，縮短問題判別時間、協助影響分析

注意：pureQuery 非成熟持久層，無受管物件支援；若需成熟持久層/受管物件，可能需 OpenJPA 等。未來版本望向所有 Java 應用（不限 pureQuery API 編寫）實現優勢。

WebSphere Customer Center 原持久機制

使用兩種機制：因 EJB 2 查詢效能問題，早期決定查詢操作用直接 JDBC 呼叫，CRUD 操作用 EJB 2 CMP。

EJB 2 CMP 架構視圖

四層架構（左至右）：請求框架操作轉換訊息 → Tx 控制器處理交易邏輯 → 業務元件處理元件邏輯 → 持久層（CMP 實體 Bean）執行 CRUD。業務元件從業務物件 (BObj) 取得實體物件 (EObj) 送持久層，返回後再以 BObj 包裝 EObj。EObj 與表一對一映射，作為持久層與業務元件間傳輸物件。

直接 JDBC 架構視圖

查詢操作持久層由業務元件呼叫，支援直接 JDBC 呼叫。查詢參數傳遞至 BObjQuery（不同業務元件有不同實現）→ 呼叫共用 SQLQuery 類取得 SQL ResultSet → 傳遞至 ResultSetProcessor 建立業務物件（每業務元件有特定實現）。

現有持久機制的問題

EJB 2 CMP 實體 Bean 問題

• CMP 僅解決部分 ORM 需求：實體 Bean 非 POJO，不可隨意傳遞，須手動在 CMP Bean 與自有實體物件間移動屬性值
• CMP ORM 程式碼不可在 JDBC 查詢重用：CMP 產生 Bean-表映射碼，因 Bean 非 POJO，JDBC 查詢無法利用
• CMP 開發複雜：單一 Bean 需 6 個類 + 部署描述符 + 映射檔 + 資料庫結構；調用步驟繁瑣（JNDI 上下文 → 查找 EJB Home → 發現 Bean → 更新）
• 依賴 J2EE 伺服器：不同伺服器需不同部署碼與描述符，增加維護與分發工作

直接 JDBC 呼叫問題

• ORM 依賴手動程式設計：麻煩、易錯、降低開發生產力

JDBC 與 EJB 2 CMP 結合問題

• 同一交易中同時執行更新與查詢時發生資料同步問題：CMP Bean 更新至交易結束才寫入資料庫，導致同一交易中後續 JDBC 查詢不可見更新資料

效能問題

• CMP EJB 查詢無法在查詢場景執行（故改用直接 JDBC）
• CMP 實體 Bean 更新效率低：需資料庫讀取與更新（容器管理特性）
• 容器管理產生大量程式碼：雖分離關聯層與物件層，但犧牲效能；團隊編程模型中由複雜本地 SQL 處理關聯層，無需對程式設計師隱藏 SQL，實體管理基本無用

技術路線圖問題

• 規劃使用 XML 資料型別，非標準 JDBC SQL 型別；DB2 與 Oracle 解釋不同，需修改基本 CRUD SQL，但 CMP 產生的基本 CRUD SQL 不可修改，無法採用 XML 型別
• EJB 2/CMP 在 JEE5 中已棄用，被 EJB 3/JPA 取代；JPA 設計簡化開發、提供查詢靈活性，但仍基於實體管理概念

新持久機制期望

基於問題與未來規劃，需新持久機制，要求：

• 簡單物件關聯映射：Java Bean 屬性到表欄位映射（無實體關聯/繼承映射）、超類映射支援、基本 CRUD SQL 產生、插入/更新/刪除前後生命週期回調
• 所有產生碼可移植至不同應用伺服器
• 開發流程易降低升級成本：支援「自下而上」（有表結構開發物件層與 ORM）與「中間會合」（有表結構與物件層開發 ORM）方法的開發工具
• 可擴展彈性：使用 SQL 所有功能、修改產生的 CRUD SQL
• 效能優於現有機制
• 平滑遷移既有碼
• 客戶可擴充實體/屬性，機制與客戶既有碼向後相容
• 技術符合下版本交付進度、採用風險最小
• 強大技術路線圖、與團隊方向一致、至少 5 年可用

受管持久性與 pureQuery 比較

調查三種機制：現有 EJB 2/CMP、EJB 3/JPA、pureQuery。前二者為受管持久方案，pureQuery 非。表 1 依需求評價：

決策與執行計畫

顯然，受管持久方案不符團隊編程模型，團隊欲釋放 SQL 威力而非隱藏它，實體管理增加不必要開銷且負面影響效能。鑑於 Data Studio Developer 工具對 SQL 開發的協助與以資料為中心的開發關注，pureQuery 成最自然選擇。為支援決策，制定計畫驗證技術：

• 確定 pureQuery 開發與交付環境
• 調查程式設計模型、產品交付/開發軟體平台、物件關聯映射開發工具、樂觀控制實現
• 估算 CMP 與直接 JDBC 遷移至 pureQuery 工作量
• 調查遷移既有 EJB CMP Bean 與直接 JDBC 呼叫方式
• 執行功能測試消除向後相容疑慮
• 調查 pureQuery 與 EJB 2/CMP、直接 JDBC 共存性
• 調查全域交易 (XA) 支援
• 執行基準測試消除效能疑慮，確保新機制優於現有

結語與下期預告

本文概述 MDM Server 與 pureQuery，深入剖析 Customer Center 原持久機制與問題，依期望比較三技術，pureQuery 脫穎而出並制定執行計畫。下期將詳細討論技術驗證結果：遷移實體 Bean 至 pureQuery 的開發者生產力、查詢與 CRUD 效能結果、交易一致性，並分享經驗教訓助類似專案。