Go to Qiita Advent Calendar 2024 Top
LoginSignup
7
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?

More than 3 years have passed since last update.

@watsboon

JJUGナイトセミナー　メモ２（JakartaEE・MicroProfile）

Last updated at Posted at 2020-02-02

#はじめに
2020年1月22日にJJUGナイトセミナー「Jakarta EE特集」を聴講したので、その内容をまとめてみた。

イベント紹介ページ
https://jjug.doorkeeper.jp/events/102611

前回は前半パートを書いたので、
今回は後半パートをまとめた。

話の中で登場した用語の意味や説明しているサイトは備忘として、最下部にまとめている。

#Jakarta EE + Microprofile との付き合い方
セッションの概要はイベントページより抜粋

概要 エンタープライズ系システム開発の主流であったJava EEが、Oracleの手を離れEclipse Foundationに移り、名称もJakarta EEに変わりました。一方、Web系/Cloud系ライトウェイト開発の潮流を受けてMicroprofileという新しい規格も登場しています。国内ではこのJakarta EEとMicroprofileとの関係について、ベンダーの立場から離れて客観的に語られることが少ないため、非常に分かりづらい状況が続いている印象です。本セッションでは、J2EE以前からの歴史を振り返りつつ、Oracle Code One 2019での最新情報を織り交ぜながら、これら新仕様が今後どう進んでいくのか、どのように付き合えばいいのか、その流れに対してどのように戦略を立てる方法があるのかを詳解します。

##1.エンタープライズシステムとJakartaEE,MicroProfileの歴史
まずそれぞれの生まれた歴史について、振り返る。
###1-1.エンタープライズ系の歴史

###1-2.JavaEEの歴史
JavaEEの歴史とMicroProfileの誕生経緯についての振り返り。

  • 1999年：J2EE 1.2をサン・マイクロシステムズが開発しリリース
  • 2001年：J2EE 1.3をリリース
  • 2003年：J2EE 1.4をリリース
  • 2006年：JavaEE 5をリリース
  • 2009年：JavaEE 6をリリース
  • 2010年：オラクルがサン・マイクロシステムズを買収
  • 2013年：JavaEE 7をリリース　
  • 2016年：MicroProfileが誕生し、JavaEEと分岐
  • 2017年：JavaEE 8をリリース
    • 同年、JavaEEをEclipse Foundationに寄贈しオープンソース化する
  • 2019年：JakartaEE 8をリリース

####1-2-1.そもそもMicroProfileとは
こちらの記事にまとめられてる
Eclipse MicroProfile まとめ (1.3対応版)

JavaEE 8とは別な仕様を作ってリリースしている。
MicroProfileに含まれる仕様は以下を参照
https://wiki.eclipse.org/MicroProfile/Implementation

####1-2-2.MicroProfileが生まれたが故に発生した問題
JavaEE 8に入れるはずだったSPECがMicroProfileに先に取り込まれたため、
JavaEE 8に入らなかった。
その結果、JavaEE 7からJavaEE 8でメジャーアップデートが行われなかった。

それにより現在ではJakartaEEとMicroProfileが別な仕様で２種類並存することになった

##2.JakartaEE（JavaEE）とMicroProfileの違い
###2-1.JakartaEE（JavaEE）の特徴

  • Webからバックエンドまで全方位的に実装されている
    • Webフロントの仕様はASP.NETを模したようなJSFを導入
    • EJB(Enterprise JavaBeans)の仕様はWebLogicから導入
    • JMS(Java Message Service)の仕様はWebSphereMQなどから導入
    • Servletの仕様はApache JServから導入
    • etc・・・

　　など様々なところから寄せ集めながらもアプリ作成に必要な機能を満たすようにしている。

  • JavaEE 7からJakartaEE 8にかけてあまりバージョンアップしていない
    • これは前述の通り、MicroProfile側に仕様が盛り込まれたのが起因している
  • アプリケーションサーバーがJakartaEE 8に対応していないものもある
    • 有名どころのWebLogic、GlassFish、Liberty、WildFlyなどは対応している
    • 国産系の富士通のInterstage、NECのWebOTX、日立のCosminexusはまだ対応していない

　　ただし、対応はしていなくても、JavaEE 7からJakartaEE 8までほとんど変わっていないこと、
　　JDKは各社とも自社のJDKをサポートするよう提供していることから実害は出ていない模様。
　　（新しい機能が使えないといった問題はある）

　　JakartaEEのターゲットは長期運用するアプリケーションであるため、
　　アプリケーションサーバーは多少古くても問題ないとされてる模様。
　　そのため、JakartaEE 8に向けたバージョンアップはせず、次のJakartaEE 9に向けて
　　バージョンアップをする可能性がある。

###2-2.MicroProfileの特徴

  • JakartaEEと同じ機能も提供している
    • JAX-RS：アノテーションでHTTPリクエスト・レスポンスをJavaコードにマッピングする
    • CDI：インスタンスのスコープを管理する
    • JSON-B：JavaオブジェクトとJSONの相互変換を行う
    • JSON-P：データをクロスドメインから受け取る手法
    • Common Annotations：一般的な注釈（アノテーション）

　　基本的な小さなビジネスロジックを作るのであれば、JakartaEEと大差無い

  • JakartaEEにないオリジナルの仕様が存在する
    • Config
    • Metrics
    • Health
    • Fault Tolerance

　　オリジナル仕様はJavaEE 8に取り込まれなかったもので、あると便利といったレベルの機能。
　　各機能についてはまとめられてる方の記事を参考。
　　https://qiita.com/omix222/items/50804e30e43085ceb912

  • プロダクトはJakartaEEとはだいぶ異なる
    • Helidon(Oracle)
    • Quarkus(Redhat)
    • Thorntail

　　などがある。利用できるプロダクトはMicroPrfileのHP を参照。
　　なお、プロダクトの違いは後述。

####2-2-1.MicroProfileで致命的な特徴

  • JMS系の機能、Web表示系のフレームワークが無い
    • MicroProfileだけのアプリケーションを作るのは無理がある
    • バッチのアプリケーションであれば、MicroProfileだけで作ることは可能
  • DB接続系のAPIの標準が存在しない
    • CDIはサポートしているが、CMTのAPIがサポートされていない
    • そのため、生のJDBCを使い、ドライバマネージャとのコネクションやコミットを直接書く必要がある

####2-2-2.MicroProfileの特徴のまとめ

  • MicroProfileだけではアプリ作成できない
  • MicroProfile利用時は別のプロダクトのライブラリーフレームワークと組み合わせて使う必要がある
  • ただし、組み合わせたことで互換性に問題がある（ベンダーロックインの恐れあり　※原因は後述）
  • 利用する場合はベンダーロックインの危険性を考慮しておく必要がある

####2-2-3.MicroProfileのプロダクトの特徴
プロダクトごとにサポートしている機能が異なる

Helidon
Web表示系はNetty。
トランザクション処理はJPAが使える、ただし実装はOracle UCPやHikariCP。
CMTやJTAもサポートしている。
基本的なCDIとJTAで、CMTを使ったコンテナマネージメントトランザクションのアプリケーションは作成できる。
Quarkus
トランザクション処理はJPAが使え、実装はHibernate ORM。
CMTをサポートしている。
Webのフレームワークが無さそう（Quarkusの拡張機能で何かしら代用可能？）。
非同期処理系はApache Kafkaが導入されているが、Apache Kafka自体がJMS APIにまだ対応していない（現在対策中）。
Payara Micro/Open Liberty/Piranha
JakartaEE対応やMcicroProfile対応の異なるパッケージを有しており、アプリケーションを作成する際にFormXMLに書くインポートライブラリーを修正することで、MicroProfile＋JakartaEEのように組み合わせて利用することが可能。

以上のようにプロダクト毎にサポートする機能が異なることで、ベンダーロックインの問題が発生する。
これはMicroProfileの機能が少なすぎることで各プロダクトが独自に拡張してしまうことが原因となっている。

