JJUG夜间研讨会备忘录2(JakartaEE·MicroProfile)

首先

由于我参加了2020年1月22日的JJUG夜间研讨会“Jakarta EE特别篇”,所以我总结了其内容。

活动介绍页面
https://jjug.doorkeeper.jp/events/102611

因为上次写了前半部分,
这次将整理后半部分。

在对话中提及的术语的含义和解释的网站被整理在底部作为备忘录。

与Jakarta EE + Microprofile的互动关系

会议概要摘要可从活动页面中获取。

概述
Java EE,曾经是企业级系统开发的主流,现在已经脱离Oracle,转移到了Eclipse Foundation,并更名为Jakarta EE。与此同时,随着Web和云轻量级开发的趋势,也出现了一种新的规范,名为Microprofile。国内较少客观地谈及Jakarta EE和Microprofile的关系,导致情况非常复杂。本次演讲将回顾J2EE之前的历史,并结合2019年Oracle Code One的最新信息,详细解释这些新规范将如何发展,该如何应对,以及为这个趋势制定战略的方法。

1. 企业系统及JakartaEE,MicroProfile的历史

首先回顾每个人的出生历史。

1-1. 企業界的历史

    • 1964年 :メインフレーム IBM System/360

以降、IBM System/360の国産互換機が登場

1980年代:Unixの登場

1990年代:Linuxの登場

この辺りで様々なアプリケーションサーバーが登場するが、各社で独自のアプリケーションサーバーを開発したため、統制が必要となってくる

WebLogic
CORBA
Netscape

Apache Software FoundationがApache HTTP Server以外にApache JServを開発
MicrosoftがInternet Information Services(IIS)を開発

2000年代:統制し共同制作するため、J2EE(Java 2 Platform, Enterprise Edition)が誕生した。
ただし、MicrosoftはJ2EEに参加せず、.NET Frameworkを開発した。
そのためJavaと.NETの2つの流れに分裂する。
2010年代以降:Java側はJavaEE 5に名前を変え その後JakartaEEに。
.NET Frameworkは.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版本)。

我們正在開發並發佈一個與JavaEE 8不同的規範。
MicroProfile所包含的規範可以參考以下鏈接:
https://wiki.eclipse.org/MicroProfile/Implementation

1-2-2. 由于MicroProfile的诞生而导致的问题。

由于原本应该包含在JavaEE 8中的规范被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支持,因此未出现实际的问题。(尽管存在无法使用新功能的问题)

由于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

以下是一种可能的中文表达方式:
包括但不限于这些。可使用的产品请参考MicroProfile的官方网站。
此外,产品的差异将在后文中提及。

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

 

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
这些框架都具有不同的Jakarta EE和MicroProfile支持包,可以通过修改FormXML中的导入库来组合使用MicroProfile + Jakarta EE来创建应用程序。

由于每个产品支持的功能不同,导致了供应商锁定问题。这是由于MicroProfile功能过少,导致各个产品都需要自行扩展的原因。

3. JakartaEE和MicroProfile的互动关系

3-1. JakartaEE和MicroProfile各自的适用性

首先,我认为在开发应用程序时,可能存在适合与不适合的情况,因此需要先整理出它们之间的差异。

    • API、新機能のバージョンアップ状況

JakartaEE

直近10年程度、大きく変わってない

MicroProfile

1年に一度バージョンアップし、その際に大量のAPIを追加している

アプリケーションの起動方法

JakartaEE

アプリケーションサーバーを起動させ、WARファイルやEARファイルをデプロイする

MicroProfile

アプリケーションサーバーが無いため、自分でセルフブートアップする

アプリケーションの起動速度

JakartaEE

JVM自体が遅いこと、キャッシュが大量に発生することから、かなり遅くなる
コンテナ型であることも遅い要因

MicroProfile

起動の早いGraalVMが導入されているため、組み合わせると一瞬で起動させることができる

3-2. 岩崎先生的观点是,希望将MicroProfile作为一个独立规范纳入JakartaEE中。

    • FaultTorerance

メソッド呼ぶ際のタイムアウト値を設定可能で、アノテーションで制御できる
バッチ処理で活用できそう?

Config

アプリ設定ファイル、VM引数、環境変数をアノテーションだけで読むことが可能になる

Open APIやREST Client

Restful通信に有効なAPI
JakartaEEはAPIをアップデートしてない

未来要如何处理JakartaEE和MicroProfile的关系?

由于JakartaEE的更新较为缓慢,无可否认地已经落后于时代,因此,将快速更新且具有现代功能的Microprofile与之结合使用变得至关重要。

3-3-1. One example of combination. (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. Combination Example 2

三-三-二。组合示例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

广告
将在 10 秒后关闭
bannerAds