効率的な開発プロセスの推奨事項を確認してください
昔、J2EEは、具体的には、アプリケーション・サーバは、あまりにも肥大化して考えられている「ヘビー級」。開発者は、アプリケーションを開発するために、この技術の使用は非常に退屈でイライラすることができます。しかし、J2EEフレームワークの名前は、Java EEに変更されていないので、仮定はもはや適用されます。Java EEのは、企業のどのようなフレームワークと他とのフレームワークとの間の差に比べて軽量、標準とは何ですか？
技術の選択では、考慮すべき最も重要な側面の一つは、開発プロセスにおける開発者の生産性です。それが目標に向かって、会社が許可されますので、エンジニアは、達成するために患者と収益創出能力と同じくらいの時間を費やす必要があります。
技術および方法は、時間の開発者を最小限にするように選択する必要があります。具体的にどのような時には、：;設定のアプリケーションを、ビジネスユースを無関係な導管の実施形態で;、テストの構築と展開待って構築し、環境と外部依存関係を設定します。しかし、利用可能な技術のほとんどは行っていません。
1.なぜ規格？
他のフレームワークと比較して、Java EEの最大の利点の一つは、標準化されたAPIを使用することです。基準は十分に非常に退屈していない技術革新を聞こえるかもしれない - Javaの仕様要求（JSR）は、過去の結果は、業界でよく証明されているされているので、本質的に、これは、本当です。しかし、これらの基準の使用は、いくつかの利点があります。
2.統合ガイドライン
Java EEの特定のAPIは-そのようなコンテキストと依存性注入（CDI）のように、JAX-RS、 JSONの処理（JSR 353）、および検証豆-うまく一緒に動作することができ、そしてシームレスに互いに組み合わせることができます。最も重要なのは、CDIは、アプリケーションコンポーネント間の「接着剤」として使用されています。仕様は以下のような情報が含まれている「容器支持仕様AとB場合は、AとBがシームレスに統合しなければならないとうまく動作します。」
例えば、JAX-RSは、例えば、JSONP形式をサポートしてJsonObject呼び出しBeanのチェック機能をサポートしているリクエストやレスポンスエンティティとして-検証が失敗した場合、正しいHTTPステータスコードを含む（リスト1を参照します）。
@Path("duke")
public class DukeResource {
@GET
public JsonObject getDuke() {
return Json.createObjectBuilder().add("name", "Duke").build();
}
@POST
public void create(@Valid @NotPlayedYet Game game) {
// game object has been validated at this point
}
}リスト1. JAX-RSとJSONPのビーン検証統合
使用JSONPのコンテンツタイプは、タイプがあることを意味application / jsonし、検証が失敗した場合は、HTTPステータスコードを送信します400 Bad Request。すべてが完全に行うことができます任意のコードを記述することなく、この構成。
別の例は、によってCDIに開発を可能にすることである@Injectコンポーネントオブジェクトとユーザ定義の管理注入するJava EEビーン。豆の検証理解するために、リスト2を参照してくださいValidator直接他のCDI管理対象Beanを使用し、。
public class GameNotPlayedValidator implements ConstraintValidator<NotPlayedYet, Game> {
@Inject
GameHistory history;
public void initialize(NotPlayedYet constraint) {
// no initialization needed
}
public boolean isValid(Game game, ConstraintValidatorContext context) {
return !history.exists(game);
}
}CDI統合のリスト2.豆の検証
統合は、開発者が直接経験を提供することができ、仕様の主要な特徴です。開発者は、アプリケーションサーバの統合や構成に依存することができますので、あなたは、アプリケーションのビジネスロジックに集中することができます。
3.設定駆動開発オーバー大会
Java EEの構成規則駆動方式なので、最も実用的なアプリケーションでは、大規模な設定は必要ありません。面倒なXML記述子の時代は終わりました。単純なJava EEアプリケーションでは、あなたは、単一のXMLファイルは必要ありません。
宣言型注釈、昔ながらのJavaオブジェクト（POJO）簡単な注釈付きハンドルHTTPリクエスト（ため@Path）、または別々のJavaBeansエンタープライズ（EJB）豆（など@ Statelessを含む取引、監視またはインターセプター- ）。過去には、これらの方法はよく様々なフレームワークで文書化されており、およびJava EEで標準化されています。
必要であれば、XMLディスクリプタはまだ時に配備構成で使用することができますが、設定より規約は、開発者の効率を最大化するのに役立ちます。
4.外部依存関係
いくつかの実用的なビジネスプロジェクトは、ワークの展開にどのような状況下でも、追加の依存関係を動作しませんでした。しかし、これらの理由から、主に技術を駆使した依存関係 - エンティティマッピングフレームなどのApache CommonsのかGoogleグァバライブラリー例えば、含む、またはロギングを使用 - というよりも、例。
Java EEの7 - 特にJavaの8と組み合わせて使用 - 他の依存関係なしに、ほとんどのユースケースをカバーするのに十分な機能を備えています。箱から出した内容のほとんどは、インターセプタブレーカ（アダム・ビエンオープンソースのライブラリを参照）を介して、または複雑なコレクション操作によって、例えば、射出CDIプロバイダによって設定することができ、実装するために最小限のコードを使用することができますJavaの8ラムダ式とストリーム。
もちろん、あなたはここで車輪の再発明をしないと主張することができます。しかし、実際には、展開ワークに含まれて依存関係の外部メガバイトから書かれた数行のコードを保存するために、あまり意味がありません。
経験は、最大の問題は、の導入に直接依存していないことを示したが、依存し過ぎています。アプリケーションサーバーに依存して、既存のライブラリバージョンの競合が頻繁に渡され、紛争に挑戦につながるされています。一日の勤務時間中に、開発者ではなく、プロジェクトへの小さな機能を実装するために必要な時間に焦点を当てるよりも、これらの競合を管理するより多くの時間を過ごしたいです。これは主に依存関係によって駆動される技術の実施形態の駆動装置を有していない場合に適用されます。
単純なJava EE 7プロジェクトMavenのプロジェクトオブジェクトモデル（POM）に促さ関連ドキュメント、リスト3を参照、アダム・ビエンに触発された文書のJava EE 7 Essentialsの原型。
<project xmlns="http://maven.apache.org/POM/4.0.0"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xsi:schemaLocation="http://maven.apache.org/POM/4.0.0 http://maven.apache.org/xsd/maven-4.0.0.xsd">
<modelVersion>4.0.0</modelVersion>
<groupId>com.sebastian-daschner</groupId>
<artifactId>game-of-duke</artifactId>
<version>1.0-SNAPSHOT</version>
<packaging>war</packaging>
<dependencies>
<dependency>
<groupId>javax</groupId>
<artifactId>javaee-api</artifactId>
<version>7.0</version>
<scope>provided</scope>
</dependency>
</dependencies>
<build>
<finalName>game-of-duke</finalName>
</build>
<properties>
<maven.compiler.source>1.8</maven.compiler.source>
<maven.compiler.target>1.8</maven.compiler.target>
<failOnMissingWebXml>false</failOnMissingWebXml>
<project.build.sourceEncoding>UTF-8</project.build.sourceEncoding>
</properties>
</project>3. JavaのEE 7のMaven POMファイルをリスト
もちろん、時には図書館の目標が不可欠である達成するためのアプリケーション統合ソフトウェアが必要です。しかし、これらの依存関係は、ビジネス・ニーズによって証明するために必要。一般的に、それは理にかなって、外部ライブラリの生成を最小限にするために時間と労力を節約できます。
不可欠である - などいくつかのケースでのJUnit、Mockitoまたは、Arquillianとしてライブラリは、ので、テストの依存関係のために、それは、別の話です。しかし、再び、依存関係のテストリストにフォーカスも重要です。
5.シンプロビジョニングアーティファクト
アプリケーションサーバは、Java EEのAPIを知っているので、そのAPIは、デプロイメント成果物に含まれている必要はありません。ビジネスロジックが含まれているのみ - 最小限のグルーコードとクロス懸念に。
ビルドプロセスは多くのものを複製する必要があるため、したがって、ワークのキロバイト単位のサイズは、非常に短い時間を構築することができます。これは、各数秒の差がで構築することができます。概要開発と継続的インテグレーション（CI）サーバーに要するすべての余分な時間ならば、それは大きな違いを生むだろう。大きな影響 - 連続送達（CD）シナリオに特に当てはまる - プロジェクトの頻度が高いです。
短い建物の時間に加えて、小規模な展開アーティファクトも短いリリースと展開の時間を確保します。達成しているので、すべての場合には、部品を移動に費やした時間が最小になるように、既に、実行時に含まれています。
理想的なフレームワーク6.Docker
これは、ドッカーコンテナこのような技術のJava EEの原因のための完全なフレームワークです。ドッカーミラー層ベース、画像を構築し、基本的なイメージは、すでにオペレーティングシステム、Javaランタイムとアプリケーションが含まれています。したがって、各ユニークなコンテンツが展開されている最後の構築物は薄いワークをキロバイト単位で添加しました。唯一のそれぞれの上に構築していない、とイメージのバージョンまたはリリース - 脂肪WARまたはJAR独立した方法で、時間とストレージを節約するとの比較。
合理化された展開の成果物とどのような段階では関係ありませんが、非常に高速かつ効率的な展開パイプラインを実現することができます。
7.現代のアプリケーションサーバー
J2EEアプリケーション・サーバー・ソフトウェアが起動し、展開時間のヘビー級で、資源は、設置スペースの面積の大きさを反映しています。しかし、もはや適用されたJava EEの新しい世界インチ
（このようWildFly、ペーシュ・カショーロは、WebSphereリバティ、プロフィールやTomEEなど）すべての現代のJava EE 7のアプリケーション・サーバーは数秒で起動し、展開することができます。内部に完全にモジュラーに、彼らはできるだけ早くアプリケーション成果物を合理化するために必要なコンポーネントをロードし、展開することができます。
今すぐインストール寸法とフットプリントは非常に合理的です。アプリケーションサーバは、単純なサーブレット・コンテナのものよりも多くを消費しませんが、それは完全なJava EEの機能を持っています。興味深いことに、今のブラウザインスタンスは、より多くのメモリを消費し実行します。
各サーバーにのみ可能である一つのアプリケーションを配備する、と述べた、また正当化することができる - コンテナ内または内部のいずれかで。アプローチ「各アプリケーションサーバー1アプリケーションのための各コンテナ」により、あなたは現代のマイクロサービスアーキテクチャのための効率的で柔軟なソリューションを提供することができます。
8.包装
包装工程では、我々は、EARファイルを継続して使用するべきではありません。アプリケーション全体は、それが構築および展開するためのより多くの時間を節約することができそう、その環境内のすべてのコンポーネントのメソッドへのアクセス権を持っているために私たちを必要とし、個別の専用サーバに配備されています。また、それはまた、クラスロード階層が問題のEARファイルを引き起こす傾向が回避されます。
ほとんどのクラウドサービスとマイクロ展開では、別々のJARパッケージを使用します。彼らは、アプリケーションと業務が含まれていたときに実現します。当技術分野でJava EEは、この方法は、例えばWildFly群発、ペーシュ・カショーロマイクロまたはTomEE組み込み、チェーンを達成するために、ベンダー固有のツールを使用することができます。
しかし、上記の理由により、私は強く、ビジネスロジックが、可能な限り実行されます分離することをお勧めします。これは、アプリケーションがアプリケーションのみのコードが含まれているWARファイルにパッケージされていることを意味します。
私の意見では、同社の場合によるインストールや操作プロセスの制御を超え、「政治的」というよりも技術的な理由に、独立したJARファイルには、便利なソリューションです。私たちは、非技術的な問題のかなりの数を解決して、あなたがワークを展開するために必要なすべてを輸送し、唯一のJREを必要とすることができます。
効率的な開発プロセス9.勧告
次のように最も効果的なエンタープライズプロジェクトのソリューションの一つは次のとおりです。
- APIのJava EE 7およびJava 8を提供する場合にのみを使用
- キロバイトは、WARファイルのサイズを構築し、最低限のパイプのビジネスロジックが含まれている（例えば、JAX-RSリソースまたはJPA）
- ドッカーイメージの構築 - 唯一のベースイメージの設定が含まれているアプリケーションサーバーにWARファイルを追加します
- アプリケーションのCDパイプを展開するために容器の使用を介して送信
10.おわりに
「ヘビー級のJava EEは、」確かに一日の終わりです。APIのJava EEは、効率的で楽しい経験、および標準開発中のシームレスな統合を提供する含まれていました。特に、高速、効率的な開発プロセスのための分離されたアプリケーション・コードおよび操作方法。
新しいマルチベンダー主催のMicroProfileの計画では、将来的には、さらにJavaのEEの必要なコンポーネントを減らすことができます。
参考資料
オリジナルます。https：//community.oracle.com/docs/DOC-1008823
著者：セバスチャンDaschner
翻訳：[KeepGoingPawn]（https://blog.csdn.net/hengji666
9月福祉、社会的関心番号返信舞台裏：004は、8月のハイライトで翻訳を受ける！再福祉に行く：001、002、003を受け取ることができます！
