Cloud Native Component Framework:HelloWorld

Cloud Native Component Framework

In SimpleModeling, automatic program generation from literate models is positioned as one of the key pillars of literate model-driven development.

When automatically generating programs, the choice of target platform becomes critically important.

SimpleModeling targets cloud applications as its primary platform and develops the Cloud Native Component Framework as the component framework for that purpose.

Cozy automatically generates programs from literate models using CNCF as its execution foundation.

The goals of CNCF can be broadly summarized in the following two points.

Providing the fundamental structure of cloud applications
Centralizing quality attributes required for cloud applications within the framework, allowing components to focus on implementing domain logic

In development that assumes AI assistance, quality attributes such as logging, error handling, configuration, and deployment become a significant burden for both AI and humans.

By having CNCF take responsibility for these concerns and focusing the AI’s reasoning on domain logic, we address a crucial issue in development for the AI era.

In this article, using a HelloWorld example, we introduce the minimal setup required to understand CNCF.

Demo Environment

CNCF is designed primarily for the following two usage patterns.

Launching CNCF on Docker and registering packaged JAR components for use
Using CNCF as Scala scripts via scala-cli

In the HelloWorld example, we first launch CNCF in standalone mode using Docker.

Because basic components are pre-registered in CNCF, you can grasp the overall picture of CNCF without any additional setup.

In full-scale usage, custom components are developed and registered, but this makes the environment setup somewhat heavier.

Therefore, this article focuses on how to use CNCF as a “script execution platform.”

Command Execution

CNCF allows commands to be executed directly from the CLI with components already deployed.

In the HelloWorld example, no additional components are added, and the built-in basic components provided by CNCF are used.

The system service of the admin component provides the ping operation.

The operation path is as follows.

admin.system.ping

This is the minimal operation used to verify that the CNCF runtime is active.

CNCF is distributed as a Docker image.

By entering the following command, you can execute the ping operation using CNCF distributed via Docker.

$ docker run --rm goldenport-cncf:0.3.2 command admin.system.ping

The execution result is as follows.

runtime: goldenport-cncf
runtime.version: 0.3.2
mode: command
subsystem: goldenport-cncf
subsystem.version: 0.3.2

The built-in ping operation in CNCF was executed and displayed the current status of CNCF.

Server Execution

CNCF can be launched as a server using exactly the same configuration as command execution.

When running in server mode, a REST API is exposed, allowing operations to be invoked externally via HTTP.

By specifying the server operation, CNCF starts up as a REST server.

$ docker run -p 8080:8080 goldenport-cncf:0.3.2 server

At this point, logs are displayed on standard output.

[io-compute-0] INFO org.http4s.ember.server.EmberServerBuilderCompanionPlatform - Ember-Server service bound to address: [::]:8080

From another terminal, invoke the ping operation using the curl command.

$ curl http://localhost:8080/admin/system/ping

As a result, we were able to obtain the same outcome as command execution via the command operation.

runtime: goldenport-cncf
runtime.version: 0.3.2
mode: server
subsystem: goldenport-cncf
subsystem.version: 0.3.2

The mode is shown as server, confirming that the same Operation is running in different execution forms for command and server.

OpenAPI

CNCF also automatically provides OpenAPI definitions.

$ curl http://localhost:8080/openapi.json | jq

The execution result is as follows. You can see that many operations are registered as built-ins.

{
  "openapi": "3.0.0",
  "info": {
    "title": "CNCF API",
    "version": "0.1.0"
  },
  "paths": {
    "/admin/component/list": {
      "get": {
        "tags": [
          "experimental:admin.component"
        ],
        "summary": "admin.component.list",
        "description": "Component: admin\nService: component\nOperation: list\n(experimental; subject to change in Phase 2.8)",
        "responses": {
          "200": {
            "description": "OK"
          }
        }
      }
    },
    "/admin/config/show": {
      "get": {
        "tags": [
          "experimental:admin.config"
        ],
        "summary": "admin.config.show",
        "description": "Component: admin\nService: config\nOperation: show\n(experimental; subject to change in Phase 2.8)",
        "responses": {
          "200": {
            "description": "OK"
          }
        }
      }
    },
    "/admin/extension/list": {
      "get": {
        "tags": [
          "experimental:admin.extension"
        ],
        "summary": "admin.extension.list",
        "description": "Component: admin\nService: extension\nOperation: list\n(experimental; subject to change in Phase 2.8)",
        "responses": {
          "200": {
            "description": "OK"
          }
        }
      }
    },
    "/admin/system/ping": {
      "get": {
        "tags": [
          "experimental:admin.system"
        ],
        "summary": "admin.system.ping",
        "description": "Component: admin\nService: system\nOperation: ping\n(experimental; subject to change in Phase 2.8)",
        "responses": {
          "200": {
            "description": "OK"
          }
        }
      }
    },
    "/admin/variation/list": {
      "get": {
        "tags": [
          "experimental:admin.variation"
        ],
        "summary": "admin.variation.list",
        "description": "Component: admin\nService: variation\nOperation: list\n(experimental; subject to change in Phase 2.8)",
        "responses": {
          "200": {
            "description": "OK"
          }
        }
      }
    },
    "/client/http/get": {
      "get": {
        "tags": [
          "experimental:client.http"
        ],
        "summary": "client.http.get",
        "description": "Component: client\nService: http\nOperation: get\n(experimental; subject to change in Phase 2.8)",
        "responses": {
          "200": {
            "description": "OK"
          }
        }
      }
    },
    "/client/http/post": {
      "get": {
        "tags": [
          "experimental:client.http"
        ],
        "summary": "client.http.post",
        "description": "Component: client\nService: http\nOperation: post\n(experimental; subject to change in Phase 2.8)",
        "responses": {
          "200": {
            "description": "OK"
          }
        }
      }
    },
    "/spec/export/openapi": {
      "get": {
        "tags": [
          "experimental:spec.export"
        ],
        "summary": "spec.export.openapi",
        "description": "Component: spec\nService: export\nOperation: openapi\n(experimental; subject to change in Phase 2.8)",
        "responses": {
          "200": {
            "description": "OK"
          }
        }
      }
    }
  }
}

