Introduction to OSGi

Kishanthan Thangarajah

The Problem ?

Typical Java Systems

What we need is … Modular Systems

Dividing a complex software system into small parts/modules.

Allows us to understand the system easily. Allows us to develop part by part by different team. Allows us to reuse already developed modules.

Can we build a pure modular system with Java?

What are the limitations?

➔ Runtime vs Compile time difference.● Flat, single classpath.

➔ No standard way of building a modular system.● Class loader based techniques.

Runtime vs Compile Time

Runtime vs Compile Time

JAR (Java Archive)

➔ JAR is unit of deployment in Java.➔ Typical Java application consists a set of JAR files.➔ No runtime representation for a JAR.

➔ At runtime contents of all JAR files are treated as a single, ordered and global list which is called the class path

Problem with JAR

➔ Multiple versions of JAR files cannot be loaded simultaneously

➔ A JAR cannot declare dependencies on other JARs.➔ No mechanism for information hiding➔ Hence, JARs cannot be considered as modules

Java for Modular System

➔ Can you update a part(can be a JAR file) of a running Java application?

➔ Can you add new functionality to a new Java application at runtime?

➔ If you need to add new functionality or update existing functionality, JVM needed to be restarted.

➔ Java lacks dynamism

What’s Next?

➔ How about an abstraction where you can work at the package level as opposed to class/object level?◆ Importing packages.◆ Exporting packages.◆ A way to have private packages.

➔ Can we achieve the limitations that we discussed in Java from this model?

Next Level of Modularity

➔ Separate class loader per module.◆ creating a class-space per module.◆ delegate class loading to other modules when necessary.

➔ Solves the single class path problem.➔ Now you have a class loader network formed from

classloader delegation.➔ This network is formed with import/export package

restrictions.➔ Now we have modularity at runtime as well as

compile time.

Next level of Modularity

What is OSGi?

"The OSGi framework is a module system and service platform for the Java programming

language that implements a complete and dynamic component model, something that as of 2012 does

not exist in standalone Java/VM environments."

--Wikipedia

What is OSGi?

➔ Widely accepted specification which introduces a standard way of building dynamic, modular systems with Java.

➔ OSGi framework implementations.(Open source)◆ Eclipse Equinox.◆ Apache Felix.◆ Knopflerfish.

OSGi Layered Model

OSGi Layered Model

➔ Bundles◆ Bundles are the OSGi components made by the

developers.➔ Services

◆ The services layer connects bundles in a dynamic way by offering a publish-find-bind model for plain old Java objects.

➔ Life-Cycle◆ The API to install, start, stop, update, and uninstall

bundles.

OSGi Layered Model

➔ Modules◆ The layer that defines how a bundle can import and

export code.➔ Security

◆ The layer that handles the security aspects.➔ Execution Environment

◆ Defines what methods and classes are available in a specific platform.

Bundles

➔ Bundle is the unit of modularization in OSGi➔ OSGi based application can be considered as a

collection of Bundle➔ Bundles can share packages with other bundles

and hide packages from other bundles

➔ How does a bundle differs from a normal jar file ?

MANIFEST.MF

Bundle States

Demo

Dynamism

Modularity achieved. But what about dynamism?Can bundle alone solve the big problem?

Dynamism

➔ The moment your instantiate a new object tight coupling among modules occurs.

➔ What if I want to update the platform or part of the platform during runtime.

OSGi Services

➔ In-VM SOA model.➔ Introduces the OSGi service registry.➔ A service is Java object published in the framework

service registry.➔ Bundles can publish/lookup services using interface

names

Registering a Service

public class Activator implements BundleActivator {public void start(BundleContext bc) {

Hashtable props = new Hashtable();props.put("language", "en");//Registering the HelloWorld servicebc.registerService(HelloService.class.getName(),new HelloServiceImpl(), props);

}}

Acquiring Services

public void start(BundleContext bc) {//Get the service reference for HelloServiceserviceRef = bc.getServiceReference(HelloService.class. getName());//service reference can be null, if the service is not registered.if(serviceRef != null) {

helloService = (HelloService)bc.getService(serviceRef);} else {

System.err.println("service reference not found.");}

}

Demo

Services are Dynamic

➔ A service can register/unregister itself at any time.➔ Bundle can decide to withdraw its service from the

registry while other bundles are still using this service.

➔ A Service may not be registered when the other bundles trying to use it.◆ this depends on the start order of bundles.

➔ Bundle developer should write code to handle this dynamic behavior of services.

Monitoring Services

➔ Bundle Listeners➔ Service Listeners➔ Service Trackers➔ Declarative Services

Questions?