Java A Steep Climb? 'Carbon' Will Get You To The Peak
The OSGi Alliance just celebrated its 10th anniversary. Another vendor consortium congratulating itself? Not exactly. OSGi has done a lot to make Java less of a mountain to climb. It specifies simpler, independent modules of code that can be modified, even when the application is running. And therein lies new opportunity.
The OSGi Alliance just celebrated its 10th anniversary. Another vendor consortium congratulating itself? Not exactly. OSGi has done a lot to make Java less of a mountain to climb. It specifies simpler, independent modules of code that can be modified, even when the application is running. And therein lies new opportunity.Once known as the Open Services Gateway initiative and now known by just its initials, OSGi makes it possible to assemble and run Java components remotely. OSGi specs think in terms of bundles, one or more Java components expected to work together. It also thinks in terms of managing services through an entire software life cycle. Hence, it's an enabler of modern service-oriented architecture for the enterprise, Web services, and service configurations on a scale that we haven't seen before.
How does it do this? An old bugaboo of Java is that fact that its programs have libraries and libraries are easily modified. One programmer works with Library A on a project and finds it works with Library B, version 3. Another programmer is modifying Library C, which works with Library B version 3, provided he modifies it slightly for his system. As libraries proliferate, the two programmers are forced to keep track of each other's modifications; soon they start to lose track of what works with what.
OSGi imposes version control on bundles, keeping a directory of what works with what. If a library gets modified, that's a new library and it doesn't work with what the previous library worked with until somebody proves that it does. Java programmers talk about being stuck in JAR hell. What they mean is, they aren't sure of what library version they're working with. OSGi solves that, along with a number of other build and deploy issues.
In its 10th anniversary announcement, the OSGi Alliance cited its big name members and said they were implementing its standards. "Leading vendors using OSGi technology include IBM's WebSphere, Oracle's WebLogic, Paremus Infiniflow Service Fabric... Red Hat's JBoss, SpringSource's dm Server, and Sun Microsystems GlassFish Enterprise Server. SAP AG has announced that it will use OSGi technology..."
Instead of mentioning SAP, however, the alliance might have mentioned a lesser known entity, WSO2, a Sri Lankan and Mountain View, Calif., development firm with many contributors to the open source Apache Foundation on its staff. WSO2 has implemented OSGi in its newly minted Carbon framework, a lightweight, Web service-oriented set of components.
WSO2 has wisely gone back to the roots of its open source product line and rebuilt it around OSGi bundles to allow existing components to be modified, old components swapped out, and new components swapped in --,on a running application. Sanjiva Weerawarana, CEO, says as new modules are added to a Carbon-based application, they inherit the security and tracking mechanisms already in place on the other modules.
As of today, WSO2 offers a Web Services Application Server, Enterprise Service Bus 2.0, Registry 2.0, and Business Process Server. More pieces to come, including a Mashup Server.
If you believe in the principles of OSGi, then take a look at what you can do with these early elements of the Carbon framework. If nothing else, you'll see why, after OSGi, Java will never be the same.