Should I learn OSGi? What's the point?

Recently, I have been hearing a lot of debate around whether it is worth someone's time to learn OSGi.  Doing a simple Google search on "OSGi usability" returns results filled with phrases such as "not easy to use", "unproductive", "developer burden", and "going away".  However, you will also find that it solves a lot of common issues in the JVM, particularly issues around class loading.  So is learning OSGi worth your time?

What is OSGi?

OSGi is meant to solve common class loading issues that are seen in traditional Java EE environments; it is a set of specifications that are used in the creation of jars with extra manifest information to define dependencies and class loading behavior. These "special" jars are called "bundles", which are the primary packaging structure for OSGi-enabled applications.

Think about a large Maven project, for example. Often you will come across dependency chains where multiple versions of the same dependency are built into the same application - your system then will choose the dependency that is listed first and load that one (typically alphabetically.) This can cause behavior that is different between development and production, if the ordering changes at all between the two environments. Wouldn't you rather be making that decision yourself, or leave it to a skilled architect?

In an OSGi application, if your service is exposed to 2 different versions of the same package you are required to specify which version to use. Conflicts must be resolved, meaning your build, or potentially the startup of your service itself, will fail  (depending on where the dependency issue is).

OSGi is meant to be modular, and bundles typically have high cohesion and loose coupling.  Each bundle performs its own function, and another will do something different. Bundles are encouraged to interact to each other through exposed and imported types on the class path, and through services (shared instances of a class with a managed life-cycle.)

Benefits of OSGi

• Modularity - Code is broken down into very small chunks, making it easier to reuse code later.  In addition, many third party applications already provide bundles that can be used in your application.
• Less downtime - OSGi containers such as Karaf allow for the stopping, updating, restarting, etc of a single bundle without taking down the whole application (assuming that it is properly designed). In addition, multiple versions of your code can run at the same time on the same container. Keep in mind if you are exposing your services on URLs, the URLs for each service version must differ; otherwise, you'd never know which version of the service you are trying to hit.
• Isolated class loading - If you build a service that needs one version of `org.json` and build a second service that needs a newer version of that same package, you can have both versions deployed in your container at the same time without causing class loading conflicts. Since the versions for each dependent bundle will be specified and loaded as defined in their individual manifests, OSGi will ensure that the correct version is provided to each.
• Fine-grained import/export control - When creating a bundle, both import and export packages are defined.  'Import' packages are what your bundle pulls in from other bundles, while 'export' packages are what your bundle makes available to other bundles that depend on it.  Instead of having all the code in your bundle exposed to other bundles, you have control to pick and choose what is visible to your consumers.

Downfalls of OSGi

• Developer burden & Learning curve - I mentioned this above, and it is truly a downfall worth mentioning; learning OSGi is not easy. It takes time to understand how class loading works, and why you are running into dependency chain issues.  For those coming from a Java EE background, the learning curve can be steep.
• Compatibility of Spring Dynamic Modules (DM) - The use of Spring is fairly common in enterprise projects, so compatibility with Spring is important. Although the use of a pure XML spring implementation is supported in Fuse 6.2, the annotation based implementation of Spring is only supported through Spring 3.x, not Spring 4.  In Spring 4, Spring DM was removed.  This means that getting an annotation based Spring implementation using Spring 4 to run on an OSGi container is not only a pain, but nearly impossible and unsupported.
• Technical risk & Client burden - Not all architects, production support groups, or clients are willing to take a risk on OSGi if they know nothing about it.

How is OSGi related to Micro-Services?

Recently there has been a lot of buzz around Micro Services being the future of integration.  While that may be true, OSGi is the gateway to micro-services.  What is OSGi's focus?  Modularity, class loading control, and small services that have a very focused purpose or even just a single purpose.  That sounds a lot like micro-services.

The main difference is that micro-services are expected to each run in their own containers allowing for more control over development and updates, whereas an OSGi container might be host to multiple services.

Why is OSGi relevant to Red Hat?

Red Hat's JBoss Fuse is an open source, lightweight, and modular integration platform with a built in Enterprise Service Bus (ESB). Fuse has traditionally run on Apache Karaf, an OSGi container implementation, which has historically meant that most consultants and developers working with JBoss Fuse had to also learn OSGi; however, Fuse 6.2 allows the ESB to run on Karaf or JBoss EAP - a Java application server with a light-weight modular core. OSGi is not required.

This is not without limitation, as running on the EAP Camel subsystem places some restrictions on Apache Camel components - some are and some are not compatible. The JBoss R&D teams have put some effort into fully impementing OSGi in JBoss EAP, but there has been some debate over whether or not this will continue.

Conclusion

Learning OSGi is definitely worth your time, just don't get caught up in the details (at least in the beginning.) First, focus on learning something that takes advantage of OSGi, like Camel.  It has flexibility to run in both OSGi and Java EE containers, so even if you decide OSGi is not for you, you'll still have learned something useful.

Then, once you have gotten your feet wet with some basics, start slow and with simple examples for OSGi.  Pay attention to the modularity, class loading, and concepts of OSGi rather than looking at how to configure a complex project to run in Karaf. Even if the future is micro-services, learning and understanding more about modularity and class loading will help will all of your future Java development.