Slides used at training session on "Introduction to OSGI" framework.

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?