Jakarta EEにおけるMicroProfileコミュニティの影響

Lightbendのシニアデベロッパで、Lagomマイクロサービスフレームワークの開発者のひとりであるJames Roper氏が先日、Eclipse MicroProfileのコミッタに任命された。Jakarta EEの参加メンバであるLightbendから初のコミッタだ。

先日のブログ記事でRoper氏は、自身がコミッタになった経緯にはMicroProfileコミュニティと、Jakarta EEに対するその影響が関係している、と述べている。MicroProfileの中心的なコントリビュータは、IBM、Red Hat、Tomitribe、Payaraの4社である。氏によると、

IBMとRedHatは、Java EE市場への投資とシェアをほぼ2分するベンダであり、中心となって開発を推進するであろう大企業です。対照的にPayaraとTomitribeは、それぞれGlassfishとTomEEのサポートでビジネスを成り立たせている小さな企業ですが、積極的に議論し、自身も重要な貢献を行っています。

これら4社以外にも、MicroProfileを実装しているベンダはいくつかありますが、コミュニティ活動にはそれほど活発ではないようです。またJavaチャンピオンやJava EEガーディアンを始めとして、積極的に議論に参加している個人も相当数います。これらはすべて、コミュニティが健全であることを示すものです — ベンダと個人が混在し、活発なメンバも、それほど活発でないメンバもいる中で、皆が協力して同じ目標を目指しているのです。

MiroProfileコミッタのページによると、これら4企業には、それぞれの規模に応じて下記の数のコミッタが在籍している。

• IBM (21)
• Red Hat (17)
• Tomitribe (9)
• Payara (5)

MicroProfileコミュニティに関わるすべての企業のコラボレーションについて、Roper氏は次のようにコメントしている。

さらに驚きなのは、順調に共同開発を進めているこれら4つのベンダ同士が、実は熾烈な競争の相手であることです。彼らの製品はそれぞれが直接的に対峙しており、互いの市場シェアを奪おうと激しく争っています。それでも彼らは、相互利益を目的とした共同開発の推進方法を見出すことに成功したのみならず、これが生産的で革新的なものであることにも気付きました。MicroProfileコミュニティがJakarta EEにとってよい徴候だと思うのは、そういった理由からです。

氏は自身の経験をInfoQに話してくれた。

InfoQ: コミッタとしてMicroProfileに参加しようと思った動機は何でしたか？

James Roper: 開発者の作業を楽にしたいと、ずっと前から思っていました。Lightbendに興味を持ったのもこのためです。Play Frameworkのホットリローディングや意味の明確なデフォルト値は、JVM上に素晴らしい開発者エクスペリエンスを実現していました。自分もそのようなエクスペリエンスを開発者に提供したいと思ったのです。

MicroProfileはそれを一段階上のレベルで可能にしました — Ligjhtbendのオープンソースプロジェクトは広く使われているかも知れませんが、MicroProfileやJakarta EEの基礎であり、それらを形作っているJava標準の持つ業界浸透度には遠く及びません。MicroProfileは、私たちがLightbendで作ってきたファンタスティックな開発者エクスペリエンスを、より広いオーディエンスに届けるためのチャンスなのです。

InfoQ: LightbendがJakarta EEの参加メンバに加わった動機は何だったのでしょう？

Roper: Lightbendがコミュニティを育てる上での課題のひとつは、当社のテクノロジやアプローチが、業界の他のものとあまりにも違っていることにあります。そのため、適当なスキルを持った開発者の雇用が難しい、あるいは開発者の理解が十分でない場合に適切な利用が難しい、などの理由による導入リスクが大きいのです。

Jakarta EEに関わったことは、この問題に対処する上で２つのメリットをもたらしてくれました。ひとつは、マイクロサービスやクラウドネイティブシステムに対する当社のアプローチと互換性のある方法で標準を形成することによって、当社のプラットフォームを業界標準に近付けることができるため、当社自身による標準の実装が可能になったことです。

