Understanding integration from a "needs-based" perspective - Mule vs. Servicemix / Fuse ESB
ESB is an architecture, not a product. Two integration solutions that both call themselves "ESBs" may in fact take completely different approaches to achieve the same goal (and in some cases, they may disagree as to where the goal is located).
For this reason, when choosing between ESB solutions, it is important that organizations focus less on the title of ESB, and more on the specific needs that different approaches to the architecture are designed to address.
When discussing integration needs, technical issues such as support for specific message formats or patterns are what immediately come to mind. However, other factors fall into this category as well. These may include: expense, the solution's roadmap, project timeline vs. ease of use, specific business needs, and more.
In other words, while some amount of features list comparison is necessary when deciding between two integration solutions, it is much more useful to create a prioritized, big picture list of "needs" a given solution must meet, and compare top contenders against this list.
A "needs-based" look at ServiceMix / Fuse ESB
ServiceMix is an open source ESB project from Apache. Fuse ESB is a commercial version of this project. Like most ESBs, ServiceMix and Fuse ESB take a standards-based approach to integration. However, an important difference between Servicemix/Fuse ESB and other ESBs, which helps to clarify the needs they are designed to meet, is that the ServiceMix/Fuse project places a higher value on support for the JBI standard than any other standard.
JBI, or Java Business Integration, is a JCP-created standard that dictates a standardized message format and deployment model for all the components of a network. While originally supported by a number of large vendors, and designed to offer a standardized method of writing integration code that was modular and portable within the Java platform, JBI quickly lost momentum, as most organizations could not afford to halt mid-step and make a shift to a rigid new "standard" that did not meet more complex needs out of the box. Eventually, most of the original vendors abandoned the standard, and removed or downgraded their products' JBI support. Thus, JBI is now used in only a handful of integration projects, including ServiceMix/Fuse ESB.
One way to think about JBI is as a "container for containers," an additional layer of abstraction and components in which every element of the network must be encased in order to communicate. JBI accomplishes this task by requiring that each message created by a component be "normalized" - converted from its native format into XML - before it is received by other components. Other characteristics of the standard follow the same rigid model - configurations must usually be written in WSDL, rather than any other format, orchestration is heavily skewed to favor use of BPEL, and more.
As a committee-created standard, JBI has suffered from many outside problems, aside from the limits of its capabilities. The foremost of these is lack of adoption. Most successful JSRs are developed to meet an existing unmet need, with adoption driven by the fact that they represent a tailor-made solution.
In contrast, the JSR in which JBI was outlined attempted to convince a complex landscape of vendors and organizations with completely different integration needs and philosophies, and expensive frameworks already in use, to adopt a single new standard, which was understandably immature. Adoption of JBI as a ubiquitous standard has been hampered even further by the fact that one of its major value propositions is interoperability between different vendor's components, which the lack of adoption has made a moot point.
As ServiceMix / Fuse base their support for standards almost completely on their support for JBI, the primary "needs" they meet are ones related to strict support for this standard. Thus, organizations may choose ServiceMix / Fuse ESB if their current developers have previous experience with JBI.
Additionally, an organization may go with these projects if they feel that their integration needs would be best served by adopting the JCP standard, and their budget/roadmap allows for the potential of extensive in-house modification/extension of functionality beyond the generalized standard in the future.
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 Servicemix/Fuse ESB is the Mule project's "standards agnostic" approach to integration. Strict adherence to a single standard can look simple on paper, but as many organizations have discovered the hard way, mixed skill sets, infringing deadlines, and complex, snarled legacy infrastructures often make this approach unfeasible in the real world.
With these concerns in mind, Mule is built from the bottom up with real-world integration power as the number one goal. Thus, Mule provides seamless support for JBI containers, allowing components of ServiceMix and other implementations to be used alongside Mule's simplified architecture if necessary, without restricting developers to the JBI model. Instead, Mule uses a simple, POJO and XML-based architecture and configuration which boasts one of the smallest learning curves in the industry thanks to its similarity to standard Java.
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:
- Does not restrict developers to single arbitrary standard
- Simplified POJO-based programming model leveraging existing developer skill-sets for fast deployment
- Support for multiple access points such as JMS, JDBC, and SOAP
- 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: