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

Design Rot

We’ve all experienced that sinking feeling when maintaining a piece of crappy software. Has my change broken the system in some unintended way? What is the ramification of my change on other parts of the system? If you’re lucky, and the system has a robust suite of unit tests, they can offer some support in proving your work. In practice, however, few systems have thorough automated test coverage. Mostly we’re alone, left to verify our changes as best as possible. We might privately criticize the original developers for creating such garbage. It certainly lends a plausble excuse in explaining why the maintenance effort is so costly or time-consuming. Or it might serve as the basis upon which we recommend a re-write. But mostly, we should wonder how it happened.

Read more

Because of it’s emerging significance and my increased interest, I’ll be posting a number of entries related to OSGi. I’ll share some ideas on how OSGi stands to transform enterprise Java software development and application delivery, present some samples that illustrate these ideas, and offer a few opinions regarding the JCP and the various JSR’s that intend to accomplish similar ideals. I’m hopeful that my unbiased opinion will help developers more fully understand the value that OSGi brings to the enterprise. To help you quickly find all OSGi related entries on this site, I’ve created a separate blog category under which I’ll file these posts. I’ve also added a separate page that links to a number of other useful OSGi specific articles, websites, and blogs. If you are aware of an on-line resource related to OSGi, or know of one not on the current list, let me know and I’ll add it.

For quite some time, I’ve felt that the lack of a component technology has left a gaping hole on the Java platform. In fact, this is what led me to begin development on JarAnalyzer back in 2001 in the hope that I could help developers understand the component modularity of their existing applications. It’s also what led me to found Extensible Java in the hope that I could offer some design guidelines surrounding component modularity when developing large enterprise software systems in Java. The idea of a component technology that brings greater modularity to the Java platform is very exciting. This is my first OSGi-related post, so let’s start at the beginning. Why?

The distiction between software architecture and design is subtle, and countless trees have been sacrificed attempting to differentiate between the two. Booch sums it well, pointing out that it’s the cost of change separating the two.

All architecture is design but not all design is architecture. Architecture represents the significant design decisions that shape a system, where significant is measured by cost of change.

Cost of change can be measured in many different ways, and is contextual. Financial cost, technological risk, and derived business value are examples of what might factor into that cost. However you slice it and dice it, the business value of design is to craft a software design that minimizes the cost of change by maximizing adaptability to change.

The ability of software to adapt, however, is not constant. As unexpected shifts in technology and business occur, the original design may not accommodate current needs. Should this occur in an architecturally significant area of the system, the cost of applying the correct change may exceed the immediate business value. As this happens throughout the life of a software system, software design degrades to the point where most change is no longer cost effective, and the temptation to hack a compromised solution is great. As this begins, and continues to occur, the software is beginning to rot.

Fowler discusses Design Stamina Health in making the compelling case that software design is a worthwhile activity. I doubt many of us disagree with his conclusion, assuming that the resulting design realizes the intended goal - that it can evolve. While good software designs are able to evolve based on the known factors today, the unforeseen factors of tomorrow reap havoc on design. I doubt we can ever entirely defeat these forces, but many techniques have been discovered that allow us to craft more adaptable software designs. Object-oriented development, design patterns, software code quality metrics, design quality principles, emergent design techniques such as Test-Driven Development, and Service Oriented Architecture all represent a positive step. Yet for large enterprise software systems, there is still a key ingredient missing in delaying design rot. On the horizon looms a disruptive technology, codename OSGi, that stands to redefine how we think about designing enterprise software on the Java platform.