Java EE の概要

今日は、Java EE とは何か、その構成要素、Java EE アプリケーションのアーキテクチャの特徴について説明し、このプラットフォームのさまざまなテクノロジについて説明します。このトピック自体は広範囲に及びますが、基本的な部分にとどまりません。最後に、Java EE と Spring Framework を少し比較し、「どちらを学ぶのが良いか」という質問に答えます (ネタバレ: もちろん、すべてを学ぶ必要があります =) ) 基本から始めましょう。

Java EE - それは何ですか?

Java EE、Java SE 上に構築されたプラットフォームであり、大規模で多層のスケーラブルで信頼性の高い安全なネットワーク アプリケーションを開発および実行するための API とランタイム環境を提供します。このようなアプリケーションは、大企業が直面する問題を解決するため、エンタープライズ アプリケーションと呼ばれます。ただし、このようなアプリケーションや Java EE が提供する利点から恩恵を受けることができるのは、大企業や政府機関だけではありません。Java EE プラットフォームが提供するソリューションは、個々の開発者や小規模組織にとって便利であり、場合によっては単に必要な場合もあります。

Java EE開発

Java EE は、1998 年に設立された Java Community Process (JCP) を通じて開発されました。これにより、関係者は Java 言語プラットフォーム仕様の将来のバージョンの策定に参加できます。このプロセスの基礎となるのは、Java プラットフォームに追加することが提案されている仕様とテクノロジを説明する正式な文書である JSR (Java Specific Request) です。このようなリクエストは、コミュニティのメンバー、つまり一般の開発者や企業によって行われます。後者には、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 (5月)
• Java EE 8 (2017 年 8 月)
• ジャカルタ EE 8 (2019 年 9 月)

2017 年に、プラットフォーム開発における新たなマイルストーンが発生しました。Oracle は Java EE 開発の管理を Eclipse Foundation に移管しました。そして 2018 年 4 月に、Java EE は Java EE 8 と完全な互換性を持つ Jakarta EE に名前変更されました。

Java EEアプリケーションアーキテクチャ

短い紹介。理解を容易にするために、Java EE アプリケーションの構造と、今後使用するいくつかの用語について説明します。Java EE アプリケーションには、次の 2 つの重要な特性を持つ構造があります。

• まずはマルチレベル。Java EE アプリケーションは多層になっており、これについては後で詳しく説明します。
• 2番目に、ネスティング。Java EE サーバー (またはアプリケーション サーバー) があり、その中にコンポーネント コンテナがあります。これらのコンテナには (ビンゴ!) コンポーネントが格納されています。

Java EE アプリケーションのアーキテクチャを説明するために、まずレイヤーについて話しましょう。レベルは何ですか? さまざまなレベルでどのような Java EE テクノロジーが使用されていますか? 次に、アプリケーション サーバー、コンポーネント コンテナ、およびコンポーネント自体がどのように相互接続されるかについて説明します。ただし、これらはすべて同じものを異なる角度から見たものであり、ここでは順序はそれほど重要ではないことに注意してください。

アプリケーションレベル

多層アプリケーションは、機能原則に従って分離されたモジュール (レベル、レイヤー) に分割されたアプリケーションです。通常 (Java EE 開発のコンテキストを含む)、エンタープライズ アプリケーションは 3 つのレベルに分けられます。

• クライアント;
• 平均レベル;
• データアクセスレベル。

1. クライアント層は、Java EEサーバー(中間層)にデータを要求するアプリケーションです。次に、サーバーはクライアントのリクエストを処理し、それに応答を返します。クライアント アプリケーションは、ブラウザー、スタンドアロン アプリケーション (モバイルまたはデスクトップ)、またはグラフィカル インターフェイスを持たないその他のサーバー アプリケーションにすることができます。

2. 中間レベルは、Web レベルとビジネス ロジック レベルに分かれています。

   1. Web レイヤーは、クライアントとビジネス ロジック レイヤー間の対話を提供するいくつかのコンポーネントで構成されます。

      次の Java EE テクノロジーが Web レベルで使用されます。

      • JavaServer Faces テクノロジー (JSF)。
      • Java サーバー ページ (JSP)。
      • 式言語 (EL);
      • サーブレット。
      • Java EE (CDI) のコンテキストと依存関係の挿入。

   2. ビジネス ロジック層は、アプリケーションのすべてのビジネス ロジックを実装するコンポーネントで構成されます。ビジネス ロジックは、特定のビジネス領域 (金融業界、銀行業務、電子商取引) のニーズをカバーする機能を提供するコードです。このレベルはシステム全体の核心と考えることができます。

      このレベルに関係するテクノロジー:

      • エンタープライズ JavaBeans (EJB)。
      • JAX-RS RESTful Web サービス。
      • Java Persistence API エンティティ。
      • Java メッセージ サービス。

