Review: OSGi – a component framework for Java Bundle OSGi Framework Bundle Java Runtime Environment (JRE) Operating System (OS) Hardware “Dynamic Modules for Java”

Review: OSGi Layered Architecture Each layer depends on the layers beneath it (It is possible to use lower OSGi layers without using upper ones, but not vice versa) Bundles are the unit of modularity. They further have an associated life cycle and are the providers of services. Service Lifecycle Modularity Execution Environment HW / OS Bundles

OSGi: The Modularity Layer

Reading Ch.1: OSGi revealed Ch 2: Mastering modularity Ch 3: Learning lifecycle Ch 4: Studying services Ch 11: Component models and frameworks

Logical vs Physical Modularity Logical modularity refers to a form of code visibility. A module defines a logical boundary in your application, which impacts code visibility in a fashion similar to access modifiers Physical modularity refers to how code is packaged and/or made available for deployment. Physical modules are sometimes also referred to as deployment modules or deployment units. In general, a physical module is not necessary equal to a logical module: it’s possible to have logical modularity without physical modularity or to package multiple logical modules into a single physical module

Limitations of Java Modularity 1.Low-level control of code visibility 2.Limited deployment and management support – The classpath problem

Limitations of Java Modularity (1) Low-level code visibility control What are Java modules ? Packages, jars ? Packages are in general too finegrained to be considered modules A module would be of a size of a group of packages (maybe in a jar – or not) Problem with this: –No relationships are defined between packages –jar files by themselves provide no visibility scoping. All the public classes in implementation packages are visible to everyone, not only to the other packages forming the module

Limitations of Java Modularity (2) The classpath problem

The “class path hell” arises when more than one JAR file provides a given set of classes Example scenario: –The jar file A.jar has a class pack.a.Test that needs pack.lib.Util. During testing it was compiled against this class in Lib.jar at version –However, during deployment the class is provided by the first jar found on the classpath that contains pack/lib/Util.class. –The class carries no version information, so there is no way to diagnose problems around using that class ! –The jar file also contains no version information, so even if the class came from Lib.jar it might be the wrong one (version 1.1.0) ! –This problem can be especially hard to diagnose when an OtherLib only accidentally contains pack.lib.Util where its primary classes it is meant to provide are in another package such as pack.other.

OSGi Modularity In OSGi, logical modularity is synonymous with physical modularity: both the logical module and the physical module is referred to as a bundle

OSGi Bundles A Bundle is: “ A physical unit of modularity in the form of a JAR file containing code, resources, and metadata, where the boundary of the JAR file also serves as the encapsulation boundary for logical modularity at execution time”.

Bundle’s role in logical modularity Packages (and therefore the classes in them) contained in a bundle are private to that bundle unless explicitly exported Only explicitly exported packages can be imported (used) by other bundles Bundles extend standard Java access modifiers with module private visibility (only visible in the module)

OSGi Bundle Metadata Metadata are contained in the Manifest file The OSGI manifest extends the classical jar file manifest The OSGI-related metadata contains the following categories of information about the bundle: –Human-readable information—Optional information intended purely as an aid to humans who are using the bundle –Bundle identification—Required information to identify a bundle –Code visibility—Required information for defining which code is internally visible and which internal code is externally visible

Bundle Manifest Example Bundle-ManifestVersion: 2 Bundle-Name: Hello Bundle-Description: A Greeting Bundle Bundle-Vendor: FooProducer Bundle-SymbolicName: org.foo.hello Bundle-Version: qualifier Bundle-RequiredExecutionEnvironment: JavaSE-1.7 Export-Package: org.foo.hello Import-Package: org.osgi.framework;version="1.5.0" Bundle-Activator: org.foo.hello.Activator Human- readable info Bundle identificat ion Code visibility

Bundle Metadata: (1) Human-readable information the OSGi framework ignores this part, it is just for humans. Examples: –Bundle-Name –Bundle-Description –Bundle-Vendor –Bundle-Copyright

Bundle Metadata: (2) Bundle Identification Examples: –Bundle-SymbolicName: helps the OSGi framework to uniquely identify a bundle –Bundle-Version: an OSGI version-number, is taken together with the symbolic name for bundle identification

Bundle Metadata: (3) Code Visibility Internal bundle class path— bundle class path is a list of locations to search for classes. The difference from java class path is that the bundle class path refers to locations inside the bundle JAR file. –Bundle-ClassPath has a default value of. meaning that classes are searched in the root of the bundle jar file Exported internal code—Explicitly exposed code from the bundle class path for sharing with other bundles Imported external code—External code on which the bundle class path code depends

Bundle Metadata: Code Visibility – Exported code Export: Bundles may export packages Exported packages form the bundle's API Packages that not exported are private Packages are exported with their name and an optional version number (packages are versioned independently) Examples: –Export-Package: org.foo.hello –Export-Package: org.foo.hello, org.foo.other –Export-Package: org.foo.hello, org.foo.other; version=“2.0.0” You can also attach attributes to exported packages. Because it’s possible for different bundles to export the same packages, a given bundle can use custom attributes to differentiate its exports from other bundles. For example: –Export-Package: org.foo.hello, org.foo.other; vendor=“Manning”

