Transcript OSGi_Triangle_JUG

An Introduction to OSGi:
Creating Highly Modular Java Systems
Simon Archer, IBM
[email protected]
15 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.
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.
Use
Services
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/virgo
Eclipse Virgo is a modular open source application server based
on OSGi. It supports standard WAR files and modular webapps
comprising OSGi bundles.
Questions?