Liberty architecture

Liberty is a highly composable and dynamic runtime environment. OSGi services are used to manage component lifecycles, and the injection of dependencies and configuration. The server process comprises a single JVM, the Liberty kernel, and any number of optional features. The feature code and most of the kernel code runs as OSGi bundles within an OSGi framework. Features provide the programming models and services that are required by applications.

Figure 1. Liberty architecture
The runtime environment is an OSGi framework that contains a kernel, a JVM, and Liberty features.

In the previous figure, the runtime is an OSGI framework that contains a kernel, a JVM, Liberty features, and a container that hosts two applications.

The kernel launcher bootstraps the system and starts the OSGi framework. The configuration is parsed, and then the configured features are loaded by the feature manager. The kernel extensively uses OSGi services to provide a highly dynamic runtime environment. The OSGi Configuration Admin service manages system configuration, and an OSGi Declarative Services component manages the lifecycle of system services. The file monitor service detects application and configuration file changes, and the logging service writes messages and debug information to the local file system. As the flowing diagram shows, the kernel includes a feature manager, a file monitor, a logging service, and OSGi resources for configuration administration and for working with declarative services.

Figure 2. Liberty kernel
kernel flowchart

In the previous figure, the Liberty kernel comprises a feature manager that contains an OSGI configuration admin, OSGI declarative services, a file monitor, and a logging service. The feature manager and the OSGI declarative services are connected a feature bundle. The OSGI configuration admin and the file monitor are connected to the server.xml file. The logging service is connected to the trace log.

Features are specified in the system configuration files that are the server.xml file and any other included files. The server configuration files populate the OSGi Configuration Admin service, which injects the feature configuration into the feature manager service. The feature manager maps each feature name to a list of bundles that provide the feature. The bundles are installed into the OSGi framework and started. The feature manager responds to configuration changes by dynamically adding and removing features while the server is running. As the following diagram shows, the OSGi Configuration Admin service reads the configuration from the server.xml file, and injects the feature configuration into the feature manager. The feature manager reads bundle lists from the bundles that provide each feature, then installs and starts these bundles in the OSGi framework.

Figure 3. Feature management
feature management flowchart

In the previous figure, a feature manager contains an OSGI configuration admin. The OSGI configuration admin reads config from the server.xml file and injects it into the feature manager. The feature manager reads the bundle list in the useful-3.2.mf file and installs and starts a feature bundle in the OSGI framework.

Runtime services provide configuration default settings so that the configuration you need to specify is kept to a minimum. You specify the features you need, along with any additions or overrides to the system default settings, in a server.xml file. You might choose to structure your configuration into a number of separate files that are linked to the parent server.xml file by using an include syntax. At server startup, or when the user configuration files are changed, the kernel configuration management parses your configuration and applies it over the system default settings. The set of configuration properties that belongs to each service is injected into the service each time the configuration is updated. As the following diagram shows, The configuration administrator reads the default configuration from bundles in the kernel, applies the user-specified configuration over this default configuration, then injects the merged configuration into feature bundles.

Figure 4. Configuration management
configuration flowchart

In the previous figure, the OSGI configuration admin reads default config from the kernel bundle and the feature bundle, merges user config over the defaults, and injects it back into the bundles. The merged config is sent to the server.xml file and then, optionally, to other XML files.

The OSGi Declarative Services component is used so that function can be decomposed into discrete services, which are activated only when needed. This behavior helps the runtime environment to be late and lazy, keeping the footprint small and the startup fast. Declared services are added to the OSGi service registry, and dependencies between services can be resolved without loading implementation classes. Service activation can be delayed until a service is used: when the service reference is resolved. Configuration for each service is injected as the service is activated, and is reinjected if the configuration is later modified.