Textus Samples 01: 最小実行モデル
前提
本記事では、📄 Textus Samples: Launcherとインストール の手順で準備した環境を使います。
-
textus-tutorial-0.1.3を展開済み -
cozy/cncf/textuslauncher をインストール済み -
各 launcher の runtime を確認済み
download 手順は前提記事で扱っているため、ここでは再掲しません。
学ぶこと
-
CNCF (Cloud Native Component Framework) engine selector の基本形
-
development classpath と runtime builtin surface の違い
概念の焦点
-
Component は runtime に登録される単位、Service は操作のまとまり、Operation は実行される振る舞い (Behavior)です。
-
通常の edit/run loop では、sample directory を
--project-dev .で明示して開発中 project として読み込みます。
サンプルディレクトリ
samples/01-minimal
samples/01.a-invocation-source-lab
samples/01.b-startup-shapes-lab
samples/01.c-builtin-and-help-labプログラム
01-minimal の最小 component は、 component.d/minimal.md に定義されています。
# minimal
## Service
- `main`
## Operation
- `hello`
## Behavior
- prints `Hello CNCF`この定義では、component 名が minimal 、service 名が main 、operation 名が hello です。したがって、CLI から呼び出す selector は minimal.main.hello になります。
実行用の run.sh は、上記の selector を cncf dev command に渡すだけの小さな wrapper です。
#!/usr/bin/env bash
set -euo pipefail
SCRIPT_DIR="$(cd "$(dirname "$0")" && pwd)"
cd "$SCRIPT_DIR"
exec cncf dev command --project-dev . minimal.main.hello "$@"ここでのプログラム本体は、 Hello CNCF を出力する hello operation です。 run.sh はその operation を command モードで起動する入口です。
実行
まず、selector を直接指定して Operation を実行します。
$ cd samples/01-minimal
$ cncf dev command --project-dev . minimal.main.hello--project-dev . は現在の directory を開発中 project として読む指定です。 minimal.main.hello は minimal component の main service にある hello operation を選択します。
同じ確認をまとめて実行する補助スクリプトとして bash run.sh があります。
$ bash run.shコマンドの読み方
cncf dev command は、開発中 project の component をコマンドとして一回起動するモードです。引数に指定した minimal.main.hello は <component>.<service>.<operation> の形で、起動した component の中から呼び出す operation を指定します。
run.sh と packaged invocation を比較する時は、出力ではなく component の読み込み元に注目します。前者は開発 classpath、後者は component directory に置いた jar を使います。
期待結果
message: Hello CNCF補助 lab では、同じ minimal.main.hello を development source、startup shape、builtin/help surface から確認します。
出力の読み方
message: Hello CNCF は、selector が runtime に解決され、Operation が実行されたことを示す確認値です。
この段階では、永続化 (Persistence)、server、client、job は扱いません。後続記事では、同じ selector model を別の実行形態で確認します。
よくあるつまずき
-
selector not foundが出る場合は、component name と service name の大文字小文字ではなく CLI selector 形minimal.main.helloを確認します。 -
通常の開発確認は sample directory から
--project-dev .を付けて実行します。packaged component の検証とは、読み込み元が違います。
CNCFエンジン上の意味
CNCF engine の selector は component.service.operation です。
後続の CRUD、CQRS、Job、Subsystem のサンプルも、この selector と実行単位を前提にしています。
次へ
次の記事 📄 Textus Samples 01.a: 呼び出し元の違いでは、同じ selector を保ったまま、Component の読み込み元を development directory と component repository で切り替えて確認します。
参照
用語集
- Textus
-
Textusは、SimpleModelingによって実現されたソフトウェアを動作させるための実行基盤です。アプリケーションに共通する実行、運用、連携の機構を提供します。
- 操作 (Operation)
-
UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。
- コンポーネント (Component)
-
責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。
- Cloud Native Component Framework (CNCF)
-
Cloud Native Component Framework（CNCF）は、クラウド・アプリケーションを構成するコンポーネントを、単一かつ一貫した実行モデルで実行するためのフレームワークです。 Component / Service / Operation という構造を中核とし、command、server（REST / OpenAPI）、client、script といった異なる実行形態から、同一の Operation を再利用できることを特徴とします。 ログ、エラー処理、設定、配備といったクラウド・アプリケーションに必要な品質属性をフレームワーク側に集約することで、コンポーネントはドメイン・ロジックの実装に集中できます。 CNCF は、文芸モデル駆動開発および AI 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。
- 振る舞い (Behavior)
-
UMLにおけるBehaviorは、そのContextとなるBehaviored Classifierが時間とともにどのようにStateを変えるかを定める仕様です。可能な実行、創発する振る舞い、または特定の実行例を表せます。
- 永続化 (Persistence)
-
Undefined
- Scala
-
Undefined
- 仕様確認 (verification)
-
Verification(仕様確認)とは、規定された設計仕様や要求仕様に対して、実装が一致しているかを確認する行為である。