From the get-go, the MD-SAL architecture was split into two distinct worlds: Binding-Independent (BI, DOM) and Binding-Aware (BA, Binding).

This split comes from two competing requirements:

Type-safety provided by Java, for application developers who interact with specific data models
Infrastructure services that are independent of data models.

Type-safety is supported by interfaces and classes generated from YANG models. It generally feels like any code, where you deal with DTOs.

Infrastructure services are supported by an object, model similar to XML DOM, where you deal with hierarchical “document” trees. All you have to go by, are QNames.

For obvious reasons, most developers interacting with OpenDaylight have never touched the Binding Independent world, even though it underpins pretty much every single feature available on the platform.

The old OpenDaylight SAL architecture looked like this:

A very dated picture of how the system is organized.

It is obvious that the two worlds need to seamlessly interoperate.

For example, RPCs invoked by one world, must be able to be serviced by the other. Since RPCs are the equivalent of a method call, this process needs to be as fast as possible, too.

That leads to a design, where each world has its own broker and the two brokers are connected. Invocations within the world would be handled by that world’s broker, foregoing any translation.

The Binding-Aware layer sits on top of the Binding Independent one. But it is not a one-to-one mapping.

This comes from the fact, that the Binding-Independent layer is centered around what makes sense in YANG, whereas the Binding-Aware layer is centered around what makes sense in Java, including various trade-offs and restrictions coming from them.

Binding-Aware: what makes sense in Java.

Binding-Independent: what makes sense in YANG.

Remote Procedure Calls

For RPCs, this meant that there were two independent routing tables, with repeated exports being done from each of them.

The idea of an RPC router was generalized in the (now long-forgotten) RpcRouter interface. Within a single node, the Binding & DOM routers would be interconnected.

For clustered scenarios, a connector would be used to connect the DOM routers across all nodes. So an inter-node Binding-Aware RPC request from node A to node B would go through:

BA-A → BI-A → Connector-A → Connector-B → BI-B → BA-B (and back again)

Both the BI and connector speak the same language – hence they can communicate without data translation.

The design was simple and effective but has not survived the test of time. Most notably, the transition to dynamic loading of models in the Karaf container.

BA/BI Debacle: Solution

Model loading impacts data translation services needed to cross the BA/BI barrier, leading to situations where an RPC implementation was available in the BA world, but could not yet be exported to the BI world. This, in turn, leads to RPC routing loops, and in the case of data-store services – missing data & deadlocks.

To solve these issues, we have decided to remove the BA/BI split from the implementation and turn the Binding-Aware world into an overlay on top of the Binding-Independent world.

This means, that all infrastructure services always go through BI, and the Binding RPC Broker was gradually taken behind the barn, there was a muffled sound in 2015.