skip to main content

Execution environment

Execution environment #

Let’s think in a closed box: we know that a Cloudlet can be started or stopped, and in the same way a plugin can be installed, started, stopped or removed from a Cloudlet independently from the status of the Cloudlet execution. Runtime independence is particularly useful when the Cloudlet is running: for example, we could hot swap a report plugin with an updated version, all without having to stop the Cloudlet and thus with minimal impact on the availability of the application.

All of this is made possible by the common environment in which Cloudlet and plugins run: Apache Karaf, a framework that implements the OSGi standard.

OSGi framework #

OSGi logo OSGi defines a service-oriented Java framework that allows the development of dynamic component systems; in it, applications are built by interconnecting bundles, each of which is nothing more than a .jar whose manifest.mf file includes the framework’s own directives to configure the classpath and the dependencies of the bundle itself. The bundle is installed and executed in an OSGi container, which takes care of interconnecting it with other bundles and resolving dependencies between packages.

A special layer of the framework is dedicated to code lifecycle management: bundles can be installed, started, stopped and removed at runtime without the need to restart the whole system (the Cloudlet in our case). The resolution of a bundle’s dependencies therefore happens automatically when it is installed in the container.

OSGi lifecycle

Service configuration #

Although we do not require in-depth knowledge of OSGi, it is important to clarify the meaning of Service in Service Handler. OSGi supports the abstraction of services to realize runtime interaction between classes: in the container there is a register where bundles can publish and/or search for services specifying their Java interfaces. The instantiation and publication of a service happens when the bundle is started in the container and goes from the resolved state to the active state.

The activation mechanism of a generic plugin can be summarised as follows:

  • A bundle containing the HandlerImpl implementation of a H Handler is installed and activated.
  • HandlerImpl is instantiated and published to the service registry.
  • Some event occurs in the application that requires H to be invoked. The Cloudlet then searches the service registry for H and finds HandlerImpl.
  • HandlerImpl is invoked.

There are several ways to declare and configure an OSGi service, one of them is through blueprints. A blueprint is an xml file that declares a service to the container defining the link between interface and implementation, configuring dependency injection in a similar way to the Spring framework. The bundle should therefore contain one or more blueprints containing the declaration of the implemented handlers.

![OSGi blueprint example](/assets/img/plugins/osgi-blueprint-example.png "Example of blueprint.xml of the MyHandlerImpl class implementing the FormActionHandler “SayHello” on class “Class1”)

Further reading #

In this guide we have only touched on the main features of OSGi. Please refer to the following readings if you need to configure plugin bundles manually:

Read more: Development cycle