現在Red Hat、IBM、GlassFishのフォーク製品を販売しするPayara、TomcatベースのJava EEアプリケーションサーバ「TomEE」を提供しているTomitribe、さらには「London Java Community」、世界最大のJavaユーザーグループである「SouJava」といったところが参画する「MicroProfile」というプロジェクトが立ち上がっている。
「MicroProfileのプロジェクトは、OracleのJava EEの動きの停滞に業を煮やし立ち上がったものです。クラウド上で変化に強いアプリケーションを提供するためには、マイクロサービス化することで拡張性が高くなります。Java EEのテクノロジで、その実現を目指しているのがこのプロジェクトです」（寺田氏）
Java EE 6から、プロファイルという概念が導入されている。これは、Java EEの全機能のうち、関連する機能だけをまとめて提供する仕組みだ。MicroProfileは、マイクロサービス化のために必要な機能だけをまとめ、提供するためのプロジェクトとして立ち上がった。
「これまでのJava EEは、含まれる仕様を組み合わせて1つのフレームワークにして提供する、モノリシックなアプローチで提供されてきました。この方法が悪いわけではありません。しかしこのやり方で標準化を行おうとすると、全ての仕様ができあがるのを待ち、さらに各仕様で整合性を考慮する必要もあり、標準化プロセスに時間がかかってきました。加えて、できあがった標準仕様を各社がアプリケーションサーバ製品として実装するのにさらに時間がかかります」（寺田氏）
Java EEの仕様を、モノリシックなアプローチでまとめるのではなく、アジャイル的に策定・開発を進め、細かい単位で機能を積み上げていく。それに合わせた新しい標準化のプロセスもあるのでは。そうすることで、変化にも柔軟に対応できスピーディーに標準仕様を作れる。それを進めようとしているのが、MicroProfileのプロジェクトなのだ。
「アジャイル的なやり方で仕様を考え、優先度の高いものから決めていく。JavaOneの期間中、MicroProfileのプロジェクトでは、JavaOneとは別途彼らのやり方を伝える場を設けていました。そこで話を聞くと、このMicroProfileのやり方は今の時代に合ったものだなと感じました」（寺田氏）
このMicroProfileのプロジェクトメンバーは、これまでJava EEの仕様策定に積極的に携わってきた人たちだ。OracleのJava EEの方針と対立することがプロジェクトの目的ではなく、またJava EEの開発者を分断しようとしているわけではない。「彼らは新しい標準の作り方があり、それを自分たちの手で進めたいと考えているようです」と寺田氏。Java EEのマイクロサービス化という方針自体は双方で同じだ。要は、標準化へのアプローチの違いであり、「OracleとMicroProfileのプロジェクトが十分にコミュニケーションできていないのが問題だと思います」と寺田氏は指摘する。
「Oracleが示したJava EEの今後方針も良いものだし、MicroProfileのやり方も今の時代にマッチしたものだと思います。今は、両方の動きを十分に注目する必要があります。お互いに、まだ始まったばかりなのでどちらがよいかを判断するのが難しい状況です。そこで今は、両社の動きに十分注目する必要があります。願わくば、両者がうまくコミュニケーションをとり、お互いを尊重しその上で今後の進め方をどうするか話し合って決めて欲しいです。それによってより良いものが生まれて欲しいというのが、私の願いです」（寺田氏）
このまま両者が対立の構図となってしまうと、現状でOracleが示したJava EE 8、EE 9の提案がJCPにおける投票で全て否決される可能性もある。JCPで投票権を持つ主要各社や、世界でも有力なJavaのコミュニティがMicroProfileのプロジェクトを支持している状況もあり、これはあり得ないことではない。事の発端はOracleがJava EEの動きを止めたように見えたことだ。そういったところからも、Oracleからの歩み寄りに期待していると寺田氏は言う。お互いが歩み寄ることができれば、Java EEはより良いものになっていくのではないかと期待する。。
現在のロードマップはあくまでもOracleからの提案の段階
ロードマップの内容を確認して、Java EE 8はJava EE 9に進化するためのマイナーバージョンアップの位置づけとなっていると寺田氏は言う。これはかつてのJava EE 7の世界から、クラウド化、マイクロサービス化という新しいJava EE 9への大きな変化をスムースに行うためのものだ。この大きな変化のために、Java EE 8では当初の予定からはいくつか落とされる機能も示された。その話を聞き、「Java EE 8にネガティブな印象を持った人もいるかもしれません」と寺田氏。
JMSはそんな機能の1つ。Java EE 8ではJMS 2.0のままで2.1の開発は行わない。またMVC 1.0も落とされる予定だ。「MVCは今後マイクロサービスが主流となりRESTによる通信が増え、フロントエンドではJavaScriptが多用されるようになるため優先度が落とされたようです」（寺田氏）。落ちる機能がある一方で、JSON-B、Security、Health Checking、Configurationが新機能として追加される予定だ。JSON-BとSecurityは以前から追加が検討されていたものだ。今回のロードマップで新たに登場したのがHealth CheckingとConfigurationだ。繰り返しになるが、これらの機能追加・削除はOracleが示した提案に過ぎず、これから投票によりどうなるかが決まる。そこで、どうしてもMVCが必要だという意見が多ければ、それは継続される可能性もある。
そして寺田氏がJava EE 8で更新される技術として注目するのが、JAX-RS 2.1とServlet 4.0だ。Servlet 4.0でHTTP/2に対応し、クライアントからのリクエスト／レスポンスに対し、複数のリクエストを1つのソケット内で同時に処理できるようになる。「また、JAX-RSは性能向上が大きなポイントです。今後のクラウド化、マイクロサービス化ではRESTの呼び出しが増えることになります。その際のクライアント側の処理性能を向上させるためにかなり、重要な機能を追加しています」（寺田氏）とのことだ。
Java EE 8を経てJava EE 9では、マイクロサービス化のためのService Registry、Services Directory、Circuit Breaker、Polyglot Persistence（NoSQLサポート）、CQRSといったマイクロサービスデザインパターンへの対応が明らかにされている。
Java EE9の理解にはマイクロサービスの知識が求められる
「マイクロサービスが何かをきちんと勉強していないと、Java EE 9で入ってくる機能を理解するのは難しいかもしれません。マイクロサービスですでに提供されているデザインパターンの一部に、Java EE 9で対応します。プログラムをどうやって更新すれよいのか、さらにヘルスチェックをどうするのか。スケールアウト、スケールバックなどのオートスケールにどう対処するのか。これらにJavaの標準のAPIで対応するのにどうすればいいかを理解できれば、今回示されたJava EE 9の機能に期待できると思います」（寺田氏）
今後、クラウド上で提供するアプリケーションはマイクロサービス化の方向に進んでいくことが予想される。そのためのノウハウを学ぶことが重要になると寺田氏。モノリシックなアプリケーションの開発が全てダメというわけではない。とはいえ、今後システムアーキテクトは、マイクロサービスという新しいアーキテクチャを理解し、それをどういうときにどう活用すればよいかを提案できるようになる必要があるのだ。
言い換えれば、従来はモノリシックなアプリケーションで落ちることのない堅牢なアプリケーションを作る発想だった。それがマイクロサービス化され、クラウドの分散環境でアプリケーションが動くようになると、どこかで障害が発生したり、ネットワークが切れていたりといった状況が前提になる。そういった状況下でも、全てが動かなくなるのではなく動き続けられるようにするのだ。その実現が、これからのクラウドネイティブなシステム開発には求められるだろうと寺田氏は指摘する。
