BT

最新技術を追い求めるデベロッパのための情報コミュニティ

寄稿

Topics

地域を選ぶ

InfoQ ホームページ ニュース Eclipseがバージョン1.4と2.0のMicroProfileをリリース

Eclipseがバージョン1.4と2.0のMicroProfileをリリース

原文(投稿日:2018/08/30)へのリンク

Eclipse Foundationは先頃、APIをアップデートし、包括的なTest Compatibility Kits (TCK)、Maven Coordinates、Javadoc、各APIのGitタグを追加した、MicroProfileバージョン1.4と2.0をリリースした。それぞれJava EE 7およびJava EE 8に完全に準拠する。

MicroProfile 1.4

バージョン1.3からのアップグレードであるバージョン1.4は、一連の1.xリリースの最後となるもので、以下のAPIに対してセキュリティなどが拡張されている。

  • Open Tracing (サーバにコンポーネントタグを追加)。
  • Rest Client (非同期メソッドの追加、他のMicroProfile APIとの統合性の向上)。
  • Fault Tolerance (SPIのアップデート、Metrics APIとの連携)。
  • JWT Propagation (公開鍵設定のサポートを追加)。
  • Config (暗黙的コンバータの改善とセキュリティ更新)。

MicroProfile 1.4はJava EE 7に完全準拠しており、GitHubにコード例が公開されている。

MicroProfile 2.0

開発開始から2年を経たMicroProgile 2.0には、バージョン1.4からのアップグレードの最新バージョンとして、CDIJSON-PJAX-RS APIがアップデートされ、新たなAPIとしてJSON-Bが加えられた。

MicroProfile 2.0はJava EE 8に完全準拠する。新たに導入された機能は次のようなものだ。

  • Java EE 8 APIからの新機能。
  • 使いやすさの向上。
  • CDIベースでプログラムから使用しやすいインターフェイス。
  • API間の統合ポイントの拡大。

MicroProfile 2.0は将来のアップグレードのベースとなる予定で、リリースには次のような説明がある。

Eclipse MicroProfileは、今後もリリース毎に新たな価値を提供し、すべてのコミュニティメンバによる活発な支援を受けて進化し続けます。将来のリリースでは、既存のAPIの更新と合わせて、新たなAPIが追加される予定です。その例として、コミュニティではすでに、次のようなトピックの議論が始まっています。

  • 長期実行アクション
  • リアクティブストリーム
  • リアクティブイベント
  • データアクセス
  • イベントデータ

MicroProfileとJakarta EE

MicroProfileJakarta EEのシナジから、2つのプラットフォームが統合されるのではないかという憶測が浮上している。

MicroProfileアーキテクトであるIBMのKevin Sutter氏は、先日のブログ記事で次のように述べている。

これはフォーラムやカンファレンス、さらにはIBM社内でも耳にする、最も一般的な疑問のひとつです。Eclipse MicroProfileは、いくつかの重要な機能とリリースの積み重ねを通じて、すでに十分に確立していますし、今後のJava EEについては、Eclipse Jakarta EEで決定済みです。この2つをいつか統合するというのは、もはや難しい話です。

これらのEclipseプロジェクトにはいずれもメリットがあり、MicroProfileテクノロジ上に構築されたものがJakarta EEにコントリビュートするという形で、それぞれの領域で進歩を続けています。しかし、プロジェクトそのものを統合することは可能なのでしょうか?個人的意見としては、ノーです。MicroProfileは、かつての小さな存在から、大きく成長しています。新たなコンポーネント機能を加え、バージョンを重ねることによって、エンタープライズJavaプログラミングモデルは、マイクロサービス開発のために拡張されました。この進化が、比較的短期間で実現しているのです – 2年足らずの間に、6回のMircoProfileのメジャーリリースと、16のコンポーネントのリリースが行われています。

この大規模かつ複雑な動きに対して、Jakarta EEにはまだ、その進捗の早さに追随する準備ができていません。また、Jakarta EEではまだ仕様プロセスの定義が完了していないため、MicroProfileの求めるハイペースのリリースサイクルを受け入れる体制が整っていないのです。大きく違うのは、MicroProfileが標準団体になるという意図を持っていないことです。標準ではなく、業界に受け入れられる仕様を開発しているのです。対してJakarta EEは、JCPの標準化手順を、より現代的でオープン、ライトウェイトな実装優先プロセスで置き換えようとしています。

リアクティブプログラミングモデルの取り組みでは、最終的にJakarta EEをターゲットにしています。Lightbendのチームはこれまで、自らのリアクティブプログラミングの考え方を、エンタープライズJavaの世界に導入する最善の方法を模索してきました。その結果、MicroProfileコンポーネントを開発することが、作業を迅速に進める上で最も手短な方法だと判断したのです。

Jakarta EEに比較的新しく参加したメンバであるLightbendは、先頃、Lagomマイクロサービスフレームワークの開発メンバのひとりである、同社シニアデベロッパのJames Roper氏を、MicroProfileチームでLightbendを代表する最初のコントリビュータとして指名した。先日のInfoQとのインタビューでは、MicroProfileへのコントリビューションの計画について、氏は次のように述べている。

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

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

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

ITコンサルタントでソフトウェア開発者、アーキテクトのSebastian Daschner氏は先日のブログ記事に、次のように記している。

その誕生以来、MicroProfileは多くの支持を受けながら、さまざまな仕様を生み出してきました。元々はマイクロサービスの世界のために、高度なエンタープライズJavaを作り出すことが目的でしたが、多くのベンダの協力の下で急速に発展しました。Eclipse FoundationのもとでJava EEがJakarta EEに移行した今、MicroProfileはエンタープライズJavaの世界において、その全体像にどのように適応していくのでしょうか?

一般論としては、Java Enterpriseコミュニティが、MicroProfileの将来的なあり方について、明確かつ共通のイメージを持つことが重要になります。次のステップとしては、Jacarta EEのインキュベータとしてのMicroProfileという考え方を追求するために、次のようなことを定義し、合意する必要があります。

  • Jacarta EEとMircoProfileが技術デザイン上の原則を共有すること。
  • MicroProfileをインキュベートするためのネーミング、ブランディング、ネームスペース。
  • MicroProfileプロジェクトの将来とJakarta EEのインキュベーションのための共通プロセス。

リソース

 
 

この記事を評価

採用ステージ
スタイル
 
 

この記事に星をつける

おすすめ度
スタイル

BT