もうひとつは、業界標準が当社のアプローチに近いものになるように影響を与えられることにより、当社とJakarta EEエコシステム両方にメリットがあると思われる点です。マイクロサービスに対する当社のReactiveなアプローチは、スケーラブルでレジリエントなシステム構築には不可欠だと思います。

InfoQ: MicroProfileには、どのような貢献を予定していますか？

Roper: 私のコントリビューション(さらにはLightbendとしてのより広範なコントリビューション)は、新しいReactiveアプリケーションが中心になると思います。まず最初に、Reactive APIを記述するためのアプローチの概要作成を支援して、MicroProfileにReactive機能を実現します。このアプローチを提案する過程において、開発者がReactive Streamを処理可能にするために、MicroProfileにReactive Stream操作APIが必要であることを指摘しています。

このAPIに関する仕様は間もなく完成する予定です。これが完成すれば、MicroProfile Reactive Messagingと呼ばれる、Reactive Streamベースのコンシュームやパブリッシュ、サービス間のメッセージストリーム処理を可能にする次の仕様へとつながります。当社が現在、最も力を入れているのはこの部分です。

将来的にこれらの仕様が完成したならば、MicroProfileがReactiveアプローチから恩恵を受けられるような方法の模索をさらに続けて、この領域でのコントリビューションを図っていきたいと思います。最近になって、MicroProfileのパーシステンスが話題に上っています。私たちはLightbendで、ACIDトランザクションを用いた単独データベースを使うモノリスでは起こり得ないようなパーシステンスの問題を数多く経験しているので、議論に加わってそれらの経験を提供したいと考えています。

InfoQ: LagonマイクロサービスはMicroProfileに影響するでしょうか？もしそうならば、どの仕様(Config、CDI、JSON-P、フォールトトレランスなど)が最も貢献できると思いますか？

Roper: 正直なところ、これまでMicroProfileで行われてきた作業の多くは、遅れを取り戻すためのものでした。JSONサポートを例にすれば、JSONを使用した通信は10年ほど前に事実上の業界標準になっていますが、Java EEでは2013年になってやっと、Java EE 7でJSON-Pを使用したAST for JSONが導入されたのみです。JavaオブジェクトをJSONに変換する標準APIを備えたJavaEEやMicroProfileに至っては、現在もまだリリースされていません。それを提供する仕様がJSON-Bで、次期リリースであるMicroProfile 2.0とJava EE 8に含まれる予定です。

これに対してLagomは、業界標準になる前からこのような基本機能をサポートしていたテクノロジを基盤としていました — ですから私としては、このようなタイプの機能がLagomの最も重要な部分だとは思っていません。例えば、JSONバインディングをモデル化するソリューションには、完成度の高い優秀なものがたくさんあります。LagomもJSONバインディングを明示的にサポートしていて、適切に動作しますが、今日の優秀なフレームワークであれば、どれも同じような機能を備えています。ですから、LagomがMicroProfileに最も大きな影響を与えられると私が思うのは、既存の仕様ではありません。

Lagomが独自の価値をもたらすのは、Reactiveマイクロサービス構築のサポートです。いつ何が障害を起こすか分からない、極めて脆弱なクラウドネイティブコンピューティングの世界において、その上にパターンを適用することによって、開発者がこのような脆弱性に煩わされることなく、自らのビジネス上の問題に集中することを可能にします。

このようなパターンの実装は、業界でもあまり例がありません。新たな仕様に基づいた製品の数も極めて少ない上に、業界で広く採用されているものとなればなおさらです。これらのパターンには新しいアーキテクチャ、さらには新しいAPI — ストリーミングや非同期通信、イベントログベースの永続化のためのAPIが必要です。ですから、LagomがMicroProfileに最も大きな影響を与えられるのは、これらの新しい仕様の確立と開発にあります。

InfoQ: MicroProfileとJakarta EEに関して、読者に伝えておきたいことは他にありますか？

Roper: フレームワークやAPIにおける標準の役割については、多くの人が懐疑的だと思いますが、Java EEエコシステム全体でOracleが起こした失態を見れば一目瞭然でしょう。この件については、話したいことがいくつかあります。

