The image below illustrates that there are three alternatives for integrating systems: a custom development without any special tools or framework, the use of an integration framework, or the use of an ESB.
That integration frameworks can help developers integrate systems in a standardised way using EIPs has already been explained. However, developers frequently also encounter situations where it makes sense to use one of the alternatives.
The custom development approach is suitable for small applications because it is the simplest and fastest to use. In such developments, the source code is simply implemented via the Java standard APIs. For example, code that reads and processes data from a file or sends a JMS message can quickly be generated and easily maintained without an integration framework. In addition, small utility libraries such as the Apache Commons IO or the Spring JMS Template can be used. For small integration tasks, these are, in most cases, preferable to an integration framework.
For more complex integration scenarios, an ESB can be used instead of an integration framework. ESBs are significantly more powerful, but also more complex than integration frameworks. Furthermore, ESBs offer extended features such as a registry, a rules engine, BPM and Business Activity Monitoring. If these features are required in addition to the actual integration, using an ESB is advisable because it will allow the entire integration process to be handled within one stack. Combining several small frameworks to build a custom ESB is usually unnecessary and can introduce numerous extra pitfalls.
In addition to "big" proprietary products and product families such as Oracle's Fusion Middleware or IBM's WebSphere, there are also various open source ESBs such as the Camel-based Apache ServiceMix, Talend ESB and JBoss SwitchYard, or the Mule ESB and WSO ESB. The two categories mainly differ in that most open source products, including the integration frameworks presented above, are developer-driven and flexible. The proprietary ESBs, on the other hand, tend to be significantly less flexible, because the "development" work is handled almost exclusively via graphical user interfaces in these products. In return, commercial ESBs tie perfectly into the rest of their manufacturers' product range. Magnus Rydin and Olof Åkesson impressively demonstrate the difference in effort that is required to integrate a simple XSLT transformation with ServiceMix (implicitly with Camel) and with the Oracle Service Bus. The Talend ESB is an open source product that is similar to the proprietary products in terms of its user interface. Whether it is appropriate to use an open source product or a powerful proprietary ESB must be re-evaluated for every new project.
And the winner is...
... each of the three integration frameworks. They are relatively easy to use – even in complex integration projects. They all have one big common advantage: the same concepts are used regardless of which technologies are required.
The various DSLs are one of the major advantages of Camel. However, its numerous connectors, the easy creation of custom connectors and its very large community also speak in favour of this framework; therefore, Camel is the top choice in most cases. Mule is a good alternative if a project requires connectors to proprietary products. Due to the weaknesses mentioned above, Spring Integration should only be used if components are to be integrated into an existing Spring project and if the small number of available connectors is sufficient. However, as Camel also offers good support for the Spring framework, there is, in most cases, no particular reason for using Spring Integration.
Whatever the ultimate decision may be, it is important to understand that a lightweight framework is often sufficient and should be chosen over a powerful, complex and expensive ESB whenever possible.
Kai Wähner is an IT consultant at MaibornWolff et al GmbH. He specialises in Java EE, SOAs, cloud computing and Enterprise Architecture Management.
- Gregor Hohpe, Bobby Woolf; Enterprise Integration Patterns: Designing, Building, and Deploying Messaging Solutions; Addison-Wesley, 2003.