这是我的Java EE 7小知识系列的第二部分。 在进行简要介绍的第一个介绍之后，我决定请Arjan Tijms撰写有关Java EE 7中他最喜欢的新后端功能的文章。如果您关注Java EE领域，您将知道Arjan。 他是Java EE开发人员，JSF和Security EG的长期成员，他与Bauke Scholtz （又名BalusC）一起创建了OmniFaces ，并帮助建立zeef.com 。

1.应用程序提供的管理对象

Java EE长期以来一直具有“管理对象”的概念。 这是一种在应用程序服务器上而不是由应用程序定义的资源。 对于某些类别的应用程序，这是最佳做法，而对于其他类别的应用程序，则不是最佳做法。

Java EE 6通过引入@DataSourceDefinition开始了一次小小的变革，它允许应用程序定义自己的数据源。 Java EE 7通过@MailSessionDefinition（JavaMail 1.5），@ ConnectionFactoryDe​​finition＆@AdministeredObjectDefinition（JCA 1.7）和@JMSConnectionFactoryDe​​finition＆@JMSDestinationDefinition（JMS 2.0）对此进行了扩展。

实际上，许多应用程序已经使用JavaMail的编程API来创建邮件会话，而JCA的使用相对较少。 但是，JMS的使用更加广泛，并且缺少创建目的地（队列和主题）的（EE兼容）编程API。

这个看似很小的功能的重要性在于，在JMS历史上首次可以完全标准的方式使用它，而无需在应用程序存档中使用特定于供应商的xml文件或在应用程序服务器中不需要特定于供应商的配置。

请注意，这些应用程序提供的资源定义都没有将其余的应用程序代码牢固地绑定到这些应用程序。 该应用程序代码仍然仅看到JNDI名称，并且不依赖于资源是通过标准注释，标准XML文件，专有XML文件还是应用程序服务器上的专有配置放置在JNDI中。

进一步阅读

• 在Java EE 7中自动配置JMS资源

2.默认资源

与应用程序提供的管理对象密切相关，Java EE还引入了一些默认资源的概念。

在使用默认资源的情况下，Java EE平台会提供特定类型的随时可用的资源。 Java EE 7引入了数据源的默认值，平台的默认JMS连接工厂和默认线程池。

这些默认值的特征在于它们无法以任何标准化方式进行进一步配置。 您必须处理服务器提供的任何内容。

对于数据源，这意味着您可以获得可以向其发送SQL的“内容”，但是就性能甚至持久性没有进一步的保证（尽管数据源访问的数据库可能完全基于内存，但是实际上，它几乎总是服务器特定目录中的文件）。

对于JMS连接工厂，您可以连接到服务器的默认JMS提供程序。 由于JMS与SQL数据库不同，它是Java EE的强制组成部分，因此您通常对这里的功能有很好的了解。 例如，如果所讨论的服务器是生产就绪服务器，则默认的JMS提供程序实际上始终是生产就绪服务器。

最后，一些实际资源（例如ManagedExecutorService）使您可以访问实质上是系统的默认线程池的资源。 可以使用与使用Java EE 6中的@Asynchronous批注几乎相同的方式来使用此类线程池。您不完全知道该池中有多少个线程，也不知道ManagedExecutorService是否由与@Asynchronous相同的池支持，但是对于简单的即席多线程工作，默认值通常就足够了。

默认资源的一个特别好的方面是，在某些情况下，您甚至不必说要使用默认资源。 如果您未指定JPA持久性单元的默认数据源，那么默认数据源就是很好。

进一步阅读

• Java EE 7中的默认数据源：更少的XML和更多的默认值
• Java EE 7中的默认设置

3.提供的应用程序和便携式身份验证机制

除了上面提到的管理对象之外，传统上必须在应用程序服务器端定义和配置的另一件事是身份验证机制和身份存储（两者都有许多备用名称）。

Servlet规范确实定义了4种标准化的身份验证机制，应用程序可以通过其web.xml部署描述符（FORM，BASIC，DIGEST，CLIENT-CERT）从中选择，但是并未对这些类别的实际类或接口进行标准化，因此后来没有标准化用于自定义身份验证机制的所有API / SPI。 此外，规范中没有关于存储呼叫者姓名/凭证/组的实际位置的任何内容。

