Microkernel Pattern

The Microkernel architectural pattern applies to software systems that must be able to adapt to changing system requirements. It separates a minimal functional core from extended functionality and customer-specific parts. The microkernel also serves as a socket for plugging in these extensions and coordinating their collaboration.

Example: Most operating systems

Participating Components:

Internal servers: Also known as a subsystem-extends the functionality provided by the microkernel. It represents a separate component that offers additional functionality. The microkernel invokes the functionality of internal servers via service requests. Internal servers can therefore encapsulate some dependencies on the underlying hardware or software system.

External servers: Also known as a personality-is a component that uses the microkernel for implementing its own view of the underlying application domain. A view denotes a layer of abstraction built on top of the atomic services provided by the microkernel. Different external servers implement different policies for specific application domains. External servers expose their functionality by exporting interfaces in the same way as the microkernel itself does. It receives service requests from client applications using the communication facilities provided by the microkernel, interprets these requests, executes the appropriate services and returns results to its clients. The implementation of services relies on microkernel mechanisms, so external servers need to access the microkernel's programming interfaces.

Adapters: Also known as emulators-represent an interfaces between clients and their external servers, and allow clients to access the services of their external server in a portable way allowing the external servers/microkernel APIs change. They are part of the client's address space. Adapters also protect clients from the specific implementation details of the microkernel.

Clients: is an application that is associated with exactly one external server. It only accesses the programming interfaces provided by the external server.

Microkernel:implements central services such as communication faciliues or resource handling. Other components build on all or some of these basic services. In summary, a microkernel implements atomic services, which we refer to as mechanisms. These mechanisms serve as a fundamental base on which more complex functionality, called policies, are constructed. The microkernel is responsible for managing all system resources such as memory blocks and devices. The microkernel maintains information about resources and allows access to them in a coordinated and systematic way. If components want to access a resource, they use a unique identifier (handle) rather than accessing the resource directly. The microkernel has the task of creating these handles and providing a mapping between handles and resources.


Distributed Microkernel System:
In this variant a microkernel can also act as a message backbone responsible for sending messages to remote machines or receiving messages from them. Every machine in a distributed system uses its own microkernel implementation. From the user's viewpoint the whole system appears as a single Microkernel system-the distribution remains transparent to the user. A distributed Microkernel system allows you to distribute servers and clients across a network of machines or microprocessors. To achieve this the microkernels in a distributed implementation must include additional services for communicating with each other.

Layers and the Microkernel

The relationship between the Layers and the Microkernel pattern is twofold. Firstly, a Microkernel system may also be considered as a variant of the Layers pattern. The microkernel implements a virtual machine, relying on internal servers to do this. The internal servers are the lowest layer and also belong to the virtual machine. The applications executed by the virtual machine include external servers and adapters, representing the layer on top of the virtual machine. Secondly, for some application domains both patterns may be applied alternatively. Consider architectures for business applications . If these applications can be grouped into different categories, you could instead introduce a microkernel responsible for implementing the core business logic. This microkernel could additionally encapsulate the functionality for accessing the DBMS into internal servers. External servers would provide different views of the microkernel mechanisms, covering the business logic in different ways to capture functionality specific to a particular business category. The actual business applications are then the clients. If, however, all clients build upon the same view of the underlying business logic, the Microkernel pattern should not be applied.

Unless otherwise stated, the content of this page is licensed under Creative Commons Attribution-ShareAlike 3.0 License