3. データアクセスレベル。このレベルは、エンタープライズ情報システム (EIS) のレベルと呼ばれることもあります。EIS は、さまざまなデータベース サーバー、ERP (Enterprise Resource Planning) エンタープライズ リソース プランニング システム、およびその他のデータ ソースで構成されます。ビジネス ロジック層は、データを取得するためにこの層にアクセスします。

   このレベルでは、次のようなテクノロジーを見つけることができます。

   • Java データベース接続 API (JDBC)。
   • Java 永続性 API。
   • Java EE コネクタ アーキテクチャ。
   • Java トランザクション API (JTA)。

アプリケーションサーバー、コンテナ、コンポーネント

Wikipedia から Java EE の定義を見てみましょう。Java EE は、Java 言語の仕様と関連ドキュメントのセットであり、中規模および大企業のタスクのためのサーバー プラットフォームのアーキテクチャを記述しています。この文脈における「一連の仕様」の意味をよりよく理解するために、Java インターフェースで類推してみましょう。Java インターフェイス自体には機能がありません。それは単に、いくつかの機能が実装されるいくつかの契約を定義するだけです。ただし、他のクラスはインターフェイスを実装します。さらに、1 つのインターフェイスに複数の実装を含めることができ、それぞれの実装は細部で互いに異なる場合があります。仕様も全く同じです。裸の Java EE は単なる仕様のセットにすぎません。これらの仕様は、さまざまな Java EE サーバーによって実装されます。Java EE サーバーは、Java EE プラットフォーム API を実装し、標準の Java EE サービスを提供するサーバー アプリケーションです。Java EE サーバーは、アプリケーション サーバーと呼ばれることもあります。サーバー データにはアプリケーション コンポーネントを含めることができ、各コンポーネントはマルチレベル階層内の独自のレベルに対応します。Java EE サーバーは、コンテナの形式でこれらのコンポーネントにさまざまなサービスを提供します。コンテナは、コンテナがホストするコンポーネントと、そのコンポーネントをサポートするプラットフォームに依存しない低レベルの機能との間のインターフェイスです。コンテナは、ホストするコンポーネントに特定のサービスを提供します。たとえば、開発ライフサイクル管理、依存関係の注入、同時実行性などです。コンテナは技術的な複雑さを隠し、移植性を高めます。Java EE には4 つの異なるタイプのコンテナがあります。

1. アプレット コンテナは、ほとんどのブラウザに実装されています。アプレットを開発するときは、コンテナが安全な環境を提供しながら、アプリケーションのビジュアル面に集中できます。

2. アプリケーション クライアント コンテナ (ACC) には、Java SE アプリケーションでのインジェクション、セキュリティ管理、ネーミング サービスなどの機能の実装に必要な Java クラス、ライブラリ、およびその他のファイルのセットが含まれています。

3. Web コンテナは、Web コンポーネント (サーブレット、EJB Lite コンポーネント、JSP ページ、フィルター、リスナー、JSF ページ、および Web サービス) を管理および実行するためのコア サービスを提供します。これは、サーブレットのインスタンス化、初期化、呼び出し、および HTTP および HTTPS プロトコルのサポートを担当します。このコンテナは、Web ページをクライアント ブラウザに提供するために使用されます。

4. EJB (Enterprise Java Bean) コンテナは、アプリケーションのビジネス ロジック層を含む EJB モデル コンポーネントの管理と実行を担当します。新しい EJB Bean エンティティを作成し、そのライフサイクルを管理し、トランザクション、セキュリティ、同時実行、配布、ネーミング、非同期呼び出し機能などのサービスを提供します。

また、Java EE には、Java EE 仕様の実装でサポートする必要がある 4 種類のコンポーネントがあります。

1. アプレットは、ブラウザ内で実行されるグラフィカル ユーザー インターフェイス (GUI) アプリケーションです。豊富な Swing API を活用して、強力なユーザー インターフェイスを作成します。

2. アプリケーションはクライアント側で実行されるプログラムです。これらは通常、グラフィカル ユーザー インターフェイス (GUI) であり、バッチ処理に使用されます。

3. Web アプリケーション (サーブレットとそのフィルター、Web イベント リスナー、JSP および JSF ページで構成) - Web コンテナー内で実行され、Web クライアントからの HTTP リクエストに応答します。サーブレットは、SOAP および RESTful Web サービス エンドポイントもサポートします。

