We all dream of the perfect software program.

You know the one—it’s composed of multiple modules, each in charge of a specific, tightly defined set of tasks, each uniquely simple and elegant, interacting harmoniously to achieve the complex ends required by the user. We are taught in school how to build these perfect programs using techniques such as object-oriented programming and aspect-oriented programming. These techniques work well, but the end goal is always to make the system more reliable, more testable, more complete, and more flexible by making it more modular so that the whole is greater than the sum of the parts.

Of course, most of the software programs we work with are not perfect—have you encountered any of these issues?

• The big, bad application problem Your application is 600 MB in size and it takes 10 minutes to repackage one Java class and 20 minutes to deploy to your favorite application server. When you do finally get it to deploy, you find you’ve made a mistake and now you have to undeploy, fix, and redeploy—all outside of office hours—missing the soccer and poker night with your mates.
• The brittle-change problem A high-profile customer reports a problem, so you quickly fix the code and try to rebuild the application, only to find that the application won’t build because another component is using the internal function you just changed. When you finally get the application built and deployed, you start getting reports of other parts of the application that are malfunctioning. Working into the night—again missing the soccer game—you discover that the change you made had unforeseen consequences that could only be discovered by running the full QA suite—a process that takes 48 hours.
• The build-the-world problem Your development team is in Beijing, Mumbai, and San Ramon, and each subteam works on different parts of the application in different time zones and on different development schedules. As the team and application grow, you find that it becomes increasingly hard to keep the different parts of the product separate—any time you make a change, you find it impossible to tell which teams will be affected by your changes. The only solution is to keep all the teams on exactly the same version of the application, and to rebuild and retest the entire product every time any change is made. You eventually spend all of your time building and testing the product and none actually developing it. The company goes bankrupt, you lose your job, and now you have plenty of time to watch soccer—if only your widescreen TV hadn’t been repossessed.

These problems are all symptoms of unmodular applications.

As authors, we come from different but related, backgrounds. Arnaud and Thierry come from the enterprise application development sphere, and Andy comes from a middleware product development background, thanks to his jobs at BEA and then Oracle. But we all share the same enthusiasm and passion for Spring technologies and for anything that can help us build better software. Arnaud remembers his first contact with Spring Dynamic Modules—he attended Costin Leau’s (Spring Dynamic Modules’ project lead) talk at SpringOne Europe in 2008. What could be more exciting for a Spring enthusiast than to be able to use Spring on the OSGi platform? At last, real, runtime modularity meets Spring! Unfortunately, there was not, at the time, much in the way of resources around Spring Dynamic Modules. That was when he met Thierry and they both went on to write a French book on Spring. In contrast, Andy in 2008 had already been working with Spring Dynamic Modules for a couple of years, having been involved with its original development and having used it extensively on several BEA products. It was later in 2009 that Manning Publications contacted Arnaud and Thierry to suggest writing a proposal for a Spring Dynamic Modules in Action book.

Working with Manning can be difficult: they have high standards for their books, and we had no idea how high the mountain would turn out to be when we wrote that proposal, which then passed a succession of reviews. Some reviewers were happy with it, but others were tough, like that Oracle guy, Andy Piper. But his remarks were constructive, and based on his feedback Manning suggested that he be involved in the writing process. After all, if you want something done right, you do it yourself! Having a native English speaker on the writing team also proved useful, as some say that the French accent comes across even in written text.

We have done our best to make this book as comprehensive and accessible as possible. We hope you’ll benefit from our experience with the Spring Framework, OSGi, and in making both worlds cohabit as harmoniously as possible using Spring DM. We believe that these technologies are an important piece of the puzzle in bringing your applications closer to the mythical “perfect” program.