1. Jakarta EEはJCPやOracleから解放されているので、同じ失敗を繰り返すことはありません。Jakarta EE上にEclipseがセットアップしたガバナンスモデルは、Jakarta EEを作り上げている仕様、実装、TCKの開発とメンテナンスに最も多くの時間とリソースを投資している大手ベンダの役割と、技術革新と仕様を推進するコントリビュータからのメリットベースのコントリビューションの役割とを、絶妙のバランスで並立させていると思います。部外者の立場であったLightbendが、MicroProfileとJakarta EEのコミュニティにいとも簡単に参加できて、私自身もMicroProfileプロジェクトの主導的な開発者になったという事実が、それを証明しています。

2. Jakarta EEとMicroProfileの持つオープンなコラボレーションプロセスが、標準ベースのフレームワークとAPIの価値を高めています。コントリビュータとして参加した短い間に、私は、この業界と人々が行っているさまざまなこと、彼らにとって重要なこと、彼らがいかに問題を解決しているのかなど、Lightbendという殻に閉じこもっていては分からなかったことをたくさん学びました。

結果として、私たちがMicroProfileで取り組んでいる仕様は、Lagomでの私たちの経験から多くを得ていながら、そのプロセスにおいて獲得した広範な経験を反映することによって、Lagomよりも優れたものになると思っています。この仕様が一回りして、Lagomに実装される時を楽しみにしています。ですから私は、今後数年間でJakarta EEやMicroProfileから生み出される標準が、どのベンダが作るものよりも優れたものになると信じています。

3. クラウドを徐々に受け入れ始めたエンタープライズ企業にとって、ベンダへのロックインを回避することは、これまでにも増して非常に重要な要件になったと思います。従来であれば、ロックインとは特定のアプリケーションサーバやデータベースに束縛されるという意味であり、ハードウェアに関しては依然としてコントロールが可能でした。

今日では、アプリケーションサーバだけではありません。サーバからネットワーク、オペレーティングシステムやオーケストレーション、もちろんアプリケーションサーバやデータベースも含めた、デプロイメントインフラストラクチャ全体なのです。クラウドベンダはPaaS機能をますますプッシュしています。PaaSには固着性があり、ユーザをクラウドサービスにロックインできるからです。そのためロックインは、これまで以上にコストのかかるものになっています。

ロックインを事前回避する上での標準ベースのフレームワークの必要性は、システムをクラウドにデプロイする場合には、これまで以上に大きなものになります。Jakarta EEとMicroProfileはこのロックインを緩和する方法を提供することで、ユーザを特定のベンダに縛りつけないPaaSサービスを可能にします。これによって、最高のテクノロジを提供してくれるベンダを自由に選択して、いつでも切り換えることができるようになるのです。

InfoQ: あなたの現在の役職は何ですか、つまり、毎日どのようなことをしているのでしょうか？

Roper: MicroProfile Reactiveプロジェクトのリードと、Reactive MessagingおよびReactive Streams Supportの仕様作成が私の主な責務であり、大部分の時間をそれに費やしています。この中にはコーディング(今はReactive MessagingのTCKに着手したところです)の他、メーリングリストやGitHub、あるいは週次のハングアウトでの数多くの議論も含まれています。

