Fact-checked by Grok 2 weeks ago

Flow-based programming

Flow-based programming (FBP) is a programming paradigm that models applications as networks of black-box processes exchanging data through predefined connections, using a "data processing factory" metaphor where information packets flow asynchronously between components.^[1] Developed by J. Paul Morrison in the late 1960s at IBM Canada, FBP was first formally described in a 1971 IBM Technical Disclosure Bulletin as a modular system of tasks communicating via queues under a central scheduler to process data elements efficiently.^[2]^[1] Key concepts include asynchronous concurrent execution of processes, information packets with defined lifetimes that encapsulate data, named input and output ports for connections, and bounded buffers to manage flow without tight coupling between components, enabling loose data coupling for easier maintenance and reusability.^[1] Unlike the sequential von Neumann model, FBP emphasizes data-driven execution, supporting rapid prototyping, component reuse, and efficient utilization of multi-core processors by distributing work across independent processes.^[1] Morrison detailed the paradigm in his book Flow-Based Programming: A New Approach to Application Development (second edition, 2010), which includes tools like DrawFBP for graphical network design and implementations in languages such as C, Java, and Lua.^[1]

Fundamentals

Definition and Principles

Flow-based programming (FBP) is a programming paradigm in which applications are built as networks of independent, black-box processes that exchange data exclusively through asynchronous data flows, treating the overall system as a directed graph of data transformations rather than sequential instructions.^[3] This approach, invented by J. Paul Morrison in the late 1960s, shifts the focus from traditional control flow to data-driven execution, where processes operate concurrently without shared memory or direct dependencies.^[3] At its core, FBP adheres to principles of modularity through reusable, self-contained components that encapsulate functionality behind well-defined input and output interfaces, promoting ease of composition and maintenance in complex systems.^[3] It enforces asynchronous data exchange, allowing processes to run independently and interleave based on data availability, which inherently separates control flow from data processing and ensures deterministic behavior as outputs depend solely on inputs received.^[3] Coordination among processes is managed externally via predefined network structures, enabling implicit parallelism without explicit synchronization mechanisms.^[3] The motivation behind FBP lies in its ability to facilitate parallelism and scalability by mapping naturally to distributed or multiprocessor environments, where data streams drive execution and reduce bottlenecks in large-scale applications.^[3] By viewing programs as dynamic graphs of interconnected transformations, FBP enhances maintainability, as changes to individual processes do not propagate globally, and supports efficient resource utilization in data-intensive tasks.^[3] This paradigm has proven effective in industrial settings, such as long-term deployments in enterprise software, by prioritizing data responsiveness over rigid sequencing.^[3]

Key Components

In flow-based programming (FBP), the foundational building blocks are black-box processes, which serve as self-contained, reusable units designed to perform specific transformations on incoming data without exposing their internal state or logic to other components. These processes operate asynchronously, receiving input, processing it independently, and producing output, thereby promoting modularity and reusability across different applications. As described by the paradigm's originator, J. Paul Morrison, black-box processes encapsulate long-running functions such as sorting or merging, allowing them to be interconnected without modification to their internals.^[4]^[1] Each black-box process features input and output ports, which act as standardized, named interfaces for data exchange, enabling selective reception from multiple inputs and dispatch to designated outputs. Input ports allow a process to receive data from one or more upstream connections, often choosing dynamically based on availability, while output ports facilitate the emission of processed data to downstream processes. This port-based design ensures that interactions remain loosely coupled, with ports serving as the sole points of attachment between a process's code and the broader network structure.^[4]^[1] Connections in FBP represent directed, fixed-capacity links between output ports of one process and input ports of another, defining the pathways for data flow without incorporating buffering mechanisms or explicit synchronization. These connections transport discrete units of data, known as Information Packets, in a stream-like manner, with each packet having a defined lifetime owned either by a process or during transit. By specifying connections externally—typically in a list interpreted by a scheduler—FBP separates network topology from process implementation, enforcing a data-driven execution model where flow is governed by availability and capacity constraints, such as back pressure to prevent overflow.^[1]^[4] Unlike traditional programming paradigms that rely on shared variables for state management and inter-component communication, FBP emphasizes stateless, event-driven components connected solely through data flows, achieving the loosest form of coupling known as data coupling. This approach eliminates direct variable access across processes, reducing dependencies and enhancing maintainability, as components neither retain nor expose mutable state but instead react to incoming events via asynchronous send and receive operations. In contrast to synchronous method calls in object-oriented programming, where state is often maintained within objects, FBP's design ensures that data propagation occurs independently of process timing, fostering robustness in concurrent environments.^[5]^[1]

