昨天，我写了一篇关于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 帮助开发人员应对不断变化的市场，我感到很欣慰。