You may have seen vendors try to sell you ESB by showing you a long box labeled ESB, with all your systems and applications hanging neatly off the sides.  

 

In reality, ESB architectures are much more sophisticated than this.  ESBs are made up of a number of interoperating components, such as adaptors, messaging services, connectors, frameworks, service containers, and more, depending on how many different formats and systems must be integrated, and in what manner.  If the use case is especially complex, the ESB will take on some additional complexity by necessity.  

 

For this reason, a successful ESB solution should also provide a means of accomplishing this scaling in a graceful, unified manner.  Some ESBs, like Mule, handle this task very well.  Others look good for simple situations, but can't hit the curve balls.    

 

One thing that sets Mule ESB apart from competing ESB offerings is that although Mule does everything an ESB is expected to do at the most basic level - mediation, orchestration, routing, messaging, management, processing, etc. - it doesn't stop there.  Mule isn't "just" an ESB - it's an integration platform, allowing you to quickly create elegant, lightweight integration architectures tailored to your specific use scenario.

 

Since the beginning, the Mule project has maintained a focus on creating stable, standards-based framework and tools that make great integration architecture simple, rather than simply shoving a bundle of ESB-like functions out the door with a price tag.  This conscious decision has allowed the Mule project to better leverage the benefits of doing open-source integration: unparalleled interoperability, extensibility, and flexibility.  

 

In any integration scenario complex enough to require an ESB, using Mule offers you bulletproof integration with the lowest possible overhead, because you can pick and choose exactly which components you need, and easily combine them to handle any pattern that comes up.  

 

Use a specification such as JBI, or don't.  Normalize your messages, or don't.  Already purchased a proprietary messaging server that's working well for you?  No need to rip and replace - keep using it!  Mule's components implement battle-tested best practices and patterns for integration and service orchestration, logically exposing or hiding the services you need from your systems so you can focus on solving your problems, not re-inventing the wheel.  

 

With Mule, service components don't require any Mule-specific code - POJOs, Spring beans, Java beans, web services - Mule lets all these components talk to one another right out of the box. Mule's lightweight service container does the work of managing the components for you, bundling them with configuration settings and exposing them as services.  This ensures that the right information is passed to and from your services, based on the settings you specified for the service in the Mule configuration file.

 

Another difference between Mule and a traditional ESB is that Mule only converts data as needed, because it doesn't make assumptions about message type. In a typical ESB, connecting a new application to the bus means building a new adapter to convert the application's data into a single common messaging format. 

 

Building these new components adds a lot of extra time and effort into your integration project, as well as the additional burden of maintaining an increasing number of custom built components - the same problems that ESB architecture is supposed to solve. Mule handles this problem the right way - let every application talk its own language, and translate only as needed.  

 

With Mule, messages can be sent via any communication channel, such as HTTP or JMS, and are translated only as needed along the way to the endpoint.  This allows the complete separation of service components and business logic from message format, and removes the bottleneck caused by message normalization that plagues other ESBs.

 

Integration is mission-critical.  Mule ensures that no matter what constraints you have to work within - time, money, legacy systems, uncertain requirements - your integration solution will never let you down.

 

Mule's maturity as an integration platform also means you'll never have to worry about whether or not future complexity will render your integration architecture obsolete.  It won't.  Mule already supports more protocols, data formats, and systems than any other open source ESB project, and the Mule community, including MuleSoft's dedicated team of developers, are continually adding to the list.  

 

Click here to read about the future of Mule, including improved core support for HTTP protocols such as RSS and ATOM, more configuration flexibility with annotations and Java DSL support, and improved support for modern messaging formats and technologies such as AJAX, JSON, and Google Guice.

 

Mule ESB is the most widely used open source ESB in the world, with over 2500 production deployments, including leading companies 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.

 

To learn more about the Mule ESB and Integration Platform, visit MuleSoft.org, our open source community site.  

 

Download the latest version of Mule for free, and then jump right in - our easy to follow examples, screencasts, clear documentation, and friendly, active developer community will help you get started right away!