💻 computer science

Bridging Design and Execution: A Visual Graph Editor for Edge and Cloud Workflows

This paper presents a domain-specific visual graph editor that bridges design and execution for edge and cloud workflows by enabling users to model modular applications through kernels, shared memory, and event triggers, which are then automatically serialized for runtime deployment.

Original authors: Katarina-Glorija Grujić, Nikola Stanković, Maja Vukasović, Miloš Simić

Published 2026-06-23

📖 4 min read☕ Coffee break read

CC BY 4.0

Original authors: Katarina-Glorija Grujić, Nikola Stanković, Maja Vukasović, Miloš Simić

Original paper licensed under CC BY 4.0 (http://creativecommons.org/licenses/by/4.0/). ✨ This is an AI-generated explanation of the paper below. It is not written or endorsed by the authors. For technical accuracy, refer to the original paper. Read full disclaimer

Imagine you are trying to organize a massive, high-tech kitchen where dozens of different chefs (computers) are working together to cook a complex meal. Some chefs are in the main kitchen (the Cloud), and others are in tiny, remote food trucks (the Edge).

The problem is that these chefs need to share ingredients, know when to start cooking, and pass dishes to each other without a central manager shouting orders. Usually, telling them how to do this requires writing hundreds of lines of confusing code or filling out tedious forms.

This paper introduces a Visual Graph Editor—think of it as a drag-and-drop blueprint tool that lets you design this kitchen workflow by drawing a picture instead of writing code.

Here is how the paper explains the system using simple concepts:

1. The Three Main Building Blocks

Instead of generic boxes, the tool gives you three specific types of "Lego bricks" to build your workflow:

Kernels (The Chefs): These are the actual tasks or programs that do the work. In the paper, they are described as "computational units." In our analogy, these are the chefs chopping vegetables or baking bread. You don't need to know how they cook; you just tell the system what they are.
Memory Nodes (The Shared Pantry): This is the paper's big innovation. Instead of chefs passing ingredients hand-to-hand (which can get messy), they all access a central "Shared Pantry." This represents data that everyone can read or write. The tool lets you draw a cylinder to represent this pantry, making it clear who is putting food in and who is taking it out.
Event Triggers (The Bells): These are the signals that tell a chef to start working. For example, "When the pantry is full of chopped onions, ring the bell for the soup chef." These are drawn as red rounded rectangles to show they are the "start buttons" for the action.

2. The Rules of the Road (Edges)

When you connect these blocks with lines (edges), the tool understands the rules of the road:

Solid Lines (Hard Links): This means the chef owns the ingredient. They are responsible for keeping it fresh and updating it.
Dashed Lines (Soft Links): This means the chef can look at the ingredient but cannot change it. They are just reading the recipe.

3. From Drawing to Reality

The magic of this tool is that the picture you draw isn't just a sketch. The moment you finish your design, the computer automatically translates your drawing into a strict set of instructions (like a JSON or XML file). It then sends these instructions to the "execution engine," which actually starts the chefs, opens the pantry, and rings the bells. It bridges the gap between designing the plan and running the plan.

4. The Real-World Test: Federated Learning

To prove this works, the authors used it to design a Federated Learning workflow.

The Scenario: Imagine many phones (Edge devices) trying to learn a new language together without sending their private notes to a central server.
The Visual Solution: The authors drew a graph where:
- Local "Training Chefs" on phones read a "Global Recipe" from the Shared Pantry.
- They cook locally (train on their own data).
- They put their new recipe tips back into the pantry.
- A "Bell" rings when enough tips arrive.
- A "Master Chef" (Aggregation Kernel) reads all the tips, mixes them into a better Global Recipe, and puts it back in the pantry for everyone to use again.

Why This Matters

The paper argues that existing tools are either too simple (just drawing pictures with no real meaning) or too complex (requiring deep coding knowledge). This new editor sits in the middle:

It makes data sharing obvious (you can see the pantry).
It makes timing obvious (you can see the bells).
It ensures that if you draw a valid picture, the computer can actually run it without you having to translate it into code manually.

In short, this paper presents a tool that turns the complex, invisible logic of distributed computing into a clear, visual map that anyone can draw, understand, and immediately put to work.

Technical Summary: Bridging Design and Execution with a Visual Graph Editor for Edge and Cloud Workflows

Problem Statement
Designing modular applications for edge and cloud computing environments presents significant challenges in orchestration, coordination, and reasoning about data sharing and execution flow. While applications increasingly rely on distributed components (kernels) communicating via shared data and events, existing solutions often fail to bridge the gap between design and execution. Traditional workflow management systems (e.g., Apache Airflow, Argo Workflows) and general-purpose diagramming tools (e.g., draw.io) lack domain-specific semantics for kernel communication, shared distributed memory, and event-driven execution. Consequently, visual models created with these tools remain disconnected from runtime deployment, requiring manual translation into deployable specifications and obscuring critical dependencies in heterogeneous, loosely coupled environments.

Methodology
The authors propose a domain-specific visual graph editor designed to model kernel-based applications using a unified, executable graph representation. The methodology centers on a typed directed graph $G=(V, E)$ where vertices represent functional entities and edges represent dependencies or interactions. The system introduces three first-class abstractions:

Kernels: Computational units (functions, services, or processes) defined externally. They consume data, perform computation, and produce outputs or events.
Shared Memory Nodes: First-class graph elements explicitly modeling distributed data persistence and exchange. Unlike implicit data passing, these nodes allow for many-to-many access patterns.
Event Triggers: Nodes that capture execution dependencies, decoupling event production from kernel execution to support asynchronous and reactive workflows.

The editor enforces specific interaction semantics through typed edges:

Hard Links: Indicate data ownership (read/write), where the connected kernel is responsible for data consistency.
Soft Links: Indicate read-only access, allowing kernels to consume shared state without lifecycle responsibility.

The visual editor, implemented as a web-based application, restricts invalid connections based on node types and provides real-time validation. It allows users to configure node properties (e.g., kernel parameters, memory identifiers, trigger conditions) via property panels. Crucially, the visual graph is not merely illustrative; it is automatically serialized into machine-readable representations (JSON/XML) that preserve both structural topology and semantic attributes. This specification is passed to an execution API to instantiate kernels, manage memory, and coordinate execution.

Key Contributions
The paper outlines three primary contributions:

A Domain-Specific Visual Graph Editor: A tool tailored for modeling kernel-based applications in edge and cloud environments, moving beyond generic diagramming to executable orchestration.
A Unified Graph Model: A semantic model that explicitly represents computation, shared distributed memory, and event-driven execution as distinct, interconnected graph elements.
A Foundation for Extensibility: An architecture that supports user-defined kernels, configurable events, and alternative execution backends, facilitating the exploration of complex distributed applications.

Results and Demonstration
The paper does not present quantitative experimental benchmarks but demonstrates the system's applicability through a detailed use case: Federated Learning (FL) Orchestration.

Application: The editor models an FL workflow where local training kernels on edge devices interact with a shared global model.
Implementation: Local training kernels read global parameters from a shared memory node (soft link), perform training, and write updates back (hard link). Event triggers coordinate the aggregation of updates and the initiation of new training rounds.
Outcome: The visual representation explicitly enforces privacy constraints (via hard/soft link separation) and clarifies the cyclic execution flow. The authors argue that this approach makes data sharing and execution dependencies transparent, reducing ambiguity compared to traditional tools where such logic is often hidden or implicit.

Significance and Claims
The authors claim that this work lays the foundation for the visual orchestration of modular computation in distributed environments. The significance of the proposed system lies in its ability to:

Bridge the Design-Execution Gap: By automatically translating visual models into executable specifications, the system eliminates the need for manual translation between design and deployment.
Improve Reasoning: Explicitly modeling memory and events as graph elements enhances the ability to reason about data sharing, execution order, and dependencies, which is critical in distributed edge/cloud scenarios.
Lower the Barrier to Entry: The visual approach allows users to construct complex, valid workflows without requiring deep knowledge of the underlying execution backend or low-level configuration files.

The paper concludes modestly, noting that while the current work focuses on the graph model, user interface, and execution pipeline, future work will involve the implementation of a full execution backend, integration with existing orchestration frameworks, and evaluation through real-world application scenarios.