MicroProfile によるアプリケーション開発

この記事は Java EE Advent Calendar 2016 および Payara Advent Calendar 2016 の 18 日目です。昨日はうらがみさん (@backpaper0) の「Jersey OAuth 2クライアントで遊ぶ」(Java EE) およびかずひらさん (@kazuhira_r) 「Payara(Hazelcast)のLite Membersについて」(Payara) です。

1. MicroProfile とは?

MicroProfile は Java EE 技術をベースとしたマイクロサービス向けのプロファイルで、MicroProfile.io によって策定されています。

MicroProfile.ioIBMLondon Java CommunityRed HatTomitribePayara および SouJava といったベンダーおよびユーザーグループで構成されており、現在のところ Java Community Process とは独立して活動しています。MicroProfile は 2016 年 9 月に最初のバージョンがリリースされており、現時点でリリースされている実装には WildFly Swarm、Payara MicroProfile、WebSphere LibertyTomEE の 4 つがあります。

Payara MicroProfile は、利用可能な API が MicroProfile に限定されることを除いて Payara Micro と同じで、Hazelcast によるクラスタリングもサポートします (Hazelcast を同梱している関係で、MicroProfile 実装でありながら JCache も利用できたりします)。細かいところでは、JAX-RS の JAXB/JSON-B に差異がみられます。Payara Micro には EclipseLink (JPA 実装) が含まれるため、既定では EclipseLink MOXy が使用されます。ただし、JAX-RS の実装である Jersey には Jackson が含まれているため、MOXy が無効化された状態では Jackson が処理を代行します。Payara MicroProfile には EclipseLink が含まれないため、はじめから Jackson が使用されます。

MicroProfile は JAX-RS、CDI および JSON-P のわずか 3 つの仕様から成り立っています。このうち JAX-RS と JSON-P はサービス間の通信を主な目的としており、サービス本体を記述するために用意されているものは CDI だけです。例えば、JPA のような永続化のための仕様は MicroProfile には含まれていません。マイクロサービスでは、それぞれのサービスは外部インタフェースからデータストアまで一通り備えた、独立した存在です。そのため、データの永続化ひとつをとっても、サービスごとに最適な方法 (KVS、RDB、etc.) は異なります。他の機能についても同様のことが言えます。

マイクロサービスにおいては、各サービスの実装には標準・非標準を問わず最適な技術が選択されます。裏を返すと、目的を達成するためであればどのような技術を用いても良く、共通で使用されると考えられる JAX-RS、CDI、JSON-P のみを MicroProfile としてまとめています。MicroProfile に規定されていないものについては、サービスごとに最適な技術を任意に組み合わせるべきというのが基本的な考え方です。

2. MicroProfile によるアプリケーション開発

MicroProfile によるアプリケーション開発では、通常は複数のサービスを組み合わせてアプリケーションを構築することになります。サービスは既存のものもあれば、新たに開発するものもあるでしょう。

MicroProfile.io が提供しているデモに microprofile-conference というアプリケーションがあります。このデモ・アプリケーションはカンファレンスのスケジュール・セッション・スピーカーの管理とセッションへの投票受付を行うもので、4 つのサービスと UI を含む Web アプリケーションで構成されています。pom.xml を見ると、サービスごとに必要なモジュールを依存関係に含めていることがわかります (デモのため MicroProfile 本体だけで構築しているサービスもあります)。4 つのサービスがそれぞれ異なる MicroProfile 実装で提供されているのも興味深い点です。実をいうと、このアプリケーションは私の環境ではビルドできないのですが、ソースファイルを見るだけでも感覚はつかめることでしょう。

どのサービスも、JAX-RS でエンドポイントを提供しており、それを Web アプリケーションから呼び出す構成を採っています。サービス間の通信はなく、Web アプリケーションがサービスの取りまとめ役を果たしています。

各サービスは CRUD に相当する機能を提供しており、それぞれ独自の方法でデータストアの操作を行っています。このアプリケーションはデモのため永続化ストアは使用していませんが、実運用を想定したアプリケーションであれば永続化ストアを使用するサービスも出てくることでしょう。データストアはサービスごとに独立して管理しますが、その参照先は同一であっても構いません。例えば、1 つの RDBMS を複数のサービスが参照しても良いのです。ただし、RDBMS に対する操作 (JPA でいうところの PersistenceUnit) はサービスごとに異なります。
マイクロサービスでは、アプリケーション全体としてのトランザクション一貫性は保証せず、別の方法でそれを補います (そして、その方法はアプリケーションによって異なります)。二相コミットメントを使うことも不可能ではありませんが、それではマイクロサービスの大切な何かを失ってしまうような気がします。

3. まとめ

今回は MicroProfile.io が提供するデモ・アプリケーションを題材として、MicroProfile を利用したマイクロサービスの実装例を見てみました。MicroProfile で規定された仕様はわずか 3 つですが、マイクロサービスの視点からは標準化すべき仕様はその程度で問題なく、あとはサービスごとに必要な技術を標準・非標準を問わず必要なだけ利用すれば良いことになります。

本来であれば、MicroProfile を用いてサービスとアプリケーションを開発できれば良かったのですが、そこそこの大きさのデモ・アプリケーションが用意されたため、それを紹介させていただきました。


明日は、Java EE が多田さん (@suke_masa)、Payara がうらがみさん (@backpaper0) です。