嵌入式OSGi或应用程序包

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

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 2

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.

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 definitely recommend 1 - the app should become an OSGi bundle(s), and not only because of easy updating. If half of your code is in the OSGi framework and half is outside, you will have to construct a bridge for the communication between the two halves; you could also have issues with classes visibility.

There are also many benefits from 1, and it is not so difficult to achieve. What I would recommend is the following:

• Separate the application in as many modules as it seems logical to you.

You are not forced to have many modules - OSGi can as easily handle two bundles 10 MB each as well as 100 smaller bundles. The separation should be a result of the functionality itself - a good starting point is the UML architecture diagram you probably did before you even started implementing the stuff. The places where the different functional parts communicate with each other are exactly the places where you should think about defining interfaces instead of classes - and these interfaces will then become your OSGi services and the implementations will become the bundles - and the next time you will have to update some part you will find out it is much easier to predict the effect on the other parts of the app because you separated it clearly and declared it in the manifest of the bundles.

• Separate any external/open source libraries you use in separate bundles. They will most probably be the parts that will have to be updated more often and on a different timeline than your own code. It is also more important here to define clear package dependencies, package versions, and to avoid depending on the implementation parts instead of only on interfaces!

• Think about which parts of the app you want to expose to plugins. Then make OSGi services out of these parts - ie publish the interfaces in the OSGi registry. You don't need to implement any specific thing - you can publish any Java object. The plugins will then use the regitry for the lookup.

• The same goes for the plugins - think about what you want to get from plugins and define the respective interfaces that the plugins can implement and publish and your app can lookup in the registry.

• And as a final tip - see what bundles are already available in the OSGi framework you have chosen. There are many standard OSGi interfaces defined by the OSGi spec - for configuration, logging, persistent storage, remote connections, user admin, eventing, and many more. Since they are standard, you can use them without becoming dependent on any specific OSGi implementation. And uninstall what you don't need.

Answer 5

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