Mule Inter - App communication in same instance

Question

I have explored the web on MULE and got to understand that for Apps to communicate among themselves - even if they are deployed in the same Mule instance - they will have to use either TCP, HTTP or JMS transports.

VM isn't supported.

However I find this a bit contradictory to ESB principles. We should ideally be able to define EndPoints in and ESB and connect to that using any Transport? I may be wrong. Also since all the apps are sharing the same JVM one would expect to be able to communicate via the in-memory VM queue rather than relying on a transactionless HTTP protocol, or TCP where number of connections one can make is dependent on server resources. Even for JMS we need to define and manage another queue and for heavy usage that may have impact on performances. Though I agree if we have distributed and clustered systems may be HTTP or JMS will be only options.

Is there any plan to incorporate VM as a inter-app communication protocol or is there any other way one Flow can communicate with another Flow Endpoint but in different app?

EDIT : - Answer from Mulesoft http://forum.mulesoft.org/mulesoft/topics/concept_of_endpoint_and_inter_app_communication
Yes, we are thinking about inter-app communication for a future release. Still is not clear when we are going to do it but we have a couple of ideas on how we want this feature to behave. We may create a server level configuration in which you can define resources to use in all your apps. There you would be able to define a VM connector and use it to send messages between apps in the same server. As I said, this is just an idea.

Sherrillsherrington

Answer 1

Regarding the usage of VM as inter-app communication, only MuleSoft can answer if VM will have a future feature or not.

I don't think it's contradictory to the ESB principle. The "container" feature is pretty well defined in David A Chappell's "Enterprise Service Bus book" chapter 6. The container should try it's best to keep the applications isolated.

This will provide some benefits like "independently deployable integration services" (same chapter), easier clusterization, and other goodies.

You should approach same VM inter-app communications as if they where between apps placed in different servers.

Oddment

Thanks Victor. I agree it should keep apps deployed on it isolated. But they should be accessible via end-points. What we see currently on Mule is to be able to communicate between Apps on the same JVM one still has to rely on HTTP or an external MoM like AMQ which will carry the request on JMS. This is what I felt as an overhead. One app deployed on same JVM should be seamlessly able to communicate with another app using VM. They are still isolated but logically integrated if needed. Please correct me if I am stating the wrong. – Sherrillsherrington

The problem with this approach is that clustering would be inherently disabled. You are by design forbidding it. A good approach would be to enable Mule Enterprise Edition VM (that today as today have a terrible name, because it doesn't mean in Virtual Machine transport but in Memory transport) to communicate not only locally between in vm apps but also in the cluster (see the reliability pattern). – Perice

Are you using community or enterprise? If you are not using EE it shouldn't be difficult to write a transport that leverages a shared static ConcurrentLinkedQueue to communicate in VM using the DevKit. I would rather use redis, hornetq or some shared memory system for fast local and clustered communication. – Perice

we are using Community. So for in memory transport (I guess the memory grid stuff) is available only in EE – Sherrillsherrington

Answer 2

Seems that Mule added in 3.5 version, a feature to enable communication between apps deployed in the same server. But sharing a VM connector is only available in the Enterprise edition. Info: http://www.mulesoft.org/documentation/display/current/Shared+Resources#SharedResources-DefiningDomains

Example: http://blogs.mulesoft.org/optimize-resource-utilization-mule-shared-resources/

Fishing