Something I talk about in our Architect’s course is the structure of the ESB and how this relates to Mule and a Mule topology. Often, people think of an ESB as a single box on a diagram and then assume that they would have one single Mule running in their enterprise which represents that single box.
This is not the case.
While Mule is an ESB, and while an ESB is represented using that single box on your diagram, this assumption is wrong. At the heart of any single Mule application is one or more services like this one:
A simple enough service but there are two key questions that I want to ask you:
1 – Is this service reading in information produced by another Mule service or not?
2 – This service writes information out to a file. Will this be read by another Mule service or not?
In both cases, you cannot answer the question without knowing a bit more about the application, the use-case and what we’re trying to achieve. Let’s assume that this service reads from, and writes to, another Mule service. Do we know if these other Mule services are inside the same Mule server or not?
We do not.
In fact, all three Mule services do not have to be inside the same Mule server. In such a scenario, we could have three Mule servers each running a single service and all passing data to one another. The services will function just as well if they were all inside the same Mule server of course, so why would we want to do this? Why would we want to have multiple Mule instances?
1 – Resiliency. By having multiple Mule servers each focused on a single integration task, you can ensure that a problem with one server will not affect the others. Imagine two Mule servers in a company; one integrates data between a CRM and a production JMS server, the other integrates information aggregated from a UI and a set of foreign web services. If the JMS server is offline, a number of exceptions will cause that Mule server to behave erratically. Depending on your circumstances, this exception may even be fatal. If your entire Mule is affected, all integration is affected. On the other hand, if you kept both integration tasks separate (in separate Mule instances) an exceptional condition in one will not affect the other.
2 – Performance. If you put all your services in one Mule server, you’ll need enough RAM to keep such a large JVM running. If you spread this over multiple Mule instances, the load is spread and easily managed. (This makes sense if every Mule instance is on a separate machine)
3 – Security. If you need to place a Mule instance into a different network segment because of security restrictions (like a DMZ perhaps), you may want to place some services into a different Mule instance inside the network so that they can have access to internal resources without requiring a firewall that looks like Swiss cheese.