Microkernel Architecture (microkernel Architecture)

Microkernel Architecture (microkernel Architecture)

Microkernel architectures are sometimes also used as plug-in architecture patterns (plug-in architecture pattern), and are often implemented for product-based applications such as Eclipse and Firefox. However, many companies also make internal business software products, providing versions, release notes, and plug-in features. The Microkernel Architecture mode adds additional functionality to the core application via plugins, providing the independence and separation of scalability and functionality.

Pattern description

The microkernel architecture consists of two components: the core system and the plug-in module (plug-in modules). Application logic is split into separate plug-in modules and core systems, providing scalability, flexibility, functional isolation, and custom processing logic.

Figure 1 Microkernel Architecture pattern (microkernel architecture pattern)

The core system of the microkernel architecture typically provides the minimum set of features required for the system to run. Many operating systems use micro-kernel architecture, which is the origin of its name. From the point of view of commercial applications, core systems are generally common business logic, with no special circumstances, special rules, or custom code in complex situations.

Plug-in modules are standalone modules that contain specific processing, additional functionality, and custom code to enhance or extend additional business capabilities to the core system. Usually the plug-in modules are also independent, and some plugins are dependent on a number of other plug-ins. It is important to minimize the communication between the plug-ins to avoid dependency problems.

The core system needs to know which plugins are available and how to use them. One way to implement this is to use the plug-in registry. The registry contains information about the plug-in, such as name, data contract (input data and output data), Remote access Protocol (which determines how the plug-in connects to the core system, XML or WSDL, and so on).

Plug-in modules and core systems are connected in a variety of ways, including OSGi (Open Service Gateway Initiative), messaging, Web service, and even point-to-point binding (object instantiation). The choice of connection depends on the application type of the component and the special requirements such as distributed deployment.

The contract between the plug-in and the core system is also various, either standard or customizable. Custom contracts are typically required when using third-party plug-ins. In this case, it is common to create an adapter for the plug-in contract to your standard contract, so that the core system does not require a custom code for each plug-in. When creating a standard contract (usually XML), remember to design the version strategy from the beginning.

Case

The best example of a microkernel architecture might be eclipse. Downloading the base version of Ecilpse may be a bit stronger than a fancy editor, and once you have a few plugins installed, it becomes a highly customizable and useful product at once. Browsers are also typical examples of micro-core architecture products.

There are countless examples of such product-based software, but what about big business applications? Micro-kernel structure is also applicable. Here again, take the insurance company's claim processing as an example. (The examples in the book are not in accordance with the national conditions, look very laborious.) ）

The claims processing process is complex and there are many different rules and regulations at each stage to indicate whether compensation should be awarded. For example, the windshield of a car is crushed by rocks, some states are allowed to compensate, and some are not allowed. The standard claims process has almost unlimited conditions.

Usually insurance claims applications are handled using a large, complex rule engine. But the rule engine will snowball as it gets bigger, modifying a rule may affect other rules, or a simple rule modification requires a lot of analysts, developers, and testers. You can avoid this problem by using the microkernel architecture pattern.

As shown in 2, the core system claims processing contains the basic business logic for processing the claims process. Each plug-in module contains special rules for a state. In this example, the plug-in module can be implemented by custom code or by separating the rule engine instances. Most importantly, each state's unique rules are stripped from the core system and can be added or removed, without affecting or slightly affecting the core system and other plugins.

Figure 2 Micro-core architecture case

Precautions

One of the best parts of the microkernel architecture pattern is that it can be embedded or as part of other architectural patterns. For example, an event-handling component in an event-driven schema can be implemented using a microkernel architecture.

Micro-core architecture provides the convenience of progressive design and incremental development. You can implement a solid core system, and then incrementally add functionality and features without making significant changes to the core system.

For product-based applications, the microkernel architecture is the first choice. This is especially true for products that release new functionality over time and want to ensure that all users have access to new features. If you later find that the architecture does not meet the requirements, you can re-form other architectures at any time.

Pattern Analysis

The following table shows the ratings and analysis of the common architectural characteristics of a layered schema pattern.

Overall flexibility

Rating: High

Analysis: Overall flexibility is the ability to respond quickly to changes in the environment. Because of the low coupling between the plugins, the changes are usually isolated and can be implemented quickly. In general, the core system is stable and fast, with some robustness, with little need for modification.

Easy to deploy

Rating: High

Analysis: Depending on the implementation, the plug-in can be dynamically added at run time (hot deployment) to minimize the downtime of the deployment.

Testability

Rating: High

Analysis: Plug-ins can be tested independently and easily simulated, without the need to modify the core system to demonstrate or build prototypes of new features.

Performance

Rating: High

Analysis: Although the microkernel architecture itself does not make the application high performance, the application typically built with a microkernel architecture is good because it can customize or trim out unwanted functionality. This is the case with JBoss application server.

Scalability

Rating: Low

Analysis: Because most microkernel implementations are product-based and generally small, they are a separate unit and therefore not highly scalable. Depending on how the plug-in is implemented, sometimes scalability can be provided at the plug-in feature layer, but in general the architecture is used to build highly scalable applications.

Ease of development

Rating: Low

Analysis: Micro-kernel architectures require thoughtful design and contractual planning and management, making them more complex to implement. The version mechanism of the contract, the registration mechanism of the plug-in, the granularity of the plugin, and the choice of plug-in connection make the implementation complicated.

Resources:

Software Architecture Patterns

Colobu.com

Microkernel Architecture (microkernel Architecture)