OSGi DevCon 2008 This short talk summarizes the experiences made after having introduced OSGi technology into a Swing based technical framework for rich client application development called JEF. The framework has been developed within StatoilHydro and mainly supports systems for energy trading. We’ll show examples of code which typically had to be refactored after applying OSGi technology and briefly get into the changes to development, build and test processes. This short talk should be of interest to anyone planning to apply OSGi technology to existing projects or code bases.

1. Introducing OSGi technology to existing
projects
Nils Hofseth Andersen
Managing Consultant
Capgemini

2. | Technology Services
In collaboration with
About this Short Talk
 Experiences from projects Capgemini has done in
collaboration with StatoilHydro. 3 months project
experience condensed to less that 10 minutes.
 So in one hand you have your existing project. In the other
hand you have OSGi technology. Where to go from there?
Which challenges to expect?

3. | Technology Services
In collaboration with
First: Why did we introduce OSGi?
Client
Information
Systems
 Several Swing rich client applications – working with data from several
information systems. The need for modularity/isolation on the client
increases.
 By using Equinox we’re one step towards a transition to Eclipse RCP

4. | Technology Services
In collaboration with
Reorganizing the source code
“System”
v2.1
Logistics
Client
v1.0
Logistics
Domain
v1.1
Client
Framework
v2.1
Operations
Client
v2.0
 We split the system into components, based on high level
functionality, which we wanted to be version able
independently of each other
 This typically means reorganizing the source code in the
source code control system.
 If your system contains parts which are highly cohesive with
little coupling, this is easy. Otherwise…

5. | Technology Services
In collaboration with
One thing to keep in mind
 A few large components means less flexibility
 Many small components means high administrative overhead
Complexity/Adm
Component Size

6. | Technology Services
In collaboration with
Refactoring the source code
Client Framework
Modules (bundles)
 From static linking of modules
– to dynamic discovery of bundles (extender model)
 Reduced couplings between the framework / modules

7. | Technology Services
In collaboration with
Build System
 Moved from Ant to Maven+Ant
• Mainly due to
 Better versioning and dependency support
 A standard repository for several concurrent versions of our components
• Also started using the pom files as our main project definitions, and
to generate Eclipse project files from the pom files.
 Not using PDE, but rather bundleize the code during the
build with BND.
Component, e.g.
“Accounting”
BND
properties
Bundles
Maven

8. | Technology Services
In collaboration with
Testing & Deployment
 More emphasis on integration testing in order to verify the
bundle configurations (Manifests). Our applications are
Spring based (even the clients), so we can use Spring
Dynamic Modules for integration testing.
 We are still using Java Web Start for the client applications,
but the JNLP files needs to be modified since the client runs
in an OSGi container.
 So far the deployments on the server side has not changed
much. The server code is packaged as web applications, so
WebSphere takes care of the isolation required.

9. | Technology Services
In collaboration with
Changes for the Developers
 We wanted to make OSGi usage as transparent as possible
• Maximize time spent on solving business problems
• Minimize time spent on technical complexities
• Not using PDE in our kind of projects
 One reason OSGi “hiding” works for us is that we have very
similar public interfaces for all the client modules, and little
need for individual tuning of the Manifests.
 Currently more changes has risen from the switch from Ant
to Maven / POM’s

10. | Technology Services
In collaboration with
Summary
 Most areas of the software development environment
needed modification
 Code changes was kept to a minimum, mostly thanks to the
fact that our code already was fairly modular. Parts of the
client framework had to be enhanced to handle the dynamic
nature of OSGi.
 Our goal is to benefit from OSGi on the client side without
directly interacting with it, similar to how we indirectly use
OSGi on WebSphere 6.1.