JAVA EE 6

最佳实践： 从 Spring 迁移到

WTF ?!WTF ?!??

Bert Ertman

荷兰 Luminis 公司研究员

荷兰 Java 用户组的负责人，同时还是一位 Java Champion

这是说给谁听的？您正在使用老版本的 Spring ，却不知怎样向前发展Java EE 好像又火起来了，您应当赶上这样的趋势吗？您喜欢《 J2EE Design and Development 》这本书，但它仍没有过时吗？

为什么要倾听我们的意见？我们不为任何一家应用服务器供应商 工作我们也不是 Rod Johnson 的追随者我们广泛使用 J2EE 、 Spring 和新的 Java EE 技术针对 Java EE 和 Spring 展开过无数次讨论……

为什么要迁移？

Spring 是一项专有技术无论如何，从旧版的 Spring 升级需要大量的工作那，为什么不直接迁移到标准上来呢？

场景 A

Scenario A

但现在我们需要这样的

首先让我们澄清几个误解……

Java EE 是否过于庞大了？部署了应用后的平台启动时间

JBoss AS 7 约 2 秒Glassfish V3 约 4 秒Tomcat 6 + Spring 约 4 秒

Java EE 6 WAR 文件 < 100kb

但是我需要依赖注入

• Java EE 6 引入 CDI

• 更强大的上下文 DI 模型

• 让平台能够以标准方式扩展

但是我需要 AOP ！是吗？难道您想让你的代码变得杂乱并难以理解吗？或者，您仅仅是使用了轻量级的 AOP ， 即 Spring AOP 或 Java EE 规范中的拦截器？

我是否需要重型工具？

功能比较功能 Spring JavaEE

依赖注入 Spring 容器 CDI

事务 AOP/ 批注 EJB

Web 框架 Spring Web MVC JSF

AOP AspectJ （限于 Spring bean ） 拦截器

消息处理 JMS JMS / CDI

数据访问 JPA / JDBC 模板 / 其他 ORM JPA

RESTful Web 服务 Spring Web MVC (3.0) JAX-RS

集成测试 Spring 测试框架 Arquillian *

* 不是 Java EE 规范的一部分

这一切均可使用普通轻量级 Java EE 完成

rm -Rf spring*

?

当然，这将十分有趣！

实际情况呢？

当然，这将十分有趣！

实际情况呢？

典型的老版本 Spring 应用大量复杂的 XML 配置文件，无法使用注解

旧式 / 过时的 ORM 解决方案

（ JDBC 模板、 Kodo 、 Toplink 等）

过时的基于 Web MVC 的扩展

（ SimpleFormController 等）

迁移路径1.升级 Spring 版本2.替换 Spring 内的旧框架（ ORM 、 Web 框

架）3. Spring 和 Java EE 容器并存4.完全替换 Spring

5.移除 Spring 容器

迁移路径1.升级 Spring 版本2.替换 Spring 内的旧框架（ ORM 、 Web 框

架） 3. Spring 和 Java EE 容器并存4.完全替换 Spring

5.移除 Spring 容器

升级 Spring 版本

升级 Spring 运行时（替换 JAR 文件）无代码 / 配置变更

迁移路径1.升级 Spring 版本 2.替换 Spring 内的旧框架（ ORM 、 Web 框

架）

3. Spring 和 Java EE 容器并存4.完全替换 Spring

5.移除 Spring 容器

替换 Spring 内的旧框架 表示层

数据 /集成层

Web MVC

任务

Spring JDBC 模板Kodo

@AutoWired

业务层

JMS bean

@AutoWired

@AutoWired

JPA

JSF尚未触碰特定于 Spring 的 API

Spring bean

迁移路径1.升级 Spring 版本 2.替换 Spring 内的旧框架（ ORM 、 Web 框

架）3. Spring 和 Java EE 容器并存4.完全替换 Spring

5.移除 Spring 容器

myapp.warSpring 容器

Servlet 容器

Spring 应用程序

Spring beanSpring bean

TX

TX

管理器

管理器

AO

PA

OP

OR

