Javatech

OSGi – http://www.infoq.com/presentations/colyer-server-side-osgi

This is a very informative talk given by Adrian Colyer – CTO of Interface 21 – on the new OSGi support within Spring 2.5

——————————————————————
OSGi == The Dynamic Module System for Java
In OSGi jars/modules are called “Bundles”
Modules can declare what it provides and what it requires.
Modules can be installed, started, stopped, uninstalled, and updated *at runtime*
Bundles can publish services dynamically.
Publish/Find/Bind – Service Registry allows this

A Brief History of OSGi
- started in 1999, focus on embedded Java and networked devices
- 2003: extended support to mobile devices
- 2004: significant open source community adoption ( Eclipse plugins )
- 2006: OSGi moving into server-side Java

Current implementations:
- Eclipse Equinox
- Apache Felix
- Makewave Knopflerfish
- Prosyst mBedded Server Professional Edition

Paremus?!? Enterprise company using OSGi – who are they?

How does OSGi help me?
- Strong modularity
By default a bundle is a black box and classes are isolated from other bundles.
A bundle can export one or more packages.
Only exported packages are visible outside of the exporting bundle.
Modularity gives : Independent development, easier to maintain, faster development cycles.

- Versioning support
Versioning allows two dependent Libraries A and B to each use a different version of
Library C v1 and v2 with v1 and v2 being incompatible. This is fine so long
as no classes from C are leaked back to your application through A and B.

** What about Singletons in Library C?

- Operational control (life cycle)
With OSGi console and/or JMX you can see all modules and their status
Get information on wiriing
Install/Update/Stop/Uninstall new bundles
Activate bundles ( publishing services in the process )
Deactivate bundles ( unregistering services in the process )
All of the above happen without stopping or restarting the server.

Type-space contributions
Object-space contributions

OSGi WebApps can be written and deployed either as:
1) OSGi bundles in an OSGi-compliant container – but not many of these are open to this, yet.
2) As a more standard WebApp, but using the Embedded OSGi container ( and the ServletBridge )

Spring 2.5 is OSGi ready.

Class.forName becomes troublesome because the Class may not be exported out of its bundle.
Class.forName does it’s own caching of Classes, so the correct version of a class may not be found

OSGi doesn’t have a ContextClassLoader because:
1) it has no notion of “context”
2) is has no notion of “application”
** Solutions
1) Eclipse Equinox’s ContextFinder – this looks up the call stack for the most recent bundle
owned class and uses that bundle’s ClassLoader “which works in many, many situations”.
2) Spring Dynamic Modules: CCL Management

Web Applications
- OSGi HttpService: allows for programmatic configuration. ability to register Servlets/resources
under aliases.
- Equinox Http Registry Bundle: declarative configuration.

What does Spring Dynamic Modules for OSGiprovide? www.springframework.org/osgi
- Bundle needs: instantiating, configuring, assembling, decorating
- Bundle blueprints
- expose bundle objects as services
- wire service references between bundles
- consistent/easy way to manage dynamics
– services may come and go
– broadcast operations
- test environment
- ContextClassLoader management
- Configuration Admin service integration
- Bundle lifecycle management

OsgiBundleXmlApplicationContext
- uses bundle context and classloader to load resources
- implements Spring’s resource abstraction for OSGi
– relative resource paths resolved to bundle entries
– “bundle:” prefix for explicit specification

Instead of a ContextLoaderListener there is org.sfw.osgi.extender bundle
- acts like “ContextLoaderListener”
- automatically creates Spring application context inside a bundle
when a bundle is started. No code or dependence on Spring APIs required!

Creating a bundle – from jar file to Spring bundle…
- start with a normal old jar: mymodule.jar
- add needed headers to META-INF/MANIFEST.MF
- Bundle-SymbolicName: org.xyz.myapp.mymodule
- Bundle-Version: 1.0
- Bundle-ManifestVersion: 2
- place configuration files in META-INF/spring

Exporting a Service:

<osgi:service id=”myServiceOsgi” ref=”myService”
interface=”org.sfw.osgi.samples.ss.MyService”/>

Importing a Service

<osgi:reference id=”aService”
interface=”org.sfw.osgi.samples.ss.MyService”/>

What happens if…?
- there isn’t a matching service? Dampening…
- there are several matching services? osgi:set vs osgi:reference, perhaps.
- a matched service goes away at runtime? Dampening…
- new matching services become available at runtime? osgi:set vs osgi:reference, perhaps.

Relevant JSR’s
———————————————————-
JSR-291 Take OSGi and endorse it on Java Platform
JSR-277 Java Module System ( poor man’s osgi )
JSR-294 Language changes that support Java Module System