feature explorer kernel application composition

NOTE: This page is still being written

DISCLAIMER: This documentation refers to milestone Boda, which is currently in early stages of development. Some or all of the features mentioned here may not yet exist, or be unstable.

Application Composition

This is done by including a module loader class, which implements IModuleLoader interface. The simplest way to do that is inherit AutoModuleLoader:

    public class MyModuleLoader : AutoModuleLoader 
    { 
        // nothing to do here
        // contributed components will be discovered automatically
    }

If more control is required, one can inherit the ModuleLoader class instead. Directly implementing IModuleLoader is not recommended, because base classes shield you from addition of new members to the interfaces.

Modules can be further decomposed into pluggable features. Following a similar concept, features are plugged in by contributing their components to DI container. Features are represented by implementors of IFeatureLoader, with AutoFeatureLoader and FeatureLoader serving the base classes to inherit.

    public class ModuleLoader : IModuleLoader
    {
        public void ContributeConfiguration(IConfigurationContributor configuration)
        {
            // contribute a module-specific configuration section
            configuration.Contribute<IMyConfigSection>();
        }
        public void ContributeComponents(DependencyInjector injector, IComponentContributor components)
        {
            // get configured values 
            var myConfig = injector.Get<IMyConfigSection>();
            
            // contribute components based on a configured value
            if (myConfig.UseHighPrecision) 
            {
                components.Contribute<MyHighPrecisionCalculator>();
            }
            else
            {
                components.Contribute<MyStandardPrecisionCalculator>();
            }
        }
    }

As shown in the example IModuleLoader interface has two methods:

• ContributeConfiguration - registers configuration sections
• ContributeComponents - registers the rest of components, except the configuration sections.

The two methods are separate because this allows RegisterComponents perform conditional registrations, based on configuration values, which can be read from configuration sections that were registered in RegisterConfiguration.

Modules can be further partitioned into pluggable features. With a similar concept, features are plugged in by contributing their components to DI container. Features are represented

At the very core of the sandbox, there is a bootstrapper. The bootstrapper is invoked once the sandbox starts (which typically happens when the host process starts). The bootstrapper does exactly one thing - it loads a prescribed list of modules and features.

A module is usually a class library, or a set of class libraries,

The sandbox and the bootstrapper have no knowledge about the functions that the replica is going to perform. This is completely depends on the modules and features loaded into the sandbox.

The list of modules and features is compiled based on modules specified in

Each module has a loader class that implements IModuleLoader interface. Each module loader is invoked in the order

Conditional contribution

Module loaders can apply logic to determine whether and what concrete type of a component should be contributed. Sometimes such logic is based on configuration, which often creates a chicken-and-egg situation:

• a module loader needs to apply logic based on values read from its configuration section
• configuration sections are policy components, which are by themselves contributed in a module loader, and cannot be read up until they are implemented by the Configuration framework.

In order to resolve the above situation, module loader is divided into two phases