04/11/2023 1

OSGi IN ACTIONChapters 1 and 2

04/11/2023 2

OSGi Modularity

• OSGi framework – Dynamic modular system for Java

• Better control over the structure of your code– Dynamically manage code lifecycle– Loosely coupled approach for code collaboration

04/11/2023 3

Breaking Down the Details

• Three layers– Module– Lifecycle– Services

04/11/2023 4

Chapter OneOSGi Revealed

04/11/2023 5

Java’s Shortfalls

• No explicit support for building modular systems beyond OO data encapsulation

• Lack of modularization– Programming practices to capture logical structure– Tricks with class loaders– Serialization between in-process components

04/11/2023 6

OSGi Alliance

• Addresses the lack of support for modularity in the Java platform

04/11/2023 7

What is OSGi

• Modularity layer for the Java platform

“Modularity refers to the logical decomposition of a large system into smaller collaborating pieces”

04/11/2023 8

Java’s Modularity Limitations

• Java provides some aspect of modularity via OO but doest not support coarse-grained modular programming.

• Partitioning code via Package– Sometimes logical structure of a application

requires to call specific code to belong in different package because of the dependencies among the packages MUST be exposed as “public”, which makes them exposed to everyone.

04/11/2023 9

Error-Prone Class Path Concept

• Class path pays NO ATTENTION to code versions – finds the first version on the class path

• No way to explicitly specify dependencies• Class path approach lacks any form of

consistency checking.

04/11/2023 10

Limited Deployment & Management Support

• No easy way in Java to deploy the proper transitive set of versioned code dependencies and execute your application

04/11/2023 11

OSGi Help You

• See pages 112 - 114

04/11/2023 12

OSGi Architectural Overview

• Composed of two parts– OSGi framework• Runtime that implements and provides OSGi

functionality• Not tied to a particular vendor based on the

specification

– OSGi standard services• Define reusable APIs for common tasks, such as Logging

and Preferences.

04/11/2023 13

OSGi Layered Architecture

• Module Layer – Packaging and sharing code

• Lifecycle Layer– Providing execution-time modular management

and access to the OSGi framework• Service Layer– Interaction and communication among modules

Service

Lifecycle

Module

04/11/2023 14

Module Layer (Bundle)

• Defines the OSGi module concept called a bundle. A JAR file extra metadata.

• Logical modules that combine to form a given application.

• They explicitly declare which contained packages are externally visible (export package)

• Bundles extend the normal access modifiers (public, private, protected) in Java

04/11/2023 15

Module Layer (Bundle) Cont

• Explicitly declare which external packages the bundles depend (import packages)– OSGi manage bundle consistency via the bundle

resolution process• Respect to versions and other constraints

04/11/2023 16

Lifecycle Layer

• Defines how bundles are dynamically installed and managed in the OSGi framework.

• Lifecycle layer serves two different purposes– External to the application defines bundle lifecycle

operations (install, update, start, stop & uninstall)• Bundles can be safely added and removed from the

framework without restarting the application

– Internal to the application defines how bundles gain access to the their execution context, provides a way to interact with the OSGi framework

04/11/2023 17

Service Layer

• Promotes the concepts of service-oriented computing.

• Publish and register a service via a registry– Operations: publish, find and bind

• OSGi services are local to a single VM, sometimes refer to SOA in a VM.

04/11/2023 18

Service Layer

• Promotes interface-based development.• Promotes the separation of interface and

implementation.• OSGi services are Java Interfaces, representing

contract between service provider and service clients.

04/11/2023 19

OSGi-based Application

1. Breaking down an application into service interfaces (interface-based programming).

2. Use preferred tools and practices.– Eclipse

3. Package the service provider and client components into separate JAR files with OSGi metadata.

4. Start the OSGi framework.5. Install and start all your component JAR files from

step 3.

04/11/2023 20

Module Layer Example

• Pages 133 – 155• Group discussion

04/11/2023 21

OSGi in Context

• Java Enterprise Edition– Enterprise vs. embedded markets– OSGi plays a role in all major application servers: IBM’s