MO

RM

Java EE 6 应用服务器

CDI / EJB 容器

myapp.war

CDI bean会话 bean

TX

T

X

管理器

管理器

安全性

安全性

拦截器

拦截器

JPA

JPA

Java EE 应用程序

Java EE 6 应用服务器

CDI / EJB 容器myapp.war

CDI bean会话 bean

TX

T

X

管理器

管理器

安全性

安全性

拦截器

拦截器

JPA

JPA Spring 容器

Spring bean

Spring bean

TX

TX

管理器

管理器

AO

PA

OP

OR

MO

RM

混合在一起

在 Java EE 容器内运行 Spring

表示层

数据 /集成层

Spring bean 任务

Spring JDBC 模板

业务层

JMS bean

@AutoWired

@AutoWired

JPA

JSF

Spring 和 Java EE 容器并存表示层

数据 /集成层

Spring bean 任务

Spring JDBC 模板

业务层

JMS bean

@AutoWired

@AutoWired

JPA

JSF

EJB CDI

@Inject

@Inject

Spring DAO

Spring 配置

JSF / CDI bean

在此，我们不想了解 Spring

用 CDI 封装 Spring

编写 CDI 扩展引导 Spring 容器在 Spring 容器中查找 Spring Bean 并在 CDI 上下文中发布

CDI 扩展示例

迁移路径1.升级 Spring 版本 2.替换 Spring 内的旧框架（ ORM 、 Web 框架）3. Spring 和 Java EE 容器并存4.完全替换 Spring

5.移除 Spring 容器

完全替换 Spring

表示层

数据 /集成层

Spring bean 任务

Spring JDBC 模板

业务层

JMS bean

@AutoWired

@AutoWired

JPA

JSF

EJB CDI

@Inject

@Inject

完全替换 Spring

表示层

数据 /集成层

EJB 计时器业务层

MDB

@AutoWired

@AutoWired

JPA

JSF

EJB CDI

@Inject

@Inject

Spring JDBC 模板

TX 层将 Spring TX 和 DAO 迁移到 EJB

TX 管理器在应用服务器内默认情况下， EJB 是事务性的EJB 集成了 JPA

您是说 EJB 很好吗？

一点没错！EJB 只是容器管理的 POJO

与 Spring bean 一样，而且不需要容器配置……

DAO

Spring

DAO 配置

Java EE 替代方案

EJB

处理惰性加载

许多 Spring 应用程序使用 Open-EntityManager-In-View 模式EJB 具有扩展的持久性上下文更明确、更强大

LazyInitializationException 异常

修复惰性加载 问题

只要 bean 存在就保持 EntityManager 可用

沉迷于模板？

如果使用了 JDBC 模板将会怎样？让我们开始是否使用 ORM 的老生常谈第 1 阶段：拒绝第 2 阶段：最终将会完成迁移 ;-)

使用 Java EE 内的 JDBC 模板

可用简单的生成器方法注入可能是因为它没有依赖 Spring 容器尽管有一些额外的依赖项

模板生成器示例

迁移路径1.升级 Spring 版本 2.替换 Spring 内的旧框架（ ORM 、 Web 框架）3. Spring 和 Java EE 容器并存4.完全替换 Spring

5.移除 Spring 容器

移除依赖项类路径只需要包含 API 所需的类，并不需要包含框架类使得从大约 40 个依赖性减少 到 1 个

测试方面如何？Spring 在测试方面一直很出色

DI 让单元测试可行Spring 测试框架让 Spring 容器内测试可行灵活配置能满足多环境下测试的需要

如何进行测试？

Arquillian

使用 API 创建微部署部署到真正应用服务器在服务器中运行测试

Arquillian 示例

这一切都值得吗？

Spring 之后还有后来者吗？

我们相信，创新空间总是存在的最好是通过开源实现并且，如果有更为杰出的技术发展出来了，我们会将其整合到标准规范中

还有更多！

• Jboss 网站上的 4 部分文章系列• Pet Clinic 示例应用程序的逐步迁移• http://www.howtojboss.com

谢谢！