Java EE 6：更好的开发经验正在等待中！

自1998年首次发布Enterprise JavaBeans（EJB）以来，Enterprise Java标准已经走了很长一段路。 在1999年，创建了Java 2 Enterprise Edition（J2EE）平台，将EJB与一系列企业技术组合在一起，并发布了将成为企业应用程序的一套全面而实用的供应商和开发人员标准的套件。 2009年12月发布的Java Enterprise Edition（Java EE）6规范是该王朝的最新版本，并且已经开始在Java社区中留下自己的印记。

谁需要标准？ 在一个庞大的IT预算时代（通常以百万美元衡量），大多数人看到了标准的价值。 公司之所以会获胜，是因为与投资专有技术相比，他们的软件投资受到了更大的保护。 如果他们与特定供应商的关系变糟，或者对未来的信任受到质疑，或者即使他们只是觉得可以在其他地方获得更大的价值，他们就可以更改实现其应用程序所遵循的标准的基础产品。 他们还可以更轻松地找到并雇用开发人员来开发这些产品，因为一组标准的定义明确的技术为培训，交流和评估开发人员技能提供了通用的基础和词汇。 但是，受益于标准的不仅是公司。 开发人员的状况也更好，因为他们的知识和经验可以跨职位和跨实施转移。 他们没有被困在“无用的工作”中，积累了在其直接工作环境之外很少使用的知识。

甚至供应商也欣赏标准的价值，因为通过实施标准，他们知道他们有更大的机会向规避风险的公司出售软件。 产品将更广泛地适用并且更容易消费。

太慢太快

技术的变化与几乎其他任何行业都不一样，促使一些人声称Java EE的发布周期为2至3年太长了。 他们抱怨发布之间发生了太多的新编程创新，并且将它们整合到平台中花费的时间太长。 另一方面，企业IT人员抱怨发布太紧密。 一家拥有包含三百万行代码的软件系统的公司无法轻松升级以使用新技术。 大规模软件的发展势头使得在短时间内根本无法进行重大更改。 对于这些公司而言，过快地更改标准会使他们的系统过早地过时，并且使寻找工作的人变得更加困难。

大多数人认识到必须遵循的平衡行为。 为了使标准成功，不仅要由顾问们采用，他们要急于使用尽可能多的新技术以适应应用程序，还必须由拥有大型系统的公司采用。 在将新技术创新纳入规范之前，应在实践测试中给予一些时间。

在新方法尚未被广泛采用或被证明具有价值之前，采用新方法将使该平台面临风险，并且会对平台实施者和用户造成损害。

分解

Java EE 6平台提供了一些吸引人的新功能，以吸引新的开发人员，并对某些已知的严格规范进行了重大改进。 我们没有足够的空间来描述本文中的所有更改，因此我们将主要关注Java EE 6的新颖方面和已添加的新规范。 但是，在深入探讨细节之前，我们先来深入了解一下Java EE 6平台及其组成的各种规范。 表1简要描述了每个子规范以及在Java EE 6中对其所做的更改。

添加了六个新规范并更新了十三个规范，很明显Java EE 6不是您母亲的企业Java平台。 就开发人员如何编程应用程序而言，Java EE无疑经历了相当大的发展。

定位网络

该版本的主要目的之一是使Web应用程序的开发比以往更加容易。 为此，追求了三个主要方面的改进：创建针对Web应用程序的特殊配置文件，用于更方便地进行Web组件开发的功能以及用于完成体验的更简单的归档打包。

用于Web应用程序的单独的Java EE概要文件实际上只是更一般的概要分析概念的一个实例。 想法是，给定的应用程序类别通常只能利用Java EE技术的子集，并且通过围绕该集合定义配置文件，将更容易生产和使用与该应用程序类型相关的软件。 供应商只能实施和销售该配置文件中包含的零件，但仍可以将其作为完全兼容的配置文件进行营销。

开发人员可以只购买他们的应用程序所需的软件，而不必为整个Java EE堆栈付费或进行开发。 它代表了开发和生产运行时间占用量的减少。

鉴于Web应用程序在业界的重要性，目前，Web Profile是显而易见的首选Profile。 Web配置文件被定义为包含足够的内容，以使大多数Web应用程序能够执行所需的工作，同时省去了大多数Web应用程序不使用的技术。 以下规范构成了Web配置文件。 每个版本的版本与表1中列出的版本相同。

•EJB Lite

•Servlet

•JavaServer页面（JSP）

•表达语言（EL）

•Java交易API（JTA）

•JSP调试

•Java标准标记库（JSTL）

