キーポイント
- Helidon is a lightweight microservices framework introduced by Oracle in September 2018.
- Helidon is a collection of Java libraries designed for creating microservices-based applications.
- Helidon was designed to be simple and fast and ships with two versions: Helidon SE and Helidon MP.
- Helidon supports GraalVM to convert Helidon SE applications to native executable code.
- In this tutorial, you will be introduced to Helidon, explore Helidon SE and Helidon MP, and download GitHub repositories related to the content in this tutorial.
- Helidon 1.4.4 is the current stable release, but Helidon 2.0 is scheduled to be released in late Spring 2020.
Oracleは2018年9月、オープンソースのフレームワークProject Helidonを新たに公開しました。元々はJ4C(Java for Cloud)という名称であったHelidonは、マイクロサービスベースのアプリケーションを開発するためのJavaライブラリのコレクションです。公開から6ヶ月内の2019年2月には、Helidon 1.0がリリースされています。現在の安定版リリースはHelidon 1.4.4ですが、Oracleは現在、2020年晩春に計画されているHelidon 2.0のリリースに向けて順調に開発を進めています。
このチュートリアルではHelidon SEとHelidon MPの紹介、Helidon SEの3つのコアコンポーネントの検討、導入方法とHelidon MP上に構築された映画アプリケーションの紹介を行いたいと思っています。GraalVMや、間もなく登場するHelidon 2.0に期待される機能についても論じます。
Helidonを取り巻く状況
シンプルさと高速性を目標として設計されたHelidonのユニークな点は、Helidon SEとHelidon MPという、2つのプログラミングモデルが提供されていることです。下のグラフには、Helidon SEとHelidon MPを他のマイクロサービスフレームワークと比較した場合の位置付けが示されています。
Helidon SE
Helidon SEは、マイクロサービスの開発に必要な3つのコアコンポーネント — webサーバ、コンフィギュレーション、セキュリティ — を備えた、マイクロサービスベースのアプリケーション開発のためのマイクロフレームワークです。アプリケーションサーバを必要としない、リアクティブでシンプルでトランスペアレントな、関数スタイルの小さなAPIです。
Helidon SEの関数スタイルを、WebServer
インターフェースを使ってHelidon Webサーバを起動するという、ごく単純な例を使って見ていきましょう。
WebServer.create(
Routing.builder()
.get("/greet", (req, res)
-> res.send("Hello World!"))
.build())
.start();
この例を出発点に、ダウンロード用サーバアプリケーションの一部として、本当のstartServer()
メソッドを段階的に開発する中で、Helidon SEの3つのコアコンポーネントを探っていきたいと思います。
webサーバコンポーネント
NodeJSや他のJavaフレームワークにヒントを得たHelidonのWebサーバコンポーネントは、Netty上で動作する非同期かつリアクティブなAPIです。WebServer
インターフェースは、基本的なサーバのライフサイクルに加えて、コンフィギュレーションの可能な監視機能、ルーティング、エラー処理、メトリクスと状態監視に関するエンドポイントの構築機能を提供します。
それではstartServer()
メソッドの最初のバージョンから始めましょう。このバージョンでは、ランダムなポート上でHelidonのwebサーバを起動します。
private static void startServer() {
Routing routing = Routing.builder()
.any((request, response) -> response.send("Greetings from the web server!" + "\n"))
.build();
WebServer webServer = WebServer
.create(routing)
.start()
.toCompletableFuture()
.get(10, TimeUnit.SECONDS);
System.out.println("INFO: Server started at: http://localhost:" + webServer.port() + "\n");
}
まず最初に、ルーティングルールを備えたHTTP要求-応答処理を提供するために、Routing
インターフェースを構築する必要があります。この例では "any()
"メソッドを使って、要求を定義済の応答 "Greeting from web server!"にルーティングします。この応答がcurl
コマンドを経由してブラウザ上に表示されるのです。
webサーバの構築では、さまざまなサーバコンフィギュレーションを受容できるように設計された、create()
のオーバーロード版が起動されます。上に挙げた最も単純な例では、デフォルトのサーバコンフィギュレーションを提供するように作られた、インスタンス変数routing
を受け入れています。
Helidon webサーバはリアクティブに設計されています。すなわち、start()
メソッドがリターンして、webサーバをスタートさせるCompletionStage<WebServer>
インターフェースのインスタンスを返すので、これを使ってtoCompletableFuture()
メソッドを起動することが可能になります。サーバの使用するポートは定義されていないので、スタートアップ時に使用可能なポートをサーバがランダムに探します。
Mavenを使用して、このサーバアプリケーションをビルドして実行しましょう。
$ mvn clean package
$ java -jar target/helidon-server.jar
サーバが起動すると、次のようなメッセージがターミナルウィンドウに表示されるはずです。
Apr 15, 2020 1:14:46 PM io.helidon.webserver.NettyWebServer <init>
INFO: Version: 1.4.4
Apr 15, 2020 1:14:46 PM io.helidon.webserver.NettyWebServer lambda$start$8
INFO: Channel '@default' started: [id: 0xcba440a6, L:/0:0:0:0:0:0:0:0:52535]
INFO: Server started at: http://localhost:52535
最後の行にあるように、Helidon webサーバはポート52535を選択しました。サーバの実行中に、このURLをブラウザに入力するか、あるいは別のターミナルウィンドウで以下のcurl
コマンドを実行してください。
$ curl -X GET http://localhost:52535
同じく "Greeting from the web server!"と表示されるはずです。
Webサーバをシャットダウンするには、このコード行を単に追加すればよいのです。
webServer.shutdown()
.thenRun(() -> System.out.println("INFO: Server is shutting down...Good bye!"))
.toCompletableFuture();
コンフィギュレーションコンポーネント
コンフィギュレーションコンポーネントは、コンフィギュレーションプロパティのロードと処理を行います。HelidonのConfig
インターフェースは、定義されたプロパティファイルからコンフィギュレーションプロパティを読み込みます。プロパティファイルは一般的にYAMLフォーマットで記述します(他の形式も可能)。
それでは、アプリケーション、サーバ、セキュリティのコンフィギュレーションを提供するapplication.yaml
ファイルを作成しましょう。
app:
greeting: "Greetings from the web server!"
server:
port: 8080
host: 0.0.0.0
security:
config:
require-encryption: false
providers:
— http-basic-auth:
realm: "helidon"
users:
— login: "ben"
password: "${CLEAR=password}"
roles: ["user", "admin"]
— login: "mike"
password: "${CLEAR=password}"
roles: ["user"]
— http-digest-auth:
このapplication.yaml
ファイルの中には、app
、server
、security
という、3つのおもなセクション、あるいはノードがあります。最初の2つは簡単です。greeting
サブノードは、先程の例でハードコードしていたサーバの応答を定義しています。port
サブノートは、起動時にWebサーバが仕様するポート8080を定義します。注目して頂きたいのはsecurity
ノードです。こちらはもう少し複雑で、YAMLのマッピングシーケンスを使って複数のエントリを定義しています。http-basic-auth
とhttp-digest-auth
という2つのセキュリティプロバイダと、ben
とmike
という2人のユーザが、'-
'文字で区切られて定義されています。この詳細については後ほど、セキュリティコンポーネントのセクションで詳しく説明します。
もうひとつ、このコンフィギュレーションでは、config.require-encryption
サブシーケンスをfalse
にセットすることで、クリアテキストによるパスワードを可能にしている点にも注意してください。当然のことですが、運用環境ではこれをtrue
に設定して、クリアテキストによるパスワードを渡された場合には例外をスローする必要があります。
実行可能なコンフィギュレーションファイルができたので、startServer()
メソッドをアップデートして、定義したコンフィギュレーションを利用できるようにしましょう。
private static void startServer() {
Config config = Config.create();
ServerConfiguration serverConfig = ServerConfiguration.create(config.get("server"));
Routing routing = Routing.builder()
.any((request, response) -> response.send(config.get("app.greeting").asString().get() + "\n"))
.build();
WebServer webServer = WebServer
.create(serverConfig, routing)
.start()
.toCompletableFuture()
.get(10, TimeUnit.SECONDS);
System.out.println("INFO: Server started at: http://localhost:" + webServer.port() + "\n");
}
まず最初に、コンフィギュレーションファイルを読み込むために、Config
インターフェースのcreate()
メソッドをコールして、そのインスタンスを生成する必要があります。Config
が提供するget(String key)
は、コンフィギュレーションファイルから、key
で指定したノードないし特定のサブノートを返します。例えばconfig.get("server")
はserver
ノード下のコンテンツを、config.get("app.greeting")
は"Greeting from the web server!"を返します。
次に、イミュータブルなWebサーバ情報を提供するServerConfiguration
のインスタンスを、config.get("server")
のステートメントをcreate()
メソッドに渡すことで生成します。
インスタンス変数routing
は、ハードコードしていたサーバ応答をconfig.get("app.greeting").asString().get()
をコールして取得するようにした以外は、前回の例と同じ方法で構築しています。
webサーバも前回と同じように生成していますが、serverConfig
とrouting
という、2つのインスタンス変数を受け取るバージョンのcreate()
メソッドを使用しています。
このバージョンのwebサーバアプリケーションも、同じMavenおよびJavaコマンドを使ってビルドし、実行することができます。同じcurl
コマンドを実行すれば、
$ curl -X GET http://localhost:8080
同じく "Greeting from the web server!"と表示されるはずです。
セキュリティコンポーネント
Helidonのセキュリティコンポーネントは認証、承認、監査、アウトバウンドセキュリティを提供します。数多くのセキュリティプロバイダの実装がサポートされており、Helidonアプリケーションで使用することができます。
- HTTP Basic認証
- HTTP Digest認証
- HTTP Signature
- 属性ベースアクセス制御(ABAC)認証
- JWTプロバイダ
- ヘッダアサーション
- Googleログイン認証
- OpenID Connect
- IDCSロールマッピング
Helidonアプリケーションにセキュリティを実装するには、3つのアプローチのひとつを選択することが可能です。
- 手作業でコンフィギュレーションを提供するビルダパターン
- コンフィギュレーションファイル経由でコンフィギュレーションを提供するコンフィギュレーションパターン
- ビルダパターンとコンフィギュレーションパターンのハイブリッド
今回のアプリケーションではハイブリッドアプローチを使用してセキュリティを実装しますが、その前にいくつかの準備作業をしなければなりません。
コンフィギュレーションのsecurityノード以下に定義されたユーザを参照する方法について、もう一度見てみましょう。次の文字列を見てください。
security.providers.0.http-basic-auth.users.0.login
パーザは文字列の中に数字を見つけると、コンフィギュレーションファイルの中に一つ以上のサブノードのあることを認識します。この例では、providers
直後の0
が、最初のproviderサブノートにあるhttp-basic-auth
を参照するようにパーザに指示します。users
直後にある0
は、login
、password
、roles
を含む最初のuserサブノートを参照するように指示しています。従って、上記の文字列をconfig.get()
メソッドに渡した場合、ユーザben
のログイン、パスワード、ロール情報が返されることになります。同じように、ユーザmike
のログイン、パスワード、ロール情報は、この文字列で取り出せます。
security.providers.0.http-basic-auth.users.1.login
次に、webサーバアプリケーションに新たなクラスAppUser
を作って、SecureUserStore.User
インターフェースを実装します。
public class AppUser implements SecureUserStore.User {
private String login;
private char[] password;
private Collection<String> roles;
public AppUser(String login, char[] password, Collection<String> roles) {
this.login = login;
this.password = password;
this.roles = roles;
}
@Override
public String login() {
return login;
}
@Override
public boolean isPasswordValid(char[] chars) {
return false;
}
@Override
public Collection<String> roles() {
return roles;
}
@Override
public Optional<String> digestHa1(String realm, HttpDigest.Algorithm algorithm) {
return Optional.empty();
}
}
このクラスを使って、次のように、ロールからユーザへのマップを構築します。
Map<String, AppUser> users = new HashMap<>();
これを実現するために、コンフィギュレーションファイルのhttp-basic-auth
サブセクションから、コンフィギュレーションを使ってマップにデータを格納する新しいメソッドgetUsees()
を、webサーバアプリケーションに追加します。
private static Map<String, AppUser> getUsers(Config config) {
Map<String, AppUser> users = new HashMap<>();
ConfigValue<String> ben = config.get("security.providers.0.http-basic-auth.users.0.login").asString();
ConfigValue<String> benPassword = config.get("security.providers.0.http-basic-auth.users.0.password").asString();
ConfigValue<List<Config>> benRoles = config.get("security.providers.0.http-basic-auth.users.0.roles").asNodeList();
ConfigValue<String> mike = config.get("security.providers.0.http-basic-auth.users.1.login").asString();
ConfigValue<String> mikePassword = config.get("security.providers.0.http-basic-auth.users.1.password").asString();
ConfigValue<List<Config>> mikeRoles = config.get("security.providers.0.http-basic-auth.users.1.roles").asNodeList();
users.put("admin", new AppUser(ben.get(), benPassword.get().toCharArray(), Arrays.asList("user", "admin")));
users.put("user", new AppUser(mike.get(), mikePassword.get().toCharArray(), Arrays.asList("user")));
return users;
}
新しい機能がwebサーバアプリケーションに加わったので、startServer()
メソッドをアップデートして、HelidonのHTTP Basic認証の実装にセキュリティを追加しましょう。
private static void startServer() {
Config config = Config.create();
ServerConfiguration serverConfig = ServerConfiguration.create(config.get("server"));
Map<String, AppUser> users = getUsers(config);
displayAuthorizedUsers(users);
SecureUserStore store = user -> Optional.ofNullable(users.get(user));
HttpBasicAuthProvider provider = HttpBasicAuthProvider.builder()
.realm(config.get("security.providers.0.http-basic-auth.realm").asString().get())
.subjectType(SubjectType.USER)
.userStore(store)
.build();
Security security = Security.builder()
.config(config.get("security"))
.addAuthenticationProvider(provider)
.build();
WebSecurity webSecurity = WebSecurity.create(security)
.securityDefaults(WebSecurity.authenticate());
Routing routing = Routing.builder()
.register(webSecurity)
.get("/", (request, response) -> response.send(config.get("app.greeting").asString().get() + "\n"))
.get("/admin", (request, response) -> response.send("Greetings from the admin, " + users.get("admin").login() + "!\n"))
.get("/user", (request, response) -> response.send("Greetings from the user, " + users.get("user").login() + "!\n"))
.build();
WebServer webServer = WebServer
.create(serverConfig, routing)
.start()
.toCompletableFuture()
.get(10, TimeUnit.SECONDS);
System.out.println("INFO: Server started at: http://localhost:" + webServer.port() + "\n");
}
先程の例と同じように、インスタンス変数config
とserverConfig
を構築しています。次に、上に示したgetUsers()
メソッドを使って、ロールからユーザへのマップであるusersを構築します。
store
インスタンス変数はSecureUserStore
インターフェースから、null型安全性のためにOptional
を使用した上で、例で示したようなラムダ式として生成されます。セキュアなユーザストアは、HTTP Basic認証とHTTPダイジェスト認証の両方で使用されます。SSLを使用しても、パスワードを要求されないHTTP Basic認証は安全でない場合がある、という点は理解しておいてください。
ここまでで、SecurityProvider
インターフェースの実装クラスのひとつである、HTTPBasicAuthProvider
のインスタンスを生成する準備ができました。そのrealm()
メソッドには、認証されない場合にブラウザ(あるいは他の任意のクライアント)に送信されるセキュリティレルム(security realm)名が定義されています。今回はコンフィギュレーションファイルにリルムを定義しているので、それがメソッドに渡されます。subjectType()
メソッドは、セキュリテイプロバイダが抽出ないし伝搬するプリンシパルタイプを定義しています。このメソッドは、USER
やSERVICE
というように、2つのSubjectType
列挙型を受け入れます。userStore()
メソッドは、アプリケーションのユーザ検証用に構築したstore
インスタンス変数を受け入れます。
このprovider
インスタンス変数を使えば、Security
クラスのインスタンスを構築して、セキュリティのブートストラップや他フレームワークに統合することが可能になります。これを実際に行うには、config()
メソッドとaddAuthenticationProvider()
メソッドを使用します。addAuthenticationProvider()
メソッドを使ってチェーンすることによって、複数のセキュリティプロバイダを登録可能である点にも注目してください。例えばここで、HttpBasicAuthProvider
クラスとHttpDigestAuthProviderクラスそれぞれのインスタンス変数として、basicProvider
とdigestProvider
があるとしましょう。次のようにして、security
インスタンス変数を構築することが可能です。
Security security = Security.builder()
.config(config.get("security"))
.addAuthenticationProvider(basicProvider)
.addAuthenticationProvider(digestProvider)
.build();
WebSecurity
クラスはService
インターフェースを実装して、一連のルーティングルールや関連ロジックをカプセル化しています。create()
メソッドにsecurity
インスタンス変数を渡してインスタンス変数webSecurity
を生成し、securityDefaults()
メソッドに渡されたWebSecurity.authentic()
メソッドによって、要求が認証プロセスを通過することを保証します。
これまでの2つの例で生成したおなじみのrouting
インスタンス変数は、今回はかなり様子が違っていて、webSecurity
インスタンス変数を登録した上で、get()
メソッドを連ねることで、'/
'、'/admin
'、'user
'というエンドポイントを定義しています。/admin
、/user
という2つのエンドポイントが、それぞれユーザben
とmike
に結び付けられている点に注意してください。
ここまでで、webサーバを起動することができるようになりました!すての仕組みを実装し終わった後、構築されたwebサーバは、以前の例とまったく同じように見えます。
同じMavenコマンドとJavaコマンドを使って今回のwebサーバアプリケーションを構築すれば、次のcurl
コマンドで起動することが可能になります。
$ curl -X GET http://localhost:8080/
を実行すれば、 “Greetings from the web server!" が表示されます。
$ curl -X GET http://localhost:8080/admin
を実行すれば、“Greetings from the admin, ben!" が表示されます。
$ curl -X GET http://localhost:8080/user
を実行すれば、“Greetings from the user, mike!" が表示されます。
ここで検討した3つのHelidon SEコアコンポーネントに関連するstartServer()
メソッドの全バージョンを紹介した包括的なサーバアプリケーションや、Helidonの他のセキュリティプロバイダの実装方法を示したセキュリティの実装例も用意されています。
Helidon MP
Helidon SE上に構築されたHelidon MPは、MicroProfile仕様を実装したコンパクトな宣言型APIで、マイクロサービスベースのアプリケーションを開発するために、Javaを マイクロサービスアーキテクチャに最適化するプラットフォームです。IBM、Red Hat、Payara、Tomitribeのコラボレーションとして2016年に結成されたMicroProfileイニシアティブは、マイクロサービスアプリケーション開発に必要な最小限のAPIとして、CDI(JSR 365)、JSON-P(JSR 374)、JAX-RS(JSR-370)という、3つのAPIを規定することから始まりました。それ以来、MicroProfileは12のコアAPIへと拡張されるとともに、リアクティブストリームとGraphQLをサポートする4つの独立APIを加えています。2020年2月にリリースされたMicroProfile 3.3が最新バージョンですが、
Helidon MPでは現在、MicroProfile 3.2をサポートしています。Java EE/Jakarta EE開発者にとってHelidon MPは、使い慣れた宣言型アプローチやアノテーションの使用という面で優れた選択肢になります。しかも、デプロイメントモデルやJava EEパッケージングなどの必要はありません。
Helidon MPの宣言型について、Helidon webサーバを起動するごく単純な例を使って、Helidon SEの機能型定義と比較してみましょう。
public class GreetService {
@GET
@Path("/greet")
public String getMsg() {
return "Hello World!";
}
}
Helidon SEの機能型と比較して、スタイルの違いに注目してください。
Helidonのアーキテクチャ
Helidon SEとHelidon MPを紹介したので、この2つがどのように組み合わされるのかを見てみましょう。Helidonのアーキテクチャは下図のように表現することができます。Helidon MPはHelidon SEの上に構築されており、次章で説明するCDI Extensionは、Helidon MPのクラウドネイティブな機能を拡張するものです。
CDI Extensions
Helidonにはさまざまなデータソースやトランザクションやクライアントとの統合をサポートして、Helidon MPアプリケーションのクラウドネイティブな機能を拡張する、CDI(Context and Dependency Injection) Extensionとして、以下のエクステンションが提供されています。
- HikariCP — "ゼロオーバーヘッド"を実現した、運用レベルのJDBCコネクションプールデータソース
- Oracle Universal Connection Datapool (UCP) データソース
- Jedis — コンパクトなRedis Javaクライアント
- Oracle Cloud Infrastructure (OCI) オブジェクトストレージクライアント
- Java Transactional API (JTA) トランザクション
Helidonクイックスタートガイド
Helidon SEとHelidon MPには、それぞれクイックスタートガイドが用意されています。それぞれのページを参照して、インストラクションに従ってください。例えば、以下のMavenコマンドをターミナルウィンドウで実行するだけで、Helidon SEアプリケーションを構築することができます。
$ mvn archetype:generate -DinteractiveMode=false \
-DarchetypeGroupId=io.helidon.archetypes \
-DarchetypeArtifactId=helidon-quickstart-se \
-DarchetypeVersion=1.4.4 \
-DgroupId=io.helidon.examples \
-DartifactId=helidon-quickstart-se \
-Dpackage=io.helidon.examples.quickstart.se
これによって、小規模ながら実際に動作するアプリケーションが、helidon-quickstart-se
フォルダ下に生成されます。その中には、アプリケーションのテストとコンフィギュレーションファイル(application.yaml
)、ロギング(logging.properties
)、GraalVMを使用したネイティブイメージの構築(native-image.properties)
、Dockerを使用したアプリケーションのコンテナ化(Dockerfile
とDockerfile.native
)、Kubernetesによるオーケストレーション(app.yaml
)が含まれています。
同じように、Helidon MPアプリケーションの構築も可能です。
$ mvn archetype:generate -DinteractiveMode=false \
-DarchetypeGroupId=io.helidon.archetypes \
-DarchetypeArtifactId=helidon-quickstart-mp \
-DarchetypeVersion=1.4.4 \
-DgroupId=io.helidon.examples \
-DartifactId=helidon-quickstart-mp \
-Dpackage=io.helidon.examples.quickstart.mp
ここで生成されたアプリケーションは、次章で紹介するような、より複雑なHelidonアプリケーションを開発するための出発点として利用できます。
映画アプリケーション
クイックスタートで生成されたHelidon MPアプリケーションにクラス — POJO、リソース、リポジトリ、独自の例外(exception)、ExceptionMapper
の実装 — を追加して、Quentin Tarantino氏の映画リストを管理する完全な映画アプリケーションを開発します。以下に示すHelidonApplication
クラスに、必要なクラスを登録します。
@ApplicationScoped
@ApplicationPath("/")
public class HelidonApplication extends Application {
@Override
public Set<Class> getClasses() {
Set<Class> set = new HashSet<>();
set.add(MovieResource.class);
set.add(MovieNotFoundExceptionMapper.class);
return Collections.unmodifiableSet(set);
}
}
アプリケーションの詳細は、GitHubリポジトリをクローンして確認してください。
GraalVM
Helidonは、アプリケーションをネイティブ実行コードに変換する、複数言語対応の仮想マシンおよびプラットフォームのGraalVMをサポートしています。Oracle Labsの開発したGraalVMは、Javaで記述されたジャストインタイムコンパイラのGraal、Javaアプリケーションを実行イメージにアヘッドオブタイムコンパイルできるフレームワークのSubstrateVM、言語インタプリタ開発用のオープンソースのツールキットおよびAPIのTruffleで構成されています。最新バージョンは20.1.0です。
GraalVMのgu
ユーティリティを使って別途インストール可能なnative-image
ユーティリティを使用すれば、Helidon SEアプリケーションをネイティブ実行コードに変換することができます。
$ gu install native-image
$ export
GRAALVM_HOME=/usr/local/bin/graalvm-ce-java11-20.1.0/Contents/Home
インストールが終了すれば、先程のhelidon-quickstart-se
ディレクトリに戻って、次のコマンドを実行することが可能になります。
$ mvn package -Pnative-image
この処理には数分を要しますが、一度終了すれば、アプリケーションはネイティブコードに変換されています。実行ファイルは/target
ディレクトリの下にあります。
Helidon 2.0に向けて
Helidon 2.0.0は2020年晩春のリリースが予定されており、現在はHelidon 2.0.0.RC1が開発者向けに提供されています。注目の新機能としては、Helidon MPアプリケーションのGraalVMサポート、新コンポーネントのwebクライアントとDBクライアント、新しいCLIツール、スタンドアロンのMicroProfile Reactive Messagingの実装、Reactive Streams Operatiors APIなどがあります。
これまでは、MicroProfileのコアAPIであるCDI 2.0(JSR 365)でリフレクションが使用されていたため、GraalVMを活用できるのはHelidon SEアプリケーションのみに限られていました。しかしながら、カスタマの要求に応えるため、Helidon 2.0.0ではHelidon MPアプリケーションのネイティブイメージへの変換がサポートされます。この新機能をJavaコミュニティにプレビューするために、Oracleがデモアプリケーションを用意しています。
オリジナルにある3つのHelidon SEコアAPI — Webサーバ、コンフィギュレーション、セキュリティ — を補完するwebクライアントAPIが新たに加わり、Helidon SEのAPIセットが完結します。WebClient
インターフェースのインスタンスを構築することで、指定したエンドポイントに関連するHTTPリクエストとレスポンスの処理が可能になります。webサーバAPIと同様、webクライアントもコンフィギュレーションファイルによる設定が可能です。
間もなく登場するHelidon 2.0.0 GAリリースについては、開発者向けの詳細資料で確認することができます。
著者について
Michael Redlich氏は、ニュージャージー州クリントンにあるExxonMobil Research & Engineeringのシニアリサーチテクニシャンで、過去30年間、科学実験室およびWebアプリケーションの開発に携わっています。また、Ai-Logix, Inc(現在はAudioCodes)のテクニカルサポートエンジニアとして、カスタマにテクニカルサポートとテレフォニーアプリケーション開発を提供した経験も持っています。オブジェクト指向設計および分析、リレーショナルデータベースの設計と開発、コンピュータセキュリティ、C/C++、Java、Python、その他プログラミングおよびスクリプト言語などが氏の専門分野です。現在はMicroProfile、Jakarta EE、Helidon、Micronaut、MongoDBなどに注目しています。