昨天，我在博客中写了关于 Spring 如何帮助最大化应用程序的可移植性。 即使可移植性问题多年来一直是企业 Java 领域的热门话题，该博客也很及时。 今天，甲骨文宣布以 67 亿美元收购 BEA Systems 的交易已经完成。 两家公司的产品组合之间存在大量重叠，因此这必然会给 WebLogic 和 OC4J 的客户群带来不确定性。 WebLogic 和 OC4J 都可能属于“J2EE 服务器”类别，但它们是非常不同的产品，具有非常不同的特性。

由于许多企业应用程序最终与托管环境紧密集成，因此切换 J2EE 服务器绝非易事。 恰恰相反，它可能造成的痛苦与切换操作系统一样多。 常见的 J2EE API（例如 Servlet API）通常不是什么大问题，尽管在配置等方面存在细微差别。 真正的问题通常隐藏在事务管理设置、资源访问语义、与外部消息传递提供程序的集成、应用程序范围内的身份验证和授权等。 即使是 J2EE 的核心，即 JNDI 作为查找机制，也会由于不同的设置规则、EJB 组件的服务器特定名称等而导致许多问题。

幸运的是，许多采用 Spring 编程模型的 WebLogic 和 OC4J 客户处于有利的位置。 他们不仅享受着 Spring 风格的生产力，而且可以很好地管理未来可能发生的任何服务器迁移。 Spring Framework 与 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 帮助开发人员应对不断变化的市场，我感到很满意。