OSGi provides a standard way to build modular Java applications by introducing bundles and services. Bundles define modules that can import and export Java packages. Services allow bundles to connect in a dynamic way by publishing and consuming objects. The OSGi framework manages bundle lifecycles and provides a service registry to discover and bind to services. This allows parts of an application to be updated or replaced while it is running.

1. Introduction to OSGi
Kishanthan Thangarajah

2. The Problem ?

3. Typical Java Systems

4. 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.

5. Can we build a pure modular system
with Java?

6. What are the limitations?
➔ Runtime vs Compile time difference.
● Flat, single classpath.
➔ No standard way of building a modular system.
● Class loader based techniques.

7. Runtime vs Compile Time

8. Runtime vs Compile Time

9. 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

10. 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

11. 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

12. 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?

13. 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.

14. Next level of Modularity

15. 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

16. 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.

17. OSGi Layered Model

18. 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.

19. 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.

20. 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 ?

21. MANIFEST.MF

22. Bundle States

23. Demo

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

25. 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.

26. 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

27. Registering a Service
public class Activator implements BundleActivator {
public void start(BundleContext bc) {
Hashtable props = new Hashtable();
props.put("language", "en");
//Registering the HelloWorld service
bc.registerService(HelloService.class.getName(),
new HelloServiceImpl(), props);
}
}

28. Acquiring Services
public void start(BundleContext bc) {
//Get the service reference for HelloService
serviceRef = 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.");
}
}

29. Demo

30. 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.

31. Monitoring Services
➔Bundle Listeners
➔Service Listeners
➔Service Trackers
➔Declarative Services

32. Questions?