Choosing the right integration and ESB platform

August 2 2011

8 comments 0
motif

This is my final post in a series of to ESB or not to ESB articles where I have attempted to shed some light on what an ESB really is and show some alternative architectures for performing integration.  I’ve given an overview of four main architectures that I saw most often and provided some context about the benefits and the considerations of each.

Previous Posts:

An ESB is an architecture, not a product. ESB architecture is best suited for integration projects that include a more than a few applications and plans to role out for even more applications.  An ESB architecture is typically selected for strategic projects where the upfront cost of developing the architecture is part of the planning. Pros: Well defined architecture, decouples systems, easy to extend and scale. Cons: upfront cost to create the canonical message and define the message adapter architecture.

In a Hub and Spoke architecture, all systems integrate from a single location; the Hub. Usually, work the hub works with application data formats directly; no canonical message. The state is maintained in a shared database. To scale the architecture, the hub is clustered. Hub and Spoke architecture is a great way to get started with integration, such as a proof of concepts and smaller integration projects or to serve as an integration layer for an application. Pros: easy to get started with. Cons: hard to manage over a few integration points.

architecture is used to decouple clients from backend systems, which is good for modernizing legacy applications, refreshing existing SOAP APIs, migration of backend systems and unifying data sources.  API layer is also used to publish data such as reference data, and lookup data form flat files, databases, even Excel spreadsheets. Pros: decouple systems and creates a common interface. Cons: REST APIs are not easy to get right and hard to change.

Grid architecture is good for high-transactional or data processing tasks that can be parallelized. Having ESB-like capabilities can help feed data into the grid from different sources. Typically this type of architecture is used for processing structured data where as Apache Hadoop would be used for unstructured data. Pros: easy to scale using commodity hardware. Cons: Generally stateless, applicable to a small set of problems.

Architecture then technology

The very first post about when to use an ESB was sparked by people choosing an integration technology before understanding the architecture they needed for their project.  Once you have a high-level understanding of your needs, it makes it much easier to reduce the number of vendors to choose from.

Why Mule?

The architectures listed in this blog post series have one thing in common, I have seen them all implemented successfully by our users and customers multiple times. One of the key benefits of Mule is that it was architected to be a loosely couple integration platform that can be wired together into different integration scenarios using configuration, not custom coding. This means your architecture can evolve over time and morph to the needs of your applications and grow as the scope of the project changes.

Light-weight

Mule is one of the smallest integration platforms out there with the fully loaded distribution weighing in a paltry 40mb. It is modular by design so you can use Maven to strip out unwanted modules if you need to reduce the footprint. For me light-weight isn’t just about size it is also the cost of making changes to existing integrations; how much heavy lifting do you need to do to make changes. The Mule run-time offers modularization and super-fast hot deployment as well as a configuration model that makes it easy to re-order and add/change functionality. Furthermore, you get Mule Studio so that you can do it all in a graphical Eclipse environment.

Scaling down

Integration architectures are all well and good but what if you just want to do some quick point-to-point integrations?  Mule is lightweight and easily embeddable, it allows you to embed the Mule runtime in your App Server such as Tomcat, JBoss or WAS or just embed it directly in your application or JUnit test case. This is powerful; it means you can create unit tests for your integrations, run on your laptop and incorporate into your continuous build.

Message agnostic

An unsung feature of Mule is the container is message agnostic; this means it does not force XML messages on its users. While XML is common, there are many scenarios where you will want to use JSON, flat files, Cobol Copybooks, binary and file attachments, streams and Java objects.  What’s more is that Mule streaming allows developers to process large messages efficiently.

To the Cloud

If you’d rather leave the application architecture, hosting and monitoring of your integration to a company that lives and breaths integration 24×7 then CloudHub is for you.   is an integration Platform as a Service that gets you up and running in minutes. It offers a multi-tenanted, elastic platform with connectivity to 40+ SaaS, Social Media and infrastructure services and the ability to connect to your on-premise applications. A nice benefit of CloudHub applications is that they will also run on Mule Enterprise and Mule Community, so you are not locked into a commercial platform.

Follow: @rossmason@mulesoft



We'd love to hear your opinion on this post

8 Responses to “Choosing the right integration and ESB platform”

  1. So which architecture does Mule support / build on? or is it an entirely different thing? Can you provide a diagram for how Mule works similar to one of the four illustrated?

    Agree(0)Disagree(0)Comment
    • Hi Henry,
      Mule can be deployed in each of these architectures. We are starting to ratify them internally with a view to providing more detailed documentation around how to implement each scenario.

      Agree(0)Disagree(0)Comment
  2. […] one of the previous blog posts by Ross, “To ESB or Not to ESB“, he did a great job in outlining the two basic integration architectures: “Enterprise […]

    Agree(0)Disagree(0)Comment
  3. I have used servicemix and there was no canonical message format, is servicemix a bus, or only hub and spoke? what is the difference between hub and spoke and bus? can mule be only hub-and-spoke but not bus depending on usage? if so what changes mule used as hub-and-spoke into full blown bus?

    Agree(0)Disagree(0)Comment
    • Hi Kazik,

      ESB and Hub n’ Spoke are integration architectures, integration platforms are used to implement these styles of architecture. Proprietary ESB vendors offered limited ESB products to provide mediation between applications and nothing more. The big vendors have different products for doing API publishing, Hub n’ Spoke, ESB and Grid deployments. This means that they can theoretically sell you more, but what it results in is the end customer having to install, manage and run many bits of middleware that require different skill sets. New offerings like Mule provide a platform approach where you are not tied into one architecture and provides a common platform with full management capabilities and data center footprint for talking all integration problems. We also offer an integration Platform as a Service (iPaaS), Mule iON, that provides cloud-based integration using the same Mule platform under the covers.

      Agree(0)Disagree(0)Comment
  4. Hi,

    Does mule support Cobol Copy book format, since i dont see any transformers…

    Agree(0)Disagree(0)Comment
  5. […] Choosing the right integration/ESB platform […]

    Agree(0)Disagree(0)Comment
  6. Hi,

    How does mulesoft address the API layer integration pattern. It seems the examples are largely based on asynchronous message consumption – what about synchronous (REST, for example)? will MuleSoft take care of some of the QoS concerns (security, guaranteed delivery, etc)?

    Agree(0)Disagree(0)Comment