これに加えて、隔週で行われるMicroProfileのコミュニティハングアウトへの参加や、メーリングリストの積極的なチェックなど、MicroProfileの動向を幅広く把握するためにもかなりの時間を費やしています。最近はCNCF CloudEvents仕様(https://cloudevents.io/)にも関わっています。この仕様がMicroProfile Reactive Messagingで提供するいくつかのAPIにおいて、その基盤となる可能性が高いためです。いくつかハングアウトに参加したり、GitHubのPRを経由して提案したり、メーリングリストやGitHubで多くの議論に参加したりしています。

InfoQはIBM、Red Hat、Tomitribe、Payaraの各社に、競合企業でありながらMicroProfileでのコラボレーションに成功したことについてのコメントを求めた。

IBMでWebSphereとLibertyのランタイムアーキテクトを務めるAlasdair Nottingham氏は、次のように語っている。

Liberty開発チームにとって、競合他社とのパートナシップは新しいものではありません。20年前の1998年、WebSphereの最初にリリース(Servlet Expressと呼ばれていました)して以来、私たちのDNAの核になっています。当時IBMでJavaソフトウェアのジェネラルマネージャだったPat Sueltz氏は、“仕様では協力するが、実装では競合する”と言っていました。 それ以降のJ2EE、Java EE、CommonJ、そして今回のEclipse MicroProfileでも、私たちは同じことを行っているのです。

私たちはAPIや仕様では協力していますが、Javaの世界を見ていれば誰でも、ベンダ間の競争が熾烈であることは知っています。これは業界や各企業にとって望ましいことです。Apache TomcatやSpring Bootとの競合がなければ、今日のWildflyやLibertyはありませんでした。10年前のヘビーウェイトなアプリケーションサーバに相変わらず悩み続けていたでしょうし、Javaは現在のようなクラウド上の強力なプラットフォームではなかったと思います。

過去20年間にJava EE(現在はJakarta EE)が進化してきた様子を知らない人には奇妙に思えるかも知れませんが、私たちにとってEclipse MicroProfileがもたらした違いは、協力すること自体ではなく、協力する方法なのです。

APIの定義(と実装)にオープン開発モデルを採用したことによって、クラウドネイティブJava用の強力な新APIを、極めて短期間に構築することが可能になりました。常に同意できるとは限りませんが、Java EEのコアに基づいて、次世代のアプリケーションを構築するためのライトウェイトなAPIを提供する、という目標は同じです。

私たちがEclipse MicroProfileを通じて行ってきた作業から、APIを定義するためのオープンなアプローチが極めて効果的であることが分かりました。Jakarta EEプロジェクトも同様のオープンアプローチで進められています。Jakarta EEプロジェクトをまとめる方法は、Eclipse MicroProfileによって行われた作業から広く知られるようになりましたが、考慮の余地はまだあります。

MicroProfileは、Java EE上に共通のクラウドネイティブプログラミングの採用を進めるために始まり、Jakarta EEに引き継がれています。Jakarta EEでは、継続中の開発の出発点として、Eclipse Foundationの下で、Java EEテクノロジを再編成しなければなりません。そのため、私たちがすでに持っているプロセスを刷新すると同時に、プラットフォームをさらに進める作業を行なっています。

Eclipse MicroProfileが新たなAPI定義を継続する中で、Eclipse MicroProfileがJakarta EEで使用されるAPIのインキュベータになることによって、あるいは互いに補完し合うプロジェクトとして、密接に関連するこの2つのプロジェクトに関心と期待が集まっています。Eclipse MicroProfileとJakarta EEは対立するものではなく、今後もそうはならないということは、自信を持って言うことができます。それぞれのコミュニティの参加者に、重複する部分が非常に多いというだけなのです。

Red HatのシニアミドルウェアコンサルタントであるMike Croft氏は、次のように述べている。

MicroProfileの成功はJakarta EEの将来へのよい徴候である、というJamesの言葉は、まさにその通りだと思います。事実、競合企業であるにも関わらず、Jamesが指摘しているように、すべてのベンダの関係者は古くからの仲間であり、エンタープライズJavaの成功という目標を共有していることを認めています。

MicroProfileは、本質的にコミュニティ指導型です。すべてのことがオープンに行われ、全員が責任を負います。私の見解では、これがMicroProfileを成功に導く鍵となる特徴であり、名称やロゴ選択などに完全にオープンなアプローチを採用するという、Oracleの選択したJakarta EEの方向性そのものなのです。

MicroProfileが大きな影響力を発揮できるのは、リリース戦略と、実運用経験に基づいた迅速なイノベーションに関してです。Java EEでは従来、複数年単位のメジャープラットフォームリリースを中心に置いていましたが。MicroProfileでは、市場へのより迅速な適応と開発者への新機能の早期提供を目的として、斬新的な改善を伴った四半期リリースを行うことで成功を収めています。Jakarta EEでは独自のリリース戦略を策定する予定なので、MicroProfileでの経験とその成功を活用することが可能です。

Tomitribeの創業者でCEOのDavid Blebvins氏は言う。

IBMやRed Hat、Payaraといった企業とともにMircoProfileを開発したことは、Tomitribeの歴史と私自身のキャリアにおいて最も誇らしく、楽しい時間のひとつでした。OracleはTomitribeが注目を集め、貢献する機会を与えることで、一貫して私たちをサポートしてくれました。私たちは互いを尊敬し合い、その成功を心から願っています。OpenLibertyがリリースされた時、私は元IBMとして、それを応援しツイートする群衆の中にいました。私たちがJavaOne 2011でApache TomEEを発表した時、Red Hatチームが初めてそれを祝ってくれました。

フレンドリとは言えない競合が行われた時代が、私たちの業界にはありました。相手を卑下する発言やネットワーク炎上、偽の草の根運動(astroturfing)などは日常茶飯事でした。イノベーションがゼロサムゲームであると誤認されていた、若くてナイーブな業界としては、これが普通の事だったのでしょう。私たちはラインを引くことよりも、イノベーションに時間を費やしたいと思っています。本当のイノベーションは、皆が最高のものを出し合うことで実現するのです。

Payaraの創設者兼ディレクタであるSteve Millidge氏は、InfoQに次のように語っている。

MicroProfileとJakarta EEに挑戦する小さな企業としての私を驚かせたのは、大手企業が極めてオープンで、私たちと台頭の立場で仕事をしてくれることです。MicroProfileとJakarta EEでの開発は、その性質上、委員会や電話会議、コンセンサスと関わっています。これには大変な時間が必要で、時にはフラストレーションを感じることもありますが、すべての企業からの参加者が一致団結して、有用で革新的で一貫性を持ったAPIの将来に向けて進んでいます。

Eclipse Foundationで活動するということは、その優れたオープンソースの活動規則の下で、小企業や個人が大企業と対等の立場で参加し、活躍できることを意味します。標準ベースの次世代クラウドネイティブAPIがどのように進化するのか、興味のある企業や個人であれば、ぜひ参加して頂きたいと思います。両手を広げて歓迎します。

Javaエバンジェリストとして有名な、AxonIQのシニアバイスプレジデントのReza Rahman氏にも、Java EEガーディアンとしての経験について話を聞くことができた。

正直なところ、少なくともJava EE 5とJava EE 6の時代にコントリビューションを初めた頃から、Java EEコミュニティとは強い協力関係を続けています。私が見た限りでは、コミュニティはプロフェッショナルの雰囲気を保っていて、建設的な反対意見や合理的な妥協をし、新参者を快く受け入れるという点で、常にすばらしい存在でした。そのニーズが明らかなった時、ガーディアンを生み出すことができたのは、このような背景があったからです。

現在大きく変わったのは、所有権やロードマップ、機能、デリバリの面において、それまで長く存在したOracle(それ以前はSun)による一方的な影響力がなくなったことです。中央集権的な推進母体が実際には必要ないということを、MicroProfileコミュニティは証明しました。さらにMicroProfileの仲間たちは、ベンダによるコラボレーションと機能提供が短期間で可能であることも実証しています。過去にJava EEで私たちが経験した低迷は、Sun/Oracleによる投資とコミットメントレベルの結果であったと思わざるを得ません。Jakarta EEの下でオープンになったTCKも、間違いなく大きなメリットです。

Eclipse Foundationでの現在の状況が続くことで、これらすべてがJakarta EEにとってうまくいくことを期待しています。

リソース

• “What Can Reactive Streams Offer Jakarta EE?” 、James Roper (2018/2/6)
• “In Support of Jakarta EE's Quest to Accelerate Cloud Native Java”、Mark Brewer (2018/4/24)
• “Lightbend Podcast: Why Lightbend Joined the Eclipse Foundation's Jakarta EE Working Group”、Oliver White (2018/5/7)
• “Jakarta EEに関わるEE4J活動の最新情報”、InfoQ (2018/5/15)
• “Jakarta EE Progress to Date”、Mike Milinkovich (2018/5/24)
• “A First Look at Jakarta EE”、Roxanne Joncas (2018/5/31)