Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Introducing OSGi Technology to Existing Projects - Nils Hofseth Andersen


Published on

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.

Published in: Technology
  • Be the first to comment

  • Be the first to like this

Introducing OSGi Technology to Existing Projects - Nils Hofseth Andersen

  1. 1. Introducing OSGi technology to existing projects Nils Hofseth Andersen Managing Consultant Capgemini
  2. 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. 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. 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. 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. 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. 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. 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. 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. 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.