遷移核心原則
J2EE 標準賦予了應用可移植性：同一套遷移方法論適用於 WebLogic、Tomcat、JBoss、Resin 等所有源平台。難點在於：應用對 J2EE 規範的遵循度、非標準組件的耦合程度。標準部分按流程走，非標準部分需逐個攻克。
九步遷移法論
- 精通工具：熟練 WebSphere Studio Application Developer (WSAD)
- 選取代表子系統：覆蓋技術難點、歸納配置與依賴庫
- 架構解耦：梳理模塊依賴，消除循環引用，避免同 JVM 多份同類庫
- 原環境驗證：子系統獨立運行通過
- 配置重規劃：針對 WebSphere ClassLoader 體系調整打包結構（關鍵步驟）
- WSAD 導入修復：利用任務視圖修復構建錯誤，定位規範違背點
- ClassLoader 深度規劃：共享庫去重、統一打包策略（EAR 根目錄 + Manifest 依賴）
- 分層調試：UTC 測試 EJB → 客戶端對接
- 部署驗證與全量推廣：EAR 發布測試 → 工作量評估 → 集成測試
ClassLoader 體系與打包黃金法則
- Web 模塊共享 JAR →
WEB-INF/lib
- EJB + Web 共享 JAR → EAR 根目錄 + 各模塊
MANIFEST.MF Class-Path 引用
- 禁用 服務器級 ClassPath 配置，保持應用可移植性
- 嚴禁同一應用存在多版本同名 JAR
五大常見遷移陷阱
1. JNDI 查找規範差異
| 場景 | WebLogic | WebSphere (嚴格規範) |
|---|
| EJB 遠程接口 | 可選 PortableRemoteObject.narrow() | 必須 narrow |
| EJB 本地接口 | 全局 JNDI 可用 | 必須 java:comp/env + ejb-ref |
| ejb-ref 綁定 | 全局 JNDI 可選 | 必須 綁定全局 JNDI 名（ibm-ejb-jar-bnd.xmi） |
2. J2EE 1.3/1.4 特性配置
- CMP 2.0 連接工廠：資料源
jdbc/Sample → CMP 工廠 eis/jdbc/Sample_CMP
- MDB/JMS：按 WebSphere 專有步驟配置激活規範、監聽端口
- 表單認證：
j_security_check 替代 weblogic.servlet.security.ServletAuthentication
3. 客戶端遷移關鍵點
- IIOP 協議替代 T3：
com.ibm.websphere.naming.WsnInitialContextFactory + iiop://host:2809
- 客戶端 JDK：IIOP 方式必須使用 WebSphere 專用 JDK
- UserTransaction 查找名：
jta/usertransaction
- EJB 接口/Stub 打包進客戶端 JAR，不依賴動態下載
4. 異常處理規範收緊
- 本地 Home/Bean 方法不可拋出 RemoteException
- MDB 不可拋出 應用異常（無調用鏈）
5. 數據映射策略
- 名稱完全一致 → Top-Down 映射
- 名稱不一致 → Meet-in-the-Middle 映射
- 第三方 ORM（Hibernate/TopLink/Kodo）顯著提升可移植性
遷移項目管理建議
- 以「子系統驗證」為里程碑，避免大爆炸式整體遷移
- 建立「遷移決策日誌」：記錄每個非標準點的處理方案與理由
- 自動化對比測試：同一測試數據集在源/目標環境跑雙向驗證
- 性能基線對標：遷移後吞吐量、延遲、GC 行為必須達標
結語
J2EE 遷移本質是「規範對齊 + 非標準解耦」。掌握 WebSphere ClassLoader 機制、JNDI 嚴格模式、IIOP 協議棧，配合 WSAD 強大的靜態分析能力，絕大多數遷移可在可控風險內完成。記住：標準是盾，非標準是矛，架構師的任務是收起矛、擦亮盾。