Historical Development

Origins

Flow-based programming (FBP) was invented by J. Paul Morrison in the late 1960s during his tenure at IBM Canada in Montreal, Quebec, where he was engaged in systems architecture and programming for mainframe environments.^[3] Morrison, who had joined IBM in the United Kingdom in 1959 after graduating from King's College, Cambridge, brought experience in early compiler design and unit record equipment from his time at IBM facilities in England and the United States before relocating to Canada in 1968.^[6] The paradigm emerged as a response to the constraints of conventional von Neumann architectures and sequential programming languages prevalent in batch-oriented computing systems of the era.^[3] The initial development of FBP was heavily influenced by challenges in handling concurrent data streams within batch processing environments, particularly the inefficiencies of synchronous, procedural code in managing parallelizable tasks such as data decomposition and recombination. Morrison's early work focused on creating a data-driven approach that emphasized independent processes communicating via information flows, inspired by simulation tools like GPSS (General Purpose Simulation System) developed at IBM in the early 1960s and concepts from queue-based data flow explored in a 1967 paper by Morenoff and McLean at the Rome Air Development Center.^[3] This motivation stemmed from practical needs in developing robust applications for mainframe systems, where traditional methods led to brittle, hard-to-maintain code amid growing demands for modularity and reusability.^[3] The first conceptual foundations of FBP were laid through internal IBM documentation and prototypes around 1967–1970, predating any formal publications. Morrison developed the Advanced Modular Processing System (AMPS), an early implementation in IBM System/360 Assembler that used macros to define process networks for batch applications supporting an online banking system at a major Canadian institution.^[3] These efforts addressed the limitations of sequential programming by enabling interleaved task execution and dynamic data handling, with networks initially sketched manually on paper to visualize asynchronous flows. The inaugural public disclosure came in Morrison's 1971 article in the IBM Technical Disclosure Bulletin, titled "Data Responsive Modular, Interleaved Task Programming System," which outlined the core idea of modular, data-responsive processes.^[1]

Key Milestones and Evolution

In the 1970s, J. Paul Morrison advanced flow-based programming through his work at IBM, developing practical prototypes implemented in OS/360 environments for high-volume banking applications at a major Canadian financial institution.^[7] These early systems demonstrated asynchronous data processing across networked components, with core concepts outlined in Morrison's 1978 publication on data stream linkage mechanisms. During the 1980s, Morrison collaborated with IBM architect Wayne Stevens to refine and promote FBP concepts, integrating them with structured analysis methods. Stevens highlighted FBP's compatibility in publications, including a 1982 article on data flows in flowcharts.^[8] The 1990s marked a formalization of the paradigm with the publication of Morrison's seminal book, Flow-Based Programming: A New Approach to Application Development, in 1994, which provided a comprehensive theoretical framework and practical guidance for application development. This work emphasized the paradigm's advantages in modularity and reusability, influencing subsequent software engineering practices. During the 2000s and 2010s, flow-based programming saw the rise of open-source implementations, including JavaFBP and C#FBP, which enabled broader experimentation and integration with emerging web technologies like JavaScript runtimes.^[9] A notable advancement was the launch of NoFlo in 2011, a JavaScript-based framework that extended the paradigm to browser and Node.js environments, fostering reusable component ecosystems.^[10] Visual tools such as FlowHub, launched in 2013 as a collaborative development environment for NoFlo, and Slang, a Go-based visual flow system introduced around 2018, further supported automation in distributed systems.^[11]^[12] In the 2020s, adoption has grown in cloud-native data pipelines and AI workflows, leveraging the paradigm's strengths in scalable, asynchronous processing.^[13] Recent applications include bioinformatics pipelines, such as DeBasher in 2025, which applies flow-based principles to modular workflow execution.^[14]

Core Concepts

Processes and Black Boxes