Bundle Metadata: Code Visibility – Imported code Code is imported in form of: –Imported packages Bundles may use packages exported packages only if they explicitly import them using the package name Each import may be qualified with a version or a version range –Import-Package: org.osgi.framework; version="1.3.0“ –Import-Package: org.osgi.framework; version="[1.3.0,2.0.0)“ –Import-Package: org.foo.hello; vendor=“Manning” –Required bundles Bundles may specify a dependency on entire bundles Simplifies imports, but it is highly NOT recommended ! Better: “Depend on packages, not on bundles”

OSGi Class Search Order When a bundle needs a class at execution time, the framework searches for the class in the following order: 1.If the class is from a package starting with java., the parent class loader is asked for the class. If the class is found, it’s used. If there is no such class, the search ends with an exception. => ensures all bundles use the same core Java 2.If the class is from a package imported by the bundle, the framework asks the exporting bundle for the class. If the class is found, it’s used. If there is no such class, the search ends with an exception. => ensures that imported packages are not split 3.The bundle class path is searched for the class. If it’s found, it’s used. If there isno such class, the search ends with an exception.

OSGi Import-Package vs. Java import They serve different purposes: –The import keyword in Java is for namespace management: it allows you to use the short name of the imported classes instead of using its fully qualified class name the import statement itself doesn’t grant any visibility. you do not need to use import, because you can always use the fully qualified class name instead. –For OSGi, the metadata for importing external code is important, because it’s how the framework knows what your bundle needs.

Resolving dependencies automatically One of the most important tasks performed by the OSGi framework is automating dependency management, which is called bundle dependency resolution. A bundle’s dependencies must be resolved by the framework before the bundle can be used The OSGi framework uses a sophisticated dependency resolution algorithm

Resolving a Bundle RESOLVING = The process of matching a bundle’s imported packages to exported packages from other bundles and doing so in a consistent way so any given bundle only has access to a single version of any type. Resolving a bundle may cause the framework to resolve other bundles transitively, if exporting bundles themselves haven’t yet been resolved. The resulting set of resolved bundles are conceptually wired together If any dependency can’t be satisfied, then the resolve fails, and the instigating bundle can’t be used until its dependencies are satisfied.

Resolving dependencies The priority of dependency resolution candidate selection: –Highest priority is given to already-resolved candidates, where multiple matches of resolved candidates are sorted according to version and then installation order. –Next priority is given to unresolved candidates, where multiple matches of unresolved candidates are sorted according to version and then installation order. The resolve process is incremental ! –Dependencies are resolved taking into account the bundles that are installed at the moment –Bundles may be installed at any later moment – this may reset the resolve algorithm !

Consistency The dependencies are resolved in a consistent way if any given bundle only has access to a single version of any package. The bundle’s class space = its imported packages plus the packages accesible from its bundle classpath In order to be able to ensure consistency, sometimes uses contraints are necessary to be specified –The following example scenario illustrates this

Example package org.osgi.service.http; import javax.servlet.Servlet; public interface HttpService { void registerServlet(Sting alias, Servlet servlet, HttpContext ctx); } 1. Initial situation: two bundles installed and resolved

Example contd. The incremental dependency resolution leads to a situation that is NOT CONSISTENT ! The class spaces of the HTTP Client and HTTP service bundles are not consistent, since two different versions of javax.servlet.Servlet are reachable ! 2. Follow up: two more bundles are installed:

Example contd. 3. Solution: specifying intra-bundle dependencies The Uses Directive = A directive attached to exported packages whose value is a comma-delimited list of packages exposed by the associated exported package. It constrains the choices of the framework when resolving dependencies ! Export-Package: org.osgi.service.http; uses:="javax.servlet"; version="1.0.0" Import-Package: javax.servlet; version="2.3.0"

Example contd. For the incremental case, the framework can now detect inconsistencies in the class spaces, and resolution fails when you try to use the client bundle. Early detection is better than errors at execution time, because it alerts you to inconsistencies in the deployed set of bundles. The framework can be requested to re-resolve the bundle dependencies to remedy this situation 4. Resolution with Uses contraints:

Example contd. 5. Consistent resolution:

Summary Modularity is a form of separation of concerns that provides both logical and physical encapsulation of classes. Bundle is the name for a module in OSGi. It’s a JAR file containing code, resources, and modularity metadata. Modularity metadata details human-readable information, bundle identification, and code visibility. Bundle code visibility is composed of an internal class path, exported packages, and imported packages. The OSGi framework uses the metadata about imported and exported packages to automatically resolve bundle dependencies and ensure type consistency before a bundle can be used. Imported and exported packages capture inter-bundle package dependencies, but uses constraints are necessary to capture intra- bundle package dependencies to ensure complete type consistency.