Flow-based Programming

Software on FBP Website

JavaFBP uses Java threads, so it makes optimum use of all the processors on the machine running the application. The C# and C++/Boost implementations (see below) also use their respective thread mechanisms.

JavaFBP

John Cowan built the first Java implementation of the FBP concepts, which was also the first implementation to use native threads, allowing it to take advantage of all the processors on the computer. This software, which has been undergoing continuous refinement and improvement during the years since, now called JavaFBP, is available as Open Source on GitHub. An older version is still on SourceForge, but is not being maintained.

Material on the syntax of JavaFBP component and network definitions and the component API can be found at JavaFBP Syntax and Component API.

In earlier JavaFBP versions, the scheduler presented an IIP to a component once per invocation. This has been changed as of JavaFBP-2.6 to once per activation.  In practice this will only affect "non-loopers" (components that get reactivated multiple times).  

Checking has been added (Aug., 2014) to make sure that all input connections have been provided. Since this was not being checked before, some users may have components that treat some input ports as optional. To make this explicit, a new optional parameter has been added to the InPort metadata. If this causes any problems for current users, please let us know.

Gradle is now being used for packaging. To build the project, make sure Gradle is installed, and then follow the instructions in the README file for this project.

JavaFBP has just been promoted (Jul. 20, 2016) to Maven Central.

JavaFBP Web Sockets

A simple server written using JavaFBP can also be found on GitHub. The source code includes generalized components for Websockets Receive and Respond: WebSocketReceive.java and WebSocketRespond.java respectively. The former generates a substream for each incoming request from the client, comprising:

• an open bracket,
• socket reference IP,
• data IP and
• close bracket,

while the latter accepts a substream of any length, and returns to the client indicated by the first IP all the other contained IPs.

These two components are basically TooTallNate's AutobahnServerTest code, split into two processes, and require the Java-WebSocket-1.3.0.jar file, which is available on Maven central.

There is also a video showing how this kind of application can be "grown" organically: https://youtu.be/IvTAexROKSA .

C#FBP

The C# implementation was originally created from the Java implementation by Amanda Ge using a conversion tool - it has since been extensively modified, but the two implementations are still fairly close. Material on the syntax of C#FBP component and network definitions and the component API can be found at C#FBP Syntax and Component API. This implementation is available as Open Source on GitHub. An older version is still on SourceForge, but is not being maintained.

In earlier C#FBP versions, the scheduler presented an IIP to a component once per invocation. This has been changed to once per activation.  In practice this will only affect "non-loopers" (components that get reactivated multiple times).  

Checking has been added (Aug., 2014) to make sure that all mandatory connections have been provided. Since this was not being checked before, some users may have components that treat some input ports as optional. To make this explicit, a new optional parameter will shortly be added to the InPort metadata. If this causes any problems for current users, please let us know.

Go FBP Implementation

Go implementation of FBP - may be found as Open Source on GoFBP

Go provides good compile-time checking, good performance, and a path to WebAssembly.

Material on the syntax of GoFBP component and network definitions and the component API can be found at GoFBP Syntax and Component API. This implementation is available as Open Source on GitHub.

DrawFBP can now generate GoFBP network and subnet definitions - one minor tweak may be needed when generating networks that use subnets - see the documentation.

Deadlock Handling in GoFBP

FBP deadlocks are well understood, and are handled by other FBP implementations on https://github.com/jpaulm . They also seem to be well detected by the Go scheduler - unfortunately, they are not so easy to troubleshoot, as Go deadlock detection is not "FBP-aware", and occurs before the GoFBP scheduler can analyze the process states to determine where the problem is occurring. See below.

As of the latest Release, a stand-alone program has been added, analyze_deadlock.go, which can be used to analyze the Go stack trace. Its .exe file can be found in the project bin directory. To analyze the deadlock, send the go test output to logfile, i.e.
go test -run ForceDeadlock -timeout 0ms > logfile
then execute
bin\analyze_deadlock.exe
The test must be run with generate-gIds set to true in params.xml.The output should be something like the following:

Sender Goroutine no.: 19
Counter Goroutine no.: 20
Concat Goroutine no.: 21
Process: Sender, Status: Send
Process: Counter, Status: Send
Process: Concat, Status: Receive

Now look at the list of goroutines involved, and add the component names to your diagram, together with the "state". Typically the deadlock will be "between" the goroutines waiting to Send and those waiting to Receive.

