OSGi has been under development for a long time. In recent years it has gained some traction as an Eclipse standard. It provides a modular underpinning for Java component deployment,
OSGi has gained a reputation as an esoteric but robust offering, but also somewhat of a difficult technology to master. The veil may be lifting on OSGi; its use has grown to the point where a useful body of practical knowledge is beginning to emerge.
For example, a look “under the hood” of OSGi was provided at the recent EclipseCon 2012 event in Reston, Virg., where OSGi expert Timothy Ward of Zuhlke Engineering discussed best practices for OSGi in the enterprise. Consultant Ward is an Apache Aries Project Management Committee member.
Among a set of OSGi development tips from Ward are these: Version everything; avoid tight coupling; and don’t try to do too much. OSGi’s bundle structure – which pairs JAR components with manifest headers, is meant to help, but it needs at least as much forethought as object design, if it is to succeed.
- Version everything - The most modular format can still give birth to chaos, if you do not apply the principles of considered versioning. Says Ward: “Un-versioned bundles are like a box of chocolates - you never know what you are going to get.” Proper attention to semantic versioning makes bundles less brittle.
- Seek loose coupling – The story is familiar. Object-oriented code should be modular, cohesive and loosely coupled. The essential drive of services design today is loose coupling. The same is true for OSGi bundles. Says Ward: “Avoid tight coupling. “
- Don’t try and do too much – Conversely, don’t try to do too little with OSGi packages. It is hard to use an API with too many methods and arguments; this carries through to OSGi development. Development teams should not create a huge number of dependencies or many exported packages when working with OSGi bundles. What is a tell-tale sign of trying to do too much? When a manifest that is measured in megabytes, says Ward, “you are doing something wrong.”
OSGi tackles complexity
More on OSGi development
If OSGi is difficult to use, why use it at all? Ward answers the question: “The primary motivation is modularity. If you have a big system it’s very hard to work out everything. Big systems are hard to maintain and understand. ” And the means used to help developers understand Java systems can inadvertently add to the complexity muddle.
As an example of the complexity that OSGi can tackle, Ward shows a schema of the full Java EE application server API. Taken as a whole, that API is useful, yes, but it is very complex. It looks a bit like spaghetti. Says Ward: “There are a lot of dependencies. If you start trying to split things out it starts to really become a mess. Big applications, I assert, are just as complicated as big app servers.” Big applications usually have more external dependencies, he adds.
As a further example of the complexity of integration, Ward cites WAR files. These Web application Archive versions of JAR files can become “bigger than Tomcat” he chides, alluding to the open-source Web server/servlet container. Library class dependencies and multiple library versions he also marks as obstacles to ease of integration.
Module systems for integration
Unquestionably, there are development teams still on the fence about OSGi. Some are waiting for the Java Jigsaw module system to appear with Java SE 8. But the Jigsaw-versus-OSGi ‘’battle’’ may have calmed as Java SE has in the last year made strides to be inclusive to OSGi development methods.
OSGI’s claim to providing modular underpinning makes it a possible contender in emerging cloud application building, where the complexity of provisioning and configuration now sometimes takes a toll. Last year, OSGi advocates created a request for proposals around OSGi for cloud computing.
This year’s EclipseCon featured an OSGi Cloud Workshop where interested parties discussed OSGI in the cloud, likely to be addressed by future versions of the spec. Released last month is OSGi R5 with a slew of new services support and updates. These include support for Subsystem Services, Repository Services, Resolver Services and updates to the JMX Management Model, Declarative Services and Coordinator Services.
This was first published in April 2012