As I write this in August 2012, I find it difficult to believe that nearly five years have passed since we officially launched the Spring Integration project. I guess, as they say, time flies when you’re having fun, and I would add that it flies even faster (especially the weekends) when you’re writing a book. For those who have been anxiously awaiting a print copy since this book project was first announced in Manning’s Early Access Program, I hope you find it worth the wait.

One thing is certain: the authors are true subject matter experts. Each of my coauthors has contributed to the framework, and many of the chapters are written by the one person most intimately familiar with the topic at hand. In a few cases, new features were even added to the framework based on ideas that originated in the book. The degree of expertise is most apparent, however, in the frequent discussions about design decisions and the trade-offs involved. In those sections, I believe the reader will fully recognize that the authors’ perspectives have been shaped by real-world experience building enterprise integration solutions.

The first prototype that eventually led to the official launching of the Spring Integration project was a result of two motivations. First, I had been deeply inspired by the indispensable Enterprise Integration Patterns written by Gregor Hohpe and Bobby Woolf (Addison-Wesley, 2003). Second, I quite literally had a life-changing experience with the Spring Framework. I was determined to bring those two forces together in a way that would let them both shine.

Regarding the EIP book, I probably have one of the most well-worn copies, and it’s always within easy reach at my desk. To this day I refer to it regularly, even for something as mundane as settling upon the right terminology to use in code documentation. By the time I first read that book, I had experience with several integration frameworks and containers, and yet I felt that none truly captured the essence of those patterns. I wanted to define an API that would be immediately accessible to anyone familiar with the patterns, where not only the functionality but the vocabulary could be easily recognized.

As for my life-changing experience with the Spring Framework, in late 2005, a fortunate series of events led to my joining the core team. The company behind Spring, Interface21, had recently been established, and as an employee I quickly went from being just a Spring fanatic to being a full-time consultant, trainer, and contributor.

In those early days, I spent a majority of my time on the road. I worked on site with dozens of organizations, trained hundreds of engineers, and spoke at numerous user groups and conferences. Throughout those interactions, I noticed that developers became genuinely excited about the Spring Framework once they experienced the proverbial “aha!” moment. Soon, my primary goal was to elicit a similar reaction from users of a new extension to the Spring programming model that would focus on the enterprise integration patterns. That pretty much sums up why I started the project.

Much of the groundwork for Spring Integration was coded on the go—in planes, trains, taxis, hotel lobbies, and countless cafes. Throughout my travels, I demonstrated the early prototypes, and I processed vast amounts of feedback. My colleagues at Interface21 provided their share of honest feedback, including Rod Johnson, founder of the Spring Framework, who took an early interest in the project.

Interface21 later evolved into SpringSource which was in turn acquired by VMware. Today, I continue to lead the integration efforts within the Spring team at VMware. Now it’s much more common for me to write code at a desk, and in fact the majority of new Spring Integration code is currently written by others on the team. I’ve also been pleased to see the number of community contributors grow, a trend that should lead to many extensions to the core.

Ironically, as the founder of the project, I have a particularly difficult time devising its “elevator pitch.” I suppose it’s always a challenge to avoid verbosity when discussing something that you live and breathe day after day. That said, based on the background I provided here, such a pitch might go something like this:

Spring Integration provides support for the enterprise integration patterns while building upon the Spring programming model. It shares the Spring Framework’s goal of simplifying the developer role as much as possible. This goal is applicable even, and perhaps especially, when the developer is designing and implementing applications that aren’t simple at all. It’s a fact of life that modern applications are increasingly complex since they tend to require event-driven services interacting with data in near-real time across a wide variety of distributed systems. Those are the problems that the enterprise integration patterns address, and applying the Spring programming model to those patterns exposes their full power through a simplified developer experience.

Indeed, Spring Integration enables developers to implement those distributed, event-driven applications. It does so in a way that keeps the enterprise integration patterns in clear focus and maintains the associated vocabulary as accurately as possible. Above all, I hope you find that it does so in a way that lets the developer enjoy the journey and that this book gets you started on the right path.

Mark Fisher