In flow-based programming (FBP), processes serve as the fundamental computational units, functioning as independent, concurrent entities that execute autonomously within a network. Each process activates upon the arrival of an information packet at one of its designated input ports, triggering a cycle of data consumption, internal processing, and output generation. This activation mechanism ensures that processes remain dormant until stimulated by incoming data, enabling efficient resource utilization in asynchronous environments.^[15] The black-box property is central to FBP processes, encapsulating their internal logic completely while exposing only input and output ports for interaction. This design hides implementation details from other components, allowing processes to be treated as opaque modules whose behavior is verifiable solely through their I/O interfaces. Such encapsulation fosters reusability, as processes can be developed, tested, and deployed independently, and facilitates modular testing by isolating them from the broader network. For instance, a sorting process can be validated using predefined input packets and expected outputs without knowledge of its algorithmic internals.^[16] Activation and deactivation cycles in FBP processes emphasize stateless operation between invocations, with no shared state or memory across executions. Upon activation, a process receives and consumes the triggering input packet—typically processing it sequentially if multiple inputs are involved—performs its computation, and dispatches results to connected output ports before deactivating. Non-looping processes handle one packet per cycle and terminate afterward, while looping processes remain active to process streams until an end-of-data signal, such as a closed connection, prompts deactivation. This cycle-based model prevents race conditions and promotes concurrency without requiring explicit synchronization primitives.^[15] FBP processes support multiple inputs and outputs through port-based mechanisms, enabling fan-in (converging data from several sources to a single process) and fan-out (distributing outputs to multiple downstream processes). Input ports allow selective reception, where a process might wait for data on a specific port before proceeding, while output ports queue packets for transmission without direct invocation of recipient processes. This port-mediated communication enforces loose coupling, eliminating function calls or shared variables between processes and ensuring scalability in distributed or parallel executions.^[16]

Information Packets and Connections

In flow-based programming (FBP), information packets (IPs) serve as the fundamental units of data exchange between processes, encapsulating both payload and metadata to ensure self-contained transmission. The payload consists of the actual data content, which can vary in length from zero to approximately two billion bytes, representing entities such as words, transactions, or multi-field objects. Metadata includes elements like type information, size, and sometimes destination details, often managed through handles or descriptors that allow processes to access and interpret the data without exposing its internal structure. This design enables IPs to travel as complete, indivisible entities through the network, maintaining integrity across asynchronous flows.^[3] Connections in FBP act as typed, point-to-point channels that link the output ports of upstream processes to the input ports of downstream processes, facilitating the routing of IPs without direct process-to-process coupling. These connections operate asynchronously, allowing processes to execute independently while IPs are buffered in FIFO queues with finite capacity—typically ranging from a single IP to a large number, or effectively unlimited via file-based storage—to prevent unbounded accumulation and manage flow control. Unlike unbounded channels in some paradigms, this bounded queuing ensures deterministic behavior but requires careful capacity tuning to avoid deadlocks or livelocks. Multiple connections can attach to a single port, supporting many-to-one topologies, though one-to-many splitting is handled explicitly by processes rather than the connections themselves.^[3] The lifecycle of an IP begins with its creation by an upstream process, which allocates the packet and populates its payload and metadata before transmitting it via an output port to a connected channel. Upon arrival at a downstream process's input port—triggered by the availability of data—the IP is received, consumed for computation or transformation, and then disposed of, either by forwarding it to another connection, filing it for persistence, destroying it if no longer needed, or attaching it to a data structure. Error handling occurs through explicit disposal mechanisms, such as discarding unprocessable or undeliverable IPs using commands like "drop" or APIs (e.g., dfsdrop), which prevent resource leaks and allow error propagation via dedicated control packets without halting the network.^[3] Type safety is enforced at the connection level by verifying compatibility between the types declared on connected ports during network initialization, preventing runtime mismatches that could corrupt data flows. Metadata descriptors in IPs further support this by defining expected formats and structures, enabling processes to validate and transform data as needed—such as through type-specific handlers—while special IP variants (e.g., control IPs for substreams) maintain consistency across the network. This rigorous typing, combined with the asynchronous yet bounded nature of connections, underpins FBP's reliability in distributed and concurrent applications.^[3]

Networks and Execution

