I took the liberty of running JarAnalyzer on the OSGi bundles deployed as part of Spring 2.5.6. These are the JAR files found in the /dist/modules directory. Click the image at right to reveal the relationships between JAR files.

It’s interesting to see the dependency relationships and layering of the framework. Note that there are no cycles. I have always felt a significant advantage of Spring is the way development teams can incrementally adopt the framework. Start using core for basic dependency injection and move up the stack to JDBC and declarative transactions, ORM integration, and integration with your favorite web framework. It’s the flexible architecture of Spring that allows this. I’m guessing that when the Spring team went about modularizing the framework around OSGi, the architectural flexibility already embodied in previous versions of Spring made their job easier.

For those of you who want the more detailed information, you can view the JarAnalyzer html report for Spring 2.5.6 showing a variety of metrics related to design quality.

An image I swiped from MarkMail showing the increase in OSGi related posts on various mailing lists. No surprise that the most popular lists are Felix Dev and Spring-OSGi. The traffic shows the rise in interest in OSGi the past couple of years. Again, no surprise. It does appear, however, that most of the posts are closely tied to development of OSGi products (like Felix and Spring dm) and not from developers leveraging OSGi within their applications. OSGi hasn’t achieved deep enterprise penetration yet, and won’t until we get support from product vendors along with better tooling.

It’s been a while since I’ve posted. Since I joined Burton Group, I’ve spent most of my time over on the APS Blog. I hope to spend a bit more time here going forward. We’ll see if I can pull it off.

InfoQ recently posted a great snippet on the progress of OSGi in the Enterprise. The article mentions SpringSource, who is clearly paving the trail for OSGi in the Enterprise. While other app server vendors are using OSGi to modularize their platforms, they aren’t exposing the capabilities of OSGi to developers. Eventually, they’ll have to, but for now, they are not. That’s too bad.

If you take a step back and look at what SpringSource has done the last six months, it’s significant. First came Spring Dynamic Modules, which I showed in a previous blog entry. Then SpringSource Application Platform. Then SpringSource dm Server. And now the SpringSource Enterprise Bundle Repository. Of all, it’s the bundle repository that may be most important. While it’s been possible for a while to develop OSGi bundles, the dearth of OSGi tools and third party frameworks packaged as OSGi bundles has been a barrier to entry for enterprise developers. The bundle repository made available by SpringSource has removed that barrier.

While the InfoQ article offered a great synopsis of OSGi in the Enterprise, comparing OSGi to Maven is like comparing a Porsche to a Volkswagon. In other words, there is no comparison. OSGi wins hands down, and while offering the comparison might help explain modularization to those familiar with Maven but not with OSGi, it confuses and dilutes OSGi.

InfoQ does sum it up well, though. "…building dynamic, modular applications is where the industry is headed." That’s spot on. And as OSGi continues to penetrate the market, it means great things for the Java platform.

I’ve published a summary of the OSGi survey results on the APS blog at Burton Group. Definitely some interesting numbers. The highlights? 80% said they’ll be developing software using OSGi in the next 6 - 12 months, and almost 90% said they would today if their application server supported OSGi. Those are some convincing numbers! The biggest hurdle to OSGi adoption within the enterprise? No surprise here - better enterprise vendor support, integrated toolsets, and more OSGi resources to help understand the benefits and usage patterns.

There are more details to the survey that I’ve yet to explore, and I’ll try to share with everyone what I find after further crunching the numbers

If you haven’t taken the time to fill out the OSGi survey yet, I have to encourage you to do so. The survey will remain live until June 13th. Your feedback and help is greatly appreciated, and I hope to publish the results sometime in June or July

I’ve created a simple on-line survey to gauge interest in OSGi within the enterprise. I appreciate anyone who can spare a few moments to provide their input. I plan to leave the survey open until May 30th, 2008. At some point, I hope to share the results.

It’s time to move on and show the simple elegance Spring brings to OSGi development using the HelloWorldSpec sample from the OSGi & Modularity post. But first, a little primer on Spring Dynamic Modules. Spring DM is not an OSGi implementation. Instead, Spring DM aims to make working with OSGi easier just as Spring makes the world of Enterprise Java simpler. One of the more striking characteristics of Spring DM is that it removes most your code’s dependencies on OSGi by taking care of the OSGi plumbing. To function in an OSGi runtime environment, the Spring .jars have been packaged as OSGi bundles.

Read more

The .jar file has always been a great unit of modularity on the Java platform. Unfortunately, it also comes with the classpath baggage, and .jar files were never treated as first class components. OSGi is the next generation component platform that will bring greater modularity to the Java platform. In my previous blog, I showed the simplest OSGi components imaginable. Now I want to expand on that slightly by introducing a third component that exposes a key architectural and design benefit enabled by OSGi.

Read more

Lately, I’ve been experimenting more with OSGi, and I want to share some of the examples I’ve put together. The examples involve Felix, Spring Dynamic Modules, and Jetty, though could easily be used with Equinox. Once I’m finished with these exercises, I’m hoping to compare and contrast the different approaches I’ve taken, as well as comparing embedded Jetty with the Equinox Servlet Bridge. I’m a believer that OSGi is a disruptive technology that stands to transform Java development as we know it today.

Read more

For years, OSGi technology has flourished in the embedded systems and networked devices market. Till now, it’s remained a relatively obscure technology for the enterprise developer. Now, in part thanks to Eclipse, OSGi is emerging as a viable and valuable technology in the enterprise.

Read more

← Previous Page — Next Page →