Project Helidon入門 - Oracleの軽量フレームワークによるマイクロサービス開発

原文(投稿日：2020/06/24)へのリンク

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の３つのコアコンポーネントの検討、導入方法とHelidon MP上に構築された映画アプリケーションの紹介を行いたいと思っています。GraalVMや、間もなく登場するHelidon 2.0に期待される機能についても論じます。

Helidonを取り巻く状況

シンプルさと高速性を目標として設計されたHelidonのユニークな点は、Helidon SEとHelidon MPという、２つのプログラミングモデルが提供されていることです。下のグラフには、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というように、２つの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に結び付けられている点に注意してください。

ここまでで、ｗebサーバを起動することができるようになりました！すての仕組みを実装し終わった後、構築された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)という、３つの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などに注目しています。