Watch Ross Mason on Mule and the role of ESBs (17 min)
Asked about how people should generally map requirements to services on a bus, Ross explained:
A requirement might be that's traditionally trades may be handled by back-office entering it manually, they enter it manually into an accounting system that has some sort of interface to the general ledger and it also goes to auditing and reporting. There's quite a lot of manual process involved. There's no consistent path for the information but yet is something that can be automated; once it is automated you can improve it, you can add more functionality, you can get better reporting statistics you can get more reliable and up-to-date information. The requirements are to really use your information more efficiently and free up your resources to be working on other things. How that maps to the actual architecture is the bus is that communications channel to get all those systems to talk to each other. That's the basic need.Recently, the Mule team released version 1.3 in which they devoted a lot of time to performance improvements. While Mule has been known to handle over 1 million transactions a day, they rewrote the Http transport to be more efficient and to support message chunking. Similarly, they have improved the JMS system to manage receiver threads and session caching. See also InfoQ's article on Mule: Evolutionary Integration with ESBs.
In the interview, Ross also revealed that Mule got its name because it takes the donkey work out of integration projects.