In flow-based programming (FBP), a network is defined as a directed graph—potentially acyclic or cyclic—comprising interconnected black-box processes that collectively form a complete, executable application. These processes communicate exclusively through predefined connections that carry information packets (IPs), enabling modular assembly where the network topology is specified separately from the processes themselves. This graph structure supports hierarchical composition via subnets, allowing complex applications to be built from reusable components without tight coupling.^[1] Execution in FBP networks is demand-driven, meaning processes activate only when IPs are available on their input connections, facilitating asynchronous and concurrent operation across multiple processors or cores. Scheduling is managed by a runtime scheduler that monitors connection queues and triggers processes based on data availability, incorporating back-pressure mechanisms to suspend upstream processes if downstream queues become full (unless configured otherwise, such as with a "DropOldest" policy). This approach inherently supports parallelism without the need for locks or shared state, as communication occurs via bounded, message-passing connections that prevent race conditions.^[1]^[2] Network initialization begins with source processes, which generate initial IPs from external inputs or constants, propagating through the graph as downstream processes become ready. Shutdown occurs when sink processes—those with no output connections or connected to external outputs—complete consumption of all IPs, signaling the closure of connections to upstream processes; closed connections trigger end-of-stream notifications, ensuring orderly termination without dangling data. This lifecycle maintains resource efficiency by suspending inactive processes until data arrives.^[2] FBP networks provide determinism in that individual process outputs depend on the content of input IPs and the fixed connection topology, with stateless processes avoiding shared state issues. However, at merge points, the sequence of IPs may vary based on arrival times influenced by concurrent execution and scheduling, potentially leading to non-reproducible results across runs. The loose data coupling still minimizes other nondeterministic side effects from scheduling variations.

Examples and Applications

Classic Problem Solutions

One of the earliest demonstrations of flow-based programming (FBP) principles is the telegram problem, originally posed by Peter Naur in 1968 as a text-wrapping task. In this problem, a program reads a width parameter w, followed by lines of text, and outputs reformatted lines containing as many words as possible without exceeding w characters, avoiding mid-word splits. The FBP solution transforms this sequential imperative approach into a parallel network by treating individual words as information packets (IPs) that flow through black-box processes.^[17] Key components include a pair of complementary processes—one to serialize input text into word IPs and another to deserialize output IPs into lines—connected via initial information packets (IIPs) that carry the width parameter. This setup highlights FBP's ability to decompose linear problems into concurrent, reusable subprocesses, where parsing, validation, and routing occur in a distributed manner without shared state.^[17] Another foundational example is the batch update problem, which models the merging of a master file with transaction details to produce an updated master and exception reports. In FBP, this is achieved through a network where IPs representing records flow from input sources into a central "Collate" component, a reusable black box that synchronizes multiple streams using bracket IPs to group related records (e.g., pairing each master record with its corresponding detail transactions). Transformer processes then apply idempotent changes—ensuring operations like updates or validations can be retried without side effects—before outputs branch to updated files and report sinks. This structure emphasizes FBP's strength in handling deterministic data processing pipelines, where connections enforce order and parallelism emerges naturally from independent subprocess execution.^[17] FBP naturally supports multiplexing through fan-out and fan-in configurations, as seen in task distribution examples where a single input stream is parallelized across multiple worker instances. A load balancer process receives IPs from an upstream source and routes them to several identical black-box workers (e.g., three search components S1, S2, S3), each processing subsets independently on multi-processor hardware. Results then converge via a fan-in aggregator, maintaining order if needed through timestamping or queuing. This pattern demonstrates how FBP enables scalable parallelism without explicit threading, leveraging read-only components to avoid synchronization overhead and allowing dynamic instance scaling based on load.^[17] For interactive applications, a simple network illustrates FBP's handling of request-response loops. User inputs enter as IPs at one end, flowing through computation processes (e.g., validation or query execution) connected to backend sinks like message queues. Responses route back via cross-connections, using hash tables in subprocesses to correlate replies to original requests, forming a closed I/O cycle without blocking. This design, often visualized with requests entering upper-left and exiting lower-right, underscores FBP's event-driven concurrency, where black-box processes and predefined connections manage state isolation in real-time interactions.^[17]

Modern Data Processing Uses

