I have always had mixed feelings when using JEE. When I started with JEE around 2000, I never took the standards seriously because of the overhead involved and the superiority of the alternatives that were available. As such, I always used some other framework on a servlet engine. First with own implementations to handle functional separation between user interface and business logic, later using Spring as Dependency Injection framework.
After I discovered OSGi around 2008, I continued the approach using Spring-DM. Spring development however has moved away from OSGi since then in such a way that I either kept using old versions of Spring with Spring-DM or dropped using it completely in favour of plain OSGi Service Component annotations.
In the mean time, I always felt kind of sad that I was not able to use real JEE standards. Especially since the standard developed: with JEE5 and JEE6 the specifications became more modular and added features we needed so badly for our day-to-day software development. But always one step too late for the projects I did. Furthermore, I like OSGi because of its modularity and dynamics which are needed for the environments I do projects in. The base of the JEE standards however remains large monolithic applications which require relatively large downtimes for re-deployments.
And that’s where we are now: we can either use JEE7 standards with one of the implementing containers, or use OSGi. I know that some containers (like JBoss or Glassfish) allow the use of OSGi features on the container, but their focus is on delivering a JEE compliant container, not OSGi. For example: Glassfish itself uses (and runs in) an OSGi container. However, its installation is over 300(!) bundles (without any application), massive from OSGi perspective.
Is all lost for lightweight JEE7 based OSGi?
No. Although the hype for using OSGi in enterprise environments may be gone, it has caused some advantages for the OSGi centred mind:
- In 2008 third party libraries were almost never OSGi aware. Nowadays libraries come often as OSGi bundles or are delivered as such via the Glassfish variants on maven central.
- The JEE7 standard is more modular than before, built on interfaces and the use (from container perspective) of the reference implementations are documented relatively well. This because the reference implementations are used in multiple products. Furthermore, they are all open-source, making it easier to analyse the behaviour in case of doubt.
- There is some standardization around the JEE standards for OSGi via the OSGi enterprise specification.
- There are integration projects, like Apache Karaf, that make an effort to bring all open source solutions for JEE to OSGi.
A couple of weeks ago, a discussion arose about the environment to use for a new project I am involved in. The project developers wanted to go for JEE7 via JBoss Wildfly, but the maintenance organization required lightweight OSGi. I suggested to investigate a solution that allowed the usage of some of the JEE7 standards (in this case JPA/JTA, JSF and CDI) on plain OSGi.
And that’s what I will report about in the coming period.