就像@DataSourceDefinition一样，Java EE 6通过标准化用于身份验证机制的API / SPI以及用于从应用程序JASPIC 1.0中进行注册的编程API进行了一次小小的革命。

不幸的是，JASPIC的Java EE 6版本有一些关键的遗漏，这使得实际上很难使用这些可移植的身份验证机制。 Java EE 7中解决了其中最重要的问题。

就像应用程序提供的管理对象一样，应用程序提供的身份验证机制不会将其余的应用程序代码绑定到这些对象上，并且可以透明地将其替换为容器提供的代码。

进一步阅读

• Java EE 7的身份验证支持有哪些新功能？

4.基于CDI的@Transactional

在Java EE 7之前，高级声明式事务是EJB的领域。 在此模型中，EJB旨在用作平台提供的许多功能的通用外观。 尽管EJB从J2EE 1.4中的一项笨拙的重量级规范演变为Java EE 6中实际上相当轻量的规范，但将一个规范用作外观的模型不再被认为是理想的模型。

Java EE 6在实际引入CDI方面带来了最大的变化，而Java EE 7掀起了另一场小革命，其他规范开始改为依赖CDI。 以此为基础，一种bean类型的模型开始转换为作为基础的一种bean类型的竞争模型，其他规范在此之上进行了扩展。

专门启用此功能的是JTA 1.2，引入了@Transactional和@TransactionScoped。 这些基于Interceptors规范中的拦截器和CDI规范中的范围。 两者都主要适用于CDI bean。 改变模型的方式是，在EJB中，JTA在后台被隐式地使用，而在CDI中，JTA（在某种程度上是不可见的）在后台被使用CDI。

进一步阅读

• JTA 1.2 –不再是您祖父的交易！
• Arjan ZEEF页面上的JTA 1.2

5.方法验证

Bean验证规范可能是Java EE中功能最多且跨层的规范之一。 Bean验证可以将验证约束施加到各种Bean上，例如CDI Bean和JPA实体。

但是，这些验证约束仅在字段级别有效，并通过在类级别扩展（有效验证多个字段）而起作用。

在Java EE 7中，bean验证的适用性通过将这样的约束也放置在方法上的能力而发生了巨大的飞跃，恰当地称为方法验证。 更确切地说，现在可以将约束施加在方法的输入参数上以及方法的返回值上，并且输入约束可以在单个参数上以及在多个参数上。

尽管字段级别约束是在特定时刻进行验证的，例如，当JPA实体管理器保留实体或在JSF中进行回发之后，则每次通过任意代码调用方法时都会进行方法验证。在Java EE中，当方法为在（代理）CDI托管bean中，并且确实通过代理访问了该方法。

进一步阅读

• Bean验证1.1 Feature Spotlight –方法验证
• Bean验证1.1在Arjan的ZEEF页面上

6.表达语言可以在任何地方使用

表达式语言是Java EE中使用的一种迷你脚本语言。 它具有悠久的历史，从专门针对JSTL到本机并入JSP，本机并入JSF以及后来在JSP和JSF之间实现统一。

在Java EE 7中，这种表达语言取得了有史以来的最大飞跃，并成为完全独立的规范，通常完全在JSP和JSF之外，甚至在Java EE之外。

这意味着可以在注释，电子邮件模板，配置文件等中使用表达语言。 就像在Java EE 6中引入CDI一样，将来可以在许多其他规范中使用单独使用的表达语言。

进一步阅读

• 标准偏差：Servlet环境中的表达语言3.0插图
• Arjan ZEEF页面上的EL 3.0

7.大大简化的JMS API

Java EE中较旧的规范之一是JMS，它是关于（异步）消息传递的。 JMS也是很长一段时间（自2002年以来就没有更新！）的规范之一，尽管仍然令人惊讶，但它的使用年龄确实开始有所显示。

借助JMS 2.0，Java EE 7给JMS带来了最大的变化之一。 彻底简化的API。 这些简化的一部分使用了上面提到的默认资源，但是它还利用了Java SE 7的自动关闭功能和许多智能默认值，以最大程度地减少用户为处理诸如发送消息之类的事情而不得不管理和处理的对象数量。 。

