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

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

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

[前回](https://qiita.com/masatarou/items/e324081be4777dcdaed0)は前半パートを書いたので、
今回は後半パートをまとめた。

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

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

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

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

- 1964年　：メインフレーム　[IBM System/360](https://ja.wikipedia.org/wiki/System/360)
    - 以降、IBM System/360の国産互換機が登場
- 1980年代：[Unix](https://ja.wikipedia.org/wiki/UNIX)の登場
- 1990年代：[Linux](https://ja.wikipedia.org/wiki/Linux)の登場
    - この辺りで様々なアプリケーションサーバーが登場するが、各社で独自のアプリケーションサーバーを開発したため、統制が必要となってくる
        - [WebLogic](https://ja.wikipedia.org/wiki/BEA%E3%82%B7%E3%82%B9%E3%83%86%E3%83%A0%E3%82%BA)
        - [CORBA](https://www.atmarkit.co.jp/ait/articles/0103/08/news002.html)
        - [Netscape](https://ja.wikipedia.org/wiki/%E3%83%8D%E3%83%83%E3%83%88%E3%82%B9%E3%82%B1%E3%83%BC%E3%83%97%E3%82%B3%E3%83%9F%E3%83%A5%E3%83%8B%E3%82%B1%E3%83%BC%E3%82%B7%E3%83%A7%E3%83%B3%E3%82%BA#Netscape_Application_Server)
        - [Apache Software Foundation](https://ja.wikipedia.org/wiki/Apache%E3%82%BD%E3%83%95%E3%83%88%E3%82%A6%E3%82%A7%E3%82%A2%E8%B2%A1%E5%9B%A3)が[Apache HTTP Server](https://ja.wikipedia.org/wiki/Apache_HTTP_Server)以外に[Apache JServ](https://en.wikipedia.org/wiki/Apache_JServ_Protocol)を開発
        - Microsoftが[Internet Information Services(IIS)](https://ja.wikipedia.org/wiki/Internet_Information_Services)を開発
                                          
- 2000年代：統制し共同制作するため、[J2EE(Java 2 Platform, Enterprise Edition)](https://ja.wikipedia.org/wiki/Java_Platform,_Enterprise_Edition)が誕生した。
　　　　　ただし、MicrosoftはJ2EEに参加せず、[.NET Framework](https://ja.wikipedia.org/wiki/.NET_Framework)を開発した。
　　　　　そのためJavaと.NETの２つの流れに分裂する。


- 2010年代以降：Java側はJavaEE 5に名前を変え その後JakartaEEに。
　　　　　　　.NET Frameworkは[.NET Core](https://ja.wikipedia.org/wiki/.NET_Core)に変わり、.NET Frameworkとの決別をする。

###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対応版)](https://qiita.com/SightSeekerTw/items/b58152d65bbdc2627095#eclipse-microprofile-%E3%81%A8%E3%81%AF)

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](https://backpaper0.github.io/ghosts/jaxrs-getting-started-and-practice.html#5)：アノテーションでHTTPリクエスト・レスポンスをJavaコードにマッピングする
    - [CDI](https://cloudear.jp/blog/?p=1945)：インスタンスのスコープを管理する
    - [JSON-B](http://masatoshitada.hatenadiary.jp/entry/2015/09/03/122921)：JavaオブジェクトとJSONの相互変換を行う
    - [JSON-P](https://qiita.com/dokkoisho/items/0bc88d3bd4a40c7f4b81)：データを[クロスドメイン](https://wa3.i-3-i.info/word15224.html)から受け取る手法
    - 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](https://wiki.eclipse.org/MicroProfile/Implementation) を参照。
　　なお、プロダクトの違いは後述。

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


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

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

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

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

以上のようにプロダクト毎にサポートする機能が異なることで、ベンダーロックインの問題が発生する。
これは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は未完のフレームワーク仕様である
    - 足りない分は自分で追加する必要がある（今風の考え方なのか？）

#用語の意味と参考サイト（備忘用）
- **Helidon**
    - https://qiita.com/hrkt/items/9e5129497934bdcfdc52
- **Netty**
    - Java で非同期、イベント駆動のネットワークアプリを作るためのフレームワーク
    - Nettyまとめ：https://fatrow.hatenadiary.org/entry/20110208/netty
    - NettyのHP：https://netty.io/
- **JPA（Java Persistence API）**
    - Javaとリレーショナル・データベース（RDB）を直接的に結ぶための仕組み
    - JPAの解説まとめ：https://builder.japan.zdnet.com/sp_oracle/35067018/
- **Oracle UCP（Universal Connection Pool）**
    - 単一の接続プールで、JDBC、JCA、LDAPなど、あらゆる種類の接続を扱う
    - Oracle UCP FAQ：https://www.oracle.com/technetwork/jp/database/application-development/jdbc/overview/default-2248812-ja.html#00_01
- **HikariCP**
    - 高速かつ軽量なJDBCコネクションプールのライブラリ
    - https://openstandia.jp/oss_info/hikaricp/index.html 
- **JTA（Java transaction API）**
    - Javaでトランザクションを管理するためのAPI
    - JTA使い方まとめ：https://qiita.com/opengl-8080/items/9b9d432e0a10486bc1b4
- **CMT（Container Managed Transaction）**
    - EJBでのトランザクション管理の方式の一つ
    - トランザクションの開始と終了はEJBコンテナによって制御され、メソッドの開始時にトランザクションが開始され、メソッドが正常終了した際にコミットを行われる
- **Hibernate**
    - Java のためのオブジェクト関係マッピング (ORM) ライブラリ
- **QUARKUS（クアルカス）**
    - Red Hatが提供する、Kubernetesなどのコンテナ環境に最適化されたJavaアプリケーションを実現するフレームワーク 
    - QUARKUSのまとめ：https://qiita.com/nakkspeed/items/6da5f84df41152fb1ff5
    - QUARKUSの拡張機能：https://quarkus.io/extensions/  
- **Apache Kafka**
    - スケーラビリティに優れた分散メッセージキュー
    - 処理性能を重視しており、大規模データを高速に取り込み・配信が可能
    - 概要まとめ：https://qiita.com/sigmalist/items/5a26ab519cbdf1e07af3
    - LINEでも分散キューイングシステム、データハブとして利用している 
    - LINEでの活用方法：https://logmi.jp/tech/articles/320330