Understanding integration from a "needs-based" perspective - Mule vs. Open ESB / Glassfish ESB

When considering ESB for integration, it is important to remember that ESB is an architecture, not a product. Creating a completely standardized model for integration architecture is an inherently complex problem, as the specific set of needs to be solved varies on a use-case by use-case basis.

Although ESB architecture has gradually reached a level of maturity where certain functionalities can be expected from any implementation, the model itself is just that - a model. Technical specifications are one way to differentiate between different brands of ESB, but it is also important to consider other variables, such as overall philosophy, ease of use, the roadmap for future development, and the suitability of a given product to the culture of a company.

For example, if every developer in a company is accustomed to working in the IDE of their choice, a solution which forces a different environment on them can result in large delays, which can be very damaging to a project as mission-critical as integration.

One of the simplest ways to gain a big picture knowledge of the differences between two ESB products is to analyze them from a "needs-based" perspective. This is a two part process - first, an organization should determine the internal needs that must be met for an integration solution to be considered a success. Then, compare the needs that a given ESB product is designed to meet against your list.

When defining your organization's needs, start with basic technical requirements - pain-free connectivity to a given legacy system, compatibility with existing components that cannot be removed, and so on. These may seem like the big questions, but they are actually the easiest to answer - all you need to do is take a hard look at your infrastructure.

Next, move on to the more difficult needs - statements that describe the needs of your integration effort from a strategic perspective. Remember that a solution that looks good on paper but ultimately proves too difficult to implement is not really a solution. Example factors to consider include existing developer skill sets, the development roadmap of a solution, cost, extensibility, timeframe versus the difficulty of developing within the chosen platform, and more.

A "needs-based" look at open ESB / Glassfish ESB

Open ESB is an open source ESB that was initially backed by Sun Microsystems. Glassfish ESB is a commercially supported forked version of this project, integrated with Sun's Glassfish Java EE server. Both Open ESB and Glassfish ESB were designed from the ground up to adhere strictly to the JBI standard. JBI, which stands for Java Business Integration, is a JCP-created standard that was intended to standardize integration component architecture and deployment across the industry, by creating an additional abstraction container to manage these components - a sort of "container for containers."

Two of the main value propositions of this standard were that components from different projects could be re-used within other projects, and that adopting a single framework for all service and integration-related development would standardize skill sets and best practices across the industry. While the standard was delivered with support from a number of major vendors (excluding IBM and Oracle), the limitations of the immature standard caused enthusiasm to wane quickly, and most vendors either greatly scaled back their JBI support or dropped it completely. JBI 2.0 solved some of these problems, but ultimately met a similar fate, overshadowed in part by the growing popularity of the OSGi standard.

As JBI sought to create a standard framework for business integration, Open ESB and Glassfish ESB's adherence to this standard dictates certain practices when developing integration solutions and services. Aside from the requirement that all components be managed within JBI containers and follow JBI conventions such as normalized messaging, rather than native POJO communication, the implementation of JBI used in these containers does not dictate, but is tightly coupled to WSDL description of services.

As a reference implementation of sorts for the JBI standard, Open ESB is also tightly aligned with other JCP-created standards, such as BPEL, to the degree that performing orchestration within Open ESB and Glassfish without additional extensions implies the use of BPEL. As Sun-backed projects, Open ESB and Glassfish ESB are also tightly coupled with other Sun development tools, such as Netbeans IDE and Java EE. In the same vein, as a sub-set of the Glassfish Application Server project, Glassfish ESB must be deployed within the Glassfish Application Server.

Due to the general unpopularity of the standard, OpenESB and Glassfish ESB, along with Apache Servicemix, are some of the last remaining JBI-based projects with any degree of maturity. Although still under development, the acquisition of Sun Microsystems by Oracle in early 2010 has drastically changed the trajectory of both OpenESB and Glassfish ESB.

As the vendors of other proprietary non-JBI ESB solutions, including BEA Aqualogic, Oracle has never supported the JBI standard. Oracle has made it publicly known that they will continue to support Sun's products to protect the investment of former Sun customers and will not force migration. However, new features will be added via integrating components from other Oracle middleware products, with the stated goal of incremental progress towards an integrated middleware portfolio.

Organizations who choose Open ESB or Glassfish ESB may have some of the following needs:

Need for integration with other Sun products
Need to tightly couple their infrastructure to JBI
Need open source solution that will allow incremental migration to proprietary Oracle middleware
Already using Glassfish, and need tightly integrated ESB solution

Mule as an ESB - Meeting real-world integration needs

Mule as an ESB is the world’s most widely used open source 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 Open ESB / Glassfish 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 Open ESB 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.

A need-based look at Mule as an ESB

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.

Mule's modular, pluggable design allows for lightweight, custom-tailored integration development, while providing organizations the agility to expand the capabilities of their infrastructure to meet future challenges or incrementally adopt an SOA in a cost-effective manner.

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: