Foreword

Enterprise service bus is a loosely defined term, and lots of products are claiming to implement the ESB concept. This concept is covered in depth in the first chapter of this book; in short, the goal is to provide a distributed and reliable mediation framework that the different systems in an IT environment can use to communicate, thus removing the need for a given system to know how to talk to the others in a specific way. Integration, which is what ESBs are about, is complicated: Each time you add a system, it needs to talk to all the other systems, and ad-hoc integration between the systems has long been considered a bad solution.

The concept of EAI emerged as a solution, but it led to another set of problems related to using a hub-and-spoke architecture, where a single system, the EAI broker, becomes the center of the system and a single point of failure. The next step of this evolution led to what is now known as an ESB: Data and exchanges are conveyed from system to system in a single logical bus, decoupling all the systems from each other. This leads to a much more maintainable system and can save a lot of time in the long term.

Integration technologies are becoming commodity software, and the rise of open source integration frameworks is becoming increasingly important. Open source is now unavoidable; who would think about paying for an XML parser? ESBs aren’t at this point yet, but most of the underlying technologies in the integration world are available as open source projects, from JMS brokers to SOAP stacks to ESBs. Companies generally use ESBs to convey sensitive data, and they sometimes need advice when they’re developing the applications hosted in the ESBs or when they’re putting these applications in production. Even if you don’t immediately think of commercial support and open source together, this is one of the main reasons it’s important to have companies that can provide consulting, training, and support for such projects; this requirement is now filled by a huge number of open source projects.

In this book, you’ll learn how to use two different open source products classified as ESBs. Having committed on both Mule and ServiceMix, I think both projects are awesome and mature, have good communities, and are backed by vendors that can provide the needed support. By reading this book, you’ll see that even if the two projects have different configurations and sometimes different ways of solving the same problem, you’ll be able to solve your problems with both.

One of the key differentiators is that ServiceMix implements the Java Business Integration (JBI) specification. JBI defines a framework to connect components and make them talk together in a standard way. In the JBI world, components can host business logic (a BPEL engine or a rules engine) or handle a particular protocol (HTTP, JMS, and so on). The key benefit of JBI is that new components can be wired easily on the bus, because they all abide by the JBI specification. For example, ServiceMix doesn’t provide a BPEL engine by itself; instead, you can plug in any JBI-compliant component for BPEL (such as the one provided by Apache Ode).

Even after you’ve learned how to configure and use ServiceMix, at the end of this book, you won’t dive too far into the JBI API. The JBI specification doesn’t target end users, but rather is intended to be implemented by ESB vendors and other software vendors that want to integrate their products in a JBI-compliant environment, such as a BPEL engine, a business rules engine, a transformation engine, or another specific technology. This is, in my mind, the key benefit of JBI.

JBI 1.0 has some shortcomings: the JBI packaging and classloader architecture, the mandatory use of XML everywhere in the bus, and the fact that writing a JBI component isn’t easy. But being part of the Expert Group for JBI 2.0, my hope is that those shortcomings will be addressed in the next version of the specification—or even earlier, in ServiceMix 4, which is briefly discussed in the appendixes of this book.

That’s why open source is so attractive: The feedback from the community provides vital input for the next major version of a product, and this usually leads to better and more innovative products. Enjoy this book and learning from Tijs and Jos how to work with Mule and ServiceMix in a wide variety of integration challenges. You’re also invited to work with the community on making these open source ESBs even better!

GUILLAUME NODET

Principal Engineer IONA

Project Lead Apache ServiceMix