Open Source ESB - The Best Choice for SOA

What can we learn from this?  A few things:

• SOA isn't dead - it's more relevant than ever.
• SOA works - top down SOA adoption does not.
• It's time for an SOA solution that can be successfully implemented  - without the massive ROI risk and naive drop-everything adoption model.

In today's competitive economy, efficient, intuitive automation and integration of business processes is always a mission critical concern. SOA isn't just an architect's pipe dream - it's an essential step forward that organizations must make if they want to stay competitive and agile despite growing complexity in their business model and IT footprint.

Implementing SOA means solving two sets of problems - technical problems related to the actual architecture, and strategic problems, which describe the day-to-day process by which the SOA plan will be carried out.  In this article, we'll show you how SOA built on Open Source ESB integration platforms, such as Mule as an ESB, offers the best solutions in both of these areas.

First, let's take a look at how Open Source SOA beats heavyweight proprietary solutions at the technical problems of integration.

In traditional SOA solutions, these complex functionalities are usually all handled by a central "broker" server.  All messages are then be passed to this single server, which is responsible for every aspect of integration.

This is a bad model for several reasons.

First, a broker model creates a new single point of failure, and then gives it in the most mission critical role in the entire infrastructure.  If the broker becomes overloaded (which is not hard, given that it must handle the entire integration and routing process for every message sent on the network), the entire infrastructure loses the ability to communicate.  Clustering could eliminate this problem, but it is difficult, because duplicating that much complexity is an expensive proposition (not to mention the high per-CPU license fees charged by most proprietary vendors).

Second, using one central server to handle communication between all other network creates a far from ideal situation for organizations whose networks are spread across a large geographical area.  To avoid latency, these organizations must spend additional time and money developing a method of federating their network into geographical zones, once again duplicating all of the complexity of the broker hub, not to mention the increased cost of bandwidth.

Finally, and most importantly, proprietary brokered SOA solutions simply don't make sense for the task of integration, because the nature of the task is contrary to the business model of the companies that sell them.  A good integration solution is one where any component from any vendor can connect seamlessly with any other component, no matter how old, obscure, or specialized.

It doesn't make sense to rely on a single vendor to support competing products in addition to their own, or to consistently maintain support across versions - and if they can be, it will cost you every step of the way.  In some cases, it would be easier to build your own adaptors for certain software, but without access to the code, you're completely locked in and reliant on the vendor.

In response to the failures of the broker model , a new architecture emerged - the Enterprise Service Bus, or ESB.

Enterprise Service Bus architecture allows the de-coupling of various integration components and basing their integration capabilities on open standards, rather than closed proprietary formats.   These changes provide a number of advantages:

• No single point of failure - integration work is distributed across the infrastructure
• bottlenecks in specific parts of the integration flow can be eliminated by clustering only these components, instead of duplicating the entire hub to solve a single problem
• Modularity gives you the ability to use an integration "platform" model, rather than an integration "provider" model in your SOA - your integration architecture only needs to be as complex as your scenario demands, allowing much more agile, tailor-made solutions
• Support for open standards, such as JMS, XML, JCA, and JBI ensures interoperability while allowing for insight and input into future development

If you would like more in-depth information about how ESB takes the complexity out of application integration problems, visit our article ESB: The Next Step in Enterprise Application Integration.

Open Source ESB Makes Sense for SOA

The advantages offered by ESB architecture have made it the de-facto strategy in the industry for SOA-enabling integration scenarios involving more than three systems.

The success of ESB has resulted in a flood of ESB "products", both open source and proprietary.  When choosing an ESB solution, it is important to remember that ESB is not a product - it's an architecture.

Some proprietary ESB "products" are in fact re-factored versions of the same vendor's legacy broker-model EAI software.  These products maintain strong links to the top-down SOA model, and as such, often favor interoperability with the vendor's other offerings (SOA registries, web servers, databases), and suffer from performance, integration, and tooling problems if third-party components are added.

By contrast, open source projects like Mule as an ESB leverage the power of open standards and open source communities to avoid these issues:

• Mule as an ESB is designed with stability, re-usability, and modularity in mind - open source developers rely on the strength of individual pieces of code to provide easy points of entry for other community members.
• Mule as an ESB is agnostic to format, and compliant with standards - Mule as an ESB supports more data formats and protocols than any other open source ESB, including support for both proprietary formats and open standards.  Additionally, unlike some open source ESBs, which sacrifice interoperability in favor of compliance with a single standard, Mule as an ESB supports all major open messaging standards, but is able to pass data in native formats, transforming it or enhancing it only as needed, for improved performance and simplicity.  ESBs that subscribe to only one standard require all data to be "normalized" into a standard-compliant format, adding an additional step to the integration chain.
• Mule as an ESB's open source community is made up of hundreds of users and developers with real-world integration problems, who rely on Mule to solve them.  If a developer needs to support an obscure format, and writes a new connector to do so, they can then contribute the connector back to the codebase.  Likewise, if a problem is found, while MuleSoft offers 24/7 fast-response support for enterprise clients, often times the bug will be quickly identified and fixed by the community.  This ensures that Mule as an ESB's components are always streamlined to solve real-world problems in an efficient, stable manner.

Even though there are right and wrong ways to do SOA, all successful approaches involve a nontrivial amount of planning and strategy.  In this section, we'll look at how choosing an open source SOA solution like Mule as an ESB can help make this planning more manageable for your organization.

As we discussed in the introduction to this article, as many as 80% of top-down SOA initiatives fail.  Top-down SOA advocates often dismiss these statistics by leveling blame at the organization, rather than the failed top-down approach.

Generally, these statements center around a critique of the organization's "culture" - that the organization in question did not successfully execute a shift to "virtuous" SOA-friendly methods.

But let's get serious.  There's no need to use a soft factor like "culture" to account for the success of certain initiatives when so much more revealing factors can be analyzed.  The 20% of companies that were able to implement SOA using a top-down model weren't successful because they had "superior" cultures to the other 80%; rather, they possessed certain qualities as a result of their existing business scenario which made such a disruptive strategy feasible.

Let's look at some of the big poster organizations cited by top-down SOA advocates.  The companies that succeed at top-down SOA usually have a few things in common:

• Millions of dollars in cash to burn on half-decade-long slash and burn initiatives
• Huge development teams (and the reputation and salaries to easily attract new all-star talent)

These factors are what enable these companies to ride out the huge cost and risk outlay associated with traditional top-down SOA.  Rip and replace means no worrying about legacy integration.  Cash and developers to spare, combined with strong hiring pipelines, provide the efforts with a comprehensive safety net, much more maneuvering room when choosing solutions, and a possible means of speeding up progress if the initiative begins to lag.  Even given these benefits, many organizations commonly presented as SOA success stories still experienced a great degree of difficulty when they tried to roll out their new architectures, due to lack of understanding at the user level and all-at-once deployment without adequate testing.

While some organizations may have the time and money to make a big risky bet on top-down SOA, the majority of organizations do not.  Furthermore, many organizations that are in a position to try a traditional approach are wisely hesitant to proceed, given the extremely low success rate of the top-down SOA model.

Open source ESB integration platforms such as Mule as an ESB solve the strategic problems of SOA by enabling a new approach - SOA from the bottom up.  Open Source ESB means all the power of a proprietary integration platform, but without the price tag, and including all the benefits of open source - visibility into the source code, extensibility, modularity, and a focus on real-world integration problems.

Using Mule as an ESB, your development team can:

Start building lightweight, robust SOA-minded projects right away, using only the components they need

• Expose and integrate any existing systems as services, prolonging the life of your current investments while preparing you for an SOA-minded future
• Become intimately familiar with the integration platform that will serve as the backbone of your SOA before rolling out any massive changes, while quickly solving the real-world integration problems currently plaguing your infrastructure
• Work on SOA at a pace that makes sense for your organization's needs, without a massive ROI wager hanging overhead and the license clock ticking.

Mule as an ESB's robust, flexible integration capabilities, next-generation message routing and processing, and fast, intuitive learning curve have made it the most used open source ESB in the world, with over 1.5 Million Downloads and over 2,500 production deployments by leading organizations such as Walmart.com, Nestlé, Honeywell and DHL, as well as 85 in the Global 500 and 5 of the world’s top 10 banks.

If you would like more information about how organizations are using Mule as an ESB to do SOA the right way, check out this article - "SOA From the Bottom Up - The Best Approach To Service Oriented Architecture".

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:

• Mule Enterprise Security
• High Availability
• DataWeave