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:
- ESB or not to ESB – original post
- ESB or not to ESB revisited – Part 1. What is an ESB?
- ESB or not to ESB revisited – Part 2. ESB and Hub n’ Spoke Architectures
- ESB or not to ESB Revisited – Part 3. API Layer and Grid Processing Architecture
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.
API Layer 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. CloudHub 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
