Implementing Paths

The aim of CloudB is to provide users and consumers with the widest range of possibilities: freedom of choice. Actually, all the database solutions currently (08/03/2011) shown by comparable projects bind systems with one single data-model (either a NoSQL, SQL, GraphDB, etc.) that applications have to deal with with no alternatives, other than implementing separate instances of the storage network.

In the core of the architecture of CloudB beneath the idea of letting users to define their own data-modeling, letting the system to administer the rest (distribution, replication, parallelization): simply plug-in the Path Type library and specify the kind of data-model the path will respect at the time of its creation: and that's all.

Server Side

The mandatory passage for implementing a path type is to define a .NET class (currently only .NET and Mono are supported: it's still unplanned if to support other languages as well) that will implement the interface Deveel.Data.Net.IPath.

using System;

using Deveel.Data;
using Deveel.Data.Net;

namespace Foo.Bar {
    public class ExamplePath : IPath {
        public void Init(IPathConnection connection) {
            // at this point the path instance has been created and
            // is ready to be added to the repository of path types
            // of the system: this method will be called just once
            // to initialize and configure the path before being
            // available to everyone.
        }

        public DataAddress Commit(IPathConnection connection, DataAddress rootNode) {
            // the user has requested to commit some changes to the database,
            // that are signed as 'proposed' and currently stored at the
            // address indicated by 'rootNode'.
            // when the commit has success, the path returns an address that
            // points to the data processed.
        }
    }
}

As it is clearly visible in the example, there are two states that are respected by a path type, that are the initialization moment (optional) and the commit moment (mandatory). Every node of a CloudB network that supports ExamplePath will be called to initialize the path instance just once, at the moment of its creation, and will be issued with the data 'proposed' by the user, to be processed at commit time.

CloudB is in fact a purely transactional system: every operation of modification must go through a transaction. In this architecture, paths are called to process data at transaction time, to which they can answer returning the address of the data processed, or throwing a CommitFaultException. If during a transaction commit a single node fails to process data, the entire process fails and data remain unchanged.

Creating Path Instances

When creating a path, the user specifies the name of the path (eg. 'testdb') and the path type (eg. 'cloudbase'): the system will be informed of this request and will establish a path with the given name and type, available within the network.

The following example creates the path 'testdb' of type 'Deveel.Data.BasePath' to the root machine '192.168.0.5', listening on port '3500'.

antonello@deveel:~$ cadmin add path 'Deveel.Data.BasePath, cloudbase' testdb to 192.168.0.5:3500

In this specific case, a faster way to write this command would have been

antonello@deveel:~$ cadmin add base path testdb to 192.168.0.5:3500

In fact, Deveel.Data.BasePath, defined in the assembly 'cloudbase' is already known by the Cloud Administration Tool and the command is shortened by design. For all other kind of path types the first example is valid.

Client Side

Path Client Service

Existing Path Types