Embedded OSGi or Application Bundle

Question

I've just spent the last two days reading up all the OSGi stuff I can get my hands on and I finally think I've got my head around it.

I'm now trying to integrate it with an existing application for many reasons such as 3rd party plugins, automatic updates, not to mention that SOA just makes me happy.

I now have a decision I'm struggling to make, which is weather

1. My entire application should become an OSGi bundle installed by default in the container; or
2. My application should launch an embedded OSGi container and interact with it for all the plugged services.

I'd prefer 1, as this lets me update the application easily and the architecture would be consistent. Of course I expect to have to refactor the application into many smaller bundles. However 2 makes things much easier in the short term, but will become awkward in the future.

Answer 1

Have you looked at the Spring Application server? Doesn't this allow you to manage this stuff?

Answer 2

for option 1) you really don't want your whole application in one bundle - you would loose all the benefit from OSGi - but really that depend on the size of your application.

It really depends where you want to run application and which task you want it to perform. Also you probably want to have some kind of remoting to access the exposed services.

in option 1) you need to enable some kind of http/servlet bundle (there is a bridge that exists) in option 2) you application can run inside an application server so you don't have to worry about that.

The first question you want to ask yourself is about the operational environment. Who is going to run the application? Do they need/want to be trained on OSGi? Are they more comfortable with the J2EE stack?

I think the best option for you is to keep your options open, there is no real differences between 1) and 2) but what is staring the OSGi framework, either your code or the framework code. Your application itself, ie the bundles constituting your application will be exactly the same.

My advice would be not to worry too much about OSGi runtime to start with - but start on OSGi development - nothing stop you from developing "OSGi-style" and running in a standard JRE environment.

Answer 3

I think you want to go with option 1, and have your application consist of a set of bundles inside of an (mostly out-of-the-box) OSGi container.

1. It will improve modularity of your own code. You may even find that some parts of it can provide services of use outside of the original application.
2. It is much easier to use other bundles from inside of OSGi, than from the host application. Because the host application cannot see the bundles' classes (and the bundles can only see what you explicitly expose from the host), you have to set up a pretty convoluted classpath or resort to reflection to call bundles from outside the container.

So I'd say that even in the short run, option 1 is probably easier.

Also, I agree with Patrick's assertion that the bulk of your code does not need to care if it runs in OSGi or in a plain JVM. Especially when using Declarative Services and such the need to use OSGi interfaces and mechanisms from your code is greatly reduced: You just add a few descriptor files to the jar's META-INF.

Answer 4

I would rather go with option 2, Inherently your application is not a bundle, but an application. If you want the OSGi value addition, spawn the OSGi container from within your application. That way, at a future date if you decide to move away from OSGi, you can do in a simple way.