I'm developing a semantic-based search application in java. To make the application modular, I thought to use osgi architecture. But since I'm new to osgi, I have no idea about the pros and cons of using it. Can anyone please explain advantages/disadvantages of using osgi and what sort of an application will be benefited by using osgi/ what the application will gain by doing so??
Thank You!!
In a few words OSGi is a standard used to build modular applications. It adds new level of modularity - bundles (aka. components, modules). Each bundle contains classes and interfaces and what is the most important it must explicitly state:
From technical point of view bundles are jar files which have a bit extended META-INF/MANIFEST.MF file. All the aforementioned information is stored in MANIFEST.MF file.
From practical point of view this explicitness has both advantages and disadvantages. For me the biggest advantage is that you are forced to think about your architecture, modules and interaction between them more than in standard applications. This may create better architecture where each module is responsible for well defined tasks and modules can be reused. If it comes to disadvantages, creating a lot of modules may be painful sometimes. It is quite easy to have a lot of modules and if you really have a lot of them it may be hard to maintain all the dependencies between the modules (dependency cycles are quite painful).
OSGi is not only a standard of only building modular applications. It also specifies the environment in which bundles exist and are run. This is something you should be aware of - when using OSGi you must start your application in a special environment. This environment (for example Eclipse Equinox) is responsible for running your application. It provides some fancy possibilities. For example you can add a bundle to already running application without a need to stop this application - this may be a really important element in some types of applications (but IMHO there are not that many application which will really need this).
What is really really important is also a fact that some open source libraries may be not fully compatible with OSGi infrastructure and it may be hard to use them out of the box as it is in standard Java applications (remember that in OSGi everything should be a bundle). However, a lot of popular libraries were wrapped into bundles - for example Spring provides its bundles repository which contains many popular libraries (but not all).
OSGi is quite complicated and it is hard to describe it and its possibilities in a few words. What I wrote are just the most important (IMO) elements of OSGi. But OSGI is much more, e.g. bundles can send event to each other, they can provide services to each other. If you are interested in more details I suggest going through a tutorial. I may recommend this one in Java World. After that you may take a look at this free e-book about OSGi (it contains a lot of details). All the details about OSGi may be found in official specifications but I wouldn't say they are easy to read (at least at the beginning) - you can find them here (before downloading you will have to accept the license and some legal notices).
To summarize I think OSGi is useful while building modular applications but this is for sure not for free. It is rather a heavy standard which may disallow you to do some things and force you to do the things the OSGi way.
Some related SO questions:
My personal (2 years) experience with OSGI is that the technical bill outweighs functional benefits by orders of magnitude.
I have encountered cases were you would have to create/edit 25+ pom files to implement a one liner mock!
Design plays a big part, but I find it troubling that developers become experts in topics (like maven) that have no impact on customer facing value.
Further, this approach does not cope well with Agile. In fact, it would be a great fit for ... Waterfall
It's all about your primary focus IMHO. Deliverables vs Construction Patterns.
For short, OSGI is not evil, but it is not the best fit for small teams and quick time to market.
My personal opinion is that OSGi brings more pain than benefit. If you really need a plug-able application you may start using OSGi, but you need to write the code in a plug-able way, what is not simple at all(even when installing a plugin in eclipse it recommends to restart eclipse, have no idea why it use OSGi)
I developed two projects at work using OSGi, it is very slow at the beginning of the project because you need to wrap a lot of public libraries and not all of them is possible to wrap, because you may encounter a ClassNotDefoundError at run time because of classloader issues when working with proxy objects.
All the modularity which we have in projects which use OSGi may be achieved using just maven, when working with OSGi nobody enforce you to write a lot of fine grained bundles, if you want you may write the hole application in one big bundle.
If we talk about lose coupling between components it may be achieved using auto-wiring from spring-core or google-guice dependency injection framework.
You would need to write a book in order to properly answer that question. Indeed many books have been written on the subject. If you really want to learn about OSGi, I recommend searching for such a book.
OSGi is a Java modularity framework. It does not have any credible competition in this domain. Any application can benefit from being more modular, but modularity isn't free. It is easier to throw everything into one giant classloader and not think too hard about relationships of your components. If you do decide to give OSGi a try, the excellent PDE tooling that's part of Eclipse does support non-Eclipse-targeted OSGi development and makes it a lot easier to work with OSGi.
OSGI is painful to say the least. e.g. The maven-bundle-plugin that creates the bundle does not create the correct bundle all the time in terms of imports, exports etc. Having to hand-craft this bundle definitions would be even more tedious. Once you deploy the bundle(say in Karaf), it will show another list of dependency errors which will all need to be resolved (may times one by one)