Client Execution

CNCF can also be accessed as a CLI client against a running CNCF server.

The server is specified using the baseurl option.

In this case, the configuration is slightly special because access is made from within a Docker image to the host OS, but normally specifying a standard URL is sufficient.

$ docker run --rm goldenport-cncf:0.3.2 \
  client admin.system.ping \
  --baseurl http://host.docker.internal:8080 \
  admin.system.ping

As a result of the execution, the output of the ping operation was displayed as shown below.

runtime: goldenport-cncf
runtime.version: 0.3.2
mode: client
subsystem: goldenport-cncf
subsystem.version: 0.3.2

In this case, the CLI communicates with the CNCF server and displays the result.

Being able to operate CNCF exposed as a cloud service without implementing a dedicated CLI is a significant operational advantage.

Custom Component

CNCF allows custom components to be integrated and used.

Normally, components are built using an sbt-based project structure, but in HelloWorld we create components as minimal scripts using scala-cli.

Although it looks like an ordinary script, it actually constructs a CNCF component internally, registers the script program as an operation, and then invokes that script program.

The call corresponding to arguments is represented by an object called ScriptActionCall, through which the features provided by CNCF can be accessed.

#!/usr/bin/env -S scala-cli shebang
//> using repository "https://www.simplemodeling.org/maven"
//> using dep "org.goldenport:goldenport-cncf_3:0.3.2"
import org.goldenport.cncf.dsl.script.*
@main def main(args: String*): Unit = run(args) { call =>
  "hello world"
}

Now, let’s run it.

$ ./greeting.scala
hello world

The message “hello world” was displayed successfully.

In the development and operation of cloud services, various utilities are often required. To make it easy to develop such utilities, CNCF provides a script feature.

Because the CNCF script feature allows full access to all CNCF capabilities, utilities can be developed by reusing logic contained within components.

Arguments

Next is an example of receiving arguments. Arguments are received using call.args. The received arguments are concatenated with “hello” using ordinary Scala programming.

#!/usr/bin/env -S scala-cli shebang
//> using repository "https://www.simplemodeling.org/maven"
//> using dep "org.goldenport:goldenport-cncf_3:0.3.2"
import org.goldenport.cncf.dsl.script.*
@main def main(args: String*): Unit = run(args) { call =>
  "hello " + call.args(0)
}

Let’s provide “world” as a parameter.

$ ./greeting.scala world
hello world

The message “hello world” was displayed successfully.

Summary

In this article, we explored CNCF by actually running it, examining the following execution forms:

command
server (REST / OpenAPI)
client
custom component (scala-cli)

— stepping through these different execution forms in sequence.

The key point is that even when the execution form changes, the internal execution model remains exactly the same.

In CNCF, the following structure is consistently maintained:

Component
Service
Operation

This structure is kept consistent, and command, server, client, and script merely invoke the same Component and Operation.

As a result of this design:

There is no need to implement CLI and REST separately
OpenAPI definitions are generated automatically
Scripts and utilities can be written using the same execution model as production

These benefits are obtained naturally.

CNCF is an execution foundation designed for literate model-driven development and AI-assisted development, separating “what to execute” from “how it is invoked.”

The minimal configuration confirmed in this HelloWorld example scales directly into full cloud applications.

References

Glossary

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.
literate model: A Literate Model is a “readable model” that integrates model structure with natural-language narrative (structured documentation). It extends the idea of literate programming into the modeling domain, unifying structure (model) and narrative (structured text) into a single intelligible artifact interpretable by both humans and AI. The concept of “Literate Modeling” has been explored previously by some researchers and developers, mostly as an approach to improve documentation or code comprehension. However, those attempts did not establish a systematic modeling methodology that integrates models, narrative, and AI assistance as a unified framework. The Literate Model is a modeling concept newly systematized and proposed by SimpleModeling for the AI era. Building upon the ideas of literate modeling, it redefines them as an intelligent modeling foundation that enables AI-collaborative knowledge circulation and model generation. It is not merely a modeling technique but a framework that embeds human reasoning and design intent as narrative within the model, enabling AI to analyze and reconstruct them to assist in design and generation.
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.
Literate Model-Driven Development (LMDD): Literate Model–Driven Development (LMDD) is a software development methodology that integrates natural-language narrative and formal model structure within a unified text-based framework. It extends conventional Model–Driven Development (MDD) by treating documentation and models as a single, consistent source of truth. In LMDD, the descriptive and structural elements of development artifacts are expressed together using the SmartDox language. From this unified representation, ModelDox extracts structural data, CML (Cozy Modeling Language) defines domain-specific models, and Cozy generates executable code, documentation, and configuration artifacts. Artificial intelligence participates in the LMDD process by analyzing the narrative context, validating structural consistency, and supporting the refinement of models and generated artifacts. All artifacts are represented in text form, ensuring traceability, version control, and interoperability within standard development environments. By defining a formally connected and machine-interpretable relationship between documentation, design, and implementation, LMDD provides a foundation for AI-assisted model–driven engineering where human authorship and automated reasoning operate on the same representational layer.
error: A generic term used broadly in practice. In software engineering, it is ambiguous and may denote bugs or failures in general. In SimpleModeling, Error is treated as a broad label, with specifics clarified as Mistake, Defect, Fault, Failure, or Deviation.

Cloud Native Component Framework:HelloWorld