Turn: OSGi Introductory article: Lifecycle Layer

Introduction to OSGi: Life cycle Layer

Objective

The life cycle layer in the OSGi framework belongs to the layer above the module layer, and its operation is based on the function of the module layer. One of the main functions of the life cycle layer is to enable you to manage applications externally or to build self-managed applications (or the combination of the two), and give the application itself a great dynamic.
In this chapter, we describe the basic characteristics of the life cycle layer and how to use these features effectively. Of course, as a rule, we will still be clear about what life cycle management is and why OSGi requires life cycle management, and then explain some of the basics of the life cycle layer.

1 What is life cycle management

In general, a program (or part of a program) must be subject to some kind of life cycle. The life cycle of the software has 4 typical phases, such as:

If you're creating an app, first you have to install it, and then when all the dependencies of the app are met, we can execute the app; If the app doesn't need it, we can stop it; after a while, We may need to update the version of this app, and finally, we may remove the app, because we don't need it anymore.

We accomplish the "lifecycle management" process for applications by doing these operations externally or internally. For non-modular applications, these operations are the object of the entire application, and if it is for modular applications, then we can have a finer granularity (for a module in the application) to manage the life cycle.

Whether it's standard Java or SERVLET,JAVAEE, they all have different lifecycle management mechanisms, so why do we all need life cycle management applications?

2 Why manage the life cycle of your app

In the previous chapter we explained how to complete the modular definition of the application by joining metadata, but only the Bunlde static attribute is introduced in the metadata, and there is no mention of the dynamic characteristics of an application, such as when a particular class or object is needed and used.

In general, to manage the lifecycle of an application, it is done through the API provided by the framework. A clear set of lifecycle APIs allows your app to configure, initialize, and maintain a piece of code. The OSGi standard defines a set of APIs that allow you to perform a variety of external or internal operations on the bundle's lifecycle to achieve functional control of the bundle.

The flexibility of the application you build is greatly enhanced by the fact that the application you are building is modularized into several parts, and with these APIs you can precisely and instantly control the fate and movement of any part of it. Without life cycle management, you can only use what applications people give you, and you have low control, and once you have life cycle management, you can manage the behavior of this modular application through lifecycle management, whether it's a startup, Update or stop, etc.) for precise control. Does it feel great to put every part of the app in your own hands?

3 The life cycle of OSGi bundles

We already know how to define a bundle in the module layer, but to use bundles, we have to use the lifecycle Layer APIs to interact with the lifecycle layer of the OSGi framework. A detailed introduction to the API will be too lengthy (go to the OSGi standard bar), so the next step is to give an example of some of the features that the API provides to users.

It should be noted that the core of the OSGi framework does not enforce any specific API interaction mechanisms (such as command line, GUI, or XML configuration file), but simply Java API, so developers can arbitrarily create their own desired interaction mode, to ensure the flexibility of the framework.

In standard Java programming, you would use it by placing the jar package in Classpath, which is not the case for bundles. Bundles can only be used if they are installed (install) into a running instance of an OSGI framework. And the OSGi framework supports the complete lifecycle management of these bundles, and the dynamic nature of these management operations is evident in the implementation of the application.

State transition diagram of 3.1 bundle life cycle

This diagram clearly shows the transition conditions between each State and state of the bundle in the life cycle.
We can get the current state of the bundle through the GetState method of the bundle.
What needs to be explained here is the starting and stopping states, which are transient, meaning that the two states will automatically move to the next state after a while, without the need for a transfer condition.

3.2 Three important interfaces provided by the framework

The API for the lifecycle layer consists of the following three core interfaces: Bundleactivator,bundlecontext and bundles.

Bundleactivator: Allows you to capture the start and stop events of the bundle and make a custom response to both events.
Bundlecontext: A bundle's execution-time context in the framework, which provides a way to interact with the framework.
Bundle: Logically represents a bundle object that corresponds to a physical bundle in a BUNDLE,OSGI environment. The object contains the basic information of the bundle and the control interface of the bundle declaration cycle.

