Counting the number of sessions on OSGi, one could get the impression that this is just in its trigger phase of the Gartner hype cycle. But looking a bit closer, this technology does not seem to follow the usual pattern: OSGi is around already since 2000, at that time targeted mainly at the embedded systems world. Slowly but steadily, it has crept into more and more markets. It has by now already proved to be a stable and well-functioning platform for Eclipse and it is used in many software products like IBM Websphere Application Server (WAS) or Adobe Version Cue without anyone taking great notice. How mature OSGi already is, is demonstrated best by the fact that the OSGi Alliance has admitted that the abbreviation OSGi doesn't actually mean anything in special (formerly it should stand for "Open Service Gateway initiative").
So what is OSGi then all about? The OSGi Alliance defines it as a "dynamic module system for Java" and as a "Universal Middleware". It indeed is a component container, specialized on the clear separation of the components and their flexible lifecycle management.
OSGi and Java EE
Originating from the embedded world it is per se lightweight, in absolute contrast to an Java EE compliant application server stack. That should not say that OSGi tries to compete with Java EE, though there are many scenarios where OSGi might be the better (because lighter and leaner) choice altogether. Instead, it can also improve current Java EE architectures by modularising existing EARs and by introducing strict dependency management rules. Using an OSGi container on top of an application server brings benefits like the possibility to transparently replace a module during runtime or to run multiple different versions of a module at the same time.
OSGi and Spring
Talking of lightweight containers, Spring quickly comes into ones mind. Although Spring proponents will argue that one cannot compare Spring with OSGi as both try to achieve different things, they yet do not intervene when somebody says that Spring will be the next Java EE. So as we have already compared OSGi to Java EE, it must be allowed to compare it with Spring likewise. They both are lightweight containers, trying to decouple the parts of a modern software architecture. While Spring tries to reach this goal on a very fine-grained (object) level with dependency injection and aspects, OSGi introduces a rigorous dependency management and a runtime seperation of modules using different classloaders.. Where Spring declares its beans in the application context xml, OSGi declares its exports and services in its manifest. Both containers therefore do similar things - but with quite different means. Both approaches are beneficial for the software architecture and therefore it is legal to say that Spring and OSGi are a perfect match - with the reservation that the configuration has to be merged (and redundancies removed) and that Spring lets itself deploy inside an OSGi container. This is what the Spring-OSGi project is all about, which is scheduled to be released in August.
OSGi and Maven2
Alright, Maven2 is definitely no container by any means, but still it has one striking similarity to OSGi: The profound dependency management with automatic resolution of sub-dependencies and different versions. Maven users are blessed by not having to care about where to retrieve their dependencies from and how to put them all correctly in the build path. The dependency declarations in Mavens pom.xml is very similar to the information in OSGis manifest file. Wouldn't it be great to automatically map this information? Luckily, somebody is already working on this: There is a Maven2 OSGi plugin hosted by Apache Felix, an open source OSGi implementation project. Unfortunately this currently seems to work only one way - to generate manifest information from the pom.xml. Developers who are used to implement Eclipse plugins and therefore like the tool support to maintain the dependency information in the manifest file will still have to find some solution how to sync this information.
OSGi and the JCP
OSGi and its concepts have already a long history in the Java Community Process: Already in 1999 the JSR-8 has been submitted in order to specify OSGi within the JCP. Out of some reason that was withdrawn and the OSGi Alliance did the specification on their own. Currently, there are the JSR-277 and the JSR-291 which address modularity and dependency management (JSR-277) resp. dynamic lifecycle management (JSR-291) for Java. While JSR-277 is trying to do something very similar as OSGi already offers, the Expert Group of JSR-291 has decided to fully adopt the OSGi specification a few weeks ago. It is therefore very likely that OSGi is going to be part of Java 7.
Summary
Whereever there is the need to modularize a complex system or to dynamically start/stop/replace single modules, OSGi is definitely worth a try. There are stable and mature implementations available like Equinox which builds the core of Eclipse, with which it is easy to start and to have some first results in a matter of a couple of hours. Having the JCP now embracing the OSGi specification, it is obvious that OSGi is a key concept for the future of Java in general.
So what is OSGi then all about? The OSGi Alliance defines it as a "dynamic module system for Java" and as a "Universal Middleware". It indeed is a component container, specialized on the clear separation of the components and their flexible lifecycle management.
OSGi and Java EE
Originating from the embedded world it is per se lightweight, in absolute contrast to an Java EE compliant application server stack. That should not say that OSGi tries to compete with Java EE, though there are many scenarios where OSGi might be the better (because lighter and leaner) choice altogether. Instead, it can also improve current Java EE architectures by modularising existing EARs and by introducing strict dependency management rules. Using an OSGi container on top of an application server brings benefits like the possibility to transparently replace a module during runtime or to run multiple different versions of a module at the same time.
OSGi and Spring
Talking of lightweight containers, Spring quickly comes into ones mind. Although Spring proponents will argue that one cannot compare Spring with OSGi as both try to achieve different things, they yet do not intervene when somebody says that Spring will be the next Java EE. So as we have already compared OSGi to Java EE, it must be allowed to compare it with Spring likewise. They both are lightweight containers, trying to decouple the parts of a modern software architecture. While Spring tries to reach this goal on a very fine-grained (object) level with dependency injection and aspects, OSGi introduces a rigorous dependency management and a runtime seperation of modules using different classloaders.. Where Spring declares its beans in the application context xml, OSGi declares its exports and services in its manifest. Both containers therefore do similar things - but with quite different means. Both approaches are beneficial for the software architecture and therefore it is legal to say that Spring and OSGi are a perfect match - with the reservation that the configuration has to be merged (and redundancies removed) and that Spring lets itself deploy inside an OSGi container. This is what the Spring-OSGi project is all about, which is scheduled to be released in August.
OSGi and Maven2
Alright, Maven2 is definitely no container by any means, but still it has one striking similarity to OSGi: The profound dependency management with automatic resolution of sub-dependencies and different versions. Maven users are blessed by not having to care about where to retrieve their dependencies from and how to put them all correctly in the build path. The dependency declarations in Mavens pom.xml is very similar to the information in OSGis manifest file. Wouldn't it be great to automatically map this information? Luckily, somebody is already working on this: There is a Maven2 OSGi plugin hosted by Apache Felix, an open source OSGi implementation project. Unfortunately this currently seems to work only one way - to generate manifest information from the pom.xml. Developers who are used to implement Eclipse plugins and therefore like the tool support to maintain the dependency information in the manifest file will still have to find some solution how to sync this information.
OSGi and the JCP
OSGi and its concepts have already a long history in the Java Community Process: Already in 1999 the JSR-8 has been submitted in order to specify OSGi within the JCP. Out of some reason that was withdrawn and the OSGi Alliance did the specification on their own. Currently, there are the JSR-277 and the JSR-291 which address modularity and dependency management (JSR-277) resp. dynamic lifecycle management (JSR-291) for Java. While JSR-277 is trying to do something very similar as OSGi already offers, the Expert Group of JSR-291 has decided to fully adopt the OSGi specification a few weeks ago. It is therefore very likely that OSGi is going to be part of Java 7.
Summary
Whereever there is the need to modularize a complex system or to dynamically start/stop/replace single modules, OSGi is definitely worth a try. There are stable and mature implementations available like Equinox which builds the core of Eclipse, with which it is easy to start and to have some first results in a matter of a couple of hours. Having the JCP now embracing the OSGi specification, it is obvious that OSGi is a key concept for the future of Java in general.