Foreword

Getting different applications to work together has never been fun. It’s not sexy, the rewards are limited, and there is no glory. Throughout my career, it seemed as if a stigma was associated with integration—that it was a dirty job, and you pulled the short straw if you were working in this area. Personally, I always enjoyed working in integration, and because enterprises never throw anything away, getting different applications to work together has become an increasingly essential element of IT.

Things really became interesting when the enterprise service bus (ESB) made its debut.

The concepts on which the ESB is founded have changed over time. Since IBM first released MQSeries, enterprises have been sold on the benefits of decoupling systems using point-to-point message queues. When TIBCO brought Rendezvous to the market, it expanded the horizons of messaging by introducing the publish-subscribe model. The Java Message Service (JMS)—born through Sun’s Java Community Process (JCP)—set out to unify the point-to-point and publish-subscribe messaging models. It wasn’t long before enterprises required more than just messaging; they also needed a way to orchestrate messages between systems and perform transformations.

To address this need, major vendors such as IBM, Oracle, and Microsoft built enterprise application integration (EAI) brokers that added message brokering and centralized transformation engines on top of their existing messaging servers. The problem with the EAI approach was that it adopted a hub-and-spoke architecture where all data had to flow through the EAI broker. Although this worked for many applications, enterprises were soon pushing the boundaries of these systems; it became clear that something more flexible, scalable, and distributed was required. Enterprises needed connectivity, transaction management, security, and message routing, and they needed to host services that operated on data moving around their systems. The industry needed the ESB.

With the advance of service-oriented architecture (SOA) in the last several years, we’ve seen confusion unfold about what SOA really is. One affirmation that has resonated well in the industry is that the ESB is the foundation of SOA. The term SOA covers a much broader topic than just technology, but we need technologies like ESBs to realize the benefits of what service orientation has to offer. The ESB provides an anchor point for many enterprises that are braving the nebulous ocean of SOA marketing, vendor claims, and vaporware. The ESB bridges the gap between old and new. It acts as a mediator between application integration and service orientation, enabling enterprises to build new applications and processes from existing technology.

The ESB has gained in popularity because there is a general understanding of what an ESB is; but if you’re still confused, this book will definitely provide clarity. The notion of an ESB involves a common messaging bus that is used to communicate between different systems within an enterprise. Typically, there is a shared messaging format on the bus, and adapters between the bus and back-end applications translate data from the proprietary data formats to the shared message bus format. The power of this model is that applications can share information while being totally decoupled from one another. Additionally, the ESB provides a common platform for handling security, transformations, message routing, transactions, and monitoring. This book does a great job of covering each of these topics and dives deep into the detail of how to apply these features in the real world.

I founded the Mule project in 2003 because I was frustrated by the proprietary nature of products available for building ESB solutions. In 2001, I was working as an architect for a tier-1 investment bank. I was tasked with building a custom ESB-like solution to integrate hundreds of legacy and custom applications. Back then, the term enterprise service bus hadn’t been coined (although by 2002, Sonic Software, Fiorano, and SpiritSoft all staked claim to the term), but what we built was in fact an ESB. At the time, the technology choices were limited; you used either an application server or a heavyweight EAI solution that required a huge upfront investment in infrastructure, money, and human resources. We wanted something lightweight and easy to deploy and manage. Like many enterprises at the time, we built our own abstraction on top of JMS. We discovered early on that building our own was an extreme undertaking and a huge burden on our developers. After that experience, I realized that the industry needed an open source solution built on open standards.

The open source model is the perfect choice for developing an ESB. More accurately, open source is perfect for integration. After all, ESBs are about surfacing, manipulating, and moving data between applications. Application integration is complex on many levels. The permutations of applications, protocols, message formats, environment restrictions, and nuances in the way an application (or even a standard) has been implemented cause system integrators an unholy amount of grief. No single vendor can realistically claim to understand the intricacies of your application environment, so all the proprietary vendors have instead chosen to offer products that make their customers abide by their rules when building an ESB solution. I can say from experience that this quickly becomes a problem when the vendor’s approach doesn’t suit your needs. Sometimes, you want to get into the code and customize for the problem at hand.

By providing access to the source code, open source ESBs can alleviate these problems—but the benefits don’t stop there. By nature, open source projects are developed to be lean and modular. Developers working on the project don’t have time to maintain a huge product, and they want the code base to be accessible to their community to encourage contributions. Given that the use cases for ESBs and integration are so varied, it’s impossible to have one vendor test every scenario. It’s far better to give the code to a community of active users who provide testing and feedback about their experience with the ESB. That same user community has connectivity and message-format requirements far beyond what is provided, so it makes sense to enable the users to build support for the more exotic protocols. These extensions can then be committed back to the project for the benefit of the rest of the community.

Since the Mule project was founded in 2003, many open source ESBs have emerged. Each has its own way of doing things, and each focuses on different areas. As examples, Apache ServiceMix is built on Java Business Integration (JBI), whereas Apache Synapse is built around the Web Services (WS) standards, and Apache Tuscany uses the Service Component Architecture (SCA) standard. Mule takes a pragmatic approach by embracing these standards without forcing the use of any of them, giving the user a great deal of flexibility when building an ESB solution.

Choice is usually a good thing for consumers, but with so many choices, it can be difficult to navigate the landscape of open source ESBs. I believe this book is a valuable resource for those looking to choose an ESB and wanting a stronger grasp on how to implement an ESB using open source projects. I found the case studies in section 3 particularly useful because they pull together many of the concepts learned throughout the book.

This book guides you through a logical journey of discovery and demonstration to deliver a solid understanding of the core ESB concepts and how you can use them in the real world. I think that armed with this book and the wealth of open source projects available, you’ll be ready to take on any ESB project. Open source has made ESBs a lot more interesting. Go and enjoy yourself!

ROSS MASON

Co-Founder & CTO, MuleSource, Inc.

Founder of the Mule Project