I’m currently watching Mule 101: Demonstrations of all things Mule tutorial because I was willing to understand the whole Enterprise Service Bus thing. And this tutorial resembles many other tutorials I’ve watched about application servers or PaaS.
What are the differences between Mule ESB and Glassfish Domain Administration Server (for example)?
- You can start multiple applications in a cluster. Checked!
- You got modular architecture containing cohesive atomic services. Checked!
- You got horizontally scalability. Checked!
- Multiple physical servers behind one load-balancer. Checked!
- Interoperability between different language based servers – like communication between Glassfish and IIS. Ok, if you use canonical data model (REST, SOAP, XML) you are not supposed to have great problems. Semi-checked!
What functionality Mule ESB has, which no modern application server hasn’t?
Sorry, for not-so StackOverflow type of question, I understand that comparison questions with no clear answer are not tolerated here.
Each focuses on a different application domain. Mule is as service bus, Glassfish an application container. As you’ve noticed, like many tools these are interchangeable to some extent, but each has different strenghts.
Mule promotes a service-oriented-architecture view. It connects services with each other through configuration. In this it is like a messaging infrastructure like for example JMS, Apache Camel, etc.
In the place of enterprise beans it provides for ‘Components’ which glue the services together. But ideally these are stateless and lightweight. The event-driven architecture tries to implement an efficient solution offering e.g. asynchronous messaging, non-blocking IO and messaging guarantees.
While it is possible to build a whole application inside the ESB the result is more like a Rube Goldberg machine.
Glassfish promotes an n-tier application view. It’s technology addresses each layer of the standard model-view-controller paradigm and many more. It supports very abstract applications, but while it provides adapters for services and messaging, it is either an external standalone service or decoupled (through RMI or IIOP). The design focuses on robustness and security over performance and allows the container to make guarantees for security and reliability on behalf of the components.
You don’t have control over the internal messaging between the enterprise beans, e.g. you can’t re-route the requests, switch to calling beans asynchronously or make performance guarantees.