Java EE 6开发三剑客:JSF 2.0、EJB 3.1和JPA 2.0

JSF 2.0 尽管 Java 在展示层框架上竞争的非常激烈，但 JSF 仍然固守着自己的领地。虽然有很多关于 JSF 的易用性和健壮性的质疑声，但 JSF2.0 就是为正面解决这些问题而提出来的，它的易用，创新以及可扩展的特性包括： JSF 正式将 Facelets 作为视图技术。也许你不熟悉 Facelets ，它也是一个与 JSF 结合默契的开源视图技术。因此，与 JSP 不同的是 Facelets 更适合 JSF 的组件模型以及生命周期的概念。当然，也许 Facelets 最强大的特性就是在用 mark-up 来代替 java 代码创建自定义的组件。创建自定义组件的复杂度也许是开发者对 JSF 抱怨最多的地方了。 JSF2.0 通过使用标签为 Java EE 5 提供了基于 annotation 驱动的配置特性（比如说可以使用 @ManagedBean 和 @ManagedProperty ）。这也意味着可以一定程度上的减少 faces-config.xml 文件的大小，不过像在 navigation 这些结点的配置在 XML 文件还是不能少。 JSF2.0 为适应 AJAX 而改变了自身的生命周期，只需要局部页面的交由 AJAX 事件处理。这个特性使得 JSF+AJAX 的组合更加自然。 JSF2.0 现在内置了优秀的资源处理器。对 images ， JavaScript 文件以及 CSS 样式等都表现出众。它可以对通过逻辑名称，资源分组以及版本等方式来更好的引用资源。 除上述特性外， JSF2.0 还包括许多其它方便的改变。比如说支持事件，支持 RAILS_ENV 的开发风格 （ 就是 ROR） ，支持对标准组件集进行扩展。你可以通过下面的链接来看看 JSF2.0 的公开草案：http://jcp.org/en/jsr/detail？id=314 EJB 3.1 EJB 在 Java EE 5 就已经经历过了非常大的改动。也许看似不可能，但实际上 EJB3.0 还是在社区中广泛得到认可，并且采纳它的人也在不断增长。而这一切也许是因为我们过度的认为需要怎么怎么简化 Java EE 5 才取得这样的成绩。比如说，对 JBoss Seam 的兴趣和 GlassFish 的热情都是重要的关键因素。 EJB3.1 的目标就是在增加业务组件时，继续让 EJB 变得尽可能简单。下面是对 EJB3.1 特性的高度概括： 原本需要甚至实现 Session Beans 的业务接口变得可选了，不再强迫要求实现。在使用 Session Beans+JSF+WebBeans 的场景下尤其有用。 EJB3.1 增加了 Singleton Beans 的概念。因为人们更倾向于管理共享的应用程序状态，需要保证是完全线程安全的模型。此外， EJB3.1 新增的声明式的并发控制也更加灵活。 EJB3.1 一个可圈可点的的强大特性就是支持 cron 风格的 scheduling .除目前基于 timer API 的调度计时器外，声明式和编程式的 cron 风格的 scheduling API 也加入了进来。 另一个强大的特性就是可以通过使用 @Asynchronous 标注来对 Session Bean 的方法进行异步调用。你甚至还通过它来控制异步 EJB 方法从而返回一个 java.util.concurrent.Future 对象。 EJB3.1 Lite 概念的逐渐引入形成了一个 EJB API 的子集，并在 Web Profile 中得到应用。只不过 EJB Lite 包含了像事务处理和安全这样的特性，而那些消息机制，远程调用以及 scheduling 等非必须的自然没有必要加入其中。除上述列表所述特性外， EJB3.1 的特性还包括：括直接将 EJB 打包成 war 文件，可运行在 embedded 的容器中便于 Java SE 环境进行 JUnit 测试，使用统一的标准化全局 JNDI 命名方式。 EJB3.1 的公开草案可从以下链接获得： http://jcp.org/en/jsr/detail？id=318 JPA 2.0 到 Java EE 6 的时候， JPA 已经彻底从 EJB 中分离，形成自己的体系 （EJB3.0 已经将 JPA 分离出去了 ） . JPA 的成功是毫无疑问的。它广泛得到社区的采纳和一流供应商的支持。本来我们担心 EJB2.* 的 Enity Beans 垮台可能无法让 Java EE 再次引领持久层的标准，一个重要成功的因素就是 Gaving King 和 JBoss 社区毫不含糊的支持。 JPA2.0 的目标就是要在这次成功的基础上再接再厉，填补更多的空白，再创多的创新： JPA2.0 加入了大量必须的 ORM 映射增强特性，包括：支持通过使用 @ElementCollection 标注来增强 collections， maps 和 lists（ 这里不是指实体之间的关联关系 ） 集合，支持 map 的单向 one-to-many 关联 （JPA1.0 只允许双向 one-to-many 关联 ） . EntityManager 和 Query API 都得到改进。比如说，现在可以从结果集中直接取得第一条记录 （JPA1.0 只允许从一个 unique 结果集中反回单个记录 ） ，指定 query 结果集的最大值，访问各个供应商的底层实体对象 manager 或 query ，最后就是加入悲观锁 （JPA1.0 只支持乐观锁 ） . JPQL 也提供类似于 SQL 的 CASE ， NULLIF ， COALESCE 等函数 . JPA2.0 应广大开发者要求增加了 Criteria API .要是你对 Hibernate 或 TopLink 的 Criteria API 不熟悉的话，可以将它想像成一个以 Java 为中心的面向对象，线程安全并可以与 JPQL 划上等号的一组 API .这组 API 适合于编写复杂的动态查询语句，还可避免解析 JPQL 语句时，所抛出的运行期异常。 更完整的 JAP2.0 特性还包括：标准的二级缓存，标准的 JDBC properties ，指定超时时间等等。你可以随时通过下面的 JSR 站点看看关于 JPA2.0 公开草案的更多细节： http://jcp.org/en/jsr/detail？id=317

ejb3.1和jpa2.0? spring和hibernate要下岗啦?

JAVA EE6规范里本来就没有spring和hibernate
不过个人倒是真的更看好EJB3.1+JPA2.0

看来我的好好学学了，新技术也更新太快啦。。

名词越来越多
技术越来越多
这些和项目要做的事情,究竟有多大关系呢?
浪费时间而已.

事实上现在某些技术更新太快,但实质上改变不大

现在就熟悉SSH2，上面三者一个都不会怎么办呢！

hibernate不会下岗，jpa的前身就是hibernate，而且jpa其实是就像接口一样，还需要其他技术来实现，用hibernate来实现jpa就是一个很好的选择。
spring就难说了，seam可以取代它

JPA仅仅是一个接口而已，其中hibernate和toplink是它的实现，
EJB3和JPA本身借鉴了hibernate和spring，而Gaving King更是EJB3
规范的制定者之一

越來越多，越來越雜，代碼民工也越來越多。。。最後事情還是那些，開持用的東東不知什麼了