Sunday, March 15, 2015

OSGi : Will these (now) nano-services survive ?

OSGi Reading Survival Guide ?
Last year, I started hearing so much about "micro-services", without reading much about it, i threw a question on Twitter, "Is micro-services same as OSGi ? " . I got an answer from the man who loves starbucks (@starbuxman Josh Long from SpringSource itself ),  that "Nope, OSGi expose services in same JVM but micro-service (usually) does over REST ! "

The first half of the comment I could understand being user of OSGi, but micro-services expose services over REST was new to me (At least around an year back when I started writing this blog entry but never finished!) . Then I realized why Spring Guys are so much for Spring-Boot where servlet container is embedded in the "public static void main" type of applications and that's why Spring Boot helps to create micro-services very quickly.

In order to stick to the title of the blog, let's focus on OSGi. Actually, the name "micro-service" does sound close to OSGi's offering given its nature of "bundle-as-a service". Since OSGi bundles are nothing but small jars exposing services, i thought it would be ok calling those services as "nano-services" compared to Micro-services :)

As far as I understand, OSGi is and was always on the fence whether should be accepted or not (by developers). That's why, I wonder what's the future of OSGi ! If we really try to find out, this division would be really 50-50%. Means 50% developers love it and 50% hate it. And after using OSGi,  I totally can understand why !

Basics of OSGi : As per Wikipedia (it is always good to get official definitions copy-pasted !) - The OSGi (Open Service Gateway initiative) specification describes a module system and service platform for the Java programming language that implements a complete and dynamic component model, something that does not exist in standalone Java/VM environments.  Applications or components, coming in the form of bundles for deployment, can be remotely installed, started, stopped, updated, and uninstalled without requiring a reboot; management of Java packages/classes is specified in great detail.

Under OSGi, all our usual jar files become "bundles". Bundle is self-contained, self-described piece of "service" which exposes its functionality using mechanisms like service-registry. So even if you don't need a particular jar as a bundle, you still have to generate bundle from the jar. There are several ways to convert a jar into bundle with just one command. I am heavy user of Spring Roo which is built upon Felix OSGi container. It contains very easy commands to convert any jar into bundle.

Whole information of the bundle is inside MANIFEST file of the jar. Every jar file has MANIFEST file, but usually ignored in usual monolithic environment of JVM. But in OSGi, it is of high importance and all information of the bundle is configured using this file. For example,

Bundle-Name: Hello World
Bundle-SymbolicName: org.wikipedia.helloworld
Bundle-Description: A Hello World bundle
Bundle-ManifestVersion: 2
Bundle-Version: 1.0.0
Bundle-Activator: org.wikipedia.Activator
Export-Package: org.wikipedia.helloworld;version="1.0.0"
Import-Package: org.osgi.framework;version="1.3.0"

My Experience with OSGi : I personally got very impressed with OSGi's modularity. Other reason was to manage lifecycle of OSGi bundles remotely and installing the bundles in the run-time was good advantage. Not that, we were having very high availability requirement, we could have stopped the server for a second and two and restarted. But still having this provision of getting things done without any downtime sounded a great advantage. Plus the system where we wanted to use it was in need of modularity because we needed several custom parsers to parse different file formats and convert them into our internal format for file processing. Our architect @diligentbytes did great job of finding this as a perfect candidate for OSGi. He used spring-integration and it's "channel" was the service exposed by the bundles and the bundles talked over those channel/services.
Can not find the class ! 

Problems Faced : Since many of jars were using XML based spring configuration, we had a hard time to manage import and exports of the bundle (see Export/Import package headers above) . XML wiring could not be detected by bundlors easily, resulting into missing import and exports in manifest file. Had to deal with several ClassNotFoundExceptions. I started feeling OSGi should be called as CNFE Framework ! :)

So we ended up doing lot of manual editing of the manifest file. It was terrible experience, because as we all know, formatting requirement of manifest file is not so human. It feels like it is machine generated file with limitations of 80 characters per line etc.

Just few facts about OSGi

  1. Equinox is primary OSGi container and there are many like Apache Felix, Apache Karaf etc built on top of Equinox by adding several bells and whistles. There is one called Virgo which was previously called as "DM Server" and  was donated by Spring guys to Eclipse foundation who owned Equinox.
  2. There is something very interesting concept called "Distributed OSGi". OSGi, as mentioned above is modularity inside one JVM process but there was no way to invoke remote bundle's service. This project and reference implementation is the sub-project of main Apache project - CXF
  3. Spring framework guys were big fan of OSGi, but as per verbal information got in SpringOne, developers were always divided on whether to use it or not. So finally they downgraded its use !
  4. OSGi logically fits very good in reusing bundles/services which are common across all applications in the company. For example, separate bundle for logging or database access is nice example.
  5. Same jars with different version can co-exist in OSGi, which can not be done in monolithic java applications.
  6. All major application servers such as Jboss AS, Glassfish , Websphere support OSGi ! 
  7. But having said that, I seriously doubt major companies like Google, Facebook etc have OSGi prevalent. At least I have not come across any blog or article stating such companies are big users of OSGi.
Java 9 - All about modularity ! But who is the winner, OSGi or Project Jigsaw ?

Java 9 inherently has modularity. Initially there was a plan to include OSGi in Java 9 . But the winner is Jigsaw. This article has great overview what is going on in Java 9 for modularity front.  It also describes "Penrose", which is glue between OSGi and Jigsaw. 

Conclusion : OSGi, Go or No-Go ?

When modularity is questioned in Java application, Currently OSGi would be the most popular answer. OSGi's purpose and specifications are fantastic! But trade-off for this advantage is huge. OSGi increases work of the developer by around 5 times. What I felt about OSGi after using it, is exactly depicted in this answer on Quora ! Check the first answer.

Having said that, it is that fact that OSGi has not been taken advantage of from most of the developers community. As rightly said in this question-answer again on quora.

So, I would say, if you are not in real need of modularity on nano-level now, skip OSGi, java 9 might bring it by default, but you will need to wait until 2016 ! 

My tweets on similar topics