EAR (ファイル形式)

EAR ( Enterprise Application Archive ) は、Jakarta EE が 1 つ以上のモジュールを単一のアーカイブにパッケージ化するために使用するファイル形式です。これにより、さまざまなモジュールをアプリケーション サーバーに同時に一貫してデプロイできるようになります。また、モジュールのデプロイ方法を記述する デプロイメント記述子と呼ばれるXMLファイルも含まれています。

EAR ファイルを構築するには、 Ant、Maven、またはGradle を使用できます。

EAR ファイルは、.ear 拡張子を持つ標準のJAR ファイル(つまりZipファイル) であり、アプリケーションのモジュールを表す 1 つ以上のエントリと、META-INF1 つ以上のデプロイメント記述子を含む と呼ばれるメタデータ ディレクトリを持ちます。

• メタ情報/
  • application.xml:これは EAR のメインのデプロイメント記述子です。EAR に含まれるすべてのモジュールをリストし、構成設定を指定します。
  • MANIFEST.MF:アーカイブに関するメタデータを提供するマニフェスト ファイル。
• JAR ファイル:
  • META-INFこれらのファイルには、Enterprise JavaBeans (EJB) モジュールまたはユーティリティ クラスが含まれています。各 JAR ファイルには、通常、 JAR モジュールに固有のデプロイメント記述子を含む独自のディレクトリがあります。
• WAR ファイル:
  • これらのファイルには、サーブレット、JSP ファイル、HTML ファイル、その他の Web リソースなどの Web モジュールが含まれています。各 WAR ファイルは通常、次の構造になっています。
    • WEB-INF/
      • web.xml:Web モジュールのデプロイメント記述子。
      • classes/: コンパイルされた Java クラスが含まれます。
      • lib/: Web モジュールで使用されるライブラリ JAR ファイルが含まれます。
• RAR ファイル:
  • これらのファイルには、通常、エンタープライズ情報システム（EIS）への接続に使用されるリソースアダプタが含まれています。[1]

開発者は、アプリケーション サーバーによるデプロイメントのために、EAR ファイル内にさまざまな成果物を埋め込むことができます。

• Web モジュールの拡張子は.warです。これは、1 つ以上の Web コンポーネント、その他のリソース、およびWeb アプリケーション デプロイメント記述子で構成されるデプロイ可能なユニットです。Web モジュールは、標準の Web アプリケーション形式のディレクトリとファイルの階層に含まれています。
• POJO Java クラスは.jarファイルにデプロイできます。
• Enterprise Java Beanモジュールには.jar拡張子があり、META-INFデプロイされた永続クラスを記述する独自のディレクトリ記述子が含まれています。デプロイされたエンティティ Bean は他のコンポーネントから参照可能になり、リモートでエクスポートされた場合はリモート クライアントからも参照可能になります。メッセージ Beanとセッション Bean はリモート アクセスに使用できます。
• リソースアダプタモジュールには.rar拡張子が付きます。

ほとんどのアプリケーション サーバーは、デプロイされた EAR ファイルから Javaクラスローダーの独立したツリーとしてクラスをロードし、アプリケーションを他のアプリケーションから分離しますが、デプロイされたモジュール間でクラスを共有します。たとえば、デプロイされた WAR ファイルは、それを含む EAR ファイルにも含まれている JAR ファイルで定義されたクラスのインスタンスを作成できますが、他の EAR ファイル内の JAR ファイル内のクラスのインスタンスは必ずしも作成できません。この動作の主な理由の 1 つは、静的シングルトン (Log4J など) を使用するアプリケーションを完全に分離できるようにすることです。そうしないと、個別のアプリケーション間の構成が混乱します。これにより、異なるバージョンのアプリケーションとライブラリを並べてデプロイすることもできます。

バージョン 5 より前のJBossアプリケーションサーバーは、デプロイされたコンポーネントを分離しないという点で注目に値します。1 つの EAR ファイルにデプロイされた Web アプリケーションは、他の EAR および WAR ファイルのクラスにアクセスできます。これは、多少議論のあるポリシーです。Unified Classloader設計では、クラス データを参照または単純なコピーで共有できるため、実行中のアプリケーション間の通信オーバーヘッドが軽減されます。また、開発者はクラスローダーのツリーによって発生する可能性のある問題を理解する必要がありません。ただし、依存ライブラリの異なるバージョンが別々のアプリケーションにデプロイされるのを防ぎます。JBoss 4.0.2 では階層型クラスローダーに切り替えられましたが、バージョン 4.0.3 では下位互換性のために Unified Classloader に戻りました。この動作を変更する構成オプションが現在あります。JBoss 5.x、6.x、および 7.x では、Unified Classloading は使用されなくなりました。

ディレクトリMETA-INFには、少なくともJava EE デプロイメント記述子application.xmlと呼ばれるデプロイメント記述子が含まれています。次の XML エンティティが含まれています。

• iconは、アプリケーションを表すイメージの場所を指定します。small-iconおよび に対して細分化が行われますlarge-icon。
• display-nameアプリケーションを識別する
• description
• moduleアーカイブ内の各モジュールの要素
• security-roleアプリケーション内のグローバル セキュリティ ロールの0 個以上の要素

各module要素には、アプリケーション内の個々のモジュールを説明するejb、webまたは要素が含まれています。Web モジュールは、 URL によって Web モジュールを識別する も提供します。 javacontext-root

Jakarta EE デプロイメント記述子の次には、0 個以上のランタイム デプロイメント記述子が存在する場合があります。これらは、実装固有の Jakarta EE パラメータを構成するために使用されます。

• エンタープライズソフトウェア
• WAR (ファイル形式)
• JAR (ファイル形式)
• JAR地獄
• デプロイメント記述子

• アプリケーションのパッケージ化 - Java EE 7 チュートリアル