新たに設立されたMicroProfile Working Groupの手により、待望久しいMicroProfile 4.0のリリースがJavaコミュニティに届けられた。Jakarta EE 8との整合性がフューチャーされた他、12のコアAPIすべてがアップデートされている。ただしスタンドアロンAPIについては、今回は変更されていない。
CDI、JAX-RS、JSON-PおよびJSON-B APIは、従来それぞれのJSRに基いていたが、今回のリリースから、対応するJakarta EE 8仕様であるJakarta Contexts and Dependency Injection 2.0、Jakarta RESTful Web Services 2.1、Jakarta JSON Processing 1.1、Jakarta JSON Binding 1.0をベースとするように変更された。背景となったのは、MicroProfile 4.0が、"さまざまなJavaテクノロジに適用可能な宣言型スタイルのプログラミングを可能にするための、共通的な意味概念を表現するアノテーション集合を定義する"仕様であるJakarta Annotation 1.3を使用していることだ。
当初2020年6月に予定されていたMicroProfile 4.0のリリースは、Eclipse Foundationが必須条件としたEclipse Working Groupの設立まで延期されていた。ワーキンググループは、MicroProfile Specification Processを定義し、Atlanta JUG、IBM、Jelastic、Red Hat、Tomitribeといった組織およびJava User Group(JUG)で構成される公式なステアリングコミッティを立ち上げている。
LibertyのマイクロサービスアーキテクトでIBMアドボケートのEmily Jiang氏は、この1年間の問題を思い起こしながら、InfoQに次のように話してくれた。
MicroProfile 4.0は期限までにリリースできませんでした。個々のAPI仕様は、かなり前からリリースの準備ができていたのですが、リリースの前提条件がMicroProfile Working Groupの設立となっていて、この達成に10か月近くを必要としたためです。ワーキンググループ設立後、すぐにMircoProfile 4.0のリリースプロセスに着手しました。
仕様のライセンス要件やJavadoc、仕様への投票方法を含むリリースプロセスを確立するための実験台(guinea pig)として、MicroProfile Config 2.0を使用しました。この経験をもとに、APIリリースのテンプレートとプロセスを作ったのです。また、依存関係をベースとしてAPIリリースを3段階に分割するリリースプランを作りました。その上でAPIリリースを開始し、リリースのステージング、投票プロセスの開始などを行ったのです。
2020年内にMicroProfile 4.0をリリースするには大変な努力が必要でしたが、Eclipse Foundationの大きな助力や支援もあって、何とか12月23日にリリースすることができました。最終的にMicroProfile 4.0のリリースを発表したJelasticには、特に感謝しています。
Jakarta EEとの依存整合性を確保するため、MicroProfile 4.0では、Config、Fault Tolerance、Health、Metrics、OpenAPIの５つのAPIで、非互換的な変更を行っている。今回はそのいくつかを検証する。
MicroProfile Config 2.0
MicroProfile Config APIは、外部ソースからの実行時コンフィギュレーションを可能にすることで、アプリケーションの再パッケージ作業を最小限にする。外部リソースは優先度ベースの序数システムに基づいており、システムプロパティ(序数=400)、環境変数(序数=300)、.propertiesファイル(序数=100)などがある。これらは序数の値が高いものほど優先される。ConfigSourceインターフェースを実装すれば、独自のソースを定義することも可能だ。
Config 2.0では、@ConfigPropertiesアノテーションが導入されており、プロパティクラスへのプロパティのバルク取り出しが可能になっている。これにより、例えば設定ソースから多数の関連プロパティを読み出す場合、@ConfigPropertyアノテーションを繰り返し適用する必要がなくなる。例えば、次のような設定を考えてみよう。
server.host=localhost
server.port=8080
server.endpoint=movie
次のようにすれば、すべてのプロパティをひとつのクラスに取り出すことが可能になる。
@ConfigProperties(prefix="server")
@Dependent
public class ServerDetails {
public String host; // the value of server.host
public int port; // the value of server.port
private String endpoint; //the value of server.endpoint
public String getEndpoint() {
return endpoint;
}
}
新機能および非互換的変更に関する詳細は、リリースノートやGitHubリポジトリで確認できる。
MicroProfile Fault Tolerance 3.0
MircoProfile Fault Tolerance APIは、アプリケーション内の障害を処理するさまざまな方法(タイムアウト、リトライ、ブレーカなど)を提供する。それぞれの方法には対応するアノテーションが用意されており、それを使用することで、アプリケーションを必要な一連の処理にリダイレクトして、障害による悪影響を最小限にすることができる。
Fault Tolerance 3.0では、サーキットブレーカとバルクヘッドのライフサイクルを指定することによって、適切な機能のために呼び出し間で状態を維持することが可能になった。例えば、@RequestScoped beanに＠CircuitBrakerというメソッドがあれば、対象となるbeanインスタンスが違っていても、そのメソッドのすべての呼び出しが同じサーキットブレーカを共有する。
Fault Toleranceメトリクスがアップデートされて、Metrics 2.0の新機能であるメトリックタグをサポートするようになった。その結果、これまではメトリクスの名前に含まれていた情報が、今後はタグに含まれるようになる。
他のMicroProfile APIとの一貫性の面から、Fault Toleranceメトリクスはapplication:スコープからbase:スコープに移動された。これにより、これまで/metricsおよび/metrics/applicationエンドポイント下で公開されていたこれらのメトリクスが、今後は/metricsおよび/metrics/baseエンドポイント下で公開されるようになる。
新機能および非互換的変更に関する詳細は、リリースノートやGitHubリポジトリで確認できる。
MicroProfile Health 3.0
MicroProfile Health APIは、コンピュータノードが停止あるいはシャットダウンの危機に瀕していることを判断し、フレッシュで健全なインスタンスへの置き換え処理を行う。Metrics APIと同じように、自動的に提供される/healthエンドポイントを通じて、アプリケーションの動作状態がJSON形式で示される。
Health 3.0では、アプリケーション起動時のデフォルトの起動条件を定義することができる。起動条件はコンテナが要求を処理可能かどうかによって判断されるため、アプリケーションの起動条件が成立するようになるまで、コンテナはNGステータスを返し続ける必要がある。そのためには、MicroProfile Config値のmp.health.default.readiness.empty.responseが使用され、アプリケーションの起動準備が整ったことをコンテナに通知するためにUPがセットされる。
新機能および非互換的変更に関する詳細は、リリースノートやGitHubリポジトリで確認できる。
MicroProfile Metrics 3.0
MircoProfile Metrics APIは、MicroProfileアプリケーションに時系列テレメトリデータを提供する。組み込みの/metricsエンドポイントがPrometheus形式でデータを送信する。 @Counted、@Gauge、@Histogram、 @Timedといった組み込みアノテーションを使って、独自のメトリクスを定義することも可能だ。
Metrics 3.0でも数多くの変更が加えられているが、特にMetricsRegistryは、これまでの抽象クラスだったものがインターフェースになって、実装の必要な新しいメソッド(getType()、gauge()、histogram()、meter()など)が多数追加されている。Metricの登録が@Metricアノテーションでトリガされなくなった。アプリケーションメトリクスの登録が必要な場合は、新設されたMetricRegistryメソッドを使って行う必要がある。
新機能および非互換的変更に関する詳細は、リリースノートやGitHubリポジトリで確認できる。
MicroProfileを導入する
Spring InitialzrやQuarkus、Micronaut LaunchといったWebベースのスタータツールと同じような、クラウドベースのマイクロサービスアプリケーション開発を始めるための比較的新しいツールとして、MicroProfile Starterページが用意されている。2019年1月にリリースされたMicroProfile Starterは、MircoProfileとJava SEのバージョン、選択したMicroProfileのバージョンでサポートされるランタイム、チェックボックスで指定したMicroProfile APIなどの選択に基いて、完全なMavenプロジェクトを生成する。
MicroProfile Working Groupは現在、先日のOpenTracingプロジェクトとOpenCensusプロジェクトの統合から生まれた新プロジェクトであるOpenTelemetryと、ベンダニュートラルなアプリケーションメトリクスファサードのMicrometerプロジェクトを、それぞれOpenTracing APIとMetrics APIをリプレースする可能性のある候補として評価している。
編集者注
本ニュースストーリは発表後更新され、Emily Jiang氏の回想が追加された。