OSGi

OSGi loader requires a directory as an input. This directory has to con- tain the complete application – all bundles (components) from which it is assembled from. Loader then analyze them all one by one and at the end it evaluate their relations. Most of the information is stored in a bundle man- ifest, which is a descriptive file, mandatory for every OSGi bundle, saved inMETA-INF/MANIFEST.MF. The structure is predefined and an example manifest

file is in Listing 7.4. It describes the bundle itself by using attributes like:

Bundle-Name, Bundle-SymbolicName, Bundle-Description, Bundle-ManifestVersion, Bundle- Version. It also describes the ties of bundle on environment and other bundles

by using attributes like: Export-Package, Import-Package, Require-Bundle, Bundle-Re quiredExecutionEnvironment.

Listing 7.4: OSGi manifest file format

Bundle−N a m e : H e l l o W o r l d

Bundle−S y m b o l i c N a m e : cz . zcu . kiv . l o a d e r . o s g i . h e l l o w o r l d Bundle−D e s c r i p t i o n : A H e l l o W o r l d b u n d l e

Bundle−M a n i f e s t V e r s i o n : 2 Bundle−V e r s i o n : 1 . 0 . 0

Bundle−A c t i v a t o r : cz . zcu . kiv . l o a d e r . o s g i . h e l l o w o r l d . A c t i v a t o r Export−P a c k a g e : cz . zcu . kiv . l o a d e r . o s g i . h e l l o w o r l d

Import−P a c k a g e : org . o s g i . f r a m e w o r k ; r e s o l u t i o n :=o p t i o n a l ; v e r s i o n :=”←- 1 . 3 . 0 ”

Service−C o m p o n e n t : OSGI−INF / s e r v i c e s . xml

Bundle−N a t i v e C o d e : lib / m y l i b 1 . dll ; lib / m y l i b 2 . dll ; o s n a m e=W i n 3 2 ; ←- p r o c e s s o r=x86 , . . .

Require−B u n d l e : j a v a x . a c t i v a t i o n ; r e s o l u t i o n :=o p t i o n a l , j a v a x . m a i l ; ←- r e s o l u t i o n :=o p t i o n a l

Bundle−R e q u i r e d E x e c u t i o n E n v i r o n m e n t : JavaSE −1.6

Manifest file misses one of the most important information in an OSGi application – usage of services. Service is the only communication channel

in an OSGi framework, even events are realized through services. It is

an interface, that is registered by a bundle to inform the others that it is able to perform actions specified by this interface. Other bundles can ask OSGi framework to handle them this interface so they can use it. All services are registered or obtained directly in the source code of every bundle – thus making it hard to gather the information. Registering services in code is plain OSGi approach however there are technologies that enables easier registration of services. These technologies are called ”‘Declarative Services”’ and ”‘Spring Dynamic Modules”’, both will be discussed later on. This OSGi plug-in is able to handle all three approaches of service registration.

This is the reason to use bundles in binary form, because loader can take advantage of the ASM library5used for bytecode manipulation and analysis. Thanks to this library it is easier to get the list of all called methods and iden- tify calls that are used for manipulation with services. The methods capable of making these manipulations areregisterService(), getServiceReference(), get- ServiceReferences() which cover all possible ways of providing or requiring

service. These methods are therefore found using ASM and added to the description of each bundle.

Moreover there are two additional technologies that helps developers to reg- ister and acquire services on one place. The first of them is called “Declar- ative Services” and it is part of the latest OSGi release (4.2). It defines these information in special XML file with predefined format. The second

is called “Spring DM”6 and have a lot of common with the ”‘Declarative Services”’. It also uses XML file to define connections between services, but instead of declarative services it uses a well known Spring notation to define the same. The OSGi loader is able to read both these XML files and retrieve the necessary information from them.

Finally when all bundles were analyzed it is time to check relations. There are five types of relations we identified for an OSGi applications, bundles can be have these relations – exported or imported package, required bundle and provided or required service. All these attributes are used to create expected connections and thus provide the structure of this OSGi application.