KivaKitの紹介
1. 概要
KivaKit は、マイクロサービスとアプリケーションの開発をより迅速かつ簡単にするために設計されたモジュラーJavaアプリケーションフレームワークです。 KivaKitは2011年からTelenavで開発されています。 GitHubでApacheライセンスのオープンソースプロジェクトとして利用できるようになりました。
この記事では、連携して機能する「ミニフレームワーク」のコレクションとしてのKivaKitの設計について説明します。 さらに、各ミニフレームワークの基本的な機能についても見ていきます。
2. KivaKitミニフレームワーク
kivakitおよびkivakit-extensionsリポジトリを見ると、KivaKit1.0には54個のモジュールが含まれていることがわかります。 これは圧倒的でした。 しかし、一歩ずつ進めば、それほど悪くはありません。 手始めに、プロジェクトに含めるものを選択できます。 KivaKitの各モジュールは、単独で使用するように設計されています。
一部のKivaKitモジュールには、ミニフレームワークが含まれています。 ミニフレームワークは、一般的な問題に対処するシンプルで抽象的なデザインです。 KivaKitのミニフレームワークを調べると、それらが単純で広く適用可能なインターフェイスを備えていることがわかります。 結果として、それらはレゴ™に少し似ています。 つまり、それらは互いにスナップする単純なピースです。
ここでは、KivaKitのミニフレームワークとそれらが互いにどのように関連しているかを確認できます。
ミニフレームワーク | モジュール | 説明 |
---|---|---|
応用 | kivakit-アプリケーション | アプリケーションとサーバーの基本コンポーネント |
コマンドライン解析 | kivakit-コマンドライン | 変換と検証のミニフレームワークを使用したスイッチと引数の解析 |
成分 | kivakit-コンポーネント | アプリケーションを含むKivaKitコンポーネントを実装するための基本機能 |
変換 | kivakit-カーネル | 堅牢なモジュラータイプのコンバーターを実装するための抽象化 |
抽出 | kivakit-カーネル | データソースからのオブジェクトの抽出 |
インターフェース | kivakit-カーネル | フレームワーク間の統合ポイントとして使用される汎用インターフェース |
ロギング | kivakit-カーネル kivakit-ログ-* |
コアロギング機能、ログサービスプロバイダーインターフェイス(SPI)、およびログの実装 |
メッセージング | kivakit-カーネル | コンポーネントがステータス情報を送受信できるようにします |
Mixins | kivakit-カーネル | ステートフル特性の実装 |
リソース | kivakit-リソース kivakit-ネットワーク-* kivakit-ファイルシステム-* |
ファイル、フォルダー、およびストリーミングされたリソースの抽象化 |
サービスロケーター | kivakit-構成 | コンポーネントと設定情報を検索するためのサービスロケーターパターンの実装 |
設定 | kivakit-構成 | コンポーネント構成情報への簡単なアクセスを提供します |
検証 | kivakit-カーネル | オブジェクトの整合性をチェックするための基本機能 |
これらのフレームワークは、kivakitリポジトリにあります。 一方、 kivakit-extensions には、サービスプロバイダーのような重要性の低いモジュールがあります。
2.1. メッセージング
上の図が示すように、メッセージングは統合の中心点です。 KivaKitでは、メッセージングによってステータスレポートが形式化されます。 Javaプログラマーとして、私たちはログに記録されている情報のステータスに慣れています。 場合によっては、この情報が発信者に返されるか、例外としてスローされることもあります。 対照的に、KivaKitのステータス情報はメッセージに含まれています。これらのメッセージをブロードキャストするコンポーネントを作成できます。 また、リッスンするコンポーネントを作成することもできます。
この設計により、コンポーネントは一貫してステータスのレポートに集中できることがわかります。 コンポーネントにとって、ステータスメッセージが送信される場所は重要ではありません。 あるケースでは、メッセージをロガーに転送する場合があります。 別の方法では、それらを統計に含めることができます。 それらをエンドユーザーに表示することもできます。 コンポーネントは気にしません。 興味があるかもしれない人に問題を報告するだけです。
メッセージをブロードキャストするKivaKitコンポーネントは、1つ以上のメッセージリピーターに接続して、リスナーチェーンを形成できます。
KivaKitでは、アプリケーションは通常リスナーチェーンの終わりです。 したがって、 Application クラスは、受信したすべてのメッセージをログに記録します。 途中で、リスナーチェーンのコンポーネントは、これらのメッセージの他の用途を持つ可能性があります。
2.2. Mixins
KivaKitのもう1つの統合機能は、mixinsミニフレームワークです。 KivaKitミックスインを使用すると、インターフェイスの継承を通じて基本クラスを型に「ミックスイン」できます。ミックスインは、「ステートフル特性」と呼ばれることもあります。
たとえば、KivaKitの BaseComponent クラスは、コンポーネントを構築するための基盤を提供します。 BaseComponent は、メッセージを送信するための便利なメソッドを提供します。 さらに、リソース、設定、および登録済みオブジェクトへの簡単なアクセスを提供します。
しかし、この設計ではすぐに問題が発生します。 ご存知のように、Javaでは、すでに基本クラスを持っているクラスは、BaseComponentを拡張することもできません。 KivaKitミックスインを使用すると、BaseComponent機能を既に基本クラスを持つコンポーネントに追加できます。 例えば:
public class MyComponent extends MyBaseClass implements ComponentMixin { [...] }
ここで、インターフェースComponentMixinがMixinとComponentの両方を拡張していることがわかります。
The 混入しますインターフェイスは州() 方法
2.3. サービスロケーター
サービスロケータークラスRegistryを使用すると、コンポーネントを相互に接続できます。 Registry は、依存性注入(DI)とほぼ同じ機能を提供します。 ただし、1つの重要な点でDIの一般的な使用法とは異なります。 サービスロケーターパターンでは、コンポーネントは必要なインターフェイスにアクセスします。 一方、DIはインターフェイスをコンポーネントにプッシュします。 その結果、サービスロケーターアプローチはカプセル化を改善します。 また、参照の範囲が狭くなります。 たとえば、 Registry は、メソッド内で適切に使用できます。
class MyData extends BaseComponent {
[...]
public void save() {
var database = require(Database.class);
database.save(this);
}
}
The BaseComponent 。 require(Class) ここでのメソッドは、でオブジェクトを検索します
アプリケーションの起動時に、 BaseComponent。registerObject()メソッドの1つを使用してサービスオブジェクトを登録できます。 後で、アプリケーションの他の場所のコードは、 require(Class)でそれらを検索できます。
2.4. リソースとファイルシステム
kivakit-resourceモジュールは、ストリーミングされたリソースの読み取りと書き込み、およびファイルシステムへのアクセスのための抽象化を提供します。KivaKitに含まれるいくつかのより重要なリソースタイプをここで確認できます。
- ファイル(ローカル、Zip、S3、およびHDFS)
- パッケージリソース
- ネットワークプロトコル(ソケット、HTTP、HTTPS、およびFTP)
- 入出力ストリーム
この抽象化から2つの貴重な利点が得られます。 私たちはできる:
- 一貫性のあるオブジェクト指向APIを介してストリーミングされたリソースにアクセスします
- ResourceおよびWritableResourceインターフェースを使用して、不明なリソースタイプを使用できるようにします
2.5. コンポーネント
kivakit-component モジュールを使用すると、一般的な機能にすぐにアクセスできます。 私たちはできる:
- メッセージの送受信
- パッケージとパッケージ化されたリソースにアクセスする
- オブジェクト、コンポーネント、および設定を登録および検索します
Component インターフェースは、 BaseComponentとComponentMixinの両方によって実装されます。その結果、任意のオブジェクトに「コンポーネントの性質」を追加できます。
2.6. ロギング
KivaKitコンポーネントによって形成されるリスナーチェーンは、多くの場合、ロガーで終了します。 ロガーは、受信したメッセージを1つ以上のログに書き込みます。 さらに、 kivakit-kernel モジュールは、 Log を実装するためのサービスプロバイダーインターフェイス(SPI)を提供します。 ロギングミニフレームワークの完全な設計は、UMLここで確認できます。
ロギングSPIを使用して、 kivakit-extensions リポジトリは、いくつかのLog実装を提供します。
プロバイダー | モジュール |
---|---|
ConsoleLog | kivakit-カーネル |
FileLog | kivakit-logs-file |
EmailLog | kivakit-logs-email |
コマンドラインから1つ以上のログを選択して構成できます。 これは、KIVAKIT_LOGシステムプロパティを定義することによって行われます。
2.7. 変換と検証
kivakit-kernelモジュールには、型変換とオブジェクト検証用のミニフレームワークが含まれています。 これらのフレームワークは、KivaKitメッセージングと統合されています。 これにより、問題を一貫して報告できます。 また、使用法を簡素化します。 StringConverterのようなタイプConverterを実装するには、変換コードを記述する必要があります。 例外、空の文字列、またはnull値について心配する必要はありません。
KivaKitの多くの場所で使用されているコンバーターを確認できます。
- スイッチと引数の解析
- プロパティファイルから設定オブジェクトをロードする
- オブジェクトをデバッグ文字列としてフォーマットする
- CSVファイルからのオブジェクトの読み取り
Validatable によってブロードキャストされたメッセージは、検証ミニフレームワークによってキャプチャされます。 その後、それらを分析して、エラー統計と検証の問題に簡単にアクセスできるようにします。
2.8. アプリケーション、コマンドライン、および設定
kivakit-application 、 kivakit-configuration、、および kivakit-commandline モジュールは、アプリケーションを開発するためのシンプルで一貫性のあるモデルを提供します。
kivakit-application プロジェクトは、Application基本クラスを提供します。 アプリケーションはコンポーネントです。kivakit-configurationを使用して設定情報を提供します。さらに、
kivakit-configuration プロジェクトは、 kivakit-resource モジュールを使用して、 .properties リソース(および将来の他のソース)から設定情報をロードします。 kivakit-kernel コンバーターを使用して、これらのリソースのプロパティをオブジェクトに変換します。 変換されたオブジェクトは、検証mini-frameworkで検証されます。
アプリケーションのコマンドライン引数とスイッチは、KivaKitコンバーターとバリデーターを使用してkivakit-commandlineモジュールによって解析されます。 アプリケーションのConsoleLogで発生する問題を確認できます。
2.9. マイクロサービス
これまで、あらゆるアプリケーションに一般的に役立つKivaKitの機能について説明してきました。 さらに、KivaKitは、マイクロサービスを明示的に対象とするkivakit-extensionsの機能も提供します。 kivakit-webを簡単に見てみましょう。
kivakit-webプロジェクトには、マイクロサービスへのシンプルなRESTおよびWebインターフェイスを迅速に開発するためのモジュールが含まれています。 JettyServer クラスは、最小限のサーブレットとフィルターをプラグインする方法を提供します。面倒。 JettyServerで使用できるプラグインは次のとおりです。
プラグイン | 説明 |
---|---|
JettyJersey | RESTアプリケーションのサポート |
JettySwagger | Swagger自動RESTドキュメント |
JettyWicket | ApacheWicketWebフレームワークのサポート |
これらのプラグインを組み合わせて、SwaggerドキュメントとWebインターフェイスを備えたRESTfulマイクロサービスを提供できます。
var application = new MyRestApplication();
listenTo(new JettyServer())
.port(8080)
.add("/*", new JettyWicket(MyWebApplication.class))
.add("/open-api/*", new JettySwaggerOpenApi(application))
.add("/docs/*", new JettySwaggerIndex(port))
.add("/webapp/*", new JettySwaggerStaticResources())
.add("/webjar/*", new JettySwaggerWebJar(application))
.add("/*", new JettyJersey(application))
.start();
KivaKit 1.1には、専用のマイクロサービスミニフレームワークが含まれます。 これにより、マイクロサービスの構築がさらに簡単になります。
3. ドキュメンテーションとLexakai
KivaKitのドキュメントはLexakaiによって生成されます。Lexakai は、UML図を作成し(必要に応じて注釈でガイドされます)、README.mdマークダウンファイルを更新します。 各プロジェクトのreadmeファイルで、Lexakaiは標準のヘッダーとフッターを更新します。 さらに、生成されたUML図とJavadocドキュメントのインデックスを維持します。 Lexakaiは、Apacheライセンスの下で配布されるオープンソースプロジェクトです。
4. KivaKitの構築
KivaKitはJava11以降の仮想マシンを対象としています(ただし、Java 8のソースコードから使用できます)。 KivaKitモジュールのすべてのアーティファクトはMavenCentralにあります。 ただし、KivaKitを変更したり、オープンソースプロジェクトに貢献したりすることもできます。 この場合、それを構築する必要があります。
まず、Git、 Git Flow 、 Java 16 JDK 、およびMaven3.8.1以降をセットアップしましょう。
まず、kivakitリポジトリをワークスペースに複製します。
mkdir ~/Workspace
cd ~/Workspace
git clone --branch develop https://github.com/Telenav/kivakit.git
次に、サンプルのbashプロファイルをホームフォルダーにコピーします。
cp kivakit/setup/profile ~/.profile
次に、〜/ .profileを変更して、ワークスペースとJavaおよびMavenのインストールを指すようにします。
export KIVAKIT_WORKSPACE=$HOME/Workspace
export JAVA_HOME=/Library/Java/JavaVirtualMachines/temurin-16.jdk/Contents/Home
export M2_HOME=$HOME/Developer/apache-maven-3.8.2
プロファイルを設定したら、 bash を実行していることを確認します(macOSでは、 zsh がデフォルトです)。
chsh -s /bin/bash
最後に、ターミナルプログラムを再起動して、次のコマンドを実行します。
$KIVAKIT_HOME/setup/setup.sh
セットアップスクリプトは、kivakit-extensionsおよびその他の関連するリポジトリのクローンを作成します。 その後、git-flowを初期化し、すべてのKivaKitプロジェクトをビルドします。
5. 結論
この記事では、KivaKitのデザインについて簡単に説明しました。 また、それが提供するより重要な機能のいくつかを見学しました。 KivaKitは、マイクロサービスの開発に最適です。 消化しやすく、独立した部分で学習して使用できるように設計されています。