In MS-DOS, you can do the above all on one line, as follows:
go test -run ForceDeadlock -count=1 > logfile & bin\analyze_deadlock.exe
(Not sure if you can do this with PowerShell...?)

CppFBP and Lua Interface

The C implementation mentioned in the 1st edition of my book has been upgraded to use C++ and Boost, and is now called CppFBP - it also contains an interface component supporting the Lua scripting language, allowing FBP processes to be implemented as Lua routines.

Material on the syntax of CppFBP component and network definitions and the component API can be found at CppFBP Syntax and Component API. This implementation is available as Open Source on GitHub. An older version is still on SourceForge, but is not being maintained.

A component has been built for CppFBP which allows components (loopers or non-loopers) to be written in the Lua scripting language. We are now able to write multithreaded networks whose infrastructure is CppFBP, and where selected processes can be implemented using Lua scripts - in this environment the same Lua script can even be executing on multiple threads. Be aware, however, that non-loopers can be much slower, owing to the overhead of firing up a Lua environment each time.

Some examples of Lua scripts running under the generalized CppFBP Lua component (called ThLua) are shown in CppFBP/Lua Interface.

As Lua scripts communicate by way of character strings, if you need to pass more complex data structures through the network, you can also intermix CppFBP components in the same network - or other higher-level languages which play well with C++ and Boost.

This implementation is still under development (as of May, 2014), so there may be ongoing changes to the code and documentation.

JavaScript FBP Implementation (Archived)

JSFBP is a traditional, "classical" FBP implementation. It can be used for batch processing, and possibly for server apps (it would support an approach similar to that shown on the cover of "Flow-Based programming", 2nd ed., similar to that used by Facebook's Flux), and should appeal to people who want to use the same language for both the client and the server sides.

JSFBP only requires the addition of a small package on top of node.js, node-fibers, which is easy to install. I am informed by JavaScript experts that JavaScript has no plans to integrate node-fibers into its product evolution, for reasons that I find hard to understand, so JSFBP in its present form does not seem to be have good prospects for the long term. Moreover, JavaScript (and therefore JSFBP) does not take advantage of multiple cores, so this lack needs to be addressed for JavaScript in general.

JSFBP takes advantage of JavaScript's concept of functions as first-degree objects to allow applications to be built using "green threads". JSFBP has an internal "Future Events Queue" which supports the green threads, and provides quite good performance (average 0.82 microsecs per send/receive pair) - the JavaScript events queue is only used for JavaScript asynchronous functions, as before. Long-running functions such as reading and writing files must be implemented using callbacks, and this is supported by the JSFBP API.

Just as in the case of the other "classical" implementations, every IP has a lifetime from "create" to "drop", and it is owned by one process at a time. Once an IP has been "sent", it is no longer owned by the sending process, so it cannot be sent again by that process. Of course the process can take a copy before that point, and create a new IP using it, but then that will be a different IP. If the component wants to copy what I call an "IP tree", it can do that, but it is the component's responsibility, not the infrastructure's.

This implementation is available on GitHub. You can also find an example of a simple JSFBP component in Concat.

DrawFBP

A diagramming tool, called "DrawFBP", is also available on GitHub. For more complete information, including .jar files, source code, instructions on using it, etc., click on DrawFBP.

This tool is now available on Maven, so just go into Maven Search, and search for DrawFBP, or click on the "shield" in the Readme.md file. Download the .jar file from the most recent release in Maven, or alternatively from DrawFBP Releases, and execute it using the Java(TM) Platform SE binary.

The DrawFBP jar file contains the official JavaHelp module plus the geom2d package.

DrawFBP supports a basic "block", representing any process or subnet (an FBP network with "sticky" connections), which can be given a process name - these should be unique within a diagram. However, a block does not even need to be associated with a subnet or a simple component written in some programming language until the designer is ready to make implementation decisions. The "subnet" capability allows the designer to do stepwise decomposition - clicking on a subnet block brings up a tab showing the subnet, so the designer can easily move between the different levels of a diagram.

DrawFBP can also generate runnable networks in JavaFBP, C#FBP (with some tweaks to add components), NoFlo JSON, and the .fbp notation, originally developed by Wayne Stevens, and since adopted by the NoFlo project. The user can compile and run Java and C# networks, compare diagrams, and, in the case of Java, display descriptions and port names of precoded and precompiled components.

Diagrams are held in XML format, with an extension of .drw.

Simple DrawFBP diagram, showing both source code, and component classes.

Home