Implementation
The ESB architecture has some key principles that allow for business agility and scale. The key focus is to decouple systems from each other while allowing them to communicate in a consistent and manageable way.
- The "bus" concept decouples applications from each other. This is usually achieved using a messaging server like JMS or AMQP.
- The data that travels on the bus is a canonical format and is almost always XML.
- There is an "adapter" between the application and the bus that marshals data between the two parties.
- The adapter is responsible for talking to the backend application and transforming data from the application format to the bus format. The adapter can also perform a host of other activities such as message routing transaction management, security, monitoring, error handling, etc.
- ESBs are generally stateless; the state is embedded in the messages passing through the bus.
- The canonical message format is the contract between systems. The canonical format means that there is one consistent message format traveling on the bus and that every application on the bus can communicate with each other
Integration core principles
Let's take a look at how an ESB architecture maps to our five core integration principles:
- Orchestration: Composing several existing fine-grained components into a single higher order composite service. This can be done to achieve appropriate "granularity" of services and promote reuse and manageability of the underlying components.
- Transformation: Data transformation between canonical data formats and specific data formats required by each ESB connector. An example of this would be transforming between CSV, Cobol copybook or EDI formats to either SOAP/XML or JSON. Canoncial data formats can greatly simplify the transformation requirements associated with a large ESB implementation where there are many consumers and providers, each with their own data formats and definitions.
- Transportation: Transport protocol negotiation between multiple formats (such as HTTP, JMS, JDBC). Note: Mule treats databases like another "service" by making JDBC just another transport (or endpoint) where data can be accessed.
- Mediation: Providing multiple interfaces for the purpose of a) supporting multiple versions of a service for backwards compatibility or alternatively, b) to allow for multiple channels to the same underlying component implementation. This second requirement may involve providing multiple interfaces to the same component, one legacy interface (flat file) and one standards compliant (SOAP/XML) interface.
- Non-functional consistency: For a typical ESB initiative, this can include consistency around the way security and monitoring policies are applied and implemented. Additionally, the goals of scalability and availability can be achieved by using multiple instances of an ESB to provide increased throughput (scalability) and eliminate single-points-of-failure (SPOFs), which is the key objective for highly available systems.
Choosing an ESB platform
There are many ESB platforms out there, from big proprietary vendors to niche and open source vendors. On paper, there are lots of similarities. Here are some points to consider when making an ESB selection.
Lightweight
Mule is the most lightweight integration platform available, with the fully loaded distribution weighing in at 40 MB. It is modular by design so you can strip out unwanted modules if you need to reduce the footprint. We don't see "lightweight" as just about size either; it is also the cost of making changes to existing integrations and the amount of heavy lifting 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.
Not just mediation
Most vendors think of an ESB as purely mediation between systems and have separate products for hosting business logic and publishing services. We see this as unnecessary complexity. Mule provides a light and scalable service container for publishing REST and SOAP services. Since Mule integrates tightly with Spring, it means developers can also leverage the capabilities of Spring to implement business logic.
Accessible - any developer can learn Mule
Mule uses common tools that all Java developers are familiar with, such as Maven, Eclipse, JUnit and Spring. Mule uses an XML configuration model (similar to Spring) to define logic, and custom code can be written in a variety of languages, including Java, Groovy, JavaScript, Ruby or Python. Also, Anypoint Studio helps new developers get up to speed quickly with a graphical development environment.
Scaling up, scaling down
Mule was designed for horizontal scale on commodity hardware - no need for big iron. Mule's runtime is easily embeddable into an application. It can also be embedded in your application server such as Tomcat, JBoss or WAS or directly in your application. More importantly, Mule provides JUnit support so that it can be embedded in a JUnit test case. This is powerful because it means you can create repeatable unit tests for integrations that will run on a developer laptop and can be incorporated into a continuous build.
Message agnostic
A powerful feature of Mule is that 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. Our graphical Data Mapper is equally not fussy about the data that can be mapped. What's more, Mule streaming allows developers to process large messages efficiently.
Cloud ready
If you'd rather leave the application architecture, hosting and monitoring of your integration to the integration experts then CloudHub™ is for you. CloudHub is an integration Platform as a Service (iPaaS) that gets you up and running in minutes. CloudHub offers a multi-tenanted, elastic platform with connectivity to 150+ SaaS, Social Media and infrastructure services and the ability to connect to your on-premise applications. CloudHub applications run on Mule standalone and vice versa. This means that whether you are deploying on-premise or the cloud, there are no new concepts to learn and the developer experience is the same. No need to learn a new way of doing things.
Summary
Most organizations want to increase agility by reducing time to market for new initiatives. ESBs promote this objective by implementing a simple, well defined, "pluggable" system that scales really well. Here at MuleSoft we understand that an ESB architecture is exactly that: an architecture and not simply a product you can buy off the shelf. It encompasses not only infrastructure but application design as well.
Explore the world's most flexible ESB solution, Mule, the runtime engine of Anypoint Platform, and learn how it can help organizations build an architecture based on agility and speed.