进一步阅读

• JMS 2.0中的新增功能，第1部分：易于使用
• Arjan ZEEF页面上的JMS 2.0

8. JPA中的实体图

可以说，Java EE中除CDI之外最重要的规范之一就是JPA。 无论Java EE应用程序是基于JSF的MVC还是基于JAX-RS的Web服务，它们几乎总是具有一些持久性要求。

持久性的困难之一是确定什么是正确的数据量。 显然，这不应太少，但也不应太大，因为这通常会带来很大的性能影响。

JPA的重要调整参数一直是对特定关系的渴望和懒惰加载。 此选择主要在实体本身上进行结构化和硬编码。 这样做的问题是，在不同情况下，可能需要使用或多或少的数据的同一实体。 例如，在所有用户的概述中，您可能只想显示用户名，而在详细视图中，您还希望显示地址和其他联系方式。

在Java EE 7之前，可以通过编写单独的查询而无需为每种情况获取太少或太多的数据来完成此操作。 虽然这解决了问题，但它并不是最佳的，尤其是当它涉及大型查询时，并不是最佳选择，唯一的区别是为某个实体获取了多少关联数据。

在JPA 2.1中，Java EE 7为此引入了实体图的概念。 通过一个（命名的）图，现在可以确定是否需要以图样式的概念来获取哪些数据。 这些图是分别定义的，可以在运行时与许多不同的查询关联。

进一步阅读

• JPA 2.1实体图–第1部分：命名实体图
• Arjan ZEEF页面上的JPA 2.1

9.访问托管线程池

上面在讨论默认资源时简要提到，在Java EE 7中提供了对默认线程池的访问。

实际上，支持不仅限于此，而且Java EE 7在此之后引入了整个规范。 Java EE规范的并发工具。 使用此规范，您不仅可以获取该默认线程池，还可以获取并使用单独的线程池。 这对于QoS用例非常重要，特别是在将相互依赖的工作安排到同一池中的情况下，可以防止大量死锁情况。

不幸的是，由于无法以标准方式实际定义这些池，因此在一定程度上限制了这些附加池的实际可用性。 这与本概述开头的“应用程序提供的管理对象”项有些矛盾。

尽管存在这个问题，但对于某些较低级别的异步和并行编程，此规范提供了很多选择。

CDI调整，拦截器规格，批处理

在Java EE 7中，Interceptors规范从CDI中分离出来，为CDI铺平了道路，使CDI可以更加专注于成为Java EE的核心bean模型，同时使拦截器在整个平台上更通用。

CDI本身并没有进行大修，也没有获得真正的新功能，而是获得了一些较小但非常受欢迎的功能，例如（以更简单的方式）以编程方式获取bean实例的方式，以及在激活作用域和触发作用域时触发的事件。停用。

自动启用CDI（无需bean.xml即可激活CDI）应该是一个主要功能，但是在实践中似乎用途有限。 如果没有bean.xml文件，则仅扫描具有所谓“ bean定义注释”的bean，尤其是对于初学者而言，这并不总是很清楚。

传统上，Java EE主要处理通常运行时间较短的请求和响应。 有一个计时器服务可用于后台作业，但这是一个相对基本的功能。 几乎没有任何作业管理，检查点或重新启动的概念。

在Java EE中，引入了一个全新的规范来专门解决这些问题。 Java Platform 1.0批处理应用程序规范。 这解决了在其中指定了作业的XML文件的问题，这些文件本身包含执行实际顺序应用程序逻辑的所谓步骤。

进一步阅读

• CDI 1.1
• 拦截器1.2
• 批次1.0

感谢Arjan抽出宝贵的时间来编译所有这些内容。 下一篇文章将介绍前沿技术的十大功能，同时还将介绍一位杰出的客座博客。 在此之前，有足够的时间来使用Java EE7。以下是一些资源，可帮助您开始使用JBoss EAP 7和WildFly：

• EAP 7 Alpha和Java EE 7入门
• 带有JBoss工具的OpenShift 3上的Java EE 7应用程序
• GitHub上的Java EE 7示例

翻译自: https://www.javacodegeeks.com/2015/12/refresher-top-10-java-ee-7-backend-features.html