Java EE 8：新機能の簡潔で非常に楽観的な概要

写真：SabineHürdler/ Fotolia.com



こんにちは、Habr！



むかしむかし、2013年の蒸し暑い夏に、あなたとあなたは、アンソニーゴンカルベスによる素晴らしい本「 Learning Java EE 7 」に取り組み始めるよう説得しました。 現在、年末までに有能で魅力的なスペシャリスト、 セバスチャン・ダシュナーによるJava EE 8に関する本の作業を真剣に計画しています。







11月7日に、Dashner氏はJava EE 8の展望と利点について自分の考えを掲載した記事を公開しました。



大企業向けのプロジェクトを開発するとき、何に集中すべきですか？ Java EEプラットフォームの「軽さ」とは何ですか？ Java EEはビジネス概念と主題指向の設計をどのようにサポートしますか？ このプラットフォームはどのように進化しましたか？ どの方向に発展し続けますか？ この記事では、コンテナ環境でのJavaの新機能と統合の概要を説明します。



開発：エンタープライズプロジェクトに焦点を当てる



エンタープライズプログラムの重要なコンポーネント-これらは、資金の転換をもたらす機能です。 付加価値は、ケースの実装中に取得されますが、ビジネスロジックの提供は、技術的な実装がどのように完了するか、またはどのテクノロジーがこのために選択されるかによって異なります。 したがって、エンタープライズプロジェクトは、主に実用的なシナリオの実装で強化する必要があります。



開発者はしばしばこの状況を異なって見ます。 彼は実装の詳細、品質、および技術的ソリューションの美しさに興味があります。 プログラムは設計され、同僚と議論され、コードが処理および構造化されます。 はい、これらはすべてソフトウェア開発の重要な側面です。いずれにせよ、私たちは主に顧客の要件を満たすことに関心があり、その場合のみコードの完成に時間と労力を費やす必要があります。



エンタープライズエンジニアがこれらの問題を顧客の観点から（お金を出して）、予算のあるプロジェクトマネージャーの観点から見ると、多くのことが明らかになります。



Java Enterprise-最初のビジネスロジック！



そのため、ビジネスロジック（ドメインロジック）の実装に特別な注意を払っています。 ロジックの準備が整った場合にのみ、より狭い技術的な問題が発生します。 Java Enterpriseはこのアプローチを好みます。 サブジェクト領域-その本質-は、最初にPure Javaで実装されます。 私たちは企業部門で働いているため、通信やデータ保持などのエンドツーエンドの機能は非常に重要です。 現代のJava EEでは、それらは宣言的に完全に実装され、実質的に最小限のオーバーヘッドです。 基本的に、Java EEプラットフォームでは、「構成規則」の原則が定められており、このプログラミング手法をサポートしています。



Java仕様は、いくつかの注釈とともにビジネスロジック（純粋なJavaクラス）に追加されます。 次に、単体テストを使用してビジネスロジックを簡単に検証します。 ほとんどすべての機能は最新のJava EEのアノテーションで宣言されているため、クラスはテストで直接インスタンス化できます-エンタープライズコンテナなしでも可能です。



Java EEおよびサブジェクト指向設計（DDD）



特定のケースのエントリポイント、いわゆるファサードを、注釈付きのJavaクラスとして実装します。 サブジェクト指向設計の用語では、このようなクラスは特定のサービスを表すと言われています。 次の例は、EJBとして実装されたサービスを示しています。

@Stateless public class CarManufacturer { @Inject CarFactory carFactory; @PersistenceContext EntityManager entityManager; public Car manufactureCar(Specification spec) { Car car = carFactory.createCar(spec); entityManager.persist(car); return car; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

CarFactory



クラスは、既存の仕様に従って新しいCar



エンティティを作成します。 EntityManagerは、データベース内のこれらのエンティティの永続性を制御します。

したがって、主題指向のデザインでは「リポジトリ」パターンとして知られる概念が提示されます。 EntityManagerタイプは、完全に明確なAPIを提供します。 J2EEの世界で使用されているDAO（データアクセスオブジェクト）とも呼ばれる追加のファサードは不要になりました。



プログラムレベルでビジネスプロセスを提示する場合、 CarManufacturer



、この場合のCarManufacturer



ようなファサードの形で直接実装する必要があります。 メソッドとプロセスが過度に複雑になると、機能はデリゲートのレベルになります（この場合はCarFactory



など）。 単体テストは正しい動作を提供します-これらのテストでは、ファサードがインスタンス化され、デリゲートがそれぞれモックオブジェクトとして模倣されます。



同時にCar



などのドメインクラスはPOJO（「プレーンな古いJavaオブジェクト」）であり、永続性などの技術的に実行可能な機能を示すアノテーションを提供できます。

