Architecture
After the Introduction it should hopefully be clear in what context Transformer was created. Here we'll go into more detail on the architecture of Transformer.
Here's a graphical representation of how Transformer fits in a network device running OpenWrt or LEDE:
- Transformer is a separate daemon and cwmpd talks to it over a (Unix domain) socket.
- Clients like cwmpd send it requests very similar to the TR-069 RPCs like GetParameterValues, SetParameterValues, ... and will receive responses that are following the semantics for those RPCs.
- Transformer core is a framework that provides the infrastructure for a data model suitable for TR-069.
- The actual data model contents is provided by mappings.
- The idea is that mappings shouldn't have to know much about TR-069 and TR-106 semantics because that is taken care of by Transformer.
- To add an objecttype to the data model a mapping has to register a description of it. This consists of two parts:
- The metadata of the objecttype. This metadata can be generated offline using a tool that is provided along with Transformer. This tool reads the official data model descriptions provided by Broadband Forum in XML format and outputs a suitable structure for use in a mapping.
- Logic that maps the objecttype and its parameters to the actual data in the system. In an OpenWrt/LEDE system this usually means reading/writing UCI config files for persistent configuration and ubus for state and statistics. This logic can be as simple or as complex as needed; it depends on how well the standard data model matches with how this is configured or implemented on the device.
- Transformer is written in Lua 5.1. There are several reasons for that:
- Implementing a data model involves a lot of string manipulation. Doing that in C is tedious and rather error prone (memory leaks, segfaults).
- Lua allows the code to focus more on the functionality than on low level details.
- Lua code is easier to test in a unit/functional way.
- Because Lua code does not require a compile and link step it allows direct editing and testing on the device itself.
- The dynamic type system of Lua provides more flexibility to extend APIs without breaking backwards compatibility. It also avoids having to define all kinds of data structures upfront, leading to e.g. "union hell".
- For a scripting language Lua is very fast, lean and easy to connect to C libraries.
- Lua features like closures and coroutines allow for nice clean code.
Let's go a bit more into detail on how Transformer is structured.
Here's a more detailed look at the different parts of Transformer.
- The real core of Transformer is a collection of Lua modules with the client API as the public interface. On top of this interface a main is written. This main intializes the core based on configuration read from UCI and effectively exposes the client API over a Unix domain socket in the abstract namespace. It uses
uloopas event loop implementation (mainly because that made it trivial to make it possible for mappings to listen for ubus events, but more on that in the section about eventing). - Upon initialization the Transformer core will read all files ending in
.mapfrom the specified locations and execute them. These mappings will initialize themselves and register their objecttypes with Transformer, more specifically in the typestore.