Flow-based programming
These black box processes can be reconnected endlessly to form different applications without having to be changed internally.
FBP is a particular form of dataflow programming based on bounded buffers, information packets with defined lifetimes, named ports, and separate definition of connections.
It views an application not as a single, sequential process, which starts at a point in time, and then does one thing at a time until it is finished, but as a network of asynchronous processes communicating by means of streams of structured data chunks, called "information packets" (IPs).
In this view, the focus is on the application data and the transformations applied to it to produce the desired outputs.
The network is defined externally to the processes, as a list of connections which is interpreted by a piece of software, usually called the "scheduler".
Because FBP processes can continue executing as long they have data to work on and somewhere to put their output, FBP applications generally run in less elapsed time than conventional programs, and make optimal use of all the processors on a machine, with no special programming required to achieve this.
[1] The network definition is usually diagrammatic, and is converted into a connection list in some lower-level language or notation.
Many other flow-based languages/runtimes are built around more traditional programming languages, the most notable[citation needed] example is RaftLib which uses C++ iostream-like operators to specify the flow graph.
[4] FBP at its inception was strongly influenced by some IBM simulation languages of the period, in particular GPSS, but its roots go all the way back to Conway's seminal paper on what he called coroutines.
[5] FBP has undergone a number of name changes over the years: the original implementation was called AMPS (Advanced Modular Processing System).
Because IBM considered the ideas behind FBP "too much like a law of nature" to be patentable they instead put the basic concepts of FBP into the public domain, by means of a Technical Disclosure Bulletin, "Data Responsive Modular, Interleaved Task Programming System",[6] in 1971.
[7] A second implementation was done as a joint project of IBM Canada and IBM Japan, under the name "Data Flow Development Manager" (DFDM), and was briefly marketed in Japan in the late '80s under the name "Data Flow Programming Manager".
From the early '80s to 1993 J. Paul Morrison and IBM architect Wayne Stevens refined and promoted the concepts behind FBP.
Stevens wrote several articles describing and supporting the FBP concept, and included material about it in several of his books.
FBP thus exhibits what Raoul de Campo and Nate Edwards of IBM Research have termed configurable modularity.
Oddly enough, this image is very similar to that of unit record equipment that was used to process data before the days of computers, except that decks of cards had to be hand-carried from one machine to another.
[13] In conventional logic, the programmer rapidly discovers that neither the input nor the output structures can be used to drive the call hierarchy of control flow.
Its starting point is to describe the application as a set of "main lines", based on the input and output data structures.
One of these "main lines" is then chosen to drive the whole program, and the others are required to be "inverted" to turn them into subroutines (hence the name "Jackson inversion").
FBP and JSP share the concept of treating a program (or some components) as a parser of an input stream.
Jackson discusses the possibility of directly executing the network model that exists prior to this step, in section 1.3 of his book (italics added): FBP was recognized by M A Jackson as an approach that follows his method of "Program decomposition into sequential processes communicating by a coroutine-like mechanism"[16] W.B.
These functions are then combined to make more complex transformations, as shown here: If we label streams, as shown, with lower case letters, then the above diagram can be represented succinctly as follows: Just as in functional notation F can be used twice because it only works with values, and therefore has no side effects, in FBP two instances of a given component may be running concurrently with each other, and therefore FBP components must not have side-effects either.
The difference between the two techniques is illustrated by the Linda "school of piranhas" load balancing technique - in FBP, this requires an extra "load balancer" component which routes requests to the component in a list which has the smallest number of IPs waiting to be processed.
The object's internal data can only be accessed by means of method calls, so this is a form of information hiding or "encapsulation".
In FBP, part of the specification of a component is the data formats and stream structures that it can accept, and those it will generate.
FBP considers Carl Hewitt's actor as an asynchronous processes with 2 ports: one for input messages and one for control signals.