•JavaServer Faces（JSF）

•常见注释

•Java持久性API（JPA）

•Bean验证

•托管豆

•拦截器

•Java依赖注入

•上下文和依赖注入

您可能已经注意到，该列表没有指定EJB，而是指定了EJB Lite，这是EJB的子集，仅包含最新的POJO样式组件。 基于EJBHome和EJBObject客户端视图的较早组件，以及很少用于Web应用程序的规范的其他部分，都不属于EJB Lite。

已在Web和演示组件中添加了许多功能，以及可在Web组件中使用的新规范（将在后面讨论），但是可以说，现在创建演示对象比在Web组件中方便和灵活得多。以前的版本。 支持注释，异步返回，AJAX，标准化的facelets，验证，高级注入等功能，使Web开发人员掌握了更多功能，并且所需的工作更少。

最后，对于具有不仅仅是Web工件和持久性实体的应用程序，打包Web归档文件变得更加简单。 长期以来，使用事务性业务组件对域逻辑进行编码已被视为一种最佳实践，直到现在，EJB仍需要位于单独的JAR文件中。 一个同时使用EJB和Web组件的应用程序需要创建一个EAR文件来容纳WAR和JAR文件。 EE 6中放宽了打包要求，以允许将EJB组件打包到WAR文件中，从而完全不需要EJB JAR文件，并且同样不需要EAR文件。 WAR文件是新的应用程序档案，并且仅依赖于Web Profile的Web应用程序可以完全包装在单个WAR文件中，从Servlet和JSP到EJB和JPA持久性单元。 图1显示了如何将琐碎的应用程序打包在Java EE 5中以及如何将其打包在Java EE 6中。

新规格

在这一点上，我们将介绍此发行版中全新的一些规范。 话虽这么多，话又说不多，所以我们只能对这些规范的某些新增功能有所了解，但足以使这些改进显而易见。 我们将不讨论JASPIC，因为它严格是容器内部使用的服务提供者接口（SPI），并且我们不会讨论拦截器，因为它们在EJB规范的上一版本中已经存在，因此并不是真正的新事物。 。

RESTful Web服务

由于JAX-RS在包含在Java EE 6中之前是以1.0形式存在的，因此它已经被广泛采用。 将1.1版本添加到Java EE 6中使它获得了企业的祝福，并确保了与其他Java EE组件的集成。

REST的简单性使其成为基于SOAP协议的诱人替代品，并且使现有的企业应用程序可以轻松地将其自身的一部分导出为Web服务。 几个注释和一个简单的配置模型共同创建了几乎毫不费力的服务创建体验。 清单1显示了RESTful Web服务的根资源类的一部分。

@ Path注释指定URI，该URI指示将由该资源类提供服务的请求。 URI始终是相对于服务器的，并且可以包含任意数量的变量名，每个变量名都用大括号括起来，并用斜杠分隔。 例如，清单1中的路径被指定为/ employee / {id} ，这意味着此资源类可以为URI形式为http://someserver.com/employeeApp/someContextRoot/employee/24513的请求提供服务。 。 由于@ PathParam注入，最后一个URI组件将分配给id变量，在此示例中，该注入发生在构造函数中。

@ GET批注表示要响应的HTTP方法。 还有其他每个HTTP方法的注释。 @ Produces将请求与返回相应返回类型的service方法进行匹配，@ QueryParam将命名查询参数的值注入到目标中。 在我们的示例中， http ://someserver.com/employeeApp/someContextRoot/employee/24513?count =5的URI将导致size方法参数注入值5。

与传统的基于XML的Web服务相比，RESTful Web服务是一种跨系统实现互操作性的简单得多的方法，这导致REST变得越来越流行。 JAX-RS标准为开发人员提供了最简单的模型，使其能够利用REST，同时仍保持在熟悉的标准编程模型内。

托管豆

托管bean实际上只是一个通用托管类，几乎可以在容器中的任何地方使用。 它像JavaBean一样简单，但是可以用注释进行装饰，以使容器提供其他服务，包括资源注入，生命周期回调和拦截。 它们在容器范围内的适用性意味着它们既可以注入到EJB中，又可以充当传统的JSF管理的bean。 它们也可以成为CDI的注入目标，但稍后会更多。

托管Bean的示例确实很简单，只不过是用@ Managed-Bean注释的类。 @ Resource批注可用于注入资源。 容器将识别生命周期注释，例如@ PostConstruct ，以引起适当的回调方法调用。 根据拦截器规范定义的拦截注释甚至可以应用于触发拦截器。 清单2是一个托管bean的示例。

