Textus Samples 01.a: 呼び出し元の違い

Created: 2026-07-13 Updated: 2026-07-13

Textus Samples は、Textus component の開発手順を、小さなサンプルを順に読み解きながら理解するためのサンプル集です。

01-minimal では、Component / Service / Operation / selector の最小形を確認しました。

本記事では、その次の 01.a-invocation-source-lab を使い、同じ Operation を呼び出す時に、active Component がどこから来るのかを確認します。

前提

本記事では、📄 Textus Samples: Launcherとインストール の手順で準備した環境を使います。

  • textus-tutorial-0.1.3 を展開済み

  • 公開 channel の最新 cncf / cozy / textus launcher を確認済み

  • 01-minimal の minimal.main.hello selector を確認済み

download 手順は前提記事で扱っているため、ここでは再掲しません。

学ぶこと

  • selector と Component の読み込み元は別の概念であること

  • development directory から読み込む時の意味

  • component repository から読み込む時の意味

  • 読み込み元を変えても minimal.main.hello の意味は変わらないこと

目的と着目点

このサンプルは、 run.sh と invoke.sh という script の違いを覚えるためのものではありません。学習対象は、Textus runtime が active Component をどこから取得しているかです。

Component の名前、Service の名前、Operation の名前は同じです。変わるのは、Component 実装が development directory から読まれるのか、packaged artifact として component repository から読まれるのかです。

概念の焦点

  • selector は実行対象の論理名です。

  • invocation source は、その selector を解決するために runtime が Component を探す場所です。

  • 同じ selector が同じ結果を返しても、読み込み元が同じとは限りません。

サンプルディレクトリ

samples/01.a-invocation-source-lab

変わらないモデル

このlabは、 01-minimal と同じ最小 Component を使います。

Component: minimal
Service:   main
Operation: hello
Selector:  minimal.main.hello

ここで見るべき点は、selector の形ではなく、selector を解決するための Component がどこから供給されるかです。

開発ディレクトリからの読み込み

development directory source では、現在の sample directory が active Component の読み込み元になります。これは、Component を編集しながら短い周期で確認する時の形です。

samples/01.a-invocation-source-lab
        |
        v
runtime loads local development classes
        |
        v
minimal.main.hello

この形では、source tree がそのまま開発中 Component として扱われます。package 済み artifact を確認しているわけではありません。

Component repositoryからの読み込み

component repository source では、sample を一度 package し、component directory に置いた artifact を runtime が読み込みます。

source tree
   |
   v
packaged artifact in component.d
   |
   v
runtime loads repository-style artifact
   |
   v
minimal.main.hello

この形は、source を直接読むのではなく、配布・配置された Component を読む感覚に近くなります。

比較

観点 development directory component repository

Component source

現在のsample directory

component directory上のartifact

Selector

minimal.main.hello

minimal.main.hello

Main use

編集しながら確認する

package後の読み込みを確認する

Learning point

開発中Componentとして読む

配置済みComponentとして読む

どちらも同じ Operation を呼び出します。違いは、Operation の意味ではなく、runtime に渡される Component の供給経路です。

確認

確認する場合は、sample directory 内で2つの入口を実行します。ただし、ここでの目的は script の行を追うことではなく、同じ selector が異なる読み込み元で解決されることを確認することです。

$ cd samples/01.a-invocation-source-lab
$ ./run.sh
$ ./invoke.sh

結果の読み方

どちらも Hello CNCF を返します。この一致は、同じ selector が解決されていることを示します。

ただし、同じ結果であることだけを見て終わると、このlabの意味を取り逃します。見るべき点は、development directory source と component repository source が、同じ runtime surface を別の供給経路から作っていることです。

CNCFエンジン上の意味

CNCF (Cloud Native Component Framework) engine は selector を解決する時に、Component をどこから取得するかという読み込み経路を持ちます。

この分離により、開発中は source tree を使い、検証や配布に近い場面では artifact を使う、という切り替えができます。

次へ

次の記事 📄 Textus Samples 01.b: 起動形態では、同じ Component を command / server / client という異なる runtime role で見る方法を確認します。

参照

サイト内

関連記事

用語集

コンポーネント (Component)

責務・契約・依存関係を明示的に定義し、再利用可能で交換可能な単位としてカプセル化されたソフトウェア構成要素。論理モデルでは抽象構造単位として、物理モデルでは実装・デプロイメント単位として扱われる。

Cloud Native Component Framework (CNCF)

Cloud Native Component Framework（CNCF）は、クラウド・アプリケーションを構成するコンポーネントを、単一かつ一貫した実行モデルで実行するためのフレームワークです。 Component / Service / Operation という構造を中核とし、command、server（REST / OpenAPI）、client、script といった異なる実行形態から、同一の Operation を再利用できることを特徴とします。 ログ、エラー処理、設定、配備といったクラウド・アプリケーションに必要な品質属性をフレームワーク側に集約することで、コンポーネントはドメイン・ロジックの実装に集中できます。 CNCF は、文芸モデル駆動開発および AI 支援開発を前提に、「何を実行するか」と「どのように呼び出すか」を分離するための実行基盤として設計されています。

仕様確認 (verification)

Verification(仕様確認)とは、規定された設計仕様や要求仕様に対して、実装が一致しているかを確認する行為である。