Java EEを“クラウド・ネイティブ”にするために必要なこと──開発責任者のアニール・ガー氏が語った

WebLogic Channel編集部
2017-01-05 14:00:00
  • このエントリーをはてなブックマークに追加

クラウド・ネイティブの時代に向け、Java EEをどう強化すべきか?

 続いてガー氏は、上に挙げたような要素をJava EEに取り込むべく、オラクルが検討している提案の内容を説明した。その中でまず前提として強調されたのが、現在のJava EEのエコシステムは極めて健全であり、ほぼ全てのクラウド上で利用可能であるということだ。Java EEがそのような成功を収めている理由は、素早い変化に適応していく柔軟性を備えているからである。

 エンタープライズ・アプリケーションの基本的な構造は、今も昔もそれほど変わらない。ただし、“モダン”なアプリケーションでは、それぞれの機能が独立したサービスとして提供されるという点が大きく異なるとガー氏は話す。例えば、次に示すのは典型的なクラウド・アプリケーションの構成を示したものだ。


※クリックすると拡大画像が見られます

 ご覧のとおり、「UI/ビジネス・ロジック/データソース」という構成そのものは従来と同様だが、ビジネス・ロジックは複数の小さなサービスの組み合わせによって実現される。また、クライアントやデータソースに使われる技術が多様化している点も特徴として挙げることができる。

 Java EEの強みは、このようなアプリケーションの開発に必要な技術を、標準化されたAPIとしてカバーしている点である。現在はさまざまなオープンソース・プロダクトがモダンなアプリケーションの開発で用いられているが、標準化が追いついておらず、そのことが長期的に運用していく際のリスクになっているとガー氏は指摘する。それに対して、Java EEならばアプリケーション全体を標準化された一貫性のあるAPIによって構築できるという強みがある。

 それに加えて、“処方箋的”なプログラミング・モデルを提供している点もJava EEの強みとして挙げられる。例えば、企業がマイクロサービスへの取り組みを開始する場合、多くの開発者は第一歩をどう踏み出すべきかで悩むことだろう。柔軟性が高く、選択肢が多すぎるためだ。一方、Java EEにはさまざまなユースケースに応じたプログラミング・モデルが用意されており、第一歩で悩むことはないのだ。

 それでは、そうした強みも生かしながら、今後Java EEをどのように強化していくべきなのか。オラクルが提案している強化コンセプトは次のようになる。

  • クラウドおよびマイクロサービスのための新たな開発スタイルを導入する
  • プログラミング・モデルやパッケージング、ポータビリティまでを包括的に網羅する
  • 実績のある標準ベースの技術で構成する

 ガー氏は、これらのコンセプトの下、具体的にどのような機能強化/追加を提案しているのかを紹介した。以下に、その主なものを紹介する※1。なお、これらはあくまでも提案の段階にあり、今後はこの提案をベースにして、コミュニティやJCP(Java Community Process)において検討が進められていくことになる。

※1 オラクルの提案内容については、本サイト記事「『Java EEをクラウド時代のプラットフォームとして大きく発展させる』 Java EE 8の変更、Java EE 9を新たに提案──JavaOne 2016基調講演まとめ」も参照されたい。

非同期のプログラミング・モデル

 ユニファイド・イベント・モデルやイベント・メッセージングといったリアクティブ・プログラミングのための拡張機能を導入する。マイクロサービス・ベースのアプリケーションでは多数のサービスが同時に実行されるため、特定のサービスが処理をブロックしてしまうモデルは好ましくない。JAX-RSやHTTP/2、ラムダ式、JSON-Bといった機能も、この目的で活用される。

結果整合性(Eventual Consistency)

 データが複数にレプリケーションされている環境では、1つのレプリカに変更が加えられたら、それが他の全てのレプリカに反映されなければならない。完全にリアルタイムである必要はないが、数秒で同期処理が完了できるようにする。

キー/バリュー・ストア、ドキュメント・ストア

 RDBMSのほかに、キー/バリュー・ストアやドキュメント・ストアに対する永続化もサポートする。

セキュリティ

 クラウド環境に対応した適切なセキュリティ管理機構を導入し、OAuthやOpenIDなどもサポートする。

ロケーションの透明性および回復性

 サービスのパッケージとコンフィギュレーションを分離し、デプロイする場所に依存しないアーキテクチャを実現する。コンフィグレーションにはAPIベースでアクセスできるようにし、またサービスのステートについてもパッケージの外部に分離して管理し、APIでアクセス可能とする。

 回復性については、サーキット・ブレーカーや復旧用コマンドの導入、標準化されたヘルス・レポート機能など、事前予防的な機構を持たせることが重要になる。

シンプルなパッケージング

 ランタイムまで含めた環境一式を1つのパッケージにまとめるためにDockerモデルのアーキテクチャをサポートする。また、それに加えてサーバレスなアーキテクチャやマルチテナンシーもサポートする。

Java EEが提案するプラットフォームアーキテクチャ

 次に示すのは、以上の要素を取り入れたクラウド・ネイティブなアプリケーションのアーキテクチャである。


※クリックすると拡大画像が見られます

 「このアーキテクチャでは、アプリケーションをデプロイすると、Deployment ManagerとJLinkが、そのアプリケーションの実行に必要なDockerコンテナを自動的にセットアップします。このコンテナに含まれるのはアプリケーションに必要なツールのみであり、その他の不要な要素は一切インストールされません」とガー氏は説明する。

 また、コンフィギュレーションやロギング、キャッシングなどの機能はプラットフォーム・サービスを通じて提供され、CDI(Contexts and Dependency Injection)を使って各アプリケーションにインジェクションされる。


※クリックすると拡大画像が見られます

 そして、ここまでに説明した機能を組み込んだJava EEのプラットフォー・アークテクチャの全体像は次のようになる。


※クリックすると拡大画像が見られます

 ガー氏は最後に、Java EEの今後のロードマップを説明した。現在はJava EE 8に対する提案が行われた段階であり、今後、コミュニティと議論しながら検討と開発を進め、2017年末の正式リリースを目指すという。また、その次のバージョンとなるJava EE 9は2018年末のリリースを目標にしているという。


※クリックすると拡大画像が見られます

 以上、2016年12月に開催されたセミナー「Javaで創るクラウド時代のエンタープライズ開発」におけるアニール・ガー氏の講演の内容を基に、JavaOne 2016でオラクルが発表したJava EEへの新提案の要旨を紹介した。もちろん、これはあくまでも現時点で検討されている内容であり、Java EEを最終的にどのようなものにするかは、世界中のJavaコミュニティとの議論を通じて最終決定される。Java EEをよりよいものにするための要望をお持ちの方は、ぜひJCPやAdopt-a-JSRなどを通じてご提案いただきたい。

【関連情報】

【関連記事】