Flow-based programming (FBP) has found significant application in extract-transform-load (ETL) pipelines for big data systems, where it enables the modular assembly of data ingestion, transformation, and loading processes. Apache NiFi, built on FBP principles, automates the flow of data between heterogeneous systems, supporting operations such as routing, mediation, and guaranteed delivery through its processor-based architecture.^[18] This structure allows developers to define ETL workflows as interconnected black boxes that handle diverse data formats and volumes, making it suitable for enterprise-scale integrations without custom scripting for each step.^[18] In streaming analytics, FBP facilitates real-time processing networks for Internet of Things (IoT) and event-driven architectures by modeling data as packets flowing through dynamic connections. For instance, NiFi processes sensor data streams by chaining processors that perform filtering, aggregation, and enrichment in near real-time, enabling applications like predictive maintenance in industrial IoT setups.^[18] Similarly, Node-RED, a browser-based FBP tool, enables visual wiring of flows for IoT data processing, supporting real-time event handling across devices and services.^[19] This approach leverages the network execution model, where components activate based on available input packets, supporting low-latency handling of continuous data flows from devices.^[18] FBP supports AI workflow orchestration by chaining preprocessing, model inference, and post-processing as composable components, particularly in machine learning pipelines. Graphical FBP tools have been proposed to abstract Apache Spark ML libraries, allowing non-experts to visually assemble workflows for tasks like classification and recommendation, with automatic code generation for execution.^[13] Empirical evaluations demonstrate FBP's utility in deploying ML models, such as in ride allocation systems where data collection from multiple sources feeds into inference components, streamlining end-to-end orchestration compared to service-oriented alternatives.^[20] The scalability of FBP in cloud environments stems from its inherent support for auto-parallelism and distributed execution, where networks can span microservices without tight coupling. In ML deployments, FBP reduces cognitive complexity and maintenance overhead by centralizing data flows, as shown in applications requiring updates across distributed components, achieving up to twice the efficiency in dataset management over service-oriented architectures.^[20] NiFi exemplifies this in cloud clusters, scaling to process up to 256 million events per second across 1,000 nodes (as of April 2020 benchmarks), with features like load balancing and zero-master clustering enabling elastic resource allocation in microservices-based setups.^[21]

Implementations and Tools

Programming Languages and Frameworks

Flow-based programming (FBP) has been implemented in various programming languages through dedicated libraries and frameworks that enable the construction of networks of processes exchanging information packets. The original implementations trace back to J. Paul Morrison, the paradigm's inventor, who developed the first FBP system in 1969–1970 using IBM S/360 assembly language as AMPS (Advanced Modular Processing System). Later textual implementations include C-based prototypes from the 1990s for Unix systems, allowing asynchronous process communication via pipes and files; these laid the groundwork by providing a runtime for defining black-box processes and connections programmatically. Morrison also authored JavaFBP, a Java library integrated with the DrawFBP tool, which compiles graphical definitions into executable Java code for building and running FBP networks, emphasizing modularity and reusability in enterprise applications. An upgraded C implementation, CppFBP (using C++ with Boost and Lua scripting for processes), was developed starting in 2013.^[1]^[22]^[23]^[24] In the JavaScript ecosystem, NoFlo emerged in 2011 as a prominent FBP implementation for both Node.js server-side applications and browser environments, facilitating the creation of dataflow graphs where components process information packets in a decoupled manner. NoFlo separates control flow from business logic, supporting runtime reconfiguration and integration with reactive programming extensions like RxJS for handling asynchronous streams and events within FBP networks. This makes it suitable for web-based automation and real-time data processing, with components defined as JavaScript modules that connect via ports.^[25]^[10]^[26] Other languages have seen FBP-inspired libraries that adapt the paradigm for specific use cases, such as streaming and orchestration. In Python, Streamz provides a framework for building continuous data pipelines using reactive streams, where data flows through connected operators in a manner akin to FBP processes, supporting backpressure and integration with libraries like Dask for parallel execution. This enables FBP-like orchestration for real-time analytics without explicit threading management.^[27]^[28] For concurrent pipelines in Go, GoFlow offers a lightweight runtime that models applications as directed graphs of tasks communicating over channels, leveraging Go's goroutines for efficient, non-blocking execution of FBP networks.^[29]^[30] Integration frameworks like Apache Beam incorporate FBP-like principles through its unified model for bounded dataflows, where pipelines are defined as graphs of transforms processing collections in batch or streaming modes. Beam's SDKs, available in multiple languages including Java, Python, and Go, enforce deterministic execution and bounded buffering to prevent unbounded memory growth, aligning with FBP's emphasis on controlled information packet exchange. As of 2025, Beam has been updated with releases such as version 2.68.0 (September 2025), enhancing hybrid batch/streaming capabilities for scalable data processing in cloud environments.^[31]^[32]

Visual Development Environments

