cool hit counter Software Architecture Patterns - Chapter 3 Microkernel System Architecture_Intefrankly

Software Architecture Patterns - Chapter 3 Microkernel System Architecture

The microkernel architecture pattern (sometimes referred to as the plug-in architecture pattern) is a natural pattern for implementing product-based applications. Product-based applications are already packaged and have different versions that can be downloaded as third-party plugins. Then, many companies are also developing and releasing their own internal commercial applications like version numbers, instructions and loadable plug-in style applications (which is also a feature of this model). The microkernel system allows users to add additional applications such as plug-ins, to the core application, subsequently providing scalability and separation of functions usage.

Model description

The microkernel system architecture model consists of two pieces: the core system and the plug-in system. The application logic is divided into separate plug-in modules and basic core modules, followed by scalability, flexibility while isolating the application functionality and handling the logic of specific things. The architecture model is shown in Figure 3-1.

The core module has only the minimal functional logic that enables the application to run. Many operating systems use the microkernel system architecture, which is where the name of the structure comes from. From a business application perspective, the core system usually defines general business logic and does not contain specific processing logic for special cases, special rules, or complex conditions.

Plug-in modules are self-contained modules that contain special processing logic, additional functionality and custom code that can extend the business functionality of the core system. Usually, the different plugin modules are independent of each other, but you can design them in such a way that one plugin depends on another. Most importantly, you need to keep the interdependencies between plugins to a minimum, in order to avoid cumbersome dependency issues.

The core system needs to know which plugin modules are loadable and how to use them. A common method is through the plug-in registry. The registry contains basic information about each plugin module, including the name, data protocol and remote access protocol details. For example, a tax software plug-in for marking high-risk tax audit items might have a registry that contains the service name (AuditChecker), data signature (input data and output data format), and protocol format (XML). If accessed via SOAP, it may also contain WSDL (Web Service Definition Language).

Plug-in modules can connect to the core system in a variety of ways, including OSGi (Open Services Gateway Protocol), message queues, web services, and even direct peer-to-peer binding (object instantiation). The connection method chosen depends on the type of application being designed (small product or large enterprise product) and some specific requirements (e.g. single or distributed deployment). The architecture pattern itself does not specify any one implementation, but only requires that the plug-in modules must remain independent of each other.

The protocols for the core system and plug-in modules can be either standard or custom. Custom collaboration is usually seen when the plugin module is developed by a third-party company and you don't have control of the protocol. In this case, it is common to use the approach of creating adapters for plugin-specific and standard protocols, so that the core system does not need to include specialized code for each plugin. When building a standard protocol (usually using XML or java maps), it is important to have a good version control strategy right out of the gate.

Model examples

Probably the best example of a microkernel is the Eclipse IDE. Download the Eclipse software, which provides you with only a cool editor. However, once you start loading plugins, it becomes more customizable and useful. Internet Explorer is another common example, itself just a view previewer plus plugins to provide additional functionality.

For product-based software, the list goes on and on. But what about for large business software? The same applies to microkernel systems. Let's take insurance claims software as an example.

The insurance claims process is a very complex one. Each country has different rules and requirements about what is and is not allowed. For example, some states allow free windshield replacement if your windshield is damaged by rocks, while other states do not. This creates an almost infinite variety of conditions for a standard claims process.

Not surprisingly, most insurance claims programs utilize large and complex rule engines to handle this complexity. However, these rule engines can become increasingly complex, and using the microkernel architecture pattern can solve many of these types of problems when you change one rule while affecting others, or when making a simple rule change requires a lot of analysis, development, and testing.

What you see in Figure 3-2 represents the core system folder heap of the claims processing, which contains the required basic business logic without any specific processing. And each plugin module contains state-specific processing rules for the corresponding state. In this example, the implementation of the plugin module can use specific source code or a separate instance of the rules engine. Regardless of the specific technology used for the implementation, the core idea is that each state-specific insurance claims rule and processing is separate from the core system, and it can be added, removed, and changed without affecting other state-specific plug-in modules or the core system.

caveat emptor

One of the advantages about the microkernel architecture pattern is that it can be embedded or used as part of another architecture pattern. For example, if this pattern solves a specific problem in an application and at the same time the entire application architecture cannot be implemented with this pattern, in this case you can embed the microkernel architecture pattern into another pattern (e.g. a layered architecture). Similarly, the microkernel architecture pattern can be used on the event handling, driver architecture described in the previous section.

The microkernel architecture model provides great support for design-in extensions and incremental development. You can create a fixed core system, and as the application continues to evolve, you can add features and functionality accordingly without having to make a lot of changes to the core system.

For product-based applications, the microkernel architecture pattern should always be your architecture of choice, especially for products where you will continue to upgrade features in the future while at the same time wanting to control which target user populations have these new features. If you find over time that the pattern doesn't meet all of your requirements, you can refactor your application to another architectural pattern that better suits your specific requirements.

Model analysis

Overall agility

Rating: High

analysis: Overall agility is the ability to respond quickly to changing conditions。 Alterations can be split out to a large extent, and quickly implemented through loosely coupled plugins。 generally speaking, Most microkernel architecture core systems will stabilize quickly, Due to its powerful features and the fact that only few changes are required over time

Ease of deployment

Rating: High

Analysis: Depending on how the pattern is implemented, plug-in modules can be dynamically added to the core system at runtime (e.g., hot deployment), minimizing downtime for deployment.


Rating: High

Analysis: Plug-in modules can be tested individually and can be easily mimicked by the core system for demonstration or prototypicality, requiring only little or no change.


Rating: High

analysis: While microkernel architectures are not naturally highperformance application, But generally speaking, Most applications using the microkernel architecture model perform well, This is because you can customize and simplify the application to include only those features that are needed。 JBoss The application server is a good example: Through its plug-in architecture, You can reduce the application server to only the functionality needed, Remove unwanted features, For example, remote access, Message queues and caches consume memory,CPU and threads。


Rating: Low

Analysis: Because most implementations of microkernel architectures are product-based, they are relatively small in size and are usually implemented as individual units, and therefore are not highly scalable. Depending on how the plugin architecture is implemented, you can sometimes provide extensibility at the plugin functionality level, but in general this pattern is not suitable for generating highly scalable applications

Easy to develop

Rating: Low

Analysis: The microkernel architecture requires thoughtful design and protocol control, which makes it quite complex to implement. Protocol version control, internal plugin registration methods, plugin granularity, and a wide range of plugin connection methods all add to the complexity of implementing this model.

1、This is a crap game that I had to encore
2、Red Flag finally takes a high profile more to look forward to in the next decade
3、Windows 10 facial recognition exposed to security flaw a big head sticker could break it
4、Blockchain ecommerce a futurechanging era of technology
5、There is value and breakthrough performance is top vivoNEX new Jovi can become your third purchase reason

    已推荐到看一看 和朋友分享想法
    最多200字,当前共 发送