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.
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.
CppFBP and Lua Interface
More recently (fall 2013), the C implementation mentioned in the 1st edition 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 still older version, using fibers, is available as a zip file on the FBP web site.
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
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. An older version is still on SourceForge, but is no longer being maintained. The official version of DrawFBP is being maintained using GitHub and Gradle.
This tool is now available on Maven, so just go into Maven Search, and search for DrawFBP. 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.
To run the DrawFBP Help facility, you will be prompted to locate the javahelp.jar file. This is the standard JavaHelp jar file, and can be obtained from Maven Central, by doing a search for artifact javahelp, or from JavaHelp jar file, which has the same contents.
DrawFBP supports a basic "block", representing any process, which can be given a process name - these should be unique within a diagram. However, a block does not 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.
Diagrams are held in XML format, with an extension of .drw.
Simple DrawFBP diagram, showing both source code, and component classes.