Visual development environments for flow-based programming (FBP) enable designers to construct, simulate, and debug networks of processes and connections through graphical interfaces, leveraging the paradigm's inherent visual nature to enhance comprehension and collaboration. These tools typically support drag-and-drop assembly of components, real-time visualization of data flows, and integration with runtime execution, allowing users to prototype complex systems without writing traditional code. By representing FBP networks as diagrams, such environments reduce cognitive load and facilitate iterative development, particularly for distributed or concurrent applications.^[1] DrawFBP, developed by J. Paul Morrison, the originator of FBP, is a Java-based diagramming tool that permits users to draw multi-level FBP networks visually, simulate their execution, and export diagrams to executable code in languages like Java or C++. It emphasizes hierarchical structuring, where subnets can be collapsed or expanded for clarity, and includes features for tracing information packet flows during simulation to identify bottlenecks or errors. This tool has been instrumental in demonstrating FBP concepts since its inception, supporting both educational and practical network design.^[33]^[34] FlowHub and NoFlo UI represent web-based platforms for collaborative FBP development, with NoFlo UI serving as an open-source, browser-hosted editor and FlowHub providing a managed, multi-user environment as of 2025. Built around the NoFlo JavaScript FBP runtime, these tools offer drag-and-drop connection of components from extensible libraries, live runtime visualization of packet exchanges, and real-time collaboration for distributed teams. They support rapid prototyping by allowing immediate execution and debugging within the browser, making them suitable for web and IoT applications.^[35]^[25] Other notable tools include Node-RED, which draws influence from FBP principles to provide a browser-based editor for wiring together hardware devices, APIs, and online services in IoT flows, featuring drag-and-drop nodes and live flow tracing. Similarly, Slang by Bitspark offers a purely visual, no-code editor for stream processing networks, where users compose graphs without predefined components, enabling custom process creation through intuitive diagramming and execution monitoring. These environments collectively highlight FBP's strengths in visual prototyping, with shared capabilities like component reuse from libraries and execution debugging to accelerate development cycles.^[36]

Comparisons

With Dataflow and Reactive Paradigms

Flow-based programming (FBP) represents a specialized variant of dataflow programming, where applications are constructed as networks of black box processes connected explicitly via predefined ports for exchanging discrete information packets, rather than relying on implicit data dependencies or fine-grained operators common in general dataflow systems.^[1] In contrast to languages like LabVIEW, which employ visual wiring for dataflow execution driven by token availability and supports black box encapsulation through modular components, FBP prioritizes modularity through reusable, self-contained components that maintain internal opacity and support loose data coupling for easier reconfiguration and maintenance.^[37] This explicit connection model in FBP fosters higher-level composition over the operator-centric granularity often seen in pure dataflow paradigms, enabling asynchronous concurrency without adhering strictly to traditional dataflow firing rules.^[38] Compared to reactive programming, FBP adopts a push-based mechanism for propagating bounded data packets across fixed network topologies, diverging from the observable stream model in libraries like RxJS, where continuous data flows and change propagation rely on subscription-based event handling and operators for transformation.^[39] FBP eschews callback-heavy patterns inherent in reactive streams, instead emphasizing discrete, self-contained units of information that traverse composable pipelines, which reduces complexity in managing unbounded or infinite streams.^[1] While reactive programming excels in declarative handling of dynamic events and backpressure through protocols like Reactive Streams, FBP's packet-oriented approach provides deterministic flow control via bounded buffers, avoiding the potential for cascading reactions in event-driven scenarios.^[40] Both paradigms share foundational traits in supporting asynchronous processing and data-driven execution, allowing for scalable parallelism without explicit thread management; however, FBP centers on static, network-based composition of modular components, whereas reactive programming focuses on propagating changes through observable dependencies, often in functional contexts.^[37] This overlap in concurrency models has led to synergies, particularly in the 2020s, where hybrid approaches integrate FBP's structured workflows with reactive elements for dynamic, real-time data pipelines, as seen in frameworks combining modular data flows with just-in-time reactive code generation to enhance adaptability in machine learning and task automation.^[41]

With Object-Oriented and Actor Models

