OSGi Surgery with Neil Bartlett @ OSGi DevCon 2013

A number of the Paremus team  will be attending OSGi DevCon and EclipseCon next week and we are looking forward to the all of the great OSGi content and exploring the new venue in Boston.

If you are attending then you may be interested in the opportunity to book a 30 minute one on one slot with Neil Bartlett.  And the great news is that the charge for this is zilch / zero / nada – yes that’s right, no charge at all.


Building a high performance scalable architecture with Scala & OSGi

Skills Matter hosted their first Scala eXchange last month and Dave Savage from Paremus presented on “How to Build a High Performance Scala(ble) Infrastructure in under 5 minutes”…pun intended!

The talk gave an overview and demonstration of a proof of concept that we built for a project to show how you can use Scala with OSGi, and specifically the Service Fabric, to quickly build a scalable, dynamic, extensible and robust application to be run in the Cloud.

It was a lightening talk so there are only 5 slides in the presentation below. However you can see a podcast of Dave presenting the talk over on the Skills Matter website.

If you would like to get your hands on the code to try this for yourselves then please drop us a note.

Distributed OSGi Slides from OSGi DevCon

My colleague, Robert Dunne, presented on Distributed OSGi at the OSGi DevCon last month, run in conjunction with EclipseCon in Santa Clara.  The presentation (below) provided an introduction to the OSGi Remote Services and Remote Service Admin specifications. Robert used the Nimble Distribution, which has our implementation of these specifications included with it, to demonstrate some of the capabilities.

The Nimble Distribution is available for you to try out today in development. Various support options are available for anyone wanting to use Nimble in Production.



If you have any questions you can reach us on or submit a question to Stackoverflow using Nimble as a tag and one of our team will be pleased to respond.

How to make enterprise software Nimble

Chelonia mydas is going for the air by Mila ZinkovaWith the release of the OSGi Enterprise Specification a whole new set of developers will be trying to figure just what the hell you can do with this OSGi technology anyway?

Those who have started to explore it will have found that surprisingly OSGi doesn’t tend (initially) to make development easier, it also doesn’t tend (initially) to reduce the amount of code you need to write. So what then is it good for?

The key feature of OSGi is that it allows for proper modularization of Java software. There’s a lot of good information out there on the interweb about why modularization is important – but the key message is that modularization allows you to decide what are the building blocks of your application. Not at the nuts and bolts level that is Object Orientation and not at the red car or blue car level that is SOA, but at the intermediate level of engines, tires and gearboxes – where most engineers really like to play…

OSGi makes the task of building sets of applications easier. It is not about building one application but about building applications from applications, software reuse, yada yada, or as I like to think of it – turtles all the way down.

All this sounds great, but (more…)

OSGi Dependencies: Heaven and Hell

The road to hell is paved with unsatisfied dependencies

OSGi bundles don’t share code arbitrarily like ordinary jars. Instead they explicitly export the packages they want to share and import the packages they need. Before you can use code from a bundle, it has to be resolved by the OSGi framework. Resolution involves matching each package a bundle imports with a package exported by some provider bundle. The provider bundle also has to be resolved, so the whole process is recursive.

Manually working out which bundles you need to install before the bundle you are actually interested in will resolve can be a long winded process in which you install the bundle you want, try to resolve it, fail, add more bundles in response to the error messages, fail, tear out some hair, add more bundles, and repeat, until finally you get something that works. At this point you can look at the resolved set of bundles and make a note of them and the order you installed them in to make it work. Even then the result is quite brittle because each resolution is sensitive to the state of the framework and to bundle versions. To cut a long story short, doing things this way leads straight to the OSGi dungeon in dependency hell.  (more…)