An Overview Of MicroKernel Architecture Pattern

MicroKernel Architecture Pattern

The concept of Microkernel as Software Architecture Pattern has emerged from the principle of design of Operating System where the system is modularized basically in two parts - Kernel and the System Software.

The kernel is the heart of the operating system, whereas System Software is the other part of the body. The kernel is responsible for memory management, process Management, Inter-process communication, etc. Others like compiler, linker, and device driver are System Software, plugged into the operating system which, ultimately calls to the kernel to get their work done. The kernel is the basis that defines what we can achieve with the System.

The same design principle can also be applied to another kind of software that is evolutionary in nature in such a way that its entire foreseeable enhancement could be accomplished just by using the basic functionalities offered by the Kernel.

One such application I am going to describe here is ReportGen. ReportGen is responsible for generating the reports. Let’s first see its architecture.

MicroKernel Architecture Pattern

About Application ReportGen

ReportGen is the application that facilities generating a report in configurable format (pdf, excel, CSV, etc) and sends the report to a configurable destination (Email, Ftp Server, Printer) and others.

How does it work?

The developer of the Report creates Plugin. Consider Plugin as jar file or dll. Every Plugin implements an Interface that has the method PrepareReportData(). This method is responsible for fetching and preparing the data as it has all the queries/stored procedure/Business logic to fetch and construct the data which the report will consist of. The kernel has an exposed interface to Add Plugin (Register plugin). Before running the report developer registers this Plugin with the kernel. Once the plugin is registered, the developer through her/his client application sends a request to Kernel to execute the report. The kernel then follows below-defined steps:

Based on the request parameter, locate the assembly (Plugin) and load it in the separate application domain.
Execute its Method PrepareReportData() (use .Net Reflection) to fetch the data from DataLink Server(internal Server of the Kernel).
Send the data to another RepGen internal Server to prepare the report in the specified format.
Once the Report is prepared, send the Report to a specified destination through Report Distribution Server.

Let’s talk about each component of the diagram given above to see how they fit together in action.

RepGen Kernel

The kernel is the nucleus of application. It has primitive functionalities which the registered plugins use to get their task done.

It receives the request from Client applications in XML format. The XML contains the name of the plugin, report format (pdf, CSV, Excel, etc.), and destination like a mailing address.
From this input XML request, it extracts the plugin name (assembly name), Locates/Loads the assembly (plug-in) from its internal storage, and then executes it. The Plugin can execute either in kernel memory space or on its own. In RepGen, the Plugin executes in Kernel memory space.
For Certain features like connecting /fetching data from Database, and for Report distribution, it delegates the task to some other servers. They are known as Internal Servers of Kernel. Internal Servers can be dlls attached to the kernel or they can run on a different host. In the latter case messaging is required between Kernel and External Servers.

Here you can see Kernel is not concerned what the implementation of Plugins –what business logic it executes. It simply executes them using reflection.

DataLink Server

Datalink Server is hit by Kernel. From the input XML, it creates the Request Object and sends it to DataLink Server.
DataLink Server parses the request and hits the target database.
The response is created by the DataLink Server and communicated back to Kernel.
The response is parsed by Kernel. If Response is an error message it is logged internally or communicated to the log server. The response is communicated back to Client Apps also.
If Response returns data, it is saved internally or at another server designated for the purpose.

Report Distribution Server

Once raw data from the DataLink Server is available. The kernel creates a new Request Object for the Report Distribution server. The Request Object contains the report format (pdf, CSV, xls, etc.) destination(FTP, email distribution list), and the path of data. The first two fields of Request Object are copied from input XML, and the last – the path of data – is determined by Kernel configuration.
Report Distribution Server parses the request, generates the report, and sends the report to the destination as per the request.
Report Distribution Server can be further split into two Servers, one responsible for generating the report in the specified format, and the other for distributing the report.

This is all about a brief description of the Microkernel Architectural pattern. Finally, let’s discuss few considerations.

Client Applications interact with the kernel by sending requests in the specified format, say -XML. What about the client who doesn’t send the request in XML? Well, it needs then an Adapter to convert the request in XML.
The Kernel will create new Threads/Tasks to handle multiple requests by the client.
If Kernel is the repository of primitive services, then multiple Servers for different purposes can be built on top of it. The only caveat is that down the abstraction, the functionalities of such servers are not more than merely the composition of primitive services provided by the Kernel. Such Servers are called external servers in Microkernel architecture. Client- human or application- will then interact with these external servers, instead of directly sending the message to the Kernel.
The other tenet is that the application/server directly connected to Kernel be independent of each other. If there is a need for intercommunication between Plugins, better we think of combining them to make one, and then communicate with the Kernel.

References

Pattern-Oriented Software Architecture by Frank Buscmann, Regine Meunier, Hans Rohnert,Peter Sommerlad, Michael Stal.
https://homes.cs.washington.edu/~bershad/590s/papers/towards-ukernels.pdf