Understanding integration from a "needs-based" perspective - Mule vs. JBoss ESB

Creeping timelines and a mission critical need for integration can result in a snap decision for the product with the best looking pitch or the most outlandish integration claims. However, the history of SOA has shown us that making uninformed decisions about integration is one of the most damaging things an organization can do to their infrastructure (and their IT budget).

The key to a smooth, logical integration discovery process is simple: take the focus off of the product pitches, and focus on your organization's integration needs. Finding a solution that meets your requirements for timeline, fits your budget, aligns with your roadmap for future growth, and is a good fit for your organizational culture should all factor into your decisions just as heavily as the technical requirements. A solution that can't be implemented in time or which throws an organization into financial insecurity is not a solution at all.

For this reason, one of the best ways to cut through the vendor noise and define the differences between one integration solution and another is to think about their features from a needs-based perspective. In other words, what needs is this product really designed to solve? How do those needs match up with my organization's needs?

A "needs-based" look at JBoss ESB

JBoss ESB is an ESB-style integration offering from the makers of JBoss Server. The project originated in 2006, when JBoss acquired and open-sourced Rosetta, a proprietary ESB project from the early days of the architecture. Rosetta was acquired in an attempt to speed up the development of the JBoss ESB, as the JBoss community had been requesting an ESB-style integration solution that integrated with the rest of JBoss's products (application server, JEMS, etc.) for some time. By re-using components of Rosetta, the community was able to build a JBoss-friendly ESB much more quickly.

JBoss ESB must be deployed on the JBoss Java EE web server, and offers tight interoperability with other JBoss technologies such as JEMS and JBossMQ. Because the JBoss ESB is designed to operate in conjunction with other JBoss products, its release schedule tends to be tied to these products. The JBoss ESB roadmap is often less aggressive than that of other integration products.

In order to achieve tight integration with other JBoss products, JBoss ESB utilizes an arbitrary integration architecture, which is standards based, but differs significantly from most other ESB offerings. As such, it serves a much smaller community of users by design, and does not benefit from either the clear, real-world integration focus of platforms like Mule, or the familiarity factor of an approach that strictly adheres to a specific standard such as JBI. For this reason, JBoss ESB is generally considered to have a steeper learning curve than other integration products.

If the number one item on your list of integration "needs" is a solution that is tightly coupled with the JBoss portfolio, JBoss ESB may be a good choice.

Mule as an ESB - Meeting real world integration needs

Mule as an ESB is the world’s most widely used enterprise service bus, with over 1.5 million downloads and 2,500 production deployments. With Mule as an ESB’s simplified development model and lightweight architecture, developers can be productive in minutes, easily creating and integrating application services. Mule as an ESB takes the complexity out of integration, enabling developers to easily build high-performance, secure, multi-protocol interactions between heterogeneous systems and services.

A major difference between Mule as an ESB and other ESBs such as JBoss is the Mule project's demonstrated bottom-line commitment to meeting real-world integration needs. Many approaches to integration (strict adherence to a single standard, interoperability with the rest of a vendor's portfolio, etc.) look good on paper, but cause major problems when organizations try to implement them in production.

A variety of factors cause these solutions to fail - architectures that force developers to work within unfamiliar standards in the name of strict compliance to arbitrary standards, prohibitive cost that places harmful and unnecessary strain on the integration initiative, an all-or-nothing model of integration adoption that makes it difficult to follow battle-tested best practices for incremental integration, and more.

By contrast, Mule is built from the bottom up with real-world integration in mind. Organizations choose Mule when their number one need is "an integration solution that quickly solves our current problems, and prepares us for the future." Mule's rock solid standards-compliant, format-agnostic approach to integration, active open-source community of integration specialists, and aggressive roadmap make it the integration platform of choice for organizations that take a "big picture" approach to their infrastructure.

Some of the real-world integration benefits of Mule as an ESB include:

Support for more than 30 protocols and technologies
Simplified POJO-based programming model leveraging existing developer skill-sets for fast deployment
Support for multiple access points such as JMS, JDBC, and SOAP
No reliance on vendor-specific proprietary protocols
Ease of use – services can be configured easily in one configuration file.
Extensive data transformations out of the box
Small footprint: memory and disk, no application server required
Integration platform model: highly modular, easily extensible codebase - implement proven patterns and build streamlined solutions to unique challenges

Want to know more about the future of Mule as an ESB?

The Mule development team has released new Development features to the platform, including: