Java EE 簡介

今天我們將討論它是什麼 - Java EE：它由什麼組成，Java EE 應用程式的架構有哪些特點，並且我們將提供該平台的各種技術的描述。這個主題本身很廣泛，但我們不會停留在基礎知識上。最後，我們將對 Java EE 與 Spring 框架進行一個小小的比較，並回答這個問題：「學什麼更好」（劇透：當然，你需要學習所有內容 =）） 讓我們從基礎開始。

Java EE - 它是什麼？

Java EE是一個建立在 Java SE 之上的平台，為開發和運行大規模、多層、可擴展、可靠且安全的網路應用程式提供 API 和運行時環境。此類應用程式稱為企業應用程序，因為它們解決大型企業面臨的問題。然而，大公司和政府機構並不是唯一可以從此類應用程式和 Java EE 提供的好處中受益的人。Java EE 平台提供的解決方案對於個人開發人員和小型組織來說非常有用，有時甚至是必要的。

Java EE 開發

Java EE 是透過 1998 年成立的 Java Community Process (JCP) 開發的。它允許有興趣的各方參與制定 Java 語言平台規範的未來版本。此過程的基礎是 JSR（Java 規範請求），它是描述建議添加到 Java 平台的規格和技術的正式文件。此類請求是由社群成員——普通開發者和公司提出的。後者包括 Oracle、Red Hat、IBM、Apache 等。那些。這些人提出了他們希望包含在 Java 中的新功能和優點供考慮。然後他們進行投票，並在此基礎上決定下一版本包含哪些內容。Java EE 版本歷史如下：

• J2EE 1.2（1999 年 12 月）
• J2EE 1.3（2001 年 9 月）
• J2EE 1.4（2003 年 11 月）
• Java EE 5（2006 年 5 月）
• Java EE 6（2009 年 12 月）
• Java EE 7（五月）
• Java EE 8（2017 年 8 月）
• 雅加達 EE 8（2019 年 9 月）

2017 年，該平台的發展出現了一個新的里程碑：Oracle 將 Java EE 的開發控制權移交給了 Eclipse 基金會。並於2018年4月，Java EE更名為Jakarta EE，與Java EE 8完全相容。

Java EE 應用架構

簡短的介紹。為了更容易理解，讓我們來談談 Java EE 應用程式的結構以及我們將進一步使用的一些術語。Java EE 應用程式的結構具有兩個關鍵品質：

• 一是多層次。Java EE應用程式是多層的，我們稍後會更詳細地討論這一點；
• 其次，築巢。有一個 Java EE 伺服器（或應用程式伺服器），其中包含元件容器。這些容器容納（賓果！）組件。

為了解釋Java EE應用程式的架構，我們先來談談層。級別是多少？不同層級使用了哪些 Java EE 技術？接下來，我們將討論應用程式伺服器、元件容器以及元件本身是如何互連的。但請記住，所有這些都是從不同角度對同一件事的看法，順序在這裡並不那麼重要。

應用程式層級

多層應用程式是根據功能原則劃分為獨立模組（等級、層）的應用程式。通常（包括在 Java EE 開發的背景下），企業應用程式分為三個層級：

• 客戶;
• 平均水平;
• 資料存取等級。

1. 客戶端層是一個從Java EE伺服器（中間層）請求資料的應用程式。伺服器依序處理客戶端的請求並回傳回應。客戶端應用程式可以是瀏覽器、獨立應用程式（行動裝置或桌面）或其他沒有圖形介面的伺服器應用程式。

2. 中間層又分為Web層和業務邏輯層。

   1. Web 層由一些提供用戶端和業務邏輯層之間互動的元件所組成。

      以下 Java EE 技術用於 Web 等級：

      • JavaServer Faces 技術 (JSF)；
      • Java 伺服器頁面 (JSP)；
      • 表達語言（EL）；
      • Servlet；
      • Java EE (CDI) 的上下文和依賴注入。

   2. 業務邏輯層由實作應用程式所有業務邏輯的元件組成。業務邏輯是提供滿足某些特定業務領域（金融業、銀行、電子商務）需求的功能的程式碼。這一層可以認為是整個系統的核心。

      此級別涉及的技術：

      • 企業 JavaBeans (EJB)；
      • JAX-RS RESTful Web 服務；
      • Java持久化API實體；
      • Java 訊息服務。

3. 資料存取等級。此等級有時稱為企業資訊系統層級（EIS）。EIS由各種資料庫伺服器、ERP（Enterprise Resource Planning）企業資源規劃系統及其他資料來源所組成。業務邏輯層存取該層以取得資料。

   在此級別，您可以找到以下技術：

   • Java 資料庫連線 API (JDBC)；
   • Java持久化API；
   • Java EE 連接器架構；
   • Java 事務 API (JTA)。

應用程式伺服器、容器、元件

我們來看看維基百科上對Java EE的定義。Java EE 是一組 Java 語言的規範和相關文檔，描述了用於中型和大型企業任務的伺服器平台的體系結構。為了更好地理解「一組規範」在這種情況下的含義，我們用 Java 介面進行類比。Java 介面本身缺乏功能。它只是定義了一些合同，根據這些合約來實現一些功能。但其他類別實作了該介面。此外，一個介面可以有多種實現，每種實現在某些細節上可能有所不同。規格完全一樣。赤裸裸的Java EE只是一組規格。這些規範由各種 Java EE 伺服器實作。Java EE 伺服器是實作 Java EE 平台 API 並提供標準 Java EE 服務的伺服器應用程式。Java EE 伺服器有時稱為應用程式伺服器。伺服器資料可以包含應用程式元件，每個元件都對應於多層次層次結構中自己的層級。Java EE伺服器以容器的形式為這些元件提供各種服務。容器是它們所託管的元件與支援該元件的低階平台獨立功能之間的介面。容器為其託管的元件提供特定的服務。例如，開發生命週期管理、依賴注入、並發等。容器隱藏了技術複雜性並提高了可移植性。Java EE 中有四種不同類型的容器：

1. Applet 容器由大多數瀏覽器實作。開發小程式時，您可以專注於應用程式的視覺方面，而容器則提供安全的環境。

2. 應用程式用戶端容器 (ACC) 包含一組 Java 類別、程式庫以及在 Java SE 應用程式中實現注入、安全管理和命名服務等功能所需的其他檔案。

3. Web 容器提供用於管理和執行 Web 元件（servlet、EJB Lite 元件、JSP 頁面、過濾器、偵聽器、JSF 頁面和 Web 服務）的核心服務。它負責實例化、初始化和調用servlet，並支援HTTP和HTTPS協定。此容器用於向客戶端瀏覽器提供網頁。

4. EJB（企業Java Bean）容器負責管理和執行包含應用程式業務邏輯層的EJB 模型元件。它會建立新的 EJB bean 實體，管理它們的生命週期，並提供交易、安全性、並發、分發、命名或非同步呼叫功能等服務。

此外，在 Java EE 中，Java EE 規範的實作必須支援 四種類型的元件：

1. Applet 是在瀏覽器中運行的圖形使用者介面 (GUI) 應用程式。他們利用豐富的 Swing API 來產生強大的使用者介面。

2. 應用程式是在客戶端運行的程式。它們通常是圖形使用者介面 (GUI)，用於批次處理。

3. Web 應用程式（由 servlet 及其過濾器、Web 事件偵聽器、JSP 和 JSF 頁面組成）- 在 Web 容器中執行並回應來自 Web 用戶端的 HTTP 請求。Servlet 也支援 SOAP 和 RESTful Web 服務端點。