4. エンタープライズ アプリケーション (Enterprise Java Beans、Java Message Service、Java Transaction API、非同期呼び出し、Time Services で構築されたもの) は、EJB コンテナ内で実行されます。コンテナ管理の EJB は、トランザクション ビジネス ロジックを処理します。これらには、ローカルまたは RMI (または SOAP および RESTful Web サービスの場合は HTTP) を介してリモートでアクセスできます。

以下の図は、典型的な Java EE アプリケーション アーキテクチャを示しています。

テクノロジー

そこで、アーキテクチャを整理しました。全体的な構造が明確である必要があります。アーキテクチャ コンポーネントを説明する過程で、EJB、JSP などのいくつかの Java EE テクノロジに触れました。それらを詳しく見てみましょう。以下の表は、主にクライアント レベルで使用されるテクノロジーを示しています。 以下の表は、ビジネス ロジック レベルで使用されるテクノロジを示しています。 以下の表は、データ アクセス層で使用されるテクノロジーを示しています。

Java EE と Spring

Spring Framework は Java EE の競合相手とみなされます。これら 2 つのプラットフォームの開発を見てみると、興味深いことが見えてきます。Java EE の最初のバージョンは、IBM の参加のもとに作成されました。それらはクールではありましたが、不器用で重く、使用するのが不便でした。開発者は、多数の構成ファイルを維持する必要があることや、開発を複雑にするその他の理由により、苦労していました。同時に Spring IoC も誕生しました。小さくて綺麗で使いやすい図書館でした。構成ファイルも使用しましたが、Java EE とは異なり、構成ファイルは 1 つだけでした。Spring のシンプルさにより、ほぼ全員がプロジェクトでこのフレームワークを使用し始めました。そして Spring と Java EE は同じことへの道を開始しましたが、異なる終点からでした。Spring の開発者である Pivotal Software は、Java 開発者のあらゆる可能性と不可能性をカバーするために、次から次へとプロジェクトをリリースし始めました。徐々に、以前 Spring と呼ばれていたものが最初はプロジェクトの 1 つになり、その後 Spring Core の他のいくつかのプロジェクトと完全に統合されました。これらすべてが、元の状態と比較して Spring の必然的な複雑化につながりました。時間が経つにつれて、複雑な Spring 依存関係全体を追跡することが非常に困難になり、すべてをロードして実行する別のライブラリが必要になりました (現在、愛されている Spring Boot はどこかで問題が発生しています)。 これまでずっと、JCP は 1 つのことに取り組んできました。それは、Java EE 内で可能なすべてのことを最大限に簡素化することです。その結果、最新の EJB では、Bean を記述するには、クラスの上にアノテーションを 1 つ指定するだけで十分です。これにより、開発者は Enterprise Java Beans テクノロジの全機能にアクセスできるようになります。また、同様の簡素化は Java EE 内のあらゆる仕様に影響を与えています。結果として、Spring と Java EE は機能の点でほぼ同等です。良いところもあれば悪いところもありますが、世界的に見ると大きな違いはありません。仕事の複雑さについても同様です。Spring と Java EE はどちらも優れたツールです。Java でエンタープライズ ネットワーク アプリケーションを構築するには、おそらく現時点で最高のものでしょう。ただし、Java EE は通常、エンタープライズ アプリケーション サーバー内でのみ動作し (Tomcat は 1 つではありません)、Spring スタック上のアプリケーションは (同じ Tomcat 上の) どこでも実行でき、サーバーがまったくなくても (実行されるため)、それ自体内で独立して）。このため、Spring は小規模なフロントエンド GUI アプリケーションやマイクロサービス アーキテクチャを開発するための理想的なツールになります。しかし、アプリケーション サーバーへの依存を排除​​すると、Spring アプリケーションのスケーラビリティに悪影響が生じました。また、Java EE は、スケーラブルなモノリシック クラスター アプリケーションの実装に適しています。Spring Framework に精通した開発者は現在、労働市場での需要が高まっています。これが歴史的に起こった経緯です。Java EE が過度に複雑だった時代に、Spring は「顧客ベースを獲得」しました。それでも、Spring と Java EE の何を学ぶべきかという質問に対する明確な答えはありません。初心者には次のようなアドバイスが与えられます。両方のプラットフォームについて (少なくとも表面的には) 理解してください。Java EE と Spring の両方で小さなホーム プロジェクトを作成します。そして、仕事で必要となるフレームワークをさらに深く掘り下げます。その結果、Spring と Java EE 間の切り替えは難しくなくなります。

結果

もちろん、大規模なトピックを 1 つの記事でカバーすることはできません。たくさんの新しい用語を理解した後は、おそらくこの知識を実際の例に「適用」したくなるでしょう。したがって、引き続き Java EE について学習していきます。次の記事では、Java EE 開発用のローカル環境のセットアップに関する実践的なレッスンを紹介します。