Textus Samples 01:Component Script
前提
本記事では、📄 Textus Samples: Launcherとインストール の手順で準備した環境を使います。
-
textus-tutorial-0.1.3を展開済み -
cozy/cncf/textuslauncher をインストール済み -
各 launcher の runtime を確認済み
download 手順は前提記事で扱っているため、ここでは再掲しません。
学ぶこと
-
scala-cli script と CNCF (Cloud Native Component Framework) engine runtime の接続
-
小さな管理コマンドの実装形
目的と着目点
このサンプルは、Textus component operation を小さな管理コマンドとして扱う開発手順を確認するためのものです。大きな server や正式な component project を先に作らず、script を operation contract への薄い入口として使います。
着目点は script 自体ではなく、script が selector と input を隠しすぎず、運用者に必要な入口を薄く作ることです。
概念の焦点
-
Script は CNCF engine の別モデルではなく、operation contract への薄い入口です。
-
引数が増えた時は shell 固有の処理ではなく operation input として整理するのが基本です。
実行
まず、サンプルディレクトリに移動します。
$ cd samples/01.d-component-script開発時の確認では、 run.sh から script を実行します。
$ ./run.shscript file を直接実行して、1 ファイル script としての入口も確認できます。
$ ./script/main.scalaコマンドの読み方
run.sh は、内部で scala-cli ./script/main.scala — "$@" を実行します。つまり、学習対象は shell wrapper ではなく script/main.scala です。
script/main.scala では、scala-cli shebang、CNCF script DSL (Domain Specific Language) の import、 run(args) { … } による実行ブロックを使います。
#!/usr/bin/env -S scala-cli shebang
//> using repository "https://www.simplemodeling.org/repository/maven"
//> using dep "org.goldenport:goldenport-cncf_3:0.4.13"
import org.goldenport.cncf.dsl.script.*
@main def main(args: String*): Unit =
run(args) { call =>
"Hello CNCF"
}出力の読み方
成功出力は script が shell として動いたことではなく、裏側の Textus component operation が実行されたことを確認します。
出力に selector や result が出る場合は、script の責務 (Responsibility)と operation の責務を分けて読みます。
よくあるつまずき
-
shell script に business logic を寄せすぎると、Textus component operation contract から外れて再利用しづらくなります。
-
パス依存 (Dependency)の script にしないため、読者向け記事では download package 内の相対実行だけを示します。
次へ
次の記事 📄 Textus Samples 02:Component Packagingでは、正式な packaged component と CAR loader の流れを確認します。
参照
用語集
- Textus
-
Textusは、SimpleModelingによって実現されたソフトウェアを動作させるための実行基盤です。アプリケーションに共通する実行、運用、連携の機構を提供します。
- Cozy Modeling Language (CML)
-
CML（Cozy Modeling Language）は、オブジェクト・モデルのうち、プログラム生成と実行へ接続する実行可能モデルを記述するSimpleModelingの形式モデリング言語です。
- コンポーネント (Component)
-
責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。
- 操作 (Operation)
-
UMLにおけるOperationは、関連するBehaviorを呼び出すための名前、型、Parameter、Constraintを定めるClassifierのBehavioral Featureです。Operationは呼び出し契約を定め、MethodなどのBehaviorがその実現を担います。
- モデル (Model)
-
Modelとは、対象を特定のPurposeとConcernに基づいて選択し、理解、判断、検証、構築に利用できる形で表した抽象です。対象そのものではなく、目的に必要な要素、関係、意味を保持する表現です。
- Cloud Native Component Framework (CNCF)
-
Cloud Native Component Framework（CNCF）は、クラウド・アプリケーションを構成するコンポーネントを、単一かつ一貫した実行モデルで実行するためのフレームワークです。 Component / Service / Operation という構造を中核とし、command、server（REST / OpenAPI）、client、script といった異なる実行形態から、同一の Operation を再利用できることを特徴とします。 ログ、エラー処理、設定、配備といったクラウド・アプリケーションに必要な品質属性をフレームワーク側に集約することで、コンポーネントはドメイン・ロジックの実装に集中できます。 CNCF は、文芸モデル駆動開発および AI 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。
- DSL (Domain Specific Language)
-
DSL（ドメイン固有言語）は、特定の領域（ドメイン）に特化して設計された言語であり、その分野の概念や構造を直接的かつ簡潔に表現することを目的とします。 一般的な汎用プログラミング言語（GPL）に比べ、DSLは特定ドメインの問題解決や自動生成に適した高い抽象度を持ちます。
- 責務 (Responsibility)
-
Responsibilityとは、ObjectまたはRoleが、何を知り、判断し、行い、守るべきかを表す義務です。構造上の情報だけでなく、規則とBehaviorの所有を定めます。
- 依存 (Dependency)
-
UMLにおけるDependencyは、ClientとなるModel Elementの仕様または実装が、Supplierとなる別のModel Elementの定義へ意味的または構造的に依存することを表すDirected Relationshipです。