Flow-based programming (FBP) contrasts with object-oriented programming (OOP) in its emphasis on stateless process networks that exchange data via information packets (IPs), rather than relying on class hierarchies and synchronous method calls. In OOP, programs are structured around objects that encapsulate state and behavior, often using inheritance to create specialized subclasses, such as deriving a "Pontiac" class from a "Vehicle" base class. FBP, however, avoids inheritance altogether, promoting composition through explicit connections between independent, black-box processes that operate on streams of IPs, allowing for greater flexibility and reusability without the rigidity of deep inheritance trees. This approach aligns with design principles where processes are selected based on functionality rather than modeling real-world entities, reducing maintenance issues associated with tightly coupled hierarchies.^[42]^[43] Compared to the actor model, FBP employs typed, directed IPs flowing through named ports and bounded buffers, ensuring predictable, one-way communication along predefined connections, whereas actors communicate via untyped messages sent to dynamic mailboxes, as seen in systems like Akka or Erlang. In the actor model, each actor maintains its own internal state and processes messages asynchronously from any sender, enabling flexible, non-deterministic concurrency but requiring careful management of state isolation. FBP strictly prohibits shared mutable state among processes—relying instead on read-only global references when needed—thus guaranteeing determinism and simplifying debugging, while actors encapsulate state within individual entities, which can lead to more complex synchronization in distributed scenarios.^[44] A key advantage of FBP over both OOP and the actor model is its facilitation of inherent parallelism without the need for explicit synchronization mechanisms, as processes execute independently on data availability, making it well-suited for scalable, distributed applications. However, FBP is less ideal for modeling long-lived, stateful entities, where OOP's encapsulation or actors' internal state management provides more natural abstractions for persistent object lifecycles. These distinctions were first articulated by J. Paul Morrison in his 1994 book Flow-Based Programming: A New Approach to Application Development, where he highlighted FBP's modularity as complementary to OOP's strengths in graphical interfaces but superior for asynchronous business logic. In modern contexts, such as microservices architectures, FBP complements OOP by offering a data-flow overlay for orchestrating stateless services, enhancing scalability in distributed systems like the Industrial Internet of Things without introducing shared state complexities.^[42]^[43]^[45]

References

