后端 java ee

這是我的小型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

后端 java ee

總結

以上是生活随笔為你收集整理的后端 java ee_刷新器-Java EE 7后端十大功能的全部內容，希望文章能夠幫你解決所遇到的問題。

如果覺得生活随笔網站內容還不錯，歡迎將生活随笔推薦給好友。