Adaptive Framework 0.9.0


Adaptive Framework (AFW) is a framework for building applications that facilitate the access of data from common sources, such as databases, and presents the data and its metadata in flexible formats that can be consumed and interacted with by clients or applications that work well with object data. You will find that many aspects of its design resemble common technologies, such as Object-Relational Mapping (ORM), Enterprise Integration Patterns (EIP) and Enterprise Service Buses (ESB). This framework implements many of those same ideas and patterns in a way that's very extensible, adaptable to technology changes, considerate of open standards, and available as open source.

While many of the development-time tools were written in Python and much of the user interface components were written in TypeScript and Javascript, the core of Adaptive Framework is written in C, a language in which the primary engineers have had decades of experience with. This implementation decision affords us fine-grain control over some of the more technical aspects covered by this framework, while benefiting from the notable efficiency characteristic of C. However, it is intended that users of the framework will likely never have to write a line of C code. Instead, using the built-in extensions, configuration files, language bindings, expressions and scripts, you can influence the adaptive framework runtime without having to build or recompile anything.

It's important to understand that this is a framework, not a product or solution, and everything provided by Adaptive Framework are tools to help build applications that would benefit from these features. Specific application requirements will vary and some applications may wish to use more or less features from this framework than others.

Adaptive Framework was also designed to be modular. A core set of features exist, but extensions can be added at runtime and register additional features that look just like first-class citizens.

Objects and Metadata

Adaptive Framework was partially inspired by ideas and concepts from Adaptive Object Model ( Nearly everything in Adaptive Framework is described by objects and metadata. By separating data from metadata, and representing them by separate objects, we achieve flexibility over design that is very dynamic and doesn't require recompilation when metadata is changed.


The origins of Adaptive Framework grew from a set of procedures and tools that were created for the purpose of maintaining an identity vault. We needed to integrate data from several systems and conform to the unique rules that each system presented. We also needed to conform to the unique needs of our user base. Data access, data transformations, provisioning and deprovisioning, web applications, security, and data inconsistencies were just some of the many challenges to our project. During this process, it was also became obvious that the only constant we could seem to rely on was change itself. Requirements, data, protocols and software were always changing. Staff, along with their expertise, moved between groups or retired. Vendors could go out of business and licensing costs could change. It was imperative, therefore, to design something that was adaptable to all of these moving parts.

One feature that we really wanted was to be able to plug in any database of choice and allow for all applications, new or legacy, to interoperate with with each other. We also wanted to harvest metadata from existing systems and use it to make business decisions without replicating code and policy. We wanted to be able to adapt to new software technologies and data formats without changing business rules that were in place. We needed the ability to generate documentation and APIs in order to keep up with the data model that was constantly changing. Finally, it was ideal for the solution to be open source. These emerging design features - the interface definitions, objects, metadata, data types, functions, expressions, languages, language bindings, command-line and web-based tools, doc and code generation - produced the Adaptive Framework.

Architecture Diagram

The following diagram constructs how the parts may be assembled together, to create an Adaptive Framework Application in order to demonstrate how the parts are constructed, visually. This application leverages extensions to interact with external databases in various data formats and uses configuration files and objects to influence how it will respond to client requests.

Adaptive         Application Architecture
Adaptive Application Architecture

Adaptive Framework Core

The Adaptive Framework Core refers to the functionality that is provided by the framework, by default. Core includes built-in interfaces, data types, functions, extensions, adaptors for persisting objects, logs and request handlers. It also includes a runtime environment and a language interpreter to evaluate Adaptive Scripts and Expressions.


Extensions are shared libraries that are able to be loaded dynamically at runtime by Adaptive Framework Core. These extensions can then register additional functionality, such as new data types, functions or adaptors.


Services bundle configuration objects with extension implementations, along with startup instructions, to deploy a dynamically reloadable unit of work. These may include logging, database adaptors, authorization handlers and more.


The Server in this example is a compiled binary that is linked against the Adaptive Framework Core, and may load extensions at runtime based on configuration files that it has been provided. It will also instantiate a request handler in order to process client requests. The Adaptive Framework provides a default server implementation, based on FastCGI, which can be used behind a web server such as Apache or Nginx.

Configuration Objects

In order to configure an application, we use Configuration Objects, along with a single afw.conf file to instruct the application instance which extensions to load, what services to start and where to locate additional configurations.


The Data in this diagram may be optional, structured databases, object stores, log files, event journals, or anything else that may be used by services to read or persist data.


The Application is the sum of everything in this diagram, and is defined to Adaptive Framework through a special configuration object. This documents the application and provides some additional processing instructions, such as which extensions to load at startup, a default authorization script, general file path information and some properties useful for the Administrative Web Application.