尽管 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 样式等都表现出众。它可以对通过逻辑名称，资源分组以及版本等方式来更好的引用资源。
还是在社区中广泛得到认可，并且采纳它的人也在不断增长。而这一切也许是因为我们过度的认为需要怎么怎么简化 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
到 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 语句时，所抛出的运行期异常。
Servlet3.0 在 Java EE 6 的模型中引入了像 @WebServlet ， @ServletFilter 和 @WebServletContextListener 等标注。它们能很大程序上减少 web.xml 配置。
Servlet3.0 当然也引入 web.xml 分块思想。这就意味着容器除了可以在 WEB-INF/lib 中查找 web.xml
，还可以在任何 web 应用程序的 classpath (比如说 WEB-INF/classes 或 WEB-INF/lib 中的 jar
包)中查找 web.xml 配置文件片断。这对于像 JSF 或 Struts 这些需要在 web.xml 通过配置才能启动的 web
应用程序框架尤其有用。
另一个非常酷的特性就是可通过使用 ServletContext 来编程式的增加 Servlets ，
Filters 以及 Listeners 。和刚才提到的 web.xml
片断一样，该特性也主要是为满足框架开发人员需要动态的在运行期决定配置而新增的。
REST 的日益兴起为 web services 开发提供了新的方式。这次包含的 JAX-RS
与先前的 JAX-WS 地位相当，表示 Java EE 也认可 REST 是一种趋势。与 JAX-WS 的出发点一致， JAX-RS 也远离了
SOAP 协议的底层细节。 JAX-RS 设计的目标就是想，通过使用 POJO 编程模型和基于标注的配置，来减少 REST 开发周期。下面是对
JAX-RS 的高度概括：
@Path 标注用来决定一个 JAX-RS 的资源 URL 可以被合法访问。可用于 POJO 。
像 @GET ， @POST ， @PUT 和 @DELETE 这些标注可用来指定相应的 HTTP 方法，来对资源进行访问。
像 URL query 参数， cookies 的值以及 HTTP header 的值都可以通过 @QueryParam, @PathParam ， @CookieParam 和 @HeaderParam 等标注将其与对应的变量映射在一起。
JAX-RS 可以和 Servlets ， WebBeans 或 EJB 集成。