##3.JakartaEEとMicroProfileとの付き合い方
###3-1.JakartaEEとMicroProfileのそれぞれの適正
アプリケーションを作るうえで、向き不向きがあるのではないかと思うため、まず違いを整理する

  • API、新機能のバージョンアップ状況
    • JakartaEE
      • 直近１０年程度、大きく変わってない
    • MicroProfile
      • １年に一度バージョンアップし、その際に大量のAPIを追加している
  • アプリケーションの起動方法
    • JakartaEE
      • アプリケーションサーバーを起動させ、WARファイルやEARファイルをデプロイする
    • MicroProfile
      • アプリケーションサーバーが無いため、自分でセルフブートアップする
  • アプリケーションの起動速度
    • JakartaEE
      • JVM自体が遅いこと、キャッシュが大量に発生することから、かなり遅くなる
      • コンテナ型であることも遅い要因
    • MicroProfile
      • 起動の早いGraalVMが導入されているため、組み合わせると一瞬で起動させることができる

###3-2.MicroProfile独自仕様でJakartaEEに含めてほしいもの（岩崎さん見解）

  • FaultTorerance
    • メソッド呼ぶ際のタイムアウト値を設定可能で、アノテーションで制御できる
    • バッチ処理で活用できそう？
  • Config
    • アプリ設定ファイル、VM引数、環境変数をアノテーションだけで読むことが可能になる
  • Open APIやREST Client
    • Restful通信に有効なAPI
    • JakartaEEはAPIをアップデートしてない

###3-3.今後JakartaEEとMicroProfileにどう付き合っていくか
JakartaEEは更新が遅く時代に取り残されている部分が否めないため、更新が早く今風の機能を取り込んでいるMicroprofileを組み合わせて使っていくことが大事になってくる。

####3-3-1.組み合わせ例１
基幹系システムとWebシステムの配置場所によってJakartaEEとMicroProfileを使い分ける

  • 基幹系システム
    • JakartaEEを活用
      • MicroProfileはDB系のフレームワークが無いため
      • 基幹系はライフサイクルは長期のため安定稼働する必要があるため
  • Web系システム
    • MicroProfileを活用
      • 昨今のWebのフレームワークはJavaScript系のVue.jsやnode.jsなどで作成されるのが主流であるため
      • ios系はSwift、Android系はKotlinでアプリケーションを作るのが主流であるため
      • デバイスの仕様のライフサイクルは早く、機能更新が早い方がいいため

　　　　→Java以外の言語からの呼び出しに対応するサーバーサイドのフレームワークとしては、
　　　　MicroProfileの方が利用しやすい機能がまとまっている。
　　　　
####3-3-2.組み合わせ例２
基幹系システムのリアルタイム系の処理とバッチ系の処理で使い分ける

  • リアルタイム処理
    • JakartaEEを活用
      • アプリケーションサーバーを起動し、ソケットの接続をする必要があるため、コンテナ系のアプリケーションサーバーの方が起動が早い
  • バッチ処理
    • MicroProfileを活用
      • プロセスの開始終了を切り替えや突発稼働とかの制御をする必要があり、起動と終了が早い方がいい。

#まとめ　　

  • JakartaEEとMicroProfileは別々に動いている別のプロジェクト
    • それぞれで考え方やパッケージ名が異なるので合流はまだまだできなそう。
    • 考え方の異なる点：後方互換性、認証プロセス、権利関係
  • アプリケーションコンテナ型のJakartaEE、フレームワーク型のMicroProfile
    • 基幹系や高負荷系はコンテナ型である前者、Web系やバッチ系のフレームワークは後者にするなど使い分けが大事
  • MicroProfileは未完のフレームワーク仕様である
    • 足りない分は自分で追加する必要がある（今風の考え方なのか？）

#用語の意味と参考サイト（備忘用）

7
2
0

Register as a new user and use Qiita more conveniently

  1. You get articles that match your needs
  2. You can efficiently read back useful information
  3. You can use dark theme
What you can do with signing up
Sign upLogin
7
2

Delete article

Deleted articles cannot be recovered.

Draft of this article would be also deleted.

Are you sure you want to delete this article?