Openwest 2015 - Samuel Smith - "Flow Based Programming" (186)
Flow Based Programming (FBP) is a relatively unknown programming paradigm even though its been around as long as OOP and FP. There are no well know FBP languages. The best way to use FBP in a framework build on top of another language. Even when not using a FBP framework, programming in the style of FBP can be advantageous especially in complex distributed applications. The design of a modern distributed application can be daunting, especially if it requires the coordinated automation of multiple asynchronous tasks. A typical architecture must select and integrate a menagerie of services and libraries, which can get complicated very quickly for the developer.
Flow Based Programming (FBP), on the other hand, provides a simplifying unifying paradigm that is ideally suited for modern distributed applications, especially those requiring the coordination of multiple asynchronous tasks. This unifying paradigm can result in a great reduction in the complexity seen by the developer.
Even though a developer or architect never uses a formal FBP framework, the architectural principles behind FBP can be of great benefit as a design pattern for managing complexity in modern distributed applications. In many real world examples, elements of the FBP paradigm are used without the insight that it is a form of FBP. This presentation will show how FBP principles can guide design decisions even when not formally using FBP.
This presentation will describe the core features of the Flow Based Programming paradigm and show how they can be applied to distributed application architectures. This talk will also introduce some FBP frameworks, including Ioflo.
The flow-based programming (FBP) paradigm defines applications as networks of asynchronous behaviors, which exchange data by passing messages across externally defined connections, that are, the inputs, outputs, and parameters. These behaviors can be reconnected endlessly in different networks without any internal changes, in other words, behaviors are replacement independent, port based automata. A behavior transforms its inputs governed by its parameters into its outputs. FBP is thus naturally both component-oriented and data flow oriented.
Because at a low level FBP behaviors provide replacement independence, that is, it can be externally connected without any internal changes, composing complex networks is conceptually simple compared to a non-FBP approach.
Because the partitioning of a FBP network of behaviors occurs at the intra-process, not inter-process level, distribution of behaviors across processor resources does not change behavior internals.
An FBP framework facilitates the connecting and scheduling of networks of independent asynchronous components that exchange messages.
An FBP framework already begins where most other distributed application programming architectures are attempting to end up.
A well know architectural guideline for software design is the Dependency Inversion Principle. The DIP provides a way to
solve the following 'bad design' characteristics: [http://www.objectmentor.com/resources...]
A piece of software that fulfills its requirements and yet exhibits any or all of the following three traits has a bad design.
1. It is hard to change because every change affects too many other parts of the system. (Rigidity)
2. When you make a change, unexpected parts of the system break. (Fragility)
3. It is hard to reuse in another application because it cannot be disentangled from the current application. (Immobility)
The Dependency Inversion Principle:
A. HIGH LEVEL MODULES SHOULD NOT DEPEND UPON LOW LEVEL MODULES. BOTH SHOULD DEPEND UPON ABSTRACTIONS.
B. ABSTRACTIONS SHOULD NOT DEPEND UPON DETAILS. DETAILS SHOULD DEPEND UPON ABSTRACTIONS.
Flow based programming transcends the Dependency Inversion Principle thusly:
A. There are no modules just components.
B. There are no abstractions or details just data.
B. Components depend on data. Not other components.
Complexity Management
Actual complexity is defined as the number of dependencies between elements of a software system.
Apparent complexity is defined as the number of dependencies that programmers must manage in order to make meaningful enhancements to the software functionality.
A good design minimizes the ratio of apparent to real complexity.
Relative to other paradigms FBP excels at minimizes the actual to apparent complexity ratio. This has its greatest benefit at scale when the real complexity exceeds what is humanly possible to manage.
Saturday, May 9th, 10:00am-10:45am
Room SB 074 (Architecture)