Mule VM Transport

VM Transport is based on in-memory Queues available within Mule JVM. These can also be persisted to Files should we require more reliable storage. These are just like JMS Queues, but with in-memory persistence and embedded message broker. VM transport is useful in the following scenarios:

• Asynchronous communication is desired but external message broker (such as Active MQ) can’t be used. This can be for for performance or non-availability reasons.
• Need to unit-test flow functionality with the help of VM endpoints before they can be replaced with the actual endpoints (such as HTTP, JDBC etc.,). This eliminates the dependency on external transport while letting us test flow functionality.
• Protocol transformation – when a facade endpoint needs to be exposed to the outside world. Lets see the flow below to understand how this facade can be used.

As shown above, we can expose Mule flow with an inbound VM endpoint via HTTP/SOAP/REST facade endpoints. This eliminates the need to have different flows for different protocols.

Lets create an example to understand how VM transport works. We will try to create two flows with a VM outbound endpoint in the vmFlow1 and VM inbound endpoint in vmFlow2. We shall modify payload in vmFlow2 and return the modified payload to vmFlow1. We shall also log modified payload through Logger component. VM endpoints in this scenario will use “request-response (synchronous)” exchange pattern.

We will then change exchange pattern of VM endpoints to “one-way (asynchronous)” and see the change in behavior.

Lets get started. As usual, create a new Mule flow in “Mule Training” project and name it “vm”.

Create a HTTP inbound endpoint with port as “8082” and path as “vm”. Then drag and drop a VM endpoint next to HTTP. Select “request-response” as exchange pattern. Also, specify “vm-example” as Queue Path.

Drag and drop another VM endpoint below vmFlow1. Mule Studio automatically creates another flow named vmFlow2. Select “request-response” as exchange pattern. Also, specify “vm-example” as Queue Path. This ensures messages passed from vmFlow1 are read in vmFlow1 since Queue paths are same.

Next, drag and drop “Set Payload” transformer next to VM endpoint. Specify ” # [ message.payload ] – Modified in VM flow” in the Value field of this transformer.

Finally, drag and drop a Logger component and specify ” # [ message.payload ] ” in its Message field.

Save and run “Mule Training” project. Once Mule Server is successfully started, access http://localhost:8082/vm from brows

We can see “/vm – Modified in VM flow” as output. Here, “/vm” is the payload passed from vmFlow1 and ” – Modified in VM flow” gets appended in vmFlow2.

Now, modify both VM endpoints to use “one-way” message exchange pattern. Mule automatically loads these changes if server is running. Otherwise, save and re-run project.

Access http://localhost:8082/vm again. We can now see output as “/vm”. However, Logger component prints “/vm – Modified in VM flow” message.

This is because vmFlow1 successfully passes “/vm” payload to vmFlow2. However, since VM endpoints are one-way, vmFlow2 wouldn’t return modified payload back to vmFlow1. However, since HTTP by default is request-response, we get to see payload originally received in vmFlow1. Also, we can see that vmFlow2 completes normally with logger component displaying appended string output.

Completed VM flows can be seen here. For further reading, please see VM Transport Reference in Mule docs.