SDN Controller Programming Guide

Unlike with relational systems, where entities and relationships are modeled and then indexes are

added to support whatever queries become necessary, with Cassandra queries that need to be

supported efficiently are thought of ahead of time.

Cassandra does not support joins at the query time because of its high scale distributed nature.

This mandates duplication and de-normalization of data. Every column family in a Cassandra

keyspace is self-contained with all data necessary to satisfy a given query. Thus, moving towards a

“Column Family per query” model.

In the HP VAN SDN Controller, define a column family for every entity. For each query on that

entity, define a secondary column family. These secondary column families serve exactly one

query.

Reference Application using Distributed Persistence

Any application that needs to use the distributed persistence in the HP VAN SDN Controller needs

to include/define the following components:

 A Business Logic component as OSGi service.

 A reference to Distributed DataStoreService and Distributed QueryService

 A DTO (transport object) per entity.

 DAO–Data access object to interact with the persistence layer.

 A sample of each of these will be presented in this section. For demonstration purposes, I

have created a Demo application that persists Alerts in the Distributed Database

(Cassandra).

Business Logic Reference

When the Cassandra demo application is installed, the OSGi service for business logic gets

activated. This service provides a north bound interface. Any external entity/app can use this

service via the API provided by this service. In this case, we have Alert service using Cassandra.

This service provides API for all north bound operations such as posting an Alert into the

database, deleting the alerts and updating the alert state. There is another interface that provides

for the READ operations and is mostly used by the GUI interface. This second north bound service

is called CassandraAlertUIService.

The implementation of these services needs to interact with the underlying persistence layer. This is

one by using an OSGi @Reference as shown below.

CassandraAlertManager.java:

@Component

@Service

public class CassandraAlertManager implements

CassandraAlertUIService, CassandraAlertService {

@Reference(policy = ReferencePolicy.DYNAMIC,

cardinality = ReferenceCardinality.MANDATORY_UNARY)

private volatile DataStoreService<DataStoreContext> dataStoreService;

@Reference(policy = ReferencePolicy.DYNAMIC,

cardinality = ReferenceCardinality.MANDATORY_UNARY)

private volatile DistQueryService<DataStoreContext> queryService;

...