<!-- [if !mso]> <style> v\:* {behavior:url(#default#VML);} o\:* {behavior:url(#default#VML);} w\:* {behavior:url(#default#VML);} .shape {behavior:url(#default#VML);} </style> <![endif]--><!-- [if gte mso 9]><xml> <w:WordDocument> <w:View>Normal</w:View> <w:Zoom>0</w:Zoom> <w:PunctuationKerning /> <w:DrawingGridVerticalSpacing>7.8 磅</w:DrawingGridVerticalSpacing> <w:DisplayHorizontalDrawingGridEvery>0</w:DisplayHorizontalDrawingGridEvery> <w:DisplayVerticalDrawingGridEvery>2</w:DisplayVerticalDrawingGridEvery> <w:ValidateAgainstSchemas /> <w:SaveIfXMLInvalid>false</w:SaveIfXMLInvalid> <w:IgnoreMixedContent>false</w:IgnoreMixedContent> <w:AlwaysShowPlaceholderText>false</w:AlwaysShowPlaceholderText> <w:Compatibility> <w:SpaceForUL /> <w:BalanceSingleByteDoubleByteWidth /> <w:DoNotLeaveBackslashAlone /> <w:ULTrailSpace /> <w:DoNotExpandShiftReturn /> <w:AdjustLineHeightInTable /> <w:BreakWrappedTables /> <w:SnapToGridInCell /> <w:WrapTextWithPunct /> <w:UseAsianBreakRules /> <w:DontGrowAutofit /> <w:UseFELayout /> </w:Compatibility> <w:BrowserLevel>MicrosoftInternetExplorer4</w:BrowserLevel> </w:WordDocument> </xml><![endif]--><!-- [if gte mso 9]><xml> <w:LatentStyles DefLockedState="false" LatentStyleCount="156"> </w:LatentStyles> </xml><![endif]--> <!-- [if gte mso 10]> <style> /* Style Definitions */ table.MsoNormalTable {mso-style-name:普通表格; mso-tstyle-rowband-size:0; mso-tstyle-colband-size:0; mso-style-noshow:yes; mso-style-parent:""; mso-padding-alt:0cm 5.4pt 0cm 5.4pt; mso-para-margin:0cm; mso-para-margin-bottom:.0001pt; mso-pagination:widow-orphan; font-size:10.0pt; font-family:"Times New Roman"; mso-ansi-language:#0400; mso-fareast-language:#0400; mso-bidi-language:#0400;} </style> <![endif]-->

又看到 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 6 的演化。下列资源也许对你了解本文有所帮助：

<!-- [if !supportLists]-->l         <!-- [endif]-->【翻译】 EJB3.1真的来了吗？ EJB3.1系列文章 (一 )

<!-- [if !supportLists]-->l         <!-- [endif]-->【翻译】 EJB3.1真的来了吗？ EJB3.1系列文章 (二 )

<!-- [if !supportLists]-->l         <!-- [endif]-->【翻译】 EJB3.1真的来了吗？ EJB3.1系列文章 (三 )

<!-- [if !supportLists]-->l         <!-- [endif]-->【翻译】 EJB3.1真的来了吗？ EJB3.1系列文章 (四 )

<!-- [if !supportLists]-->l         <!-- [endif]-->【翻译】 EJB3.1真的来了吗？ EJB3.1系列文章 (五 ) 终章

原文请看： http://www.theserverside.com/tt/articles/article.tss?l=JavaEE6Overview

讨论

我所在的 JSR 316 专家组，已经陆陆续续的在几个月内 Java EE 6 的细节公布出来了。本文的目的是想让你大致了解 Java EE 6 的改变，当然我们也鼓励你给我们更多的反馈。除在 JSR 316 专家组制定 Java EE 6 的工作外，我也会参与其它 JSR 的讨论。比如说 Java EE 6 平台已经发布了它的 公众审议草案，官方的公众审议将在 2 月 23 号结束。这意味着，这是最好的反馈时机。

简单回顾

Java EE 5 是一个相当成熟，布署广泛并且支持服务端友好开发的平台。 EJB 3.0 的引用已经颠覆了原有的业务组件开发模型，而原有 EJB2.x 的 Entiy Bean 模型由持久层的 JPA 来代替。 JSF 也被作为官方的标准展示层框架，当然还有咱们的 JAX-WS 2.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 ，当然原因我们也做出了说明：

表 1 ： Java EE 6 被砍的 API

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

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

Profiles: 为不同的开发人员提供不同的制定服务

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

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

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

表 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 所涉及到的技术你又怎么看？是内容太少了，太多了，还是刚刚好？光有它就足够了，还是需要在 Java EE 6 中定义其它 Profile ？还是咱们应当考虑一下更简化的“ Java EE Basic Profile ”？

快速预览 Java EE 6 体系

现在我们来来看看 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 的特点进行简要概括说明：

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

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

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

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

列出的这些令人印象深刻的特性还只是 WebBeans 的冰山一角。 WebBeans 增加了许多其它非常棒的特性来制定下一代 Java EE 的整合方案。想更近一步了解 WebBeans 吗，请点击下面链接去下载已经 公开草案吧： http://jcp.org/en/jsr/detail?id=299 .

呵呵，已经超过文本最大字数了，点击此处继续　

【翻译】Java EE 6体系结构的变革（完）