From Data Capturing to Data Sharing

In the beginning God created the Data Objects. And God blessed them, and God said unto them, Be fruitful, and multiply, and replenish the network, and subdue it: and have dominion over the protocols of the communication lines, and over the interfaces of the services, and over every bit that moveth upon the network.

Goodbye Network Computing, welcome Data Object Sharing

The classic concept of network computing is of a system that consists of multiple compute units, each that consumes some sort of data, does some calculation on it and produces the result data. The system deploys a mechanism that creates one-to-one connections between consumers and producers (the endpoints), brokers between them to let the latter understand what the former needs, and then delivers the data from its source to its destination. The structure of the delivered data is based on a contract between the two endpoints (the agreed interface). Each endpoint is supposed to have the necessary knowledge to locate the peer endpoint and then generate or interpret the data. All of these form the mechanism of Data Capturing

The Data Object Sharing concept turns this model upside down. The basic entity of a network is the Data. It consists of Data Objects that are structured in a hierarchy of data object types. The type determines the position of the object in the hierarchy (by telling the type of the object’s parent) and describes the object properties. Every application that joins the network can share data objects, and those are shared across the network so that when an application joins it has immediate access to the entire data regardless of its source.

The difference between the models has dramatic implications. Most notably, with the sharing model data delivery is not limited to one-to-one communication. Any application that produces a certain data type can share it over the network, and applications that consume this type get the data from all the sources without additional consideration.

Secondly, the view of the network as a collection of data objects enables powerful data delivery models. Hubs and routers can perform fine-grained multiplex and multicast of specific data objects. Additionally, since data objects of the same type tend to change over time only in a subset of their properties, powerful object-based data compression may be applied, similarly to video compression that is based on small discrepancies between successive frames. All together, the model allows spectacular reduction in network volume and acceleration of data delivery speed.

Another advantage of the sharing model is that it inherently supports pure event-driven programming, because the model implies that the basic units that travel through the network are events – of data object tree manipulations (insertions and removals) or property updates of existing data objects.

The Spiderwiz Programming Model and Runtime

Spiderwiz is an event-driven programming model and runtime that fully captures the power of the Data Object Sharing model. The foundation of the model is a Data Object Class Library, which contains the definitions of all the data object types used in a project. Each class defines object properties and the position of the object in the hierarchy, i.e. the type of its parent. The library classes usually do not include any implementation-specific code and are used by all the developers that participate in the project independently of each other.

Each service or microservice that plays a part in the mesh can be a producer or a consumer (or both) of some data object types. A producer manipulates the data object tree by inserting or removing objects, or updates the properties of existing objects, then commits the changes in order to share them over the network. The commits of the producers fire events at the consumers. A consumer handles the events by registering implementation classes that extend the library classes and implement event handling methods.

The Spiderwiz runtime library supports the programming model and hides everything else deep under the hood. That includes dealing with communication lines, network protocols, endpoints, services, interfaces, data serialization, compression, routing, multiplex and multicast, service discovery, pub/sub and all the cogwheels that require 90% of programming resources just to move the data around rather than dealing with the data itself. As a programmer, you never have to deal with them. As a system administrator, you just need to specify configuration parameters.

To get convinced that Spiderwiz delivers what it promises, put your hands on it through its tutorial. Go ahead and see how programming is a joy when it is easy as a Lego toy.