First Touch with OSGi


Published on

About basic OSGi concepts: why OSGI? what is OSGi? How it benefits us?

Published in: Technology, Education
1 Like
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide

  • Why OSGi? Because of Java’s limitations on modularity.
    Nowadays an application is normally constructed by multiple modules. Modules are appeared as JAR files in Java. Here is an abstraction hierarchy of Java: application is composed of JARs; JARs are composed of packages; packages are composed of types; and types are composed of methods
    But...somehow JARs are just simply a delivery mechanism with no runtime semantics.
    First of all, why are JARs just a delivery mechanism? Probably you already can tell from the abstraction hierarchy: methods, types and packages all have visibility controls, but there is no such thing in JARs! At the application level, all JARs are public!
    As we all know, visibility control is important in decoupling dependencies. Think about information hiding. Since there is no such thing in JAR files, they are easily coupled to each other.
  • The 2nd problem with JAR files is, it simply go on a flat classpath and it fight for position on the classpath. The classpath pays no attention to code versions, it simply adopts a first-come first-serve algorithm, whichever comes first wins! Let’s take a look at the picture, classes are merged at runtime. This is the so-called class overlaying. It makes supporting different versions of classes at runtime impossible. Just to remind you, maven is kind of special, if two JARs have the same group id and artifact id, the one with the higher version always wins.
    To summarize...
    The consequence is...
  • OSGi (Open Service Gateway initiative) is a dynamic module system for Java
    It adds a few key elements, in particular, it talks about bundles instead of JARs
    A bundle is a self-describing JAR. It adds identity and dependency information on top of the JAR file. This simple idea has two effects, producers and consumers both have an opportunity to express their side of the contract, and the runtime has the information it needs to enforce these expectations.
  • Now we need to slightly modify the abstraction hierarchy. Under the OSGi framework, bundles replace JARs as modules.
  • So what exactly is a bundle?
    First of all, it has identity information, it requires to have an unique id and version combination
    And it also has dependency information, it requires that packages containing...
    The producers tell the customers what they have, and the customers ask for what they need from the producers. Fair enough.
  • with these visibility...
    each bundle has its...
    Now the Spring problem is fixed, right? The Symantec code can has its own Spring dependency without being affected by the Spring from the elasticpath OFTB code.
  • Another key concept that OSGi introduces is service.
    while importing and exporting of packages are only static contracts, OSGi uses service to facilitate dynamic collaboration. A service is simply an object that implements a contract, that is registered with the OSGi service registry, and with its package visible to the world. The consumer bundle only need to query the service implementation from the service registry. We will have an example in the end.
    The latest OSGi implementation also supports dynamically registering and injecting these services.

  • 1. nasa uses it to control space missions

  • First Touch with OSGi

    1. 1. First Touch with OSGi Owen Ou @JingwenOwenOu
    2. 2. Why OSGi? • Java’s limitations on modularity • Application > JAR > Package > Type > Method • JARs are simply a delivery mechanism with no runtime semantics • JARs have no visibility control
    3. 3. Why OSGi? (cont.) • JARs fight for position on the classpath, FCFS algorithm, e.g., class overlay, maven is higher versioned JAR wins • To summarize, Java has no support for defining or enforcing dependencies • The consequence is tightly coupled JARs with multidirectional and even cyclical dependencies
    4. 4. What’s OSGi? • OSGi is a dynamic module system for Java • It talks about bundles instead of JARs • Bundle = identity & dependency info + JAR
    5. 5. What’s OSGi? (cont.) • OSGi is a dynamic module system for Java • It talks about bundles instead of JARs • Bundle = identity & dependency info + JAR Application > Bundle > Package > Type > Method
    6. 6. OSGi bundle • Identity: unique id + version combination • Dependency: packages containing API must be explicitly export; bundles including code that uses this API must have a matching import
    7. 7. OSGi bundle (cont.) • with these visibility constraints, a strong basis of loosely coupled module system is achieved • each bundle has its own class loader, making it possible for two bundles to depend on the same bundle with different versions
    8. 8. OSGi service • importing and exporting of packages are static contracts • services are used to facilitate dynamic collaboration
    9. 9. OSGi lifecycle
    10. 10. OSGi implementations • Equinox, Felix, Knopflerfish, Snippets • Equinox: OSGi standard + extension/ extension point + fragment • Usages: Eclipse, Spring DM Server, NASA, embedded system
    11. 11. Benefits of OSGi • Example: a hello world example
    12. 12. Questions?
    13. 13. Discussions • Why can OSGi decouple dependencies? • What’s the difference between OSGi’s dependency control and Maven’s dependency management? Can they replace each other? Or can they combine together to be a powerful match? • What’s the difference between OSGi’s service injection and Spring’s dependency injection? Can they replace each other? Or can they combine together to be a powerful match?
    14. 14. Reference • OSGi and Equinox: Creating Highly Modular Java™ Systems • Modular Java: Creating Flexible Applications with Osgi and Spring • Getting Started with OSGi: Declarative Services and Dependencies