 @Entity @Table(name = "cars") public class Car { @Id @GeneratedValue private long id; @OneToOne(optional = false, cascade = CascadeType.ALL) private Engine engine; @OneToMany(cascade = CascadeType.ALL) private Set<Seat> seats = new HashSet<>(); //    }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

サブジェクト指向の設計では、 エンティティはサブジェクト領域に関連する特定のオブジェクトとして理解されます。 これらは、アプリケーションの「ルート」オブジェクトです。 JPAは、追加のコストをほとんどかけずに永続性へのマッピングエンティティを提供します。これは、アノテーションを使用して行われます。 @Entity



アノテーションの@Entity



も、DDDの世界に調和して適合します。 JPAでは、 @Entity



を識別できる必要があります。



JPAは、集約と呼ばれる概念もサポートしています。 したがって、例を続けると、車にはいくつかの座席があります。 サブジェクトエリアでは、各座席を識別できます。 ルートCarオブジェクトから関連するすべてのSeatインスタンスに操作カスケードを保存します。 したがって、すべての構成要素を含む使用可能な識別子を使用して、データベースからマシン全体を照会できます。

メソッドまたはクラスで比較的複雑なオブジェクトの作成をカプセル化するDDDファクトリーは、メソッドがドメインエンティティの一部である純粋なJavaで、またはCDIを使用して、Java EEの世界で実装されます。 CDIについては、プロデューサーメソッドについて特に言及する必要があります-非常にコンパクトで便利です。 次の例では、最初にエンティティ「automobile」の一部であるファクトリを示します。

 public class Car { ... public LogBook createDriverLog() { //   logbook } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

本質的にパッキングファクトリは、特定のオブジェクトを作成するために、対応するエンティティに多数のプロパティが必要な場合に主に推奨されます。 次の例は、CDIを使用してCarFactory



派生物を作成するCarFactory



を示しています。

 public class CarFactoryProducer { @Produces public CarFactory exposeCarFactory() { CarFactory factory = new BMWCarFactory(); //    return factory; } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

最初の例のように、 CarFactory



タイプを使用してCarFactory



インスタンスを実装できます。



これらの例は、現代のJava EEで技術的なオーバーヘッドを大幅に減らすことなく、軽量開発アプローチがどのように実践されるかを示しています。 主な焦点はビジネスロジックであり、特別なオーバーヘッドなしでエンタープライズアプリケーションの技術要件に適合します。



Java EEでの通信：JAX-RS、JMS、WebSocket、およびJSON



JAX-RS、JMS、またはWebSocketを使用したサーバーエンドポイントは、シン宣言型APIが開発者の生活を楽にする方法を示す他の例です。 ほとんどのアプリケーションの状況では、Java EEの「構成合意」の原則で十分です。 その他の場合、動作はプログラムで拡張できます。



JSON-Bを使用したJSONバインディングは、Java EE 8で導入された別の新機能です。XMLのJAXBと同様に、JSON-BはJavaクラスからJSONへの宣言型マッピングを可能にします。 Java EE 8では、JSON-BはJAX-RSとシームレスに統合されます。 JAX-RSランタイムは、参照タイプのJSONマッピングをJSON-Bに委任します。 したがって、JAX-RSリソースで使用されるこれらのタイプのクラスは、注釈を定義できます。 追加の構成オーバーヘッドなしで、これらの注釈はHTTP要求および応答で考慮されます。 次の例は、JSON-Bを使用してシリアル化可能なUser



クラスを示していUser



。

 public class User { @JsonbTransient private long id; @JsonbProperty("username") private String name; ... }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

このアプリケーションの場合、HTTPエンドポイントを表すJAX-RSリソースは、リクエストまたはレスポンスの本文を"User"



ます。

