What is the retepMicroKernel?

The retepMicroKernel is a small container for Java applications enabling them to run as native applications on Linux, Solaris (both with 32 and 64 bit architectures), OSX (Intel 64bit) and Windows (32bit XP).

It's not intended to replace larger application containers like GlassFish, JBoss or SpringSource DM Server but is targeted at applications where the use of a full J2EE/OSDI container would be overkill, limited memory, Desktop based applications or applications which contain discrete independent components - like a core application and then smaller applications which manage the core.

Clustering is supported internally for Terracotta although you can use other clustering technologies like JGroups.

Currently applications written for the retepMicroKernel use Spring as the deployment container. However from version 9.9 onwards Spring will be an optional requirement as the kernel core will be able to support alternate deployment architectures other than Spring.

With the Spring environment the kernel manages the entire startup process of Spring, provides a pluggable architecture for components to be automatically deployed, an internal JNDI service and annotations for declaring how beans are deployed so that you can create an application without the use of any messy xml.

The retepMicroKernel comprises four distinct components:

• Binary launcher
• MicroKernel core
• Spring deployment module
• Apache Maven plugin

These components provide the following features:

• Core bootstrap environment removing the need to write one for every application
• Provides additional deployment options by use of annotations removing excessive xml writing
• Provides the detection of additional beans for deployment simply by placing them in the classpath (think plugin support)
• Provides automatic detection of Terracotta enabling the application to be clustered
• Simple deployment of beans into JNDI or JMX
• Enables the packaging of a group of related applications to be deployed together, with shared and isolated configuration for each application
• Binary executables for each supported operating system

Binary launcher

The binary launcher is a platform specific binary who’s job is to configure the application, start the Java virtual machine and finally start the application by bootstrapping the microKernel.

We use a binary launcher rather than using the default java launcher for several reasons:

Enables the kernel to locate where it's components are installed

Described in full below, it enables you to place the launcher in the shell PATH so you don't have to enter long paths for your application.

Enables daemonisation of the process if the operating system supports it

For example on Linux you can start the application as a daemon. The application will then continue to run even if you log off the host system.

Enables multiple application deployment

If you have several applications which share configuration and/or libraries you can deploy them together as one unit. The kernel will then determine what configuration is specific for the application and what config is common prior to launching the application.

Makes identifying a process easy when supporting it within a live environment.

For example, when you have multiple applications running on a single server and you need to identify the actual process being used you can easily find the process by it's application name. With the default java process, dependent on the operating system you only see it as java. In a live environment I've accidentally killed the wrong process before because of this.

Sets up the correct ClassLoader's for the application

The microKernel uses its own ClassLoader for the application. This is totally transparent to the application, however the ClassLoader handles the resolution of the application's jar files, removing the need to add dependencies within the manifests and takes advantage of the Maven repository architecture for dependency resolution.

Support for Terracotta

If you have the local environment setup for Terracotta the kernel will automatically detect it and cluster the application. All you need to do is to implement Terracotta specific beans.

Alternate application layouts

Applications built by the maven plugin can take two forms - STANDARD and OSX. Both can be used on any platform however the OSX form represents a .app so the application appears as a standard OSX application.

MicroKernel core

This is the core of the kernel. Launched directly by the binary launchers, it manages the ClassLoader and the lifecycle of one or more deployment modules.

Spring deployment module

This deployment module provides Spring support comprising a core management class, annotations and core services like the in-memory JNDI server, JMX Server and deploying MBeans to that server, Spring bean resolution and deployment.

Maven plugin

The Maven plugin is used to assemble applications, ensuring that all artifacts are present and installed in the correct locations required by the kernel and generates a deployable artifact for the application.

Artifacts are compressed zip or tar archives (the latter can be either uncompressed or compressed with gzip or bzip2).

The plugin also supports two file layouts: Standard and OSX (.app)