OSGi is a dynamic module system for Java. An OSGi system is a network of components that communicate via defined interfaces. Each component is deployable, manageable, and updatable, with predictable effects on the other deployed components. Each component can be stopped, started, deployed, and undeployed without having to shut down the component host. Sound familiar? This is service-oriented architecture (SOA) in a single JVM… All the goodness of SOA, with none of the badness.
If you are a Java developer, or the administrator for a JEE system, most likely you are using OSGi already. The Eclipse development environment is OSGi-based: Eclipse modules are OSGI components. Almost every application server is based on OSGi: JBoss, Weblogic, WebSphere.
Using OSGi for a business application should affect your design. Most systems allocate technical requirements to components. For the most part, these components live only in the architecture and design. In most all the projects I’ve ever worked on, the deliverable Java code lives in big honkin’ jar files with little or no traceability back to the architecture and design. Inside the jar file, every class has access to every other class, and the internal dependencies end up spreading all over the place. Reasoning about the code base, or pulling out smaller features for reuse elsewhere, becomes very difficult.
In a well-designed OSGi architecture, each logical component from the architecture and design should become one OSGi bundle (the OSGi jargon for component). Clients have access only to the public interface of each bundle; the implementation remains inaccessible. Instead of a handful of big honkin’ monolithic jar files, you end up with many small well-defined bundles. This direct correspondence of one architecture/design artifact (a component) to one development/runtime artifact (a bundle) is what I like the most about OSGi.
Some benefits of a network of well-defined, small components:
- Easy to support different implementations of the same interface. When development starts, you can quickly release stub bundles of the interfaces your team is responsible for; other teams consume your stub bundle to write their own bundles. As you complete real implementations of each interface, your clients can replace their stubs with the real thing, without missing a beat.
- Clients can upgrade only the bundles they’re interested in. With one big honkin’ jar file, every client has to upgrade every time you release, even if they don’t need the defect fixes or new features in this release. With a network of small bundles, each client only gets what they really need.
- An end to classpath hell. The OSGi runtime can host different versions of each bundle.
- Supposing you are a software vendor, you can package your applications as a set of bundles. You can offer a basic cheaper system with a few bundles, and value-added features implemented as extra bundles. Your clients that don’t want or need a NIEM interface, and your clients that want it very much, are both happy.
There are some drawbacks to OSGi for business applications.
- Currently using OSGi with plain ol’ Web applications can take some work. Products like the SpringSource dm Server aim to make this easier. Also, the OSGi Alliance is working on Enterprise specifications to define how OSGi can be used with JNDI, data sources, JPA, etc.
- Java developers have to become a little more aware of design issues. Most Java programmers I work with want to get their features implemented and defects resolved with as little time and thought as possible. This is the very genesis of the big honkin’ jar files I keep mentioning… It takes little time or thought to slam out one more class and add it to the one big honkin’ jar file. This problem should get easier with better tool support. For example, the Spring Tool Suite and IntelliJ IDEA have first-class support for OSGi development.
Caught last 15 of Golf Channel’s new morning show. OMG. 2 reverential mentions of FedEx Cup chase. no such thing, especially on Jan. 3.