What Does Osgi Solve

why osgi is used?

OSGi provides a modular system with versioning of the modules, and further a bit of life cycle management. It manages dependencies between modules, dynamic/lazy startup/uninstall of modules, lookup/discovery and such.

Part of this will become part of the java language. It enables a lesser complexity than a spaghetti wiring of classes.

Can OSGi help reduce complexity?

OSGi pays off because it enforces modularization at runtime, something you previously did not have, often causing the design on paper and implementation to drift apart. This can be a big win during development.

It definitely helps make it easier to work in teams, if you let teams focus on a single module (possibly a set of bundles), and if you get your modularization right. One could argue that one can do the same thing with a build tool like Ant+Ivy or Maven and dependencies, the granularity of dependencies that OSGi uses is in my opinion far superior, not causing the typical "dragging in everything plus the kitchen sink" that JAR level dependencies cause.

Modular code with less dependencies tends to lead to cleaner and less code, in turn leading to less bugs that are easier to test for and solve. It also promotes designing components as simple and straightforward as possible, whilst at the same time having the option to plug in more complicated implementations, or adding aspects such as caching as separate components.

Hot deployment, even if you do not use it at runtime, is a very good test to validate if you modularized your application correctly. If you cannot start your bundles in a random order at all, you should investigate why. Also, it can make your development cycle a lot quicker if you can update an arbitrary bundle.

As long as you can manage your modules and dependencies, big projects stay manageable and can be easily evolved (saving you from the arguably bad "complete rewrite").

The downside of OSGi? It's a very low-level framework, and whilst it solves the problems it is intended for quite well, there are things that you still need to resolve yourself. Especially if you come from a Java EE environment, where you get free thread-safety and some other concepts that can be quite useful if you need them, you need to come up with solutions for these in OSGi yourself.

A common pitfall is to not use abstractions on top of OSGi to make this easier for the average developer. Never ever let them mess with ServiceListeners or ServiceTrackers manually. Carefully consider what bundles are and are not allowed to do: Are you willing to give developers access to the BundleContext or do you hide all of this from them by using some form of declarative model.

using osgi to develop an application

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:

which other components or Java packages it uses,
and which packages it wants to expose to be used by other components.

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:

What does OSGi solve?
What's the best way to get started with OSGI?
Can OSGi help reduce complexity?
Has anyone found OSGi to be useful in corporate applications?

OSGi: how to ensure classpath consistency?

An OSGi application will not throw ClassNotFoundExceptions and NoClassDefFoundErrors if your manifest is correct. That is, you need to tell OSGi which packages your bundle uses; if you don't do this correctly or honestly, then OSGi cannot help you. In other words: GIGO (Garbage In, Garbage Out).

For example, you use the package org.w3c.dom but you do not list it in your Import-Package statement. Therefore OSGi does not know that you need access to that package, and so when you actually try to load classes from that package, they are not available.

So, you need to make sure your Import-Package statement is accurate with respect to the packages your bundles actually use. The good news is that the "bnd" tool can do this for you by generating the bundle manifest, using bytecode analysis to find all the statically referenced packages.

Update:
Your final question asks how to test that your bundles are consistent before discovering problems at runtime. Bnd has a "verify" feature that does exactly this. Actually if you use Bnd to generate the manifest in the first place, then you will not need the verify feature. However, I don't know anything about your build process so you might find it difficult to move to a Bnd-based build in the short term... in this case it would be relatively simple to add the verification task as a post-processing step after the build. However I would still recommend trying to use Bnd earlier in the build process.

OSGi and application servers

There is (to some extend) an overload of the term "application".

OSGi is a runtime environment (and development model) for modular Java applications. The term "application" in this case can be really, really low level. For example, an application server can be considered such an "application".

Application servers are also a runtime environment (and development model) for Java applications. However, the term "application" in this case typically refers to a higher level application type (eg., web applications). Application servers typically include a rich set of higher functionality and programming APIs for building web applications (Servlets), persisting data into databases (JPA) and clustering capabilities. Most application servers these days are composed of modules (eg., core, servlet engine, EJB container, etc.). Some application servers use OSGi under the covers. Others have their own modular runtime environment which also offers OSGi capabilities.

But it's also possible to develop higher level applications (such as web applications) directly using only OSGi runtime environment. However, an OSGi framework itself does not include any of the additional functionality. It has to be assembled yourself. There are some "distributions" that include a framework and several modules.

In which area using OSGI make sense?

For me, the most important feature of OSGi is the ability to plug/unplug a code module at runtime without stopping the JVM, so the other modules (unless dependent from the plugged/unplugged one) continue to run.

Example, Liferay Portal (7.0+) is built on OSGi because it needs to add/remove features and applications at runtime without interrupting the portal itself.
While, instead, if you need to add a library (even an SPI) to a Spring app, you at least have to stop it, add the dependency in the pom, compile and run again.

There are other advantages in using OSGi (modularity and encapsulation are the key points) but in my opinion this is the main one and I don't know any other java technology that does this.

Anyway, better know that OSGi is not a piece of cake. These advantages have a drawback in a steep learning curve and a lot of try-and-error.
So, in my opinion, the use of OSGi should be carefully evaluated taking all into account.