Itara

Glossary

Mon, 01 Jan 0001 00:00:00 +0000

Clear, shared vocabulary matters: if people can talk about the project fluently, the ideas travel. If the words are missing or inconsistent, the point gets lost. This is the reference for that vocabulary.

Agent

See Wiring Agent.

Authentication

Verifying that a caller’s claimed identity (see Identity) is genuine, at the topology layer.

Authentication is connection-level and pluggable: an implementation receives whatever identity signal is available for a connection and either produces a verified identity or rejects the call outright. Used without qualification, this term refers to authenticating a calling node, not an end user or account.

itara-cli

Mon, 01 Jan 0001 00:00:00 +0000

itara is the command-line tool for working with an Itara wiring configuration — inspecting a topology at a glance, and validating it for logical mistakes before it’s deployed. It’s implemented once, in Rust, and operates purely on the file formats — the wiring config YAML and .itara metadata TOML files — so it works identically regardless of which language (Java or Rust) actually produced the artifacts being wired together; there’s simply nothing language-specific for it to know about.

Vision

Mon, 01 Jan 0001 00:00:00 +0000

This document describes where Itara is going, not just where it is. It is a living document.

Itara — the open-source specification and its reference implementations — is the cornerstone of this vision, not the whole of it. Everything else on this site describes what exists today, working, open source, and usable. This page describes the future that today’s Itara is the first step toward.

The north star

A production system should have a declared, validated, and executable topology — how its components communicate and connect — that is easy to change without touching business code, without migration ceremony, and without downtime. And it should be able to do so safely: with the confidence that the new topology is correct before it is applied, that every connection is validated, and that nothing can be misconfigured silently.

API Documentation

Mon, 01 Jan 0001 00:00:00 +0000

Full class and method documentation is generated directly from source and hosted by each language ecosystem’s own standard tooling — not duplicated here, so it never drifts out of sync with what’s actually published.

Java

itara-core and itara-agent on javadoc.io

Rust

Rust crates are not yet published to crates.io. Once they are, generated documentation will be available automatically at docs.rs under the published crate name.

Architecture

Mon, 01 Jan 0001 00:00:00 +0000

This page describes how Itara actually works today — the module structure, the layering rules, what happens at startup, and what happens on a call. For where this is going, see Vision. For the formal, normative behavior every implementation must satisfy, see the wiring configuration and metadata format references.

The core idea, in one paragraph

The Itara agent runs before application code. It reads a wiring config, loads the plugins that config actually requires, generates proxies and listeners for each declared connection, and registers everything in the component registry — before the application handles its first request. By the time your entry point executes, the topology is fully wired. Component code calls other components through plain interface references and never knows whether the call goes in-process or across a network — or which language the other component is written in. The specification itself is language-neutral: a Java component and a Rust component can participate in the same topology, wired by the same config, producing a single distributed trace.

Wiring Configuration

Mon, 01 Jan 0001 00:00:00 +0000

The wiring configuration is the YAML file that describes the topology of an Itara deployment: which nodes exist, and how they’re connected to one another (or to the outside world).

This document describes the file format itself — the schema, the required and optional fields, and what makes a document valid.

Top-level structure

nodes:
 - id: "gatewayNode"
 component: "gateway"
 - id: "calculatorNode"
 component: "calculator"
 
connections:
 - id: "gateway-to-calculator"
 caller:
 nodeId: "gatewayNode"
 callee:
 nodeId: "calculatorNode"
 transport:
 id: http
 params:
 host: "${CALC_HOST:-localhost}"
 port: "${CALC_PORT:-8081}"
 serializer:
 id: json

Field	Type	Required	Description
`nodes`	list of Node	No (defaults to empty)	Every node in the topology.
`connections`	list of Connection	No (defaults to empty)	Every connection between nodes.

An empty or comment-only file is valid and parses to an empty configuration (no nodes, no connections).

Metadata Format

Mon, 01 Jan 0001 00:00:00 +0000

A .itara file is a small TOML document shipped alongside every build artifact (a component, an API, a transport, a serializer, an observer, etc). It declares what the artifact is — its identity, the versions it was built against, and (depending on its kind) a handful of kind-specific declarations that other tooling and the agent itself use to wire things up safely.

Unlike the wiring configuration, which is one file describing an entire deployment topology, a .itara file describes exactly one artifact.

Search Results

Mon, 01 Jan 0001 00:00:00 +0000

Website information

Mon, 01 Jan 0001 00:00:00 +0000

Site built with Docsy v0.1.0

Build information

Netlify build information:

Attribute	Value
Netlify built	`true`
Date/time¹	2026-09-23 16:33 UTC²
ID	`6ab3ff3ad310250008c94e32`
Deploy log	6ab3ff3ad310250008c94e34
Deploy context	production
Commit	@439131a
Branch	`main`

Approximate build timestamp. ↩︎
In your timezone: unknown. ↩︎