Microkernel Pattern an overview based on

POSA 1, pp. 171-192 and

Real-Time Design Patterns: Robust Scalable Architecture for Real-Time Systems, Bruce
Powel Douglass, Addison Wesley, Object Technology Series, 2003, ISBN 0-201-69956-7,
pp. 151-157.
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.
Context: The development of several applications that use similar programming interfaces that
build on the same core functionality.
Problem: Want to develop software for an application domain that needs to cope with a broad
spectrum of similar standards and technologies. Systems like operating systems and GUIs often
have a long life-span. New technologies emerge; old ones change.
Forces:
The application platform must cope with continuous hardware and software evolution.
The application platform should be portable, extensible and adaptable to allow easy
integration of emerging technologies.
Success depends on capability to run applications written for existing standards.
Need more than one view of the functionality of the underlying application platform.
Applications in the domain need to support different but similar application platforms.
The applications may be categorized into groups that use the same functional core in
different ways, requiring the underlying application platform to emulate existing standards.
An application platform that provides the functional core of a domain is an exclusive resource for
its clients.
The functional core of the application platform should be separated into a component with
minimal memory size, and services that consume as little processing power as possible.
Solution
Encapsulate fundamental services in a microkernel component.
This includes functionality that enables other components running in separate processes to
communicate with each other.
Responsible for maintaining system-wide resources such as files or processes. In addition, it
provides interfaces that enable other components to access its functionality.
Internal servers contain core functionality that cannot be implemented in the microkernel without
causing an unnecessary increase in size or complexity.
External servers implement their own view of the underlying microkernel using mechanisms
available through the interfaces of the microkernel. Every external server is a separate process
that represents an application platform.
A microkernel system is an application platform that integrates other application platforms.
Clients communicate with external servers using communication facilities provided by the
microkernel.
Structure

There are five kinds of participating components:

internal servers
external servers
adapters
clients
microkernel
The microkernel is the main component and implements central services. Other components build
on these basic services indirectly by using one or more interfaces that comprise functionality
exposed by the microkernel.
The microkernel encapsulates many system-specific dependencies. Most of the hardwaredependent parts are hidden from other participants. Clients of the microkernel only see particular
views of the underlying application domain and the platform specifics.
Microkernel maintains system resources such as processes or files. It controls and coordinates the
access to these resources.
A microkernel implements atomic services (mechanisms) which serve as a fundamental base on
which more complex functionality (policies) are constructed.
An internal server (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.
Design goal:
Keep the microkernel as small as possible to reduce memory requirements.
Provide mechanisms that execute quickly to reduce service execution time. Additional or
more complex services are implemented by internal servers that the microkernel activates
or loads only when necessary. Internal servers are accessible only by the microkernel
component.
An external server (a personality) is a component that uses the microkernel for implementing its
own view of the underlying application domain. A view is a layer of abstraction on top of the
atomic services. Different external servers implement different policies for specific application
domains.
External servers expose their functionality by exporting interfaces. Each external server runs in a
separate process. It receives service requests from client applications using communication
facilities provided by the microkernel, interprets these requests, executes the appropriate services
and returns results to its clients.
A client is an application associated with exactly one external server. It only accesses
programming interfaces provided by the external server.
Adapters (emulators) represent interfaces between clients and their external servers. They allow
clients to access the services of their external servers in a portable way. Adapters are part of the
clients address space. Clients written for an emulated platform can be compiled and run without
modification because the adapter mimic the programming interfaces of the existing application

platform that the external server implements. Adapters also protect clients from the specific
implementation details of the microkernel.
When a client requests a service from an external service, the adapter forwards the call to the
appropriate server. The adapter uses the communication services provided by the microkernel.
Each client is associated with an adapter used as a bridge between the client and its external
server. Internal servers are only accessible by the microkernel component.
Class
Microkernel

Collaborators
Internal server

Responsibility
Provides core
mechanisms
Offers communication facilities
Encapsulates system dependencies
Manages and
controls resources

Class
External server

Class
Collaborators
Internal server Microkernel
Responsibility
Implements
additional services
Encapsulates
some system dependencies

Collaborators
Microkernel

Responsibility
Provides programming interfaces for
its clients.

Class
Client
Responsibility
Represents an
application

Collaborators
Adapter

Class
Adapter
Responsibility
Hides system dependencies such as
communication
facilities from the
client.
Invokes methods of
external servers on
behalf of clients

Collaborators
External server
Microkernel

External Server
receiveRequest
dispatchRequest
executeService

Microkernel
calls

Internal Server

executeMechanism
initCommunication
findReceiver
createHandle
sendMessage
callInternalServer

activates

receiveRequest
executeService

initializes
communication
Adapter

sends request

createRequest
callService

Client
calls service

doTask

Dynamics
The dynamic behavior depends on the functionality it provides for interprocess communication.
The scenarios assume the availability of remote procedure calls.
Implementation
Carry out the following steps:
1. Analyze the application domain. Perform domain analysis and identify the core functionality
necessary for implementing external servers. If you already knew the policies your external
servers need to offer, if you have a detailed knowledge about the external servers you are going to
implement, continue with step 2.
2. Analyze external servers. Analyze the policies the external servers are going to provide.

3. Categorize the services. Whenever possible, group all the functionality into semanticallyindependent categories.These categories are not directly related to the application domain. Rather
they are necessary to implement the system infrastructure. Some of these operations may be
candidates for migration to internal servers.
4. Partition the categories. Separate the categories into services that should be part of the
microkernel and those that should be available as internal servers. You need to establish criteria
for this separation. Time-critical, frequently-used, or hardware-dependent operations should be
implemented within the microkernel component.
5. Find a consistent and complete set of operations and abstractions for every category you
identified. Microkernel provides mechanisms, not policies. Each policy an external server
provides must be implemented through use of the services the microkernel offers through its
interfaces.
6. Determine strategies for request transmission and retrieval. Specify the facilities the
microkernel should provide for communication between components e.g., asynchronous,
synchronous. This depends on the requirements of the application domain. The relationship
between communicating components may be a 1-1, many-1, many-many relationship. If low-level
communication facilities are available, you can build more complex communication mechanisms
on top of them. See Forwarder-Receiver, Client-Dispatcher-Server. Other examples of
communication facilities are synchronous remote procedure calls and asynchronous mailboxes. A
mailbox is a message buffer where a set of components can read messages from the buffer and
another set of components has permission to write messages to it.
7. Structure the microkernel component. Design it using the Layers Pattern to separate systemspecific parts form system-independent parts of the microkernel. Places the services the
microkernel exposes to other components in the uppermost layer and use the lower layers to hide
system dependencies from higher layers.
8. To specify the programming interfaces of the microkernel, you need to decide how these
interfaces should be accessible externally. If in a module physically shared by other components,
use conventional method calls. If in a separate process, existing comm facilities are required for
transmitting requests from components to the microkernel. The kernel represents an exclusive
resource can be a bottleneck. Provide multiple threads within the kernel that wait for incoming
requests and use them to execute appropriate services. Ensure consistency of internal data.
9. The microkernel manages all system resources such as memory blocks, devices including
implementing strategies for sharing, locking, allocation and deallocation of the resources.
10. Design and implement the internal servers as separate processes or shared libraries. Do this in
parallel with steps 7 to 9. Some of the microkernel services need to access internal servers.
Distinguish between active (processes) and passive servers (shared libraries).
11. Implement the external servers. Each external server is implemented as a separate process that
provides its own service interface. Specify how external servers dispatch requests to their internal
procedures.
12. Implement the adapters. Decide whether one adapter is available for all clients or if every
client is associated with its own adapter (less memory contention vs. better response times).
Provide operations to the adapters clients that are forwarded to an external server. When the

client calls a function of the external server, the adapter packages relevant information into a
request and forwards the request to the appropriate external server. The adapter then waits for the
servers response and finally returns control to the client, using the facilities for inter-component
communication.
13. Develop client applications. Clients depend on the policies implemented by their external
server.
Variants Microkernel System with indirect Client-Server connections. A Client and Server
communicate with each other indirectly using the microkernel as a message backbone. All
requests pass through the microkernel. Useful when security requirements force the system to
control all communication between participants.
Distributed Microkernel System. A microkernel acts as a messaging backbone responsible for
sending messages to remote machines or receiving messages from them. Every machine in the
distributed system uses its own microkernel implementation. From the users viewpoint, the whole
system appears as a single Microkernel system distribution is transparent. 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.
Examples Windows NT offers 3 external servers: OS/2 1.x server, POSIX server, and Win32
server. POSA 1 describes four others. Douglass says that an RTOS (real-time operating system) is
a common subsystem example. The core set of services include create a task, delete a task,
allocate and deallocate memory, provide task event and message queues, and schedule/execute a
task set. On top of those services, a developer can link in additional components to provide more
services. Common service components for RTOS include bus communications, file services,
networking services, and middleware services. Thus an RTOS becomes usable in a much wider set
of application problems from tiny, highly memory-constrained systems to systems consisting of
sets of high-powered networked CPUs.
Consequences
The Microkernel pattern offers some important benefits: portability, flexibility and extensibility,
separation of policy and mechanism, scalability, reliability, transparency. See POSA 1 for
explanations.
The Microkernel architectural framework also has liabilities: performance, complexity of design
and implementation.
See also the Broker pattern for distributed software systems consisting of interacting and
decoupled components; the Reflection pattern which provides a two-tiered architecture a base
level corresponds to a combination of microkernel and internal servers and a meta level enables the
behavior of base-level functionality to be changed dynamically. The meta level allows integration
of customer-specific extensions to the base-level services. This corresponds to the provision of
external servers in a microkernel architecture. Per Douglass, the Component-Based Architecture
Pattern is a more general pattern that permits the addition of components at run-time. The Layers
Pattern is more general still.