Components: General Information¶

This section describes the QTasks component model as the basis for the entire framework architecture. It provides a general understanding of what a component is in QTasks, what principles underlie their interaction, and how they form a coherent system.

All subsequent pages in the "Components" tab expand and detail the provisions described here, focusing on specific aspects: abstract classes, classes that implement the QTask interface, and classes that implement the QTaskManager interface.

All subsequent pages of the "Components" tab expand on and detail the concepts described here, focusing on specific aspects: abstract classes, data schemas, execution threads, asynchrony, and the plugin system.

What is a component in QTasks?¶

A component in QTasks is an isolated architectural element that implements a strictly defined responsibility and interacts with the rest of the system exclusively through contracts.

A component:

is unaware of the specific implementations of other components;
does not store references to their internal state;
does not contain business logic that goes beyond its area of responsibility.

This separation allows QTasks to be viewed not as a single process, but as a system of interchangeable nodes connected by data flows.

Main and additional components¶

In the QTasks architecture, components are conditionally divided into two groups:

core components — form the mandatory minimum task processing pipeline;
additional components — extend the behavior of the system without being critical for basic task execution.

The boundary between these groups is not based on importance, but on architectural necessity: core components define system invariants, while additional components use these invariants to extend functionality.

Contracts and abstractions

Component interaction is based on contracts expressed through abstract classes and data schemas.

Contracts and abstractions¶

Component interaction is based on contracts expressed through abstract classes and data schemas.

A contract defines:

what data the component accepts;
what data it returns;
at which points behavior extension is allowed.

A component's implementation can be replaced entirely if it remains compatible with the contract. This is a key mechanism for the evolution of the QTasks architecture.

Data Transfer Between Components¶

QTasks components do not exchange execution objects or Python process state. All data is transferred in the form of schemas — structured, serializable representations of the task state and its processing context.

This approach provides:

transparency of data flows;
the ability to store and restore state;
independence from the execution environment;
simplified debugging and testing.

Execution flows and asynchrony¶

Asynchrony and parallelism in QTasks are not global properties of the system. They are localized within specific components and managed independently by them.

Each component:

determines its own execution model (sync/async);
controls its own queues, locks, and semaphores;
does not impose its model on other components.

This allows different execution models to be combined within a single system.

Plugins and extension points¶

Components provide predefined extension points where additional behavior can be implemented.

Plugins:

do not change component contracts;
do not interfere with their internal state directly;
are integrated into existing execution flows.

Thus, extensibility is achieved without violating architectural invariants.

Changing and replacing components¶

The QTasks architecture allows for the following scenarios when working with components:

creating your own component from scratch;
replacing the standard implementation with a custom one;
completely disabling an unnecessary component;
using different implementations of the same component in different environments.

The only mandatory condition is compliance with the contract expected by the rest of the system.

The role of this section¶

The "Components" section is designed to develop architectural thinking when working with QTasks. It explains not only how components are structured, but also why the architecture looks the way it does.

Understanding this section is critical when:

developing your own components;
deeply integrating QTasks into your infrastructure;
analyzing execution flows and performance;
designing non-standard usage scenarios.