Software Architecture Patterns — Microkernel Architecture
Welcome back to the Software Architecture Patterns blog series. This is the 3rd chapter of the series and we’ll be talking about Microkernel Architecture Pattern. Hopefully, by the end of this post, you’ll have an understanding of this particular architecture pattern and how it can benefit you. So let’s get to it!
This blog goes as a series and we will be covering the following topics as the main chapters of the series.
- What is a Software Architecture Pattern
- Layered Architecture Pattern
- Microkernel Architecture Pattern (this post)
- Event Driven Architecture Pattern
The Microkernel architecture pattern is useful when your software system or product contains many integration points to external entities. and most importantly , you will not be able to tell exactly tell what entities will get integrated into your system in the future. The Microkernel architecture pattern can be identified as a plug-in based pattern. . Also known as the plug-in architecture pattern, it consists of two main components, the core system and plug-in components.
The core system contains the minimal functionality needed to run the system. In other architectural patterns, if we replace, add, or change a rule in a system the whole system is affected. In microkernel architecture, this does not happen because we divide the rules into plug-in components. The plug-in modules include additional functionality and are isolated and independent of each other.
The core system needs to keep track of which plug-ins are available and thus keeps track of this via a registry. When plugging components to the core system, this registry is updated with information like the name, location, data contract, and contract format of the plug-in. Similarly, when removed, the registry updates accordingly by removing this information.
Contracts are essentially the input and output data. It allows data to be exchanged although the core system and the plug-in may not be of the same type. In cases of using third-party modules where the user has no control over the contract used, an adapter can be used. We can illustrate this is a direct usage of the adaptor design pattern. This ensures that no specialized code is required by the core system to read the module. As such, plug-in modules only make minimal changes to the core system. This allows the application to be easily tested and deployed.
One of the best examples for the microkernel architecture is the Eclipse IDE. Eclipse as a base product is just an editor. However, once plug-ins are added, it becomes a customizable and more useful product. Another simpler example is the web browser you use. Multiple plug-ins can be added providing more functionality to your basic web browser.
One example of this architectural pattern is Eclipse’s coed review tool. In this example, there would be a source validation tool (i.e. the core system) which reads a java file and passes it into a list of strings and prints out to a report. In this application, all the checking components are connected to the core system as plug-in components. The plug-in modules check header standards, interceptors, audit writes, etc. Having such a checklist of plug-ins and running code through the source validation tool makes it easy to do code reviews. You wouldn’t need to worry about the other standard checks as these are automated.
Map<String,String> pluginRegistry= new HashMap<String,String>();
static{
pluginRegistry.put(HEADER,”ValidationHeaderPlugin”);
pluginRegistry.put(SQL,”ValidationsqlPlugin”);
pluginRegistry.put(INTERCEPT,”ValidationinterceptPlugin”);
pluginRegistry.put(AUDIT,”ValidationAuditPlugin”);
}
This is what the registry may look like; it is just a simple map. So you can get connected with your plug-in without using any external tools.
Conclusion
Following are the Pros and Cons in Microkernel Architecture Pattern.
Pros
It can react to changes in plug-in modules while minimizing changes to the core system.
Unlike layered architecture, having plug-in modules means it is easier to deploy thereby minimizing downtime.
Testing also is easier as individual modules can be tested in isolation.
While not generally the ideal pattern to be used in high-performance applications, it can perform well due to customizing the application to only include features that are needed.
cons
Applications tend to be which are smaller in size hence are not highly scalable.
Requires a thorough analysis of the design before implementation. Items that need to be analyzed include contract versioning, internal plug-in registries, plug-in granularity, and the wide choices available for plug-in connectivity
Stay tuned to this blog series as we will be discussing how to apply most common software architecture patterns. The next post of this series will discuss the Event Driven Architecture pattern.
If you have any queries/concerns, then you can drop me an email or send me a message on LinkedIn or Twitter. I’m just a message away :)