[1]
Flow-based Programming - J Paul Morrison
In computer programming, Flow-Based Programming (FBP) is a programming paradigm, discovered/invented by J. Paul Rodker Morrison in the late '60s, ...
[2]
None
### Summary of Flow-based Programming Description from the PDF
[3]
[PDF] Diagrams being upgraded, 2009 - J Paul Morrison
... Flow-Based Programming" (or FBP for short) to describe this new set of concepts and the software needed to support it. We have in the past used the term "Data ...
[4]
Flow-based Programming :: Introduction - J Paul Morrison
The processes communicate by means of fixed-capacity connections. A connection is attached to a process by means of a port, which has a name agreed upon ...
[5]
Comparison between Flow-Based Programming and Object ...
Programmers coming to FBP from conventional programming have to undergo precisely the same paradigm shift: from concentrating on process to concentrating on ...
[7]
Flow-based Programming :: History - J Paul Morrison
History. FBP was invented by J. Paul Morrison in the early 1970s, and an early implementation of this technology has been in continuous production use at a ...Missing: origins | Show results with:origins
[9]
noflo/noflo: Flow-based programming for JavaScript - GitHub
NoFlo is an implementation of flow-based programming for JavaScript running on both Node.js and the browser. From WikiPedia: In computer science, flow-based ...Missing: 2011 | Show results with:2011
[10]
Flow-Based Programming for Machine Learning - MDPI
In particular, we intend to support graphical specification of ML programs via a flow-based programming paradigm and support auto-generation of target code, ...
[11]
Bitspark/slang: SLANG engine written in Go - GitHub
Slang is a visual flow-based programming language and programming system. It consists of the YAML-based Slang exchange format, the Slang daemon and the Slang ...
[12]
DeBasher: a flow-based programming bash extension for the ...
Apr 16, 2025 · We propose DeBasher, a tool that adopts the flow-based programming (FBP) paradigm, in which the workflow components are in control of their life ...
[13]
Flow-Based Programming: Scheduling Rules - J Paul Morrison
The process is activated as many times as there are input IPs. The decision as to when to deactivate is made within the logic of the component - it is quite ...Missing: cycles | Show results with:cycles
[14]
https://bmcbioinformatics.biomedcentral.com/articles/10.1186/s12859-025-06108-1
[15]
Flow-based Programming :: Examples - J Paul Morrison
Telegram Problem. FBP components often form complementary pairs. This example uses two such pairs. The problem described seems very simple as described in ...
[16]
Apache NiFi Overview
Oct 21, 2024 · NiFi was built to automate the flow of data between systems. While the term 'dataflow' is used in a variety of contexts, we use it here to mean the automated ...
[17]
[PDF] An Empirical Evaluation of Flow Based Programming in the Machine ...
Apr 27, 2022 · Towards agile large- scale predictive modelling in drug discovery with flow-based programming design principles. ... [34] J Paul Morrison.
[18]
Processing one billion events per second with NiFi - Cloudera
Apr 9, 2020 · We conclude our exploration of NiFi's scalability by scaling out to 1,000 nodes using 12-core Virtual Machines. We gathered performance ...
[19]
https://nodered.org/about/
[20]
NoFlo | Flow-Based Programming for JavaScript
NoFlo is a JavaScript implementation of Flow-Based Programming (FBP). Separating the control flow of software from the actual software logic.Missing: 2020s | Show results with:2020s
[21]
NoFlo: two years of flow-based programming - Henri Bergius
Jun 5, 2013 · Flow-based engine that works well in both browser and Node.js; Growing ecosystem of reusable open source components; Framework for quickly ...Why I Started Noflo · The Logic Is In The Graph · Noflo On The BrowserMissing: 2000s 2010s
[22]
Streamz — Streamz 0.6.4 documentation
Streamz helps you build pipelines to manage continuous streams of data. It is simple to use in simple cases, but also supports complex pipelines.Missing: based | Show results with:based
[23]
python-streamz/streamz: Real-time stream processing for python
Streamz helps you build pipelines to manage continuous streams of data. It is simple to use in simple cases, but also supports complex pipelines.
[24]
ANN: GoFlow - Flow-based programming package for Go
Feb 13, 2012 · There is a rule in Flow-based programming defined by J. Paul Morrison: multiple outputs can be connected to a single input, the packets will ...
[25]
Apache Beam®
Apache Beam is an open source, unified model and set of language-specific SDKs for defining and executing data processing workflows, and also data ingestion ...Overview · Documentation · Programming Guide · WordCount quickstart for Java
[26]
Apache Beam 2.68.0
Sep 22, 2025 · We are happy to present the new 2.68.0 release of Beam. This release includes both improvements and new functionality.
[27]
jpaulm/drawfbp: Tool for Creating and Exploring Flow ... - GitHub
DrawFBP is a picture-drawing tool that allows users to create multi-level diagrams implementing the technology and methodology known as Flow-Based Programming ...Missing: JP | Show results with:JP<|control11|><|separator|>
[28]
https://github.com/python-streamz/streamz
[29]
noflo/noflo-ui: NoFlo Development Environment - GitHub
The NoFlo Development Environment is an offline-capable, client-side web application that helps users to build and run flow-based programs built with FBP ...
[30]
Bitspark - 2025 Company Profile, Team & Competitors - Tracxn
Aug 3, 2025 · Company Details. Bitspark offers Slang, a visual flow-based programming language. It follows a no-code approach and represents programs using ...
[31]
[PDF] Advances in Dataflow Programming Languages
Flow-Based Programming: A New Approach to Application Development. van Nostrand Reinhold, New York, NY. MOSCONI, M. AND PORTA, M. 2000. Iteration con ...
[32]
[PDF] Exploring the potential of flow-based programming for machine ...
Aug 9, 2021 · Flow-based programming was created by J.P. Morrison [28], and can be considered a special case of the more general dataflow pro- gramming ...
[33]
Introduction to Reactive Programming - Project Reactor
Reactive programming is an asynchronous programming paradigm concerned with data streams and the propagation of change.
[34]
A survey on reactive programming - ACM Digital Library
This survey describes and provides a taxonomy of existing reactive programming approaches along six axes.
[35]
[PDF] A Composable Just-In-Time Programming Framework with LLMs ...
Jun 27, 2023 · Flow-Based Programming (FBP) offers a structured, modular and reactive workflow model that aligns well with the dynamic nature of task execution ...
[36]
Comparison between FBP and Object-Oriented Programming
This chapter has been excerpted from the book "Flow-Based Programming: A New Approach to Application Development" (van Nostrand Reinhold, 1994), by J.Paul ...
[37]
Flow-based Programming :: Comparison - J Paul Morrison
Comparison between FBP and Object-Oriented Programming (Chapter 25 of the 2nd edition) goes into more detail on the relationship between FBP and OOP. This ...
[38]
Actors And Flow Based Programming Discussion - C2 wiki
Actors can receive messages from any sender; CSP processes must explicitly name the sending process. FBP processes can only receive IPs from processes they are ...
[39]
Control Flow Versus Data Flow in Distributed Systems Integration
Aug 16, 2021 · Control Flow Versus Data Flow in Distributed Systems Integration: Revival of Flow-Based Programming for the Industrial Internet of Things.