昨天，我寫了一篇關於Spring 如何幫助最大化應用程式可移植性的部落格。儘管可移植性問題一直是企業 Java 領域的一個持續性話題，但這篇部落格非常及時。今天，Oracle 宣佈其以 67 億美元收購 BEA Systems 的交易已完成。兩家公司產品集存在大量重疊，因此這必將為 WebLogic 和 OC4J 的客戶群帶來不確定性。WebLogic 和 OC4J 可能都屬於“J2EE 伺服器”類別，但它們是截然不同的產品，具有截然不同的特性。

由於許多企業應用程式最終會與託管環境緊密整合，因此切換 J2EE 伺服器絕非易事。恰恰相反，它可能會像切換作業系統一樣痛苦。常見的 J2EE API，例如 Servlet API，儘管在配置等方面存在細微差別，但通常不是主要問題。真正的問題通常隱藏在事務管理設定、資源訪問語義、與外部訊息傳遞提供商的整合、應用程式範圍的身份驗證和授權等方面。即使是 J2EE 的核心，即 JNDI 作為查詢機制，也可能由於不同的設定規則、EJB 元件的伺服器特定名稱等原因而導致許多問題。

幸運的是，許多采用 Spring 程式設計模型的 WebLogic 和 OC4J 客戶都處於有利地位。他們不僅享受 Spring 式的生產力，而且為應對未來可能出現的任何伺服器遷移做好了充分的準備。Spring 框架與 Spring Security 等關鍵產品相結合，可以處理企業應用程式自身邊界內的許多常見問題。環境服務以典型的 Spring 委託風格使用，比標準 J2EE 場景更具體。因此，從應用程式的角度來看，遷移到不同的託管環境通常侵入性要小得多。

我們還從 WebSphere 上的 Spring 使用者那裡瞭解到，他們讚賞在他們目前面臨的遷移場景中獲得的相同可移植性優勢：在 WebSphere Application Server 本身的不同代產品之間（5.1 / 6.0 / 6.1 / 6.1 配合 EE 5 功能包），以及在傳統的 WebSphere Application Server 和基於 Geronimo 的 WebSphere Community Edition 之間（它們在共同的 WebSphere 名稱下是截然不同的產品）。

我從未想過自己會從事保險行業 ;-) — 但看到 Spring 幫助開發人員應對不斷變化的市場，我感到很欣慰。