WebSphere, JBoss, GlassFish and so on• Jini– Concept of service providers, service consumers and service

lookup registry.– Jini model assumes remote access across multiple VM

processes whereas OSGi assumes everything occurs in a single VM process.

– Open source Newton combines OSGi and Jini technologies in a single framework.

04/11/2023 22

OSGi in Context Cont

• NetBeans– Common with OSGi – promotes interface programming.

Uses a lookup pattern similar to OSGi registry.• Java Management Extensions (JMX)

– Not comparable to OSGi; it’s complementary– Used to mange and monitor an OSGi framework and its

bundles and services.– JMX is not a module system.

• Lightweight Containers– Significant movement from IoC vendors to port there

infrastructures to the OSGi framework

04/11/2023 23

OSGi in Context Cont

• Java Business Integration (JBI)• JSR 277 (Java Module System)– Intend to define a module framework, packaging

format and repository system.• JSR 294 (Improved Modularity Support)– Superpackage– Project Jigsaw – modularize the JDK– Still evolving

04/11/2023 24

OSGi in Context Cont

• Service Component Architecture (SCA)– Component model – defines composite

components• .NET– Assembly which has modularity aspects similar to

an OSGi bundle

04/11/2023 25

Chapter TwoMastering Modularity

04/11/2023 26

What is modularity?

• Designing a system from a set of logically independent pieces; these logical pieces are called modules

• A module defines an enforceable logical boundary

• Details of a module are visible only to code that is part of a module.

04/11/2023 27

Module

“A module defines a logical boundary. The module itself is explicitly in control of which classes are completely encapsulated and which are exposed for external use.”

04/11/2023 28

Modularity vs. OO

• Modularity provides many of the same benefits as OO.– Separation of concerns

• Break down a system into minimally overlapping functionality or concerns

• Classes have explicit dependencies due to the references contained in the code. Modules have implicit dependencies due to the code they contain.

• Modularity and OO each address granularity at different levels.

04/11/2023 29

Module

“A set of logically encapsulated implementations classes, an optional public API based on a subset of the implementation classes and a set of dependencies on external code.”

04/11/2023 30

Logical vs. Physical Modularity

• Logical Modularity– Code visibility – module defines a logical boundary in

an application which impacts code visibility– Logical module is referred as a bundle

• Physical Modularity– How code is packaged and/or made available for

deployment.– Physical module is the JAR file– Physical modules also referred to as deployment

modules or deployment units

04/11/2023 31

Why modularize?

• Two key concepts– Cohesion– Coupling

• Reusable code• Using OSGi to modularize an application will

address the Java limitations discussed in Chapter One

04/11/2023 32

Bundle

“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.”

04/11/2023 33

Bundle’s Role in Physical Modularity

• Don’t need anything special to make a class a member of a bundle. Just added it to the JAR file.

• Physical containment of classes in a bundle JAR files leads to a deployment unit

• Containment of bundle metadata via the manifest file.

04/11/2023 34

Where should the metadata go?

• In source code or a separate file?• Separate file

– Don’t need to recompile your bundle to make a change to the metadata

– Don’t need access to the source code– Don’t need to load classes into the JVM to access associated

metadata– Code doesn’t get a compile time dependency on OSGi API.– Can use the same code in multiple modules– Can easily use code on older or smaller JVMs that don’t

support annotations

04/11/2023 35

Code Visibility

• OSGi extents code visibility– A public utility being used with a bundle is NOT

exposed outside the bundle. This extents encapsulation above the package level in Java. Which means that the bundle imposes a logical boundary on public classes.

– Code is ONLY exposed explicitly via the export statement.

04/11/2023 36

Metadata

• Human-readable information– Optional information intended to document the

bundle• Bundle identification/ Code visibility– Used by the OSGi framework

04/11/2023 37

JAR File Manifest• Groups of name-value pairs (attributes)

name: value

Manifest-VersionL 1.0Creaked-By 1.4 (Sun)Bundle-ManifestVersion: 2Bundle-SymbolicName: org.foo.apiBundle-Version: 1.0.0.SNAPSHOTBundle-Name: Simple Paint APIExport-Package: org.foo.apiImport-Package: javax.swing, org.foo.api

