1. ArmoniK Java SDK — Overview

1.1. Client–Worker Model

ArmoniK implements a Client–Worker distributed processing model. Responsibilities are clearly separated:

Client Responsibilities

  • Create and manage sessions.

  • Submit tasks and define execution dependencies (task graphs).

  • Manage input/output blobs and error handling.

Worker Responsibilities

  • Implement the computation logic for each task.

  • Read input blobs and produce output blobs.

  • Optionally submit new tasks (dynamic workflows).

1.2. SDK Goals

  • Simplify the development of Clients and Workers.

  • Provide pre-built Worker containers following unified conventions.

  • Offer a high-level Worker API with consistent lifecycle and error handling.

  • Provide simplified Client APIs to create sessions, submit tasks, and manage data.

  • Promote best practices: idempotency, error reporting, observability.

  • Ensure compatibility and long-term maintainability across ArmoniK versions.

  • Ensure interoperability: clients and workers can be mixed across languages.

1.3. Interoperability

The SDK is designed to enable cross-language interoperability — you can mix clients and workers across SDK languages.

Example: A Java client orchestrates tasks executed by Python or C# workers.

Two conventions make this possible:

Convention 1 — Payload structure

The payload is a JSON association table mapping logical names to blob IDs:

{"inputs": {"A": "id1"}, "outputs": {"result": "id2"}}

Convention 2 — Task options

Dynamic library loading is enabled via standardized task options carrying:

  • Path to the library

  • Symbol (class/function name)

  • Blob ID for the library artifact