3.2.1 Bundleactivator

The interface of the bundleactivator is defined as follows:

Public Interface bundleactivator {< Span class= "KWD" >public void Start (bundlecontext Context)   exception; public void Stop (bundlecontext Context)   exception;                /span>                

If a class implements this interface, then this class becomes a activator. But it is not enough to have the implementation, you have to let the OSGi framework know the existence of this activator. So you also need to add one of the following attributes to the manifest file (assuming that the Activator class you define is called Org.foo.Activator):

Bundle-Activator：org.foo.Activator

In this way, when the bundle starts (start), the OSGi framework calls the Activator start method, and the same applies to the Stop method.

It is important to note that not every bundle needs a activator, sometimes your bundle is just to share the code with other bundles, and does not need to do extra action at startup and stop, so whether to use this excuse, but also the specific problem specific analysis.

3.2.2 Bundlecontext

Do not know the careful classmate noticed no, in fact, in the Bundleactivator interface start and stop two methods, the incoming parameters are bundlecontext. The functions of the methods in this interface are mainly divided into two parts:
• Part of and deployment related to lifecycle management
• The other part is about using the service layer to interact between bundles
Here we focus primarily on the first part of the approach, where the main methods are listed below:

Public Interface Bundlecontext {...StringGetProperty(StringKey);BundleGetbundle();BundleInstallbundle(StringLocation, InputStreamInput) Throws Bundleexception;BundleInstallbundle(StringLocation) Throws Bundleexception;BundleGetbundle(LongId);Bundle[]Getbundles();void Addbundlelistener (bundlelistener< Span class= "PLN" > Listener); void Removebundlelistener ( bundlelistener Listenervoid Addframeworklistener ( Frameworklistener Listenervoid Removeframeworklistener ( Frameworklistener Listener ... }             /span>                

Bundle context is the only execution context for the bundle associated with it, and the context is meaningful only when the bundle is part of the active state. An accurate description of this time period is between the two points at which the Start method is called and the Stop method is called. So if a bundle is not in this time frame, but his Bundlecontext object is used, then the framework throws an exception.

The framework uses this context object for the purpose of security and resource allocation for bundles, so the Bundlecontext object should be treated as a private object and should not be arbitrarily passed between bundles.

3.2.3 Bundle

In the Bundlecontext interface, we find a method known as Getbundle, from which we can get the bundle object.

For each bundle that is installed into the framework, the framework creates a bundle object that is logically expressed. This interface defines the method of the bundle lifecycle management, the following is the fragment of this interface, the function of this interface method is obvious:

Public Interface Bundle {...BundlecontextGetbundlecontext();LongGetbundleid();DictionaryGetheaders();DictionaryGetheaders(StringLocale);StringGetLocation();IntGetState();StringGetsymbolicname();VersionGetVersion();voidStart(IntOptions) Throws Bundleexception;voidStart() Throws Bundleexception;voidStop(IntOptions) Throws Bundleexception;voidStop() Throws Bundleexception;void Update ( Inputstream Input)  throws  bundleexception; void Update ()  throws< Span class= "PLN" > bundleexception;void Uninstall ()   bundleexception;  ... }             /span>                

A little bit of explanation is the GetLocation method, most implementations of the OSGi framework are to interpret locatioin as a URL to the OSGi bundle, which, when needed, is downloaded to the framework for installation using a URL. However, the OSGi standard does not specify that the location must be a URL, and that the URL is not necessary because we can also install bundles through the input stream.

In addition, bundles can not change their own state, such as an active bundle can not stop themselves, stop itself will throw an exception.

4 Summary

After the module layer, we also introduced the OSGi module layer, here mainly introduces some core interfaces, the specific use of the example will still be in the "OSGi development environment and HelloWorld" for you to show. The content of this chapter is still relatively basic, there are many details and more in-depth content is not presented here, those content will be in the advanced chapter for you to explain.

Turn: OSGi Introductory article: Lifecycle Layer