Bobox
Bobox

The Bobox is highly parallel implementation of streaming system. Although it is the most suitable for data processing applications (such as databases), it can be easily used in many other areas.

The Bobox consists logically of two parts - back-end and front-end.

The front-end is responsible for generation of models (i.e. directed graph where the nodes are boxes and edges are connections and also provides implementation of boxes.

The back-end is responsible for instantiation of models and their evaluation.

If you want to develop your own Bobox application, all you need to do is to implement boxes (several boxes are already implemented in the library ), create a model with them and pass it to the back-end. This process is really easy and straightforward, as you can see for example here, here or here :-)

Implementation of boxes

Each box consist of two parts - the model of the box which describes important properties of the box and the implementation of the box which determines its behaviour.

Each box has some inputs and outputs , each input and output may contain multiple input arcs resp. output arcs .

The most common are I/Os which have exactly one arc, however, some boxes (e.g. broadcast) have I/Os with multiple arcs. The type of the I/O is determined by bobox::io_descriptor::multiplier_type. However, the developer of a box may choose if he wants to index I/O as input/output or input/output arc. See for example bobox::basic_box which contains methods for both possibilities.

The streams are represented as a flow of data envelopes . The end of the stream is indicated by the poisoned pill . The developer may access directly the envelopes and work with them, or use some class which makes manipulation with streams easier.

Creation of models

Basically, there are two ways of creating models. The first one is to use directly the class bobox::model, the second is the use of Bobolang Language . Both approaches may be combined, i.e. the static parts of the model might be written in Bobolang, the dynamic parts might be created programmatically.

The main model (i.e. the model which is passed to back-end) must have exactly one input and exactly one output. When the scheduler decides to evaluate the model, it sents one poisoned envelope to its input. Sending a poisoned envelope to the output means, that the evaluation has finished.