Java EE 6体系结构的变革

又看到 Reza 同学为 Java EE 6 奔走呼告了。如同在浩浩荡荡的就业大军中的一员，Reza 带着自己的最新“简历”—— Java EE 6，向咱们开发人员展示耳目一新的感觉。但从本文的字里行间中，隐隐约约还是能觉察到它的困惑和迷茫：“已经付出了这么多， Java EE 6能再次成功吗?开发者会采纳它吗?如果不是，我们还应该做什么?......”。当年 EJB2.* 的垮台掀起了反对使用 EJB的浪潮。实际上我接触 JavaEE 比较晚 ( 大概在 2007 年初 ) ，没有使用过 EJB2.* ，但也是不够客观的照着大家说的抨击EJB ，天天嘴边挂着 Struts ， Spring ， Hibernate 。但随着对 JavaEE的不断关注与了解，渐渐发现自己的盲从于无知。此次 Java EE 6的特性预览更有让我渴望学习它的冲动。“技术选型的抉择政治因素往往大于技术本身 。” Java EE 6的推广还应该要更多的成功实战项目来赢得“政治因素”。但如同刚毕业的应届生，没有经验也要面对就业，除实力本身外，靠的就是运气了......

　　简单回顾

　　Java EE 5 是一个相当成熟，布署广泛并且支持服务端友好开发的平台。 EJB 3.0 的引用已经颠覆了原有的业务组件开发模型，而原有EJB2.x 的 Entiy Bean 模型由持久层的 JPA 来代替。 JSF 也被作为官方的标准展示层框架，当然还有咱们的 JAX-WS2.0 代替了 JAX-RPC 作为新的 SOAP web services API 。 Java EE 5 的目标非常明确——通过引入Annotation ， POJO 编程模型，零配置 (zero-configuration)等一系列概念从而降低开发的复杂度，帮助开发人员从 XML 地狱中解脱出来。尽管对 Java EE持观望态度的还是大有人在，但是也许要证明“实际上 Java EE 5已经获得成功”的最有利的证据就是由于上述提到的种种改变，使得很多家伙第一次开口说他们已经考虑接受 Java EE 。还是这帮家伙，在体验Java EE 编程模型后，不断的向我们反馈他们的震惊。

　　大局观

　　Java EE 6 又将是迈向理想中那简洁，高效以及整合完好平台之旅的一大步。 Java EE 6 又有了一系列技术上的革新：有全新的 WebBeans1.0 和 JAX-RS 1.1 API ，也有更加成熟的老牌 API Servlet3.0 。

　　除少数相对较小的改变外 ( 比如说标准的全局 JDNI 命名，本文将不会谈到 ) ，大多数 JSR 316 中的主题都是精挑细选出来的。现在咱们就一同来看看这些变化。想了解更多细节，我推荐你把公众审议草案下载下来看看。这是链接地址： http://jcp.org/en/jsr/detail?id=316 .

　　砍掉没用的 API

　　Java EE 的第一版发布于 1999 年。在竞争异常激烈的业界一直作为官方标准，那时间也不算很短了。但在这段时期里， Java EE只是一味的在成长，结果导致到现在平台变得臃肿不堪，充斥着一堆毫无用处的过时 API ，用起来不爽，布署起来也不方便。 Java EE 6开始正儿八经的处理这些 API ，确保平台更加轻量级，同时也是为了腾出更多的空间，更利于 Java EE 的健康成长。表 1显示了那些被砍掉的 API ，当然原因我们也做出了说明：

被砍的 API	被砍原因
JAX-RPC	JAX-RPC 是早期通过 RPC 调用和 SOAP web services 进行交互的编程模型。由于 Web services 成熟后从 RPC 模型中分离出来，更加健壮，更多特性和流行 JAX-WS API 实际上已经代替了 JAX-RPC 。
EJB 2.x Entity Beans CMP	复杂，笨重，过度复杂的 EJB2.* 的 Entity Bean 模型已经被 Java EE 5 的基于 POJO 的流行轻量级 JPA 持久层模型所代替。
JAXR	JAXR 是 Java API 中少数几个用于 UDDI 注册服务的接口之一。遗憾的是，由于 UDDI 并没有广泛使用，现在 JAXR 已经几乎没有啥应用，而且供应商支持的也很少，难免遭到被砍命运。
Java EE Application Deployment (JSR-88)	JSR 88 是当初是用于 J2EE 应用程序在应用服务器上进行的配置和部署的标准 API 。可是该 API 始终没有得到众供应商的支持，不得不砍掉。
Java EE Management (JSR-77)	和 JSR 88 有着相似的命运， JSR77 原本是用于为应用服务器创建监控管理的 API 。可是各大供应商热情仍然并不高涨，难逃被砍命运。

表 1 ： Java EE 6 被砍的 API

　　上述精简 API 的原则上是，应用服务器供应商不需要强制的去支持这些技术，但是不排除一些大型的供应商仍就会对这些被砍 API 继续维持一段时期。

　　对于此次调整你有什么看法?太过于激进了?还是仍然过于保守?你还用上述表格中看得到的 API 吗?还有其它你认为也应该被砍掉的 API 吗?

对于 Java EE 主要抨击之一就是它太庞大了。确实啊，大多数中小型的 Java web 应用程序根本用不了所有 Java EE 技术(full Java EE stack) 。你可以想像一下，如果要构建一个类似于 SOA 的应用程序，会用到消息，事务，持久化以及 WebServices ，但犯不着需要使用像 JSP 或 JSF 这类的展示层技术。