 @Path("users") @Produces(MediaType.APPLICATION_JSON) public class UsersResource { @Inject UserStore userStore; @GET public List<User> getUsers() { return userStore.getUsers(); } }
      
      

        
        
        
      

    
        
        
        
      
      

        
        
        
      

    
     

JSON-Bシリアル化はすべてを自動的に取得します。HTTP経由で送信されるユーザーのリストのJSONオブジェクトには、 username



プロパティが含まれ、 id



はありません。



宣言的なアプローチとJava EE APIとの相互作用は、エンタープライズ開発に特に適しています。この分野では、最も重要なものにのみ焦点を当てる必要があるためです。



Java EEおよびゼロ依存アプリケーション：DockerおよびKubernetesとの連携



プログラマが可能な限り生産的に作業する必要があるという事実は、ビルドおよびデプロイメントモデルレベルにも反映されます。 Java EEアプリケーションでは、アプリケーションは伝統的に実装から分離されています。 クラスはAPIのみをインポートします-実装はエンタープライズコンテナーを提供します。 このアプローチにより、アセンブリ、配信、展開の時間が最小限に抑えられます。 連続配信パイプラインのすべての段階で、アプリケーションコンテンツのみがコンパイル、アセンブル、配信されますが、フレームワークの実装はそうではありません。 後者は実行時にすでに発生しています。



これが、Java EEがコンテナーとオーケストレーションの世界で、つまりDockerおよびKubernetesとの組み合わせで最も利益をもたらす理由です。 書き込みのためにファイルシステムでコピーが使用され、個別のキャッシュが個々のコンテナイメージのレベルで動作する場合、インフラストラクチャは最も必要な操作のみを実行します。 各反復で、アプリケーションのコンパイルされたクラスのみが配信されますが、技術的な部分は配信されません。 このアプローチは、WARアーカイブにパッケージ化されたいわゆる「ゼロ依存アプリケーション」によって提供されます。 さらに、アプリケーションには、 provided



れたスコープの依存関係のみが含まれます。



次の例は、GlassFish 5ベースイメージとJava EEアプリケーションを含むDockerファイルを示しています。 潜在的なアプリケーションの依存関係は、デプロイされたバージョンには配信されませんが、Dockerファイルの初期段階でのみ表示されます。



FROM oracle/glassfish:5.0



# provided-

COPY ...jar $GLASSFISH_HOME/glassfish/domains/domain1/lib/ext/



COPY target/cars.war $GLASSFISH_HOME/glassfish/domains/domain1/autodeploy







起動時に生成されるDockerイメージは、アプリケーションを自動的に実行します。

依存関係ゼロのアプリケーションとDockerファイルのこれらの要素のおかげで、「コピーオンライト」の概念が実装され、継続的な配信パイプライン全体が大幅に加速されます。 ランタイム環境も、複数のアセンブリ間に存在する依存関係も変更されない場合（通常これが発生します）、 cars.war



アーカイブ内のアプリケーションのクラスのみがパックされて送信されます。



通常、エンタープライズプロジェクトでは、アプリケーションサーバーに関連する複雑さ、バージョン、および構成を少なくとも部分的に処理する必要がありました。 サーバーには多くのアプリケーションがあり、展開、構成、および新規インストール操作を複雑にし、場合によっては調整も必要になります。 この問題は、Dockerなどのコンテナーを使用して解決されます。 コンテナーには、ランタイム環境や構成など、アプリケーションの実行と構成に必要なものがすべて含まれているため、テクノロジーの選択は他のアプリケーションに依存しません。 たとえば、Java EE 7からJava EE 8への切り替えなどのアップグレードは、それほど面倒で危険ではありません。 したがって、デプロイされたバージョンでは、スタック全体とメガバイト単位の依存関係を提供する必要はありません。これらはすべて、対応するベースイメージの一部です。



Java EE 8以降



そのため、Java EE 8には新しい機能がありますが、その中で最も注目すべきは、JSON-Bの新しい標準です。 以前は、JSONなどのJSONを表示するためのフレームワークは、サードパーティの依存関係、特に推移的な依存関係とアプリケーションサーバーライブラリ間のバージョンの競合を解決する役割を担っていました。 競合の解決にはリソースと時間がかかりました。 Java EE 8は、これらすべての追加コストなしで実行できます。



JSON-Bに加えて、セキュリティを提供する別の新しい標準であるセキュリティAPIが導入され、CDI、JSON-P、Bean Validation、JPA、Servlet、JSFなどの古いAPIが更新されました。 さらに、サーバー送信イベント、JAX-RSのリアクティブクライアント、新しいJSON-P 1.1機能などの革新に特に注目しています。 Bean Validation 2.0、およびさまざまな標準の統合における多数の改善。 Java EE APIがここ数か月および数年で進化した方向は、開発者の観点から非常に楽観的であり、Java EEプラットフォームのEclipse Foundationへの移行後（Eclipse Enterprise for Java（EE4J）に準拠）、Java EEのさらなる開発はよりオープンになりますモードとおそらくスピードアップ。



まとめ



最新のJava EEにより、プログラマーはアプリケーションの最も重要な側面に集中し、技術コストを最小化できます。 展開可能なバージョンが可能な限りコンパクトになったため、Java EEはDocker、Kubernetes、OpenShiftなどのコンテナ環境と最適に統合されるようになりました。