CloudsMovement

Technical Classification of the CloudsMovement Architecture

CloudsMovement is based on a hybrid, distributed architecture in which central control functions are separated from the actual application processing.

The architecture can be divided into two main layers:

1. Central Control Layer – Control Plane

The central CloudsMovement instance, for example at www.dsource-solution.de, is primarily responsible for:

• User login and authentication
• User and permission management
• Session management
• Job management and job brokering
• Assigning users to authorized CloudsMovement nodes

The central instance therefore controls and coordinates processing without necessarily executing the actual business logic itself.

2. Local Processing Layer – Compute Plane

Business processing takes place on a CloudsMovement node at the user's premises. This node can, for example, run on an existing PC or notebook.

The actual applications and, depending on the use case, the associated local data and tenant areas are located there, for example:

DATA/<USERAREA>

The local CloudsMovement node therefore serves as the application and data host.

The business logic can be implemented in different programming languages or runtime environments, such as Xbase++, Harbour, Python, or Go.

Request Flow

From the user's perspective, access is provided through a web interface. The browser does not need to know which computer actually executes the requested business function.

A typical flow is:

Browser → central CloudsMovement control plane → authenticated job → CloudsMovement node → local application / local data → result → browser

The user first logs in to the central CloudsMovement instance and requests an authorized function.

CloudsMovement assigns this request to the responsible node. The corresponding application or function is executed there. The result is then returned to the CloudsMovement infrastructure and presented to the user, for example as HTML in the browser.

Integration of Existing Applications

A key advantage of this architecture is that existing business applications do not necessarily have to be fully migrated to a conventional web or cloud architecture.

For example, an existing Xbase++ or Harbour application can continue to run on a local computer. CloudsMovement provides the connection between a modern browser-based user interface and the existing business logic.

This allows the user interface, business logic, and data storage to be separated more clearly.

For existing applications in particular, this can significantly reduce migration effort.

Decentralized Data Storage

In principle, the architecture makes it possible to keep sensitive company data locally within the respective organization.

Ideally, the central CloudsMovement service only needs to process the information required for control, for example:

User X is authorized to execute function Y on CloudsMovement node Z.

Whether and which application data is transferred through the central infrastructure during a job depends on the specific implementation. Data protection and data security therefore do not arise automatically from the architecture; they must be ensured through appropriate technical and organizational measures.

Example: Small Trades Business

A small business could use an existing PC or the owner's notebook as a CloudsMovement node.

Employees access authorized functions through browsers, tablets, or smartphones. The actual business application and operational data can continue to be processed on the local computer.

In such scenarios, this may eliminate the need to operate a separate conventional application or terminal server.

Security Requirements

The key technical challenges of the architecture include:

• Secure authentication and authorization
• Encrypted communication
• Reliable and traceable job delivery
• Unambiguous assignment of users, sessions, jobs, and nodes
• Securing the local CloudsMovement node
• Logging security-relevant events
• Protection against unauthorized or manipulated function calls

It is particularly important that the central instance must not be able to execute arbitrary programs or commands on a node.

The local CloudsMovement agent should only be able to launch explicitly authorized applications, machines, or functions. It must also verify that the requesting user is authorized to use the respective function.

This creates a clearly defined security boundary between central control and local execution.

Architecture Model

In technical terms, CloudsMovement can be described as a

hybrid, distributed application architecture with a central control plane and decentralized compute and data nodes.

The core architectural concept is the separation of:

centralized accessibility and control

and

decentralized processing and data storage.

This distinguishes CloudsMovement from a conventional web application, in which the web server, business logic, and database are typically located within a centrally operated server or cloud infrastructure.

CloudsMovement instead follows the principle:

Control is centralized – execution can take place locally at the user's premises.