1 / 10

Introducing OSGi technology to existing projects

Introducing OSGi technology to existing projects. Nils Hofseth Andersen Managing Consultant Capgemini. About this Short Talk . Experiences from projects Capgemini has done in collaboration with StatoilHydro. 3 months project experience condensed to less that 10 minutes.

carlotta-feddis
Download Presentation

Introducing OSGi technology to existing projects

An Image/Link below is provided (as is) to download presentation Download Policy: Content on the Website is provided to you AS IS for your information and personal use and may not be sold / licensed / shared on other websites without getting consent from its author. Content is provided to you AS IS for your information and personal use only. Download presentation by click this link. While downloading, if for some reason you are not able to download a presentation, the publisher may have deleted the file from their server. During download, if you can't get a presentation, the file might be deleted by the publisher.

E N D

Presentation Transcript

  1. Introducing OSGi technology to existing projects Nils Hofseth AndersenManaging ConsultantCapgemini

  2. 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. First: Why did we introduce OSGi? Client • 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 InformationSystems

  4. Reorganizing the source code • 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… LogisticsClientv1.0 LogisticsDomainv1.1 “System”v2.1 ClientFrameworkv2.1 OperationsClientv2.0

  5. 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. Refactoring the source code • From static linking of modules – to dynamic discovery of bundles (extender model) • Reduced couplings between the framework / modules Modules (bundles) Client Framework

  7. Build System BNDproperties • 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” Bundles Maven

  8. 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. 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. 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.

More Related