An Introduction to OSGi:Creating Highly Modular Java Systems

Simon Archer, IBMsarcher@us.ibm.com15 November 2010

Who is this guy anyway?• I’m a software engineer, just like you.

• Comp. Sci. degree from the UK, where I learned Smalltalk in the early ’90s. Smalltalk developer in London and then Cary.

• Smalltalk is the perfect programming language (debate later).

• Learned Java in 1996 as demand for Smalltalk began to wane.

• Joined OTI in 1998 and started using OSGi in 1999 when it emerged as a solution for networked devices such as set-top boxes.

• At OTI we worked with automotive customers that wished to build dynamic telematics applications, for which we used OSGi.

• Been involved with Eclipse and Equinox since their inception.

Who is this guy anyway?• Also at OTI, worked on an RFID edge application that tracks

goods as they flow in and out of a warehouse, while communicating with back-end server. All OSGi-based.

• Since 2006 I’ve worked on the Jazz Foundation team at IBM’s Rational division in RTP.

• Jazz uses OSGi on the client (it’s an Eclipse-based application) and on the server using the Equinox Servlet Bridge.

• In February 2010 I co-authored the book “OSGi & Equinox: Creating Highly Modular Java Systems” with Jeff McAffer and Paul Vander Lei. See http://www.equinoxosgi.org.

• Talked about all things OSGi at EclipseCon 2010.

OSGi is a hot topic these days; all the major Java application server vendors have adopted OSGi as their base runtime, Eclipse has been using OSGi as the basis of its modularity story and runtime for at least the past five years, and countless others have been using it in embedded and “under the covers” scenarios. All with good reason.

OSGi is a hot topic these days; all the major Java application server vendors have adopted OSGi as their base runtime, Eclipse has been using OSGi as the basis of its modularity story and runtime for at least the past five years, and countless others have been using it in embedded and “under the covers” scenarios. All with good reason.

From the Preface of “OSGi & Equinox: Creating Highly Modular Java Systems”

What is OSGi?

• OSGi defines a Java framework for building and executing modular software. Leverages Java’s class loading techology.

• OSGi once stood for “Open Services Gateway initiative”, but now it’s just “OSGi”.

• The OSGi Alliance is an independent, non-profit corporation working to define open specifications.

• The OSGi Service Platform Core Specification describes a software deployment and configuration management architecture.

• On the web at http://www.osgi.org.

• There are numerous implementations:– Equinox, from Eclipse, http://eclipse.org.equinox

– Felix, from Apache, http://felix.apache.org

– Knopflerfish, http://knopflerfish.org

The OSGi Framework

• Core framework is remarkably small at just 27 Java types.• In OSGi parlance a software module is called a bundle.

Application > Bundle > Package > Type > Method

• OSGi enables the implementation of loosely coupled software modules.

• OSGi enables the implementation of highly cohesive software modules.

• OSGi enables dynamic installation, update and removal of software modules; no VM restart required.

• But using the OSGi framework is not all that it takes…

Coupling?

• Coupling is an outward view of the number of relationships between a bundle and other bundles in the system.

• Bundles should be loosely coupled.• A loosely coupled bundle is more likely to be

used, reused and tested.• “Don’t make me inflate an entire universe!”• Loosely coupled bundles are simpler to

understand, test, debug change, etc.

Loose Coupling is Good

Tight Coupling is Bad!

Cohesion?

• Cohesion is an inward view of the relevance of the elements of a bundle to one other.

• In a highly cohesive bundle all parts are directly related to, and focused on, addressing a defined, narrowly focused topic.

• Sadly, low cohesive bundles are rife.

• Highly cohesive bundles require careful design to keep them small.

High Cohesion is Good

Low Cohesion is Bad

The Software Crisis

• Yes, there is still a software crisis!

• Many applications are fragile monoliths with poorly defined dependencies, collaboration points and behavioral responsibilities.

• Modularity is remarkably hard without OSGi.

• OSGi enforces good software modularity.

• Modularity, it turns out, is the lubricant of collaboration.

Modular Software, Right?

Wrong!

Manage Dependencies

Encapsulation

• Bundles should be encapsulated from each other.

• Encapsulation enables loose coupling.

• Encapsulation enables the hiding of implementation details.

• A bundle’s API should be split into internal and external.

• Encapsulation at the module level is challenging in Java due to weak visibility rules.

Good Fences Make Good Neighbors

Granularity

• Bundle size matters.• The size of a bundle affects its coupling and cohesion.• Big bundles often have low cohesion and high coupling.• Big bundles are harder to:

– Use

– reuse

– Test

– Debug

Size Does Matter

Plain Old Java Objects (POJOs)

• Bundles should be POJOs (as far as possible).

• While OSGi-defined types exist, you should not create dependencies between your bundles and OSGi types.

• Bundles that are just POJOs are easier to test, use and reuse.

It's bad mojo to pollute the

POJO

OSGi Services

• Bundles can collaborate via the OSGi service registry.• A service is just an instance of a POJO class.• Services are often stateless.• Services must be thread-safe.• Multiple implementations and instances of a service are

common.• Services are dynamically bound and unbound at runtime

by either OSGi-specific wiring code, or the Declarative Services runtime.

UseServices

Not Everything Should be a Service

Importing and Exporting Packages

• By default a bundle can only see java.* and its own types.

• Bundles can export packages to other bundles.

• Bundles can import packages from other bundles.

• At runtime a bundle is only resolved if its imported packages can be satisfied.

OSGi will make your app dynamic

OSGi on the Server?

• It is possible to package the OSGi framework inside a WAR and run it in a servlet container on Tomcat, WebSphere, etc.

• This is what the Jazz Project uses.

• See: http://www.eclipse.org/equinox/server.

• This, and everything mentioned so far is discussed in the book…

http://equinoxosgi.org

Demo Time!

Demo

Interested in JEE?• The Apache Aries Project: http://incubator.apache.org/aries

The Aries project is delivering a set of pluggable Java components enabling an enterprise OSGi application programming model. This includes implementations and extensions of application-focused specifications defined by the OSGi Alliance Enterprise Expert Group (EEG) and an assembly format for multi-bundle applications, for deployment to a variety of OSGi based runtimes.

• The Eclipse Virgo Project: http://www.eclipse.org/virgoEclipse Virgo is a modular open source application server based on OSGi. It supports standard WAR files and modular webapps comprising OSGi bundles.

Questions?