4. 企業應用程式（使用 Enterprise Java Bean、Java 訊息服務、Java 事務 API、非同步呼叫、時間服務建置）在 EJB 容器中運作。容器管理的 EJB 處理事務業務邏輯。它們可以在本地或透過 RMI（或用於 SOAP 和 RESTful Web 服務的 HTTP）遠端存取。

下圖展示了一個典型的 Java EE 應用程式架構：

科技

所以，我們已經整理好了架構。整體結構應該清晰。在描述架構組件的過程中，我們接觸到了一些Java EE技術，例如EJB、JSP等。讓我們仔細看看它們。下表顯示了主要在客戶端層級使用的技術： 下表展示了業務邏輯層所使用的技術： 下表展示了資料存取層使用的技術：

Java EE 與 Spring

Spring 框架被認為是 Java EE 的競爭對手。如果你看看這兩個平台的發展，就會出現有趣的畫面。Java EE 的第一個版本是在 IBM 的參與下創建的。事實證明它們很酷，但笨拙、沉重且使用起來不方便。由於需要維護大量配置檔案以及其他使開發變得複雜的原因，開發人員陷入了困境。同時，Spring IoC誕生了。這是一個小而美麗且易於使用的圖書館。它還使用了一個配置文件，但與 Java EE 不同的是，它只有一個。Spring的簡單性導致幾乎每個人都開始在自己的專案中使用這個框架。然後 Spring 和 Java EE 開始了相同的目標，但起點不同。Spring 的開發商 Pivotal Software 開始發布一個又一個項目，以涵蓋 Java 開發人員所有可能和不可能的需求。漸漸地，先前所謂的Spring首先成為其中一個項目，然後與Spring Core中的其他幾個項目完全合併。所有這些都導致​​ Spring 與原來相比不可避免地變得複雜。隨著時間的推移，追蹤整個 Spring 依賴關係變得非常困難，需要一個單獨的庫來載入和運行所有內容（現在心愛的 Spring Boot 在某個地方出現了問題）。 一直以來，JCP 都在致力於一件事——最大限度地簡化 Java EE 中可能實現的一切。因此，在現代 EJB 中，要描述一個 Bean，只需在類別上方指定一個註解就足夠了，這使開發人員能夠充分利用 Enterprise Java Beans 技術的功能。類似的簡化也影響了 Java EE 中的每個規格。因此，Spring 和 Java EE 在功能方面大致相當。有些事情更好，有些事情更糟，但如果你放眼全球，並沒有太大差異。工作的複雜性也是如此。Spring 和 Java EE 都是優秀的工具。也許是目前用 Java 建立企業網路應用程式的最佳選擇。然而，Java EE 通常只能在企業應用伺服器中工作（Tomcat 不是），Spring 堆疊上的應用程式可以在任何東西上運行（在同一個 Tomcat 上），甚至根本不需要伺服器（因為它會運行）它本身獨立）。這使得 Spring 成為開發小型前端 GUI 應用程式或微服務架構的理想工具。但消除對應用程式伺服器的依賴對 Spring 應用程式的可擴展性產生了負面影響。Java EE 非常適合實現可擴展的整體叢集應用程式。目前，勞動力市場對熟悉 Spring 框架的開發人員的需求量更大。歷史上是這樣的：在 Java EE 過於複雜的時候，Spring「贏得了客戶群」。然而，對於學什麼 Spring 還是學 Java EE 的問題，還沒有明確的答案。可為初學者提供以下建議。熟悉（至少表面上）這兩個平台。使用 Java EE 和 Spring 編寫一個小型家庭專案。然後深入研究工作中所需的框架。因此，在 Spring 和 Java EE 之間切換並不困難。

結果

當然，一個大型主題不可能在一篇文章中涵蓋！在了解大量新術語之後，您可能希望將這些知識「應用」到現實生活中的範例中。因此，我們將繼續研究 Java EE：您將在下一篇文章中找到有關設定本地 Java EE 開發環境的實作課程。