core modules execution

Module Execution

This is the last topic within the modules section and describes the last methods executed on a plugin module. At this point in the bootstrap process, the following has been completed:

• The host process obtained a reference to ICompositeContainerBuilder by calling the CompositeContainer extension method on IServiceCollection.
• The host process registered plugins using the ICompositeContainerBuilder reference followed by calling the Compose method:
  • Modules where Initialized
  • Modules where Configured
  • Modules registered services
• ICompositeApp singleton component added to IServiceCollection representing the build composite-application.

Starting / Stopping Composite-Application

Now that composite-application has been bootstrapped, the last step is to start all plugin modules. This takes place when the host is started by referencing the built composite-application (ICompositeApp) and invoking its start method. When the host is stopped, the composite application is stopped.

var builder = WebApplication.CreateBuilder(args);

// ..

// Add Plugins to the Composite-Container:
builder.Services.CompositeContainer(builder.Configuration, new SerilogExtendedLogger())
    .AddSettings()

    .AddPlugin<InfraPlugin>()
    .AddPlugin<AppPlugin>()
    .AddPlugin<DomainPlugin>()
    .AddPlugin<WebApiPlugin>()
    .Compose();

var app = builder.Build();

// ...

var compositeApp = app.Services.GetRequiredService<ICompositeApp>();
var lifetime = app.Services.GetRequiredService<IHostApplicationLifetime>();

lifetime.ApplicationStopping.Register(() =>
{
    compositeApp.Stop();
    Log.CloseAndFlush();
});

var runTask = app.RunAsync();
await compositeApp.StartAsync();
await runTask;

The order of the last three lines of code are important. The RunAsync method is invoked on WebApplication first so ASP.NET can begin starting listening for requests. If monitoring is being used with a container orchestrator, the microservice must be able to handle requests while composite-application is starting. This allows the container orchestrator to make requests to determine if the microservice is fully started. After the composite-application has started, the task returned from RunAsync is awaited.

When the microservice is stopped, the composite-application is stopped. This is achieved by registering a delegate to the ApplicationStopping event of the IHostApplicationLifeTime service.

Module Execution Methods

Each plugin module can execute code by overriding the following methods:

Execution Method	Description
StartModuleAsync	Called after all services have been registered and the DI Container has been created.
RunModuleAsync	Called after all modules have been started. This method can contain logic depending on another module being started.
StopModuleAsync	Called when the composite-application is stopped. Allows the module to complete any processing before the host is stopped.

When the microservice is bootstrapped, NetFusion logs each module that is started, ran, and stopped.

Execute the microservice and observe the order in which the methods write to the log.

cd ./src/Examples.Bootstrapping.WebApi/
dotnet run
# Type Ctl-C

[IMAGE]

The above shows that each of the plugin modules where started. Core plugin modules are started first followed by modules contained within Application plugins and ending with the Host plugin modules. After all of the plugin modules have been started, they are run in the same order. When the host process is terminating, all plugin modules are stopped in the reverse order started.

Next Steps

This concludes all of the bootstrap specific components used to assemble a composite-application from a set of plugins. Next, core plugin implementations provided by NetFusion will be discussed. These infrastructure based plugins can be used when developing application specific microservices. A benefit of the plugin bootstrap process is a given microservice can choose only the core infrastructure plugins needed.