• OSGi manifest attribute values are a list of clauses separated by commas

Property-Name: clause, clause, clause

04/11/2023 38

Bundle Identification

• Bundle-Name – doest not defined the bundle name to the framework. Used for documentation.

• Bundle-SymbolicName – defined the bundle name to the framework. Follows the Java packaging naming. Required! (R4 Spec)

Bundle-SymbolicName: org.foo.shape• Bundle-Version – bundle version number

Bundle-Version: 2.0.0 Only valid value!

04/11/2023 39

OSGi Version Number Format

• Version number is composed of three separate numerical values plus an optional qualifier

1.0.0.alpha

Major Number Minor Number Micro Number Qualifier

04/11/2023 40

OSGi Version Number Examples

• 1.0.0.beta is newer than• 1.0.0.alpha• 1.0.0 is older than both Higher Version

1.0.0 1.0.0.alpha 1.0.0.beta 1.1.0 1.1.1 1.2.0

04/11/2023 41

OSGI Metadata Captures

• Internal bundle class path – the code forming the bundle

• Exported internal code – explicitly expose code from the bundle class path for sharing with other bundles

• Imported external code – external code on which the bundle class path depends

04/11/2023 42

Code Visibility – Standard JAR File

• JAR file with a Main-Class attribute in the manifest file

java –jar app.jar• No Main-Class attribute

java –cp app.jar org.foo.Main• Page 250 (iBook)• Standard JAR files are implicitly searched.

04/11/2023 43

Code Visibility - OSGi

• Internal Bundle Class Path– The Explicit search is called bundle class path– List of locations to search for classes– Locations define in the bundle manifest file

Bundle-Classpath“An ordered, comma-separated list of relative bundle JAR file locations to be searched for class and resource requests”

04/11/2023 44

Bundle Class Path – Internal

• Internal class path using Bundle-ClassPath• Specify a list of paths where the class loader

should look for classes

Bundle-ClassPath: .,other-classes/,embedded.jar

• Period (.) signifies the bundle JAR file. If period not supplied the framework supplies the period.

• Ordering is important!

04/11/2023 45

Bundle Class Path – External

• External class path use Export-Package– Explicitly expose internal bundle classes to share with other

bundlesExport-Package: org.foo.shape, org.foo.other

Export-Package“A comma-separated list of internal bundle packages to expose for sharing with other bundles”

• Instead of exposing individual classes, OSGi defines sharing among bundles at the package level

• Not every public class contained in the package is exposed to other bundles

04/11/2023 46

Package Versioning

• Every package has a version number. Attributes are used to associate a version number.

Export-Package: org.foo.shape; org.foo.other; version=“2.0.0”

• No version specified, defaults to “0.0.0”

04/11/2023 47

Importing External Code

• OSGi requires bundles to explicitly declaring their dependencies on external code via importing.Import-Package: org.foo.shape

Import-Package“A comma-separated list of packages needed by internal bundle code from other bundles”

• Importing packages does not import subpackages• Not uncommon in large projects the Import-

Package declaration to grow large.

04/11/2023 48

Importing Examples

• Adding attributes to filter packagesImport-Package: org.foo.shape; vendor=“Manning”

• Adding version numberImport-Package: org.osgi.framework; version=“1.3.0”– Note the version range is 1.3.0 to infinity– See Table 2.2 for version range and meaning– No version number, default to “0.0.0” to infinity.

04/11/2023 49

Java vs. OSGi Import

• Import statement in source files are managing namespaces not dependences

• OSGi uses package-level granularity for expressing dependences.

04/11/2023 50

Bundle Growth

• Bundle grows too large over time REFACTOR• Splitting the various export packages into

multiple bundles.

04/11/2023 51

Class Search Order

• See section 2.5.4

04/11/2023 52

Bundle a JAR file or a JAR file a Bundle

• Group discussion

04/11/2023 53

Paint Program

• Group discussion