Textus Samples 01.a: Invocation Source

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

Textus Samples is a collection of small samples for learning Textus component development step by step.

In 01-minimal , we examined the smallest shape of Component / Service / Operation / selector.

This article uses the next sample, 01.a-invocation-source-lab , to examine where the active Component comes from when invoking the same Operation.

Prerequisite

This article uses the environment prepared in 📄 Textus Samples: Launchers and Installation.

  • textus-tutorial-0.1.3 has been extracted

  • The latest public cncf , cozy , and textus launchers have been checked

  • The minimal.main.hello selector in 01-minimal has been checked

The download steps are covered in the prerequisite article, so they are not repeated here.

What You Learn

  • That selector and Component loading source are separate concepts

  • What it means to load from a development directory

  • What it means to load from a component repository

  • That the meaning of minimal.main.hello does not change when the loading source changes

Purpose / Why This Sample Matters

This sample is not for memorizing the difference between run.sh and invoke.sh . The learning target is where the Textus runtime obtains the active Component.

The Component name, Service name, and Operation name are the same. What changes is whether the Component implementation is loaded from the development directory or from a component repository as a packaged artifact.

Concept Focus

  • A selector is the logical name of the execution target.

  • The invocation source is where the runtime looks for the Component used to resolve that selector.

  • Even when the same selector returns the same result, the loading source is not necessarily the same.

Sample Directory

samples/01.a-invocation-source-lab

Stable Model

This lab uses the same minimal Component as 01-minimal .

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

The point to observe here is not the selector shape, but where the Component used to resolve the selector is supplied from.

Development Directory Source

With development directory source, the current sample directory becomes the loading source for the active Component. This is the shape used for short edit-and-check cycles while developing a Component.

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

In this form, the source tree itself is treated as the in-development Component. It is not checking a packaged artifact.

Component Repository Source

With component repository source, the sample is packaged first, and the runtime loads the artifact placed in the component directory.

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

This form is closer to reading a distributed or deployed Component rather than reading source directly.

Comparison

観点 development directory component repository

Component source

Current sample directory

Artifact in component directory

Selector

minimal.main.hello

minimal.main.hello

Main use

Check while editing

Check loading after packaging

Learning point

Load as an in-development Component

Load as a placed Component

Both invoke the same Operation. The difference is not the Operation meaning, but the supply path of the Component handed to the runtime.

Confirmation

For confirmation, run the two entry points inside the sample directory. The goal is not to trace each script line, but to confirm that the same selector is resolved through different loading sources.

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

Reading the Result

Both return Hello CNCF . This match shows that the same selector is being resolved.

However, stopping at the same result misses the point of the lab. The key point is that development directory source and component repository source create the same runtime surface through different supply paths.

CNCF Engine Meaning

When resolving a selector, the CNCF engine has a loading path that determines where the Component is obtained from.

This separation lets developers use the source tree during development and use artifacts for verification or deployment-like situations.

Next

In the next article 📄 Textus Samples 01.b: Startup Shapes, we examine the same Component through different runtime roles: command , server , and client .

References

In Site

Related Articles

Glossary

Component

A software construct that encapsulates well-defined responsibilities, contracts, and dependencies as a reusable and replaceable unit. In the logical model, it serves as an abstract structural unit; in the physical model, it corresponds to an implementation or deployment unit.

Cloud Native Component Framework (CNCF)

Cloud Native Component Framework (CNCF) is a framework for executing cloud application components using a single, consistent execution model. Centered on the structure of Component, Service, and Operation, it enables the same Operation to be reused across different execution forms such as command, server (REST / OpenAPI), client, and script. By centralizing quality attributes required for cloud applications—such as logging, error handling, configuration, and deployment—within the framework, components can focus on implementing domain logic. CNCF is designed as an execution foundation for literate model-driven development and AI-assisted development, separating what is executed from how it is invoked.

verification

Verification is the activity of confirming that an implementation conforms to its specified design or requirements.