上下文和依赖注入

在Java EE 5中，可以使用@ Resource和某些资源类型的其他一些特定注释来使用相当有限的资源注入形式。 然而，最新的依赖注入技术已经远远超出了这一点，因此创建了一种高级的注入形式。 上下文和依赖注入（CDI）为绑定到上下文的对象定义了一组注入规则，并结合了定义明确的生命周期，最终不仅提供了合格的注入，而且还提供了事件通知，拦截和修饰。 我们不会介绍CDI的所有功能，但是有两个示例显示了注入变得多么简单和强大。

Java依赖性注入规范定义了一组标准注释，注入框架和容器可以使用这些注释。 CDI支持其中两个注释，供开发人员在其域代码上使用，以及两个元注释，以为其注入基础结构装饰自己的注释：

•@ Inject –指定一个注入点

•@ Qualifier –用于注释的元注释，该注释将进一步限制注入点

• @Scope –定义新范围时使用的元注释

•@ Named –用于命名bean的内置限定符注释

由于与Java EE的其余部分集成，因此CDI可以注入（也可以注入）受管Bean（无论是否使用JSF）和EJB。 它也可以注入到servlet中。 上下文可以对应于servlet中的三个Request ， Session和Application范围中的任何一个，以及JSF中新的Conversation范围。 如果需要，可以添加唯一的用户定义范围。

限定词是通常由应用程序开发人员定义的注释，可在注入点使用它来提供有关要注入的对象的更多详细信息。 它为注入提供了语义，但是将实际注入点与指示注入内容的代码或逻辑分离。 清单3显示了使用合格注入的示例。 定义@Preferred限定符，然后将注入的客户对象限定为WebCustomer 。 因为CustomerOrder的作用域为HTTP会话（使用内置的@SessionScoped注释进行注释），所以将在当前会话中的任何地方注入并引用相同的上下文CustomerOrder有状态会话Bean实例。 有状态会话bean的生命周期将由CDI控制和管理。

CDI可以提供更多的功能，因此强烈建议您进行一些实验或阅读教程。 请参阅Java EE教程以获取良好的起点。

Bean验证

状态验证是合理的常见任务，几乎可以发生在应用程序的任何层。 有时，它甚至可以在多个层上执行，例如在表示层上，再在后端持久性引擎上执行。 为了防止重复并允许对域对象状态进行实用且通用的验证，创建了bean验证标准。 可以通过使用一组标准注释和API以及实现该规范的兼容可插入验证提供程序来执行验证。

设置要验证的bean就像在要检查的bean字段（或属性）上放置约束注释一样容易。 可以将它们放在一个类上，以便针对整个类进行验证，但是大多数情况下，仅验证单个状态字段才有意义。 验证将通过调用验证API以编程方式进行，或者作为JSF或JPA应用程序中生命周期状态更改的结果而发生。 如果Bean验证失败，则验证器将抛出ValidationException，指示Bean在其当前状态下无效。

开发人员还可以定义自己的约束和验证逻辑，从而使验证可以采用任何形式或执行几乎任何检查。 结果是，验证可以根据您想要或需要的简单程度或复杂程度，并具有额外的灵活性来创建要在特定时间进行验证的约束组。 清单4显示了一个用一些内置约束装饰的类，以及一个自定义@ValidScore约束。 还显示了约束定义（具有三个必需的属性）和验证实现类。

HockeyGame类作为一个简单类保留，以使其与其他与验证无关的工件保持清晰，但它很可能是这样注释的实体，其中包含JPA映射。 实例可以在创建实例时进行验证，也可以在数据库插入时进行进一步验证。 验证后，将针对存储在游戏中的ScoringInfo实例调用ScoreValidator.isValid（）方法。

摘要

Java EE 6平台是一个完整的多供应商Java平台，并且基于标准的事实意味着它可以被更多的开发人员和更多的应用程序使用。 尽管Java作为一种语言已经添加了越来越多的功能，有时会增加其在编程体验中的复杂性，但是企业平台在每个新发行版中都变得越来越容易使用。 供应商和开发人员可用的更多，而所需的更少。 同时，Java EE作为顾问和公司IT部门的稳定，可靠的平台而保持了声誉。

我们试图让您了解Java EE 6中已添加的各种功能，但是还有很多内容未提及。 获得更准确的平台感觉的最佳方法是下载并试用。 Glassfish参考实现服务器是开放源代码且免费的，可用于实验以及将应用程序部署到生产环境中。 有关如何下载和使用Glassfish的更多信息， 请参见[4] 。 更好的开发经验正在等待中！