　　Profile 就是为解决这个问题而设计的。Profiles 其实就是一个 Java EE API 的子集，对于特定的应用程序有着各自的解决方案。比如说，被提议到的 Java EEWeb Profile 仅仅只包含了一些最有可能大绝大多数 Java web 应用程序中使用的 API 。像 Profiles这样的理念已经在标准化的世界上取得的成功也是由来已久。也许你早就知道， Java ME 其实就支持 Profiles——支持每种特定的设备运行环境。类似的， Profiles 可用来更好的组织日益复杂的 web services 世界 ( 比如说 WS-IBasic Security Profile 等等 ) 。

　　虽然 Java EE 6 通过 JSR 来定义了一些规则用于创建新的 Profiles ，但这一次仅仅只有一个 Profile 当选—— Web Profile 。表 2 列出了 Web Profile 与 Java EE 完整平台的比较情况：

API	Web Profile	Full Profile
Servlet 3.0	<!-- [if gte vml 1]> <![endif]-->
JSP 2.2
JSTL 1.2
EL 1.2
JSF 2.0		支持
WebBeans 1.0 (?)	支持	支持
EJB 3.1 (Lite)	支持	支持
EJB 3.1 (Full)		支持
JPA 2.0	支持	支持
JTA 1.1	支持	支持
JMS 1.1		支持
JavaMail 1.4		支持
JAX-WS 2.2		支持
JAX-RS 1.1		支持
JAXB 2.2		支持
JACC 1.0		支持
JCA 1.6		支持

表 2 ： Java EE 6 的 Web Profile

　　WebBeans 为什么也能入围的原因曾经也是一个大大的问号，至今大家对是否应该在 Java EE 6 中加入 WebBeans仍然各执一词。围绕 WebBeans 的争论焦点是：它怎么适合加入 Java EE 体系?还有是不是 JSR所研究的技术就一定是对的呢?对于你是否也是这么想的呢?也许你并不了解 WebBeans ，下面我会对此话题进行延伸。是否 WebBeans应该纳入到 Java EE 6 中呢?如果不这么做，那 JSR 应该做出什么样的改变?同时还应留心一下 EJB Lite ，它是虽不是完整版的EJB ，但此次也被加入到 Web Profile 中了。下面我也会简要的再提到 EJB Lite 。

　　对于 Java EE 的 Profiles 思想，你又有何看法?符合 Profile 的轻量级的应用程序服务器是否对你有用?关于 Web Profile 所涉及到的技术你又怎么看?是内容太少了，太多了，还是刚刚好?光有它就足够了，还是需要在 JavaEE 6 中定义其它 Profile ?还是咱们应当考虑一下更简化的“ Java EE Basic Profile ”?

现在我们来来看看 JSR316 专家组所做的工作，看看哪些技术加入到了 Java EE平台上了。虽然这项工作非常重要并且我们也渴望听到你对上文提到的内容提出建议。从这一章节开始，我们来快速看看 Java EE 6 API的改变。我是极力推荐你自己去深度发掘下列所提到的每一项 API 。我认为你会喜欢接来的内容，所有的 API 都会因你时宜的反馈而更加精彩。

　　WebBeans 1.0

　　在 Java EE 6 的里程碑上， WebBeans 也许算得上是最具开创性的 API 了。 WebBeans 填补了 Java EE的很多空白。尽管 WebBeans 由 Seam ， Google Guice 以及 Spring 所进化而来，但它并不是直接的复制。实际上，WebBeans 本身就拥有许多独一无二的创新。 WebBeans 由 JBoss/Red Hat 的 Gaving King 和Google 的 Bob Lee 领导着。下面就对 WebBeans 的特点进行简要概括说明：

　　WebBeans 将 JSF， JPA 和 EJB3 等编程模型统一了起来，让人感觉它们是一个整合完好的开发平台。这一切是通过将 EJB3 的 beans ， JPA 的entity 以及普通 Java Bean 注册为 WebBeans 的组件，然后通过使用 EL表达式进行访问。当然，它们之间也可以在进行“依赖注入”。实际上，如果你需要的话， WebBeans 完全可以让你忽略 JSF 的backing beans 。

　　通常在上下文中， WebBeans 隐式的管理着所有注册组件的生命周期。除传统的request, session 和 application 等主要作用域外，它还添加了一些新作用域“ dependent ”和“conversation ”。 dependent 显式的“继承”了调用者的作用域，而 conversation 则是一个全新的作用域，(conversation 上下文与一个浏览器窗口(或页卡)联系在一起，这个浏览器窗口(或页卡)由随每个请求提交的一个标志来标识。conversation 作用域使用 HTTP Session 的一个单独的区段在页面之间迁移数据 。 )从 EJB3.1来看，它又填补了客户端组件作用域 ( 包括 stateless ， stateful 和 shared) 与 Web 应用程序中心端的空白。

　　WebBeans 为大家引入一组成熟的依赖注入特性，提供了一个完整的以 Java 为中心的类型安全开发平台。这些特性包括：对任意非 EJB 的 Java 对象的整合，将非托管的对象注入到托管对象中去，使用对象工厂，指定组件化的布署环境并利用 stereotypes 去管理 annotations 。

　　WebBeans 可以通过 Annotation 将拦截器 (interceptor) 绑定到目标对象上，增强了 Java EE的拦截器模型。通过 Annotation 所绑定的拦截器会自动的作用于目标对象，这一点与现在的 Java EE 5 是不同的( Java EE5 中目标对象与拦截器之间还是通过间接方式